This was yet another piece of code that essentially was unworkable thanks to the limited screen space with the old bitmap fonts.
With the new font there is enough screen space to do this properly.
This has to be set in the console, the default is still the regular small font. Mainly added because some mods have really hard to read fonts where it is not easy to decipher the numbers.
1. Top-level menu names are now properly handled.
2. Changing "Any or All terms" option now immediately updates the results.
3. Reformatted menu.zs to have tabs instead of spaces.
The most important one is the autosave tagging. This was done because the old printout was missing the year and printed the month as a 3 character English string, sabotaging any attempt to sort the autosaves by anything meaningful.
Parts of this menu suffered badly from lack of screen space to convey the intended information due to the oversized fonts. With the new font this is a lot less problematic (unless using 320x200, of course)
* added a CVAR that sets how localizable graphics need to be dealt with.
* pass the substitution string to OkForLocalization so that proper checks can be performed.
* increased item spacing on Doom's list menus to 18 from 16 pixels, because otherwise the diacritic letters would not fit. 20 would have been more ideal but 18 was the limit without compromising its visual style
* added a second text-only main menu because here the spacing cannot be changed. Doing so would render any single-patch main menu non-functional. So here the rules are that if substitution takes place, it will swap out the entire menu class.
* fixed some issues with the summary screen's "entering" and "finished" graphics.
Passing something non-constant at compile time here is extremely dangerous, especially when users can replace those strings if they like.
It now uses FString::Substitute in all cases where something needs to be inserted into a template string.
* entering a savegame description did not work anymore
* the length check was too restrictive and always underestimated the available space
* use the console font for entering a savegame description. This has more characters and better contrast for this content.
* the interface to the text enterer used bad measurements.
For the Doom IWADs the provided font looks almost identical to the characters used on the title patches. So, for any level name that got replaced in some language, it will now check if the retrieved name comes from the default table, and if not, ignore the title patch and print the name with the specified font.
This also required removing the 'en' label from the default table, because with this present, the text would always be picked from 'en' instead of 'default'. Since 'en' and 'default' had the same contents, in any English locale the 'default' table was never hit, so this won't make any difference for the texts being chosen.
Last but not least, wminfo has been made a local variable in G_DoCompleted. There were two places where this was accessed from outside the summary screen or its setup code, and both were incorrect.
This was broken by several small unicode-incompatible code fragments.
This commit also removes the input limit for the player name and the savegame description. With multibyte encoding, limiting them to a fixed length did not work right.
Currently these will just overflow the fields if the text becomes too long, this needs some additional work.
The script side cannot do anything useful with this, because most actions require parameters in global variables, so this is a first grade candidate for rogue mods to make the engine misbehave.
One sector in an underwater area of KDIZD Z1M3 got tagged with an incorrect Transfer_Heights effect which caused render glitches in that area.
There were also a few AddSectorTag calls without first clearing the sector's tags leading to potentially undefined behavior.
The text file
gzdoom/wadsrc/static/zscript/statscreen/statscreen.txt
is set to use strings called “$ENTERING” and “$FINISHED”, located in the language files, in intermission screens between levels in Heretic. However, these strings are named incorrectly in the language files, instead being written as “$WI_ENTERING” and “$WI_FINISHED” for some reason I’m unaware of. After renaming the original script, the ingame text shows up through what is written in the language files, as intended.
On a miscellaneous note: in GZDoom, the text between levels in Heretic says “Entering:”. In the DOS version, it says “Now entering:”. This is accurately reflected in the English language file, though, and thus faithful to the original when displayed ingame.
currentUILevel is now primaryLevel.
For ZScript, currentVMLevel was added. This is also exported as 'level' and will change as needed.
This also means that no breaking deprecations will be needed in the future, because in order to sandbox a level only 4 variables need to be handled: level, players, playeringame and consoleplayer.
The remaining global variables are not relevant for the level state.
The static 'level' has been mostly removed from the code except some places that still need work.
- Allows defining of what actor is replacing another for information.
- If multiple arachnotrons, a modder can attribute them as being a replacer of Arachnotron itself, allowing A_BossDeath and GetReplacee to work with it.
This was always used with 'consoleplayer' which really is the only thing making sense here. But this is a part of the global state which should be avoided in play code.
In particular, this makes no real sense in case of secondary maps where it should always return false.
All these required access to the sector's Level reference.
The remaining references to the global 'level' variable are all in deprecated functions which is ok.
LevelLocals on the left side of.a function call will now always be remapped to 'Level', which will either remap to the same-named instance variable or the global deprecated one.
In a few degenerate cases where there is a conflicting local variable named 'level' it may error out but that is unavoidable here but this is very unlikely.
This had two different flags that were checked totally inconsistently, and one was not even saved.
Moved everything into a few subfunctions so that these checks do not have to be scattered all over the code.
UI always runs on the primary level, so this does not need the ability to operate on multiple levels. Additionally, this can later be set to null when running play code so that scope violations result in an abort.
When player is picked up item that does morph, the corresponding toucher actor is changed in process
Previously, morhing item was removed from original actor leaving player's inventory in inconsistent state
https://forum.zdoom.org/viewtopic.php?t=63124
Unlike the other classes, the places where variables from this class were accessed were quite scattered so there isn't much scriptified code. Instead, most of these places are now using the script variable access methods.
This was the last remaining subclass of AActor, meaning that class Actor can now be opened for user-side extensions.
This was the only code using the ViewBob member variable.
This also moves the range check for this variable to its application, because a badly behaved mod can just as easily change it at run time instead of just setting an absurdly large value in the class definition.
The current behaviour offsets to the front of the actor rather than the side, due to an oversight in the code, which oddly is not present in the A_FireBullets equivalent.
This should be less of a drag on the playsim than having each light a separate actor. A quick check with ZDCMP2 showed that the light processing time was reduced to 1/3rd from 0.5 ms to 0.17 ms per tic.
It's also one native actor class less.
The loop never checked if the item was still valid and would continue to try to use it, even after it was removed from the inventory and destroyed.
As native code this just failed silently, but with the VM it needs to be explicitly checked.
Add 'useowncoloradd_{top,mid,bottom}' sidedef properties to the UDMF
spec
Only use side's additive colors if 'useowncoloradd_(top|mid|bottom)' is
set.
Rename UseOwnColors flag to UseOwnSpecialColors
Add UseOwnAdditiveColor flag to side_t::part
Add EnableAdditiveColor to side_t
Add Side.EnableAdditiveColor to ZScript API
Sector.SetAdditiveColor actually called Sector.SetSpecialColor
Add use boolean property, used to determine whether or not to override the sector's additive wall colour with the side's additive colour.
The new specification is more flexible, and allows assigning additive
colors to individual parts of a sector (walls, sprites, flats) and even
individual parts of a side (top, middle, bottom)
Add AdditiveColors arrays to sector_t and side_t::part
Initialize AdditiveColors arrays to 0
Export AdditiveColors to ZScript
Save AdditiveColors in saved game files
Use colors from AdditiveColors arrays when setting the additive color
for the render state
Add code to parse the new UDMF additive color properties
Remove additive color slot from sector color/part enum
Add SetAdditiveColor to sector_t and side_t
Add GetAdditiveColor to side_t
Export new methods and additive color arrays to ZScript
Rename ColorAdd to AddColor
Add AddColor to FRenderState
Tweak SpecialColors array in ZScript to include the additive color
Add uAddColor to the shader compiler
Add uAddColor to the texel
- TriggerPainChance(Name mod, bool forcedPain)
- One exception: PainThrehold is only checked in ReactToDamage, since this function does not require checking damage amount.
Unlike everything else from the IWADs this had to use the 'light' keyword in ZScript because this is merely a base class for many others and the light definitions here need to be inheritable.
Many uses of random() & value have been turned into random(0, value).
This is not only more efficient, it also ensures better random distribution because the parameter-less variant only returns values between 0 and 255.
