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.
Index and take length of tag lists like a table, 1-indexed. There are three
methods which may be used on tag lists:
list:iterate() - returns an iterator over the tags in the list
list:has(tag) - returns a boolean whether the tag is in the list
list.shares(list2) - returns whether two lists share a tag
"find" is also an alias to "has". Each method may be accessed from the global
taglist library too, e.g. taglist.iterate(list)
Tag lists may be compared with an equality operator too. This will tell you if
the two lists are composed of identical tags.
Accessible from sector.taglist, line.taglist and mapthing.taglist.
