There's simply never enough of them and they are used far too infrequently to justify the hassle of tagging along two TMaps per class.
For what they provide, single global lists that handle all player classes at once are fully sufficient.
The math in DCanvas::FillBorder does not always work out so better clean the entire screen before drawing a fullscreen image to ensure that the menu blend is always drawn over something valid.
CVAR with this flag can be set in console or from command line when sv_cheats is enabled
There is no such restriction for changing its value from ACS, via SetCVar() and related functions
'cheat' modifier can be used in CVARINFO lump to create variable of this kind
The idea is, when status bars are moved to ZScript that only this small wrapper class needs to be dealt with and the implementation can be left alone. SBARINFO is far too complex to be scriptified, but having it inherit directly from DBaseStatusBar and access its member variables severely limits the options of dealing with the status bar code. This way, it only accesses some globally visible functions in DBaseStatusBar and no variables.
- renamed the global ST_X and ST_Y variables because it is far too confusing and error-prone to have the same names inside and outside DBaseStatusBar.
This was done to ensure it can be properly overridden in scripts without causing problems when called during engine shutdown for the type and symbol objects the VM needs to work and to have the scripted version always run first.
Since the scripted OnDestroy method never calls the native version - the native one is run after the scripted one - this can be simply skipped over during shutdown.
The original implementation just printed a mostly information-free message and then went on as if nothing has happened, making it ridiculously easy to write broken code and release it. Changed it to:
* Any VMAbortException will now terminate the game session and go back to the console.
* It will also print a VM stack trace with all open functions, including source file and line numbers pointing to the problem spots. For this the relevant information had to be added to the VMScriptFunction class.
An interesting effect here was that just throwing the exception object increased the VM's Exec function's stack size from 900 bytes to 70kb, because the compiler allocates a separate local buffer for every single instance of the exception object.
The obvious solution was to put this part into a subfunction so that it won't pollute the Exec function's own stack frame. Interesting side effect of this: Exec's stack requirement went down from 900 bytes to 600 bytes. This is still on the high side but already a lot better.
- instead add a list of SpecialInits to VMScriptFunction so this can be done transparently when setting up and popping the stack frame. The only drawback is that this requires permanent allocation of stack objects for the entire lifetime of a function but this is a relatively small tradeoff for significantly reduced maintenance work throughout.
- removed most #include "vm.h", because nearly all files already pull this in through dobject.h.
* everything related to scripting is now placed in a subdirectory 'scripting', which itself is separated into DECORATE, ZSCRIPT, the VM and code generation.
* a few items have been moved to different headers so that the DECORATE parser definitions can mostly be kept local. The only exception at the moment is the flags interface on which 3 source files depend.
