It's an optional extension of deprecated keyword:
deprecated("2.4", "use ModernFunction instead") int OldFunction();
deprecated("3.5", "use ModernVariable instead") int OldVariable;
Usage of such members will produce the following report:
Script warning, ":zscript.txt" line 123:
Accessing deprecated function OldFunction - deprecated since 2.4.0, use ModernFunction instead
Script warning, ":zscript.txt" line 456:
Accessing deprecated member variable OldVariable - deprecated since 3.5.0, use ModernVariable instead
This data is game critical and may only be altered by code that knows what is allowed and what not. It must never be altered by any user code ever.
However, since the SkyViewpoint actors need to set up some relations between themselves and the default sky portals the previously purely internal 'internal' flag has been exported as a new keyword.
Let's use inline checkers in PType instead of constantly having to do clumsy IsKindOf checks etc. Once complete this also means that the types can be taken out of the class hierarchy, freeing up some common names.
This is only the parsing part, the arrays are not yet getting evaluated.
This required quite a hacky workaround because the gramma couldn't be made to accept the rule. The scanner will check if a 'static' token is immediately followed by a 'const' token and will combine both to a new 'staticconst' token that does not create conflicts with other rules.
Note that this completely disables the newly added keywords 'play' and 'ui' for unversioned code to allow using them as identifiers as I have found at least one mod that uses a variable named 'play' that would have been rendered broken otherwise.
This also disables many ZScript only keywords for other parsing jobs.
- support transient object member variables for information that does not need to be put in a savegame.
- fixed: special initialization of objects needs to pass the proper defaults along, otherwise the parent classes will use their own, inappropriate one.
* It will now use #include, just like most other definition formats and can be mixed with regular definitions. However, due to how the Lemon-generated parser works this will not recursively pull in all files, but store them in a list and process them sequentially. Functionally this shouldn't make a difference, because ZScript is mostly order-independent - the only thing where order is important is native classes, but these are completely internal to zdoom.pk3 where proper order is observed.
- added new VM instructions to access the constant tables with a variable index.
- refactored VMFunctionBuilder's constant tables so that they are not limited to one entry per value. While this works fine for single values, it makes it impossible to store constant arrays in here.
- implemented multiple-return-value assignment. Due to some grammar conflicts the originally intended Lua-inspired syntax of 'a, b = Function()' could not be done, so it's '[a, b] = Function()'
- added a new type 'NativeStruct'. This will be used for types that cannot be instantiated, and is also needed to cleanly handle many internal types that only can exist as reference.
Syntax-wise I chose to make it as strict as possible to reduce the chance of errors: Virtual base functions must be declared with the 'virtual' keyword, and overrides in child classes with the 'override' keyword. This way any mismatch in parameters that otherwise would cause silent failure will outright produce a compile error.
- added initializer syntax for vectors. A vector can be set with vectorvar = (x,y,z); for a 3-dimensional vector and vectorvar = (x, y); for a 2-dimensional one.
- removed 'self' as a dedicated token. Internally this gets handled as a normal but implicitly named variable so the token just gets in the way of proper processing.
- removed P_ prefix from SpawnMissile export.
- fixed a crash with misnamed function exports.
- allow class extensions.
These are separate blocks in different files that get concatenated to one class body for processing. The reason is to allow spreading the many functions in Actor over multiple files, so that they remain manageable. For example, all the Doom action functions should be in their respective files, but their symbols need to be in Actor. To extend a class, both files need to be in the same translation unit, so it won't allow user-side extension of internal classes.
