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
This can only be used if the entirety of the game code is aware and dealing with this properly. However, that isn't the case so the amount of glitches this causes far exceeds the number of desired interpolations.
- extended the maximum settable light size in GLDEFS to 1024 throughout.
- fixed: A fullbright flat should not be subjected to a sector's material color.
This reverts commit dd03bb1fcb.
Turns out that making this work in GL will create a complete mess so better remove the option as it would only cause problems.
Both of these may be true when occuring during normal gameplay, but not during an exception unwind in the serializer, which caused crashes if ACS errored out due to mismatched scripts.
The general rule is as follows: A class name as a string will always be looked up fully, even if the class name gets shadows by another variable because strings are not identifiers.
It is only class names as identifiers that must obey the rule that if it is not known yet or hidden by something else that it may not be found to ensure that the older variable does not take over the name if it gets reused.
If a later module reused an existing name for a different class or struct type, this new name would completely shadow the old one, even in the base files.
Changed it so that each compilation unit (i.e. each ZScript and DECORATE lump) get their own symbol table and can only see the symbol tables that got defined in lower numbered resource files so that later definitions do not pollute the available list of symbols when running the compiler backend and code generator - which happens after everything has been parsed.
Another effect of this is that a mod that reuses the name of an internal global constant will only see its own constant, again reducing the risk of potential errors in case the internal definitions add some new values.
Global constants are still discouraged from being used because what this does not and can not handle is the case that a mod defines a global constant with the same name as a class variable. In such a case the class variable will always take precedence for code inside that class.
Note that the internal struct String had to be renamed for this because the stricter checks did not let the type String pass on the left side of a '.' anymore.
- made PEnum inherit from PInt and not from PNamedType.
The old inheritance broke nearly every check for integer compatibility in the compiler, so this hopefully leads to a working enum implementation.
