When I place the "nehahra" folder next to id1, launch with -game nehahra, and start a new game, it just gives me a black screen and the console says it doesn't recognize some of the commands. I watched a video and it should be playing a cutscene by that point.

How are you doing the different text colors btw? That's cool. 

You are very welcome. It was a fun video to make and the response has been insane. The algorithm picked it up. Over 100k views and I gained 2000 subs in 2 weeks because it it. For comparison, my next highest viewed video has around 64K views but that took nearly 4 years to get to that. Same with subs, 3000 in 4 years and 2000 in two weeks. Some great timing with this video I guess. 

I missed your response. Need more info. What engine are you using? What version of Neharah?

Also as far as the text colors, that's explained here. https://www.celephais.net/board/faq.php 

To run Nehahra mod in Mark V you must use -nehahra command line parameter, not -game nehahra.

I suggest also getting correct fmod.dll from Mark V page (somewhere in the middle there's a link): http://quakeone.com/markv/

Not sure if running the movie is the same, my guess that perhaps it is. Either way I think you can watch full Seal of Nehahra movie on youtube anyway. 

No worries now, I have it sorted. Great pack too! 

So Matthais Worch is over on the Quake Mapping Discord messing around with TrenchBroom and "updating" Beyond Belief and he's experiencing sorting issues where QBSP will show overlapping brushes with the "back" brush being sorted first. We think this is due to updates in QBSP since he's using GLQuake to test. Could someone point me to where this might have been discussed in the past? And if there's something that can be done in leu of using outdated compilers?

I am curious about it and it would save him quite a bit of work if he could figure it out. 

Assuming you're talking about transparent water - I think Quakespasm doesn't have any alpha sorting at all, things like portals behind water will just be drawn in whatever order.
Other than that I don't understand how QBSP can "show" anything. If two solid brushes were overlapping, only one surface should remain. If two different bmodels overlap you'll get regular z-fighting. 

I wasn't clear. It was late when I posted that.

In these very old maps, Matthias has overlapping brushes that used to display properly without z-fighting. Now the order is reversed and we're trying to figure out if it's QBSP that is the cause and if there's a way to reverse the order of which brush is chosen to display. It could be that he developed these in WinQuake and the rendering order was more "predictable" in that exe.

Some quotes:

it looks wrong in the editor, the brushes overlap. but back then, they overlapped "correctly" to prioritize the desired brush after compile. my maps were full of this stuff

i made everything in wireframe in Quest, couldn't avoid it really

Here's a GIF showing it. 

Still not exactly clear.
So, two worldspawn brushes occupy the same plane, and the smaller one used to take priority but now does not. If that is the problem, it must be QBSP, and whatever goes on in the editor or in the game is irrelevant (Trenchbroom will always flicker, and the game will always only show the face that survived qbsp).

Could be some sorting based on brush size. Maybe it used to be based purely on the order of brushes in the map file. Doesn't seem like there are any switches to disable it though. Probably only coders who have dealt with compilers directly would have an actual answer. 

In my experience, it seemed like the later brush in the map file would take precedence over earlier ones in the map file. So, it could be that editing those brushes re-ordered them in the file (at least in some editors, any modified brush gets moved to the end of the list.)

If he specifically creating brushes in the same order as before (wall then light fixture) and it's giving opposite results, that could be from a change in QBSP. To verify this I guess he could re-compile the unmodified map source and see if it gives expected results or the same problem that the modified maps have. 

I just downloaded Nehahra from Quaddicted through Mark V's console. It worked right away with "game nehahra". 

It doesn't work well though. After playing through a bit of it, I didn't get many of the voices. 

How come more code from Quake 2 hasn't been borrowed by Quake 1 mods?

Case in point; ladders and rotating brushes. Quake 2 got ladders right on its first try 25 years ago, yet AD has those godawful sticky catapult deathtraps. Quake 2 has really easy to use rotating brushes, yet both AD and Quoth both stuck with that horrendously buggy and limited system from the mission packs.

Scrolling textures is another Q2 feature that I'm sure would get a lot of use in Q1.

As somebody who only has some very basic coding knowledge, I'm just curious why these seemingly obvious solutions haven't been borrowed. 

Trying to watch this again :D
It's so long. The voice acting is hilarious. I've tried to watch it numerous times in my life. 

Solved a lot of that stuff engine side - rotatings especially.

Mh did it for RMQ engine, but that was spoiled since nobody wanted the mod.

The main thing is that it's hard to decompile the solutions from Q2 - you really need the source and a reason to do it.

The reason is usually supplied because a mapper wants feature X.

The best mod for mapper features was Q2 Lazarus - physics, weight, monsters improvements, custom monsters, custom monster flags, monster AI (including proper jumping and waypoints), new weapons, trains, drivable vehicles and a load of other stuff. It had (a lot) more features than HL1.

It also, unfortunately, never really had its potential tapped. The handful of mappers who used it just wanted to use the homing rockets flag.

Q1 has had a number of attempts at housing the various features in a single mod. Extras R4, Quoth, AD and the various other megamods all grabbed a few off the mapper wishlist.

Ultimately mappers don't want/use them though, which is a shame.

And yeah, Q2 is hard to decompile and does not translate to Q1 codebase. 

Is more entertaining than the MCU. 

I don't disagree with most of what ijed says, but mappers absolutely do want and use those feature-mods like Quoth, AD, Alkaline, and progs_dump. 

Software Quake prevents z-fighting by making all brush entities be clipped by the world brushes in worldspace. And this is only done against the world brushes, not against other BSP entities, which is why maps such as the ones in Contract Revoked have per-scan z-fighting issues in software Quake engines.

BSP entities such as func_wall are not "worldspawn" entities. Their brushes are stored in the map's BSP, but they're processed along with external BSP entities such as ammo boxes.

But anyway, with current hardware-accelerated Quake engines hitting a thousand frames per second, it's a shame that none of them uses some CPU code to clip the brush entities' polygons against the world like WinQuake did. That would have zero performance impact for the world itself.

Scrolling textures is another Q2 feature that I'm sure would get a lot of use in Q1.
Retroquad has it, using the [ and ] characters in texture names to indicate negative and positive scrolling for both axes.

DP and FTEQW likely supports it in some other way, maybe through Q3A shaders. But I don't remember any engine specifically using Q3A shaders in Q1 map formats. 

Proper rotating brushes would be great, but the Q2 solution relies in the q2bsp format. They store original brushes in there so that the engine can expand them in realtime. If you search for "true rotation" on this board there are conversations about a less painful method. I think those attempts were abandoned due to backwards compatibility. They also have issues due to ignoring the fact that a rotated hull won't give accurate collision.

I think good ladders are achievable in quakec, unless your complaint is the need to place a trigger instead of tagging brushes as "ladder". Probably just needs more code iteration to make it good.

Scrolling textures -- agree on this. An easy feature to implement, just needs an accepted standard, and then an example implementation. I guess the right people never strongly cared. (correction, some engine coders did address it, for example mankrip added it in retroquad I believe. And LordHavoc would probably tell you that darkplaces already supports q3 shaders so just use those.) 

Can't be func_walls, because if that were the case it wouldn't have ever looked correctly, not in WinQuake, and not in GLQuake.
Must be plain worldspawn. 

#32086: coplanar polygon overlapping simply does not exist in the BSP format. Polygons in a model can only be overlapped by the polygons of different models, and for that to happen they must be used in different entities.

dumptruck_ds: does that also happen in this version of Beyond Belief? I'm going to take a look into that later. I know the old release runs in WinQuake, but the newer wip version should run in MarkV WinQuake. 

Also, Z-fighting in the worldspawn model simply does not exist in WinQuake. func_walls does look correctly in it no matter how much polygon overlapping there is against the world model.

As I said, WinQuake clips func_wall polygons against the world polygons in worldspace, killing any overlapping against the world. 

Well yes, coplanar worldspawn brushes will just leave either one face or the other after compiling, that is my point. Either the compilers or the brush order must have changed.

In WinQuake, overlapping func_wall would have been invisible, i.e. the opposite of the desired result. Since it used to look right, it couldn't have been a func_wall. 

A significant percentage of what people want can be achieved by just using the Q2 BSP format. Of course that brings in other things that people don't want, such as storing textures outside the map.

Some of these features were discussed when designing BSP2, but in the end the overriding priorities were ease of implementation in existing codebases and keeping compatibility with the original .map file format. The fact that BSP2 succeeded vindicates this, but I still regret not including a Q3A lightgrid lump.

I need to look over how software Quake clips brush models again. It's been a while but my recollection is that it's not actually that simple, and may have dependencies on faces being converted to spans before it does the clipping. 

Case in point; ladders and rotating brushes. Quake 2 got ladders right on its first try 25 years ago, yet AD has those godawful sticky catapult deathtraps.

AD has 3 ladder systems;
1=Rubicon2 (sticky + jump upward only movement)
2=Extra4 (player facing direction for up/down movement)
3=FTE (uses skin key, works like extra4)

The reason most people use the rubicon2 system because its easy to implement, the source is available and most people understand it straight away (ie don't fall off ladders and die) Probably the best system is the FTE skin system (closest to Q2) because its engine controlled and not hacked by QC progs to fight the engine physics.

I have pestered eric to add rotating brushwork support to Quakespasm for years and at this point I think everyone has just given up because the chance of it breaking something else in the engine is too high! With no universal engine solution everyone just accepts the shite QC Hipnotic version instead. The RMQ and DP/FTE versions are very good, but to really make a difference it needs to be added to the core (QS/Mark/Fitz) engines to really be adopted. Ideally it should be a declared feature so that progs can switch around rotation types.

PS. Tried to login properly, but can't remember password anymore. I had to reply to the AD jab from Text_Fish because there is a lot of history to the reasons why stuff is the way it is!