Since it forwards directly to FindState and has no script bindings there is no need to keep it, it'd only complicate the full scriptification of the weapon class if it stuck around.
For some files that had the Doom Source license attached but saw heavy external contributions over the years I added a special note to license all original ZDoom code under BSD.
This was very poorly done without ever addressing the issues a composite render style can bring, it merely dealt with the known legacy render styles.
The same, identical code was also present in two different places.
The oversight that AlterWeaponSprite overrode even forced styles was also fixed.
OpenGL is not implemented yet but with the problems eliminated should be doable now.
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.
src/p_pspr.cpp:363:37: warning: more '%' conversions than data arguments [-Wformat]
src/gl/textures/gl_texture.cpp:845:21: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
Fixed bunch of compilation errors:
cannot pass non-trivial object of type 'FString' to variadic method; expected type from format string was 'char *' [-Wnon-pod-varargs]
Fixed linker erorr:
g_doomedmap.cpp.o: In function `InitActorNumsFromMapinfo()':
src/g_doomedmap.cpp: undefined reference to `PClass::FindActor(FName)'
- some optimization of access to OwnedStates in old DECORATE.
- consolidate all places that print a state name into a subfunction.
- allocate states from the ClassDataAllocator memory arena. States do not need to be freed separately from the rest of the static class data.
(Is there anyway to tone down GCC's warning level? It outputs too many false positives for potentially uninitialized variables in which the genuine errors get drowned.)
1) When used in a hub, returning to a previous level in the hub deactivated the runes if they were a permanent powerup.
2) When picking up two different runes with the same effect, one rune wearing off removed the effect completely.
3) This entire system was done through an extremely hacky CheatFlags implementation. This was a gross hack, and it was no wonder it didn't always work properly.
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.
- fixed PARAM_ACTION_PROLOGUE to assign correct types to the implicit pointers. It gave the actual class to the wrong one, which until now did not matter because all functions were using 'Actor', regardless of actual class association.
- fixed the definition of IceChunk and removed some redundant code here. Since A_FreezeDeathChunks already calls SetState, which in turn calls the state's action function, there is no need to call it again explicitly.
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
