source/build/src/defs.cpp:3198:56: error: cannot pass non-trivial object of type 'FString' to variadic function; expected type from format string was 'char *' [-Wnon-pod-varargs]
To allow cumulative loading without interfering with other ports, Raze will now look for files called xxxx-raze.def, where xxxx is the default .def name (e.g. duke3d-raze.def for Duke3D.) and if that is found, cumulatively load all same-named files - it will fall back on the default name if no such thing is found.
-def still overrides both and will not cumulatively load.
This was incomplete and just ignored Duke's special music, and the levelnum generation used an outdated formula so that it never managed to assign any music to the maps.
At these places there's some inteference that can bring the engine into an unstable state.
This is not a real fix, just a quick workaround. The actual problem requires closer examination why these are the only places where this happens.
The same logic as in GZDoom applies: The root must not have any other content and the subdirectory must contain identifiable game content.
Some handling was also added to strip out macOS resource fork folders because they can contain data that can confuse file detection.
This works as long as the loaded mods have one single .ini file in them - in that case it is assumed that it is supposed to replace blood.ini, which will allow dragging & dropping such archives without further user intervention.
This was supposed to get the same treatment as d_net.cpp, i.e get the old license restored and be released under a duplicate GPL/Doom Source license but it was somehow missed when it got added. Also removed all leftover Doom specific parts.
Fix undefined behavior/potential OOB access in ST_21_FLOOR_DOOR. g_AnimateGoal does not take a sector number, it takes an animation index, and caps at 1024, not 4096.
* the parser read numbers with leading zeros as octal, which is not wanted here
* texture lookup by file name must be forced for root directory entries.
The sound system may play sounds on them after their deletion - this resulted in undefined behavior. To ensure properly defined behavior the sprite needs to be retained at least as long as the sound controller may still need it - which cannot be reliably determined so it has to be kept around forever. This would be easier if the sound controller code had proper start and stop events instead of inferring what to do from secondary information.
Fixes#288.
After discovering yet another misbehaving place in the game I think it can be safely concluded that this is better left off unconditionally.
The only remaining place where this still gets checked is in nnexts, but I wouldn't expect this to work either.
Fixes#292
* Reduce code repetition.
* Clamp incoming horizon when using `settarget()` methods.
* Eliminate double calculation that was occurring in `processhelpers()`.
* Install compilers for Linux targets explicitly
* Specify compilers for Linux target by executable names instead of full paths
* Switch to latest Clang target to 11
* Use ZMusic 1.1.6
* Since f4b27bbd27, `D:/Program Files (x86)/Steam/steamapps/common/Shadow Warrior Classic/gameroot/addons/Sw.grp` was being picked up instead of `D:/Program Files (x86)/Steam/steamapps/common/Shadow Warrior Classic/gameroot/SW.GRP`.
* Fixes#289.
