Several problems here:
* the crucial call did not override 'mustexist'.
* once created an extended stare would not be looked at anymore.
* extended states received no usage flags.
This prevents spoiling levels when the HUD information is disabled.
This change is not retroactive: it has no effect on existing savegames.
You need to save again for this change to have an effect.
This is to ensure that if the map specifies light mode Doom (i.e. hardware approximation of software lighting) it is not overridden by the user-selected software emulating light mode.
gl_lightmode should only apply if neither the map nor gl_maplightmode set an explicit light mode.
With how this is being handled now, the CVAR needs to have the CVAR_GLOBALCONFIG flag and CVAR_NOINITCALL unset or it simply won't work right.
Since its meaning has completely changed now (i.e. it's mainly a performance switch to a less demanding implementation instead of being able to select vastly different lighting methods) making it global is more sensible.
Save games now store kills/items/secrets and player health/armor
in the comment string, which is displayed in the save/load game menu.
This change is not retroactive: old savegames will not display
this information until they are overwritten.
When no doublebinds get passed to C_DoKey it may not set the doubleclick flag.
For the automap C_DoKey gets called twice, once with the automap bindings and once with the regular bindings and doubleclicks.
The STARTUP0 check is not only redundant but also was wrong. It already gets checked and validated in the asset loading loop, and this up-front check did not handle placement as a graphic.
If all of the worst stars align when compiling Polyobject BSP and splitting a seg into two sets:
- The very first seg in the current set fails all of the metrics for determining which side of a split it is on, and doesn't know which side it should go to. Since there are 0 are in front, it goes to front by default.
- Every other seg in the same set don't fail their metrics, and they all decide they are meant to go to the front side.
- Oops! Now there's nothing in the back side!
I've fixed this by collecting all of the undecided segs in a split, and setting the new side after the other segs. Doing it in the normal loop means there's a non-zero chance the crash prevention will fail depending on how the segs are in memory.
This can technically happen with even the most simplistic Polyobjects, but it becomes more common the more complex it is (add tons of lines, move and rotate it at the same time, so on). Quite an annoying crash since it doesn't always replicate consistently.
