This is to ensure that the Class pointer can be set right on creation. ZDoom had always depended on handling this lazily which poses some problems for the VM.
So now there is a variadic Create<classtype> function taking care of that, but to ensure that it gets used, direct access to the new operator has been blocked.
This also neccessitated making DArgs a regular object because they get created before the type system is up. Since the few uses of DArgs are easily controllable this wasn't a big issue.
- did a bit of optimization on the bots' decision making whether to pick up a health item or not.
The values were still 8 and 32 respectively which applied to hardware from last decade, but for modern mods these are simply too low. New values are 64 as minimum and 128 as default.
- added script access to a sector's colormap and specialcolors fields. (Writing only through dedicated functions because these fields are render state which may need to trigger some form of refresh if the renderer changes.)
This has increasingly become an obstacle with the hardware renderer, so now the values are being stored as plain data in the sector, with the software renderer getting the actual color tables when needed. While this is a bit slower than storing the pregenerated colormap, in realistic situations the added time is mostly negligible in the microseconds range.
This addresses the main issue with TObjPtr, namely that using it required pulling in the entire class hierarchy in basic headers like r_defs which polluted nearly every single source file in the project.
This function will truncate everything that is larger than LONG_MAX or smaller than LONG_MIN to fit into a long variable, but longs are 32 bit on Windows and 64 bit elsewhere, so to ensure consistency and the ability to parse larger values better use strtoll which does not truncate 32 bit values.
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.
No need to maintain these clunky meta class for one single property. The overhead the mere existence of this class creates is far more than 100 spawned ammo items would cost.
There is no need to serialize AAmmo::DropAmount, this value has no meaning on an already spawned item.
- disabled the Build map loader after finding out that it has been completely broken and nonfunctional for a long time. Since this has no real value it will probably removed entirely in an upcoming commit.
Needless to say, this is simply too volatile and would require constant active maintenance, not to mention a huge amount of work up front to get going.
It also hid a nasty problem with the Destroy method. Due to the way the garbage collector works, Destroy cannot be exposed to scripts as-is. It may be called from scripts but it may not be overridden from scripts because the garbage collector can call this function after all data needed for calling a scripted override has already been destroyed because if that data is also being collected there is no guarantee that proper order of destruction is observed. So for now Destroy is just a normal native method to scripted classes
- fixed: FxBinary::ResolveLR' check for numeric operations was incomplete. Like far too many other places it just assumed that everything with ValueType->GetRegType() == REGT_INT is a numeric type, but for names this is not the case.
