Previously, many concatenated texture field strings were turned to text, then had that string run through get_number, then had it converted back into a string to become a stringarg.
Now, the concatenated string is copied directly to the relevant stringarg, with no intermediary steps.
This fixes an issue where a map with object or state properties would have "context drift" - breaking when the object or state list changed, due to differently ordered freeslots, or new hardcoded objects.
Affected types:
- doomednum 1110/Action 9 (Custom Mace/Chain)
- doomednum 700 and those immediately following (Ambient Sound)
- Action 4 and 414 (dash pad, play sound effect)
- Action 14 (bustable block parameters)
- Action 434 (Award Power)
- doomednum 757/Action 15 (fan particle generator)
- doomednum 1202 (bumpable hazard rock/apple spawner)
- This one has undefined behaviour in the binary map format which was not previously forbidden. This undefined behaviour is EXTREMELY vulnerable to context drift, and so it's simply not worth creating a system to write numerical values into object types - we write an explicit name only for the intended range, and otherwise report the threat of context drift when converting.
In addition, to reduce duplicated zone memory, (sidedef_t).text and (linedef_t).text have been removed from all but the Lua API. In Lua, in binary maps, they point to the host line's stringargs - the line's text and a frontside's text will return stringargs[0], while a backside's text will return stringargs[1]. I've done my best to match the previous API as closely possible, to the point of reporting false nils if the line didn't previously have text available.
However, there are four linedef Actions for which the sidedef text will be different between builds containing and not containing this commit - 331, 332, 333 (the Character-specific linedef executors), and 443 (Call Lua Script), and only if the text is long enough to go over two lines. Given that both halves would be incomplete nonsense in this case, I'm willing to wager this minor point of discrepancy is not a breaking issue.
Instead of modifying the game, cheats now set a separate "cheats were used in this session" variable, which returns some of the old behavior.
HOWEVER, cheats will STILL allow spawning / collecting emblems & unlocking unlockables. Cheats will purely prevent saving progress. (It was always frustrating that devmode would make debugging unlockable features harder...)
Lastly, the function to set no-saving was exposed to Lua (`G_SetUsedCheats(silent)`). Just thought it'd be useful for large-scale gamedata-using mods that want to add their own cheat commands.
(Except as part of srb2home, srb2path or addons_folder --
this lets addons menu work, primarily.)
- disallowed when using addfile or addfolder
- security check for xcmd receive
