This isn't used for the 3 action function calls because it requires an array allocation which would be a bit too costly for something as frequently called as action functions.
They will need a different approach.
Since CallStateChain is a public member in CustomInventory we cannot really be sure that the given state is valid so it needs checking as well.
# Conflicts:
# .gitignore
This can happen if a state that's retrieved with FindState gets used with a different actor type and can lead to hard to trace problems if not checked.
This setup has been a constant source of problems so now I reviewed all uses of FName to make sure that everything that needs to be initialized is done manually.
This also merges the player_t constructor into the class definition as default values.
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.
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)'
Combining these two groups of data has been the cause of many hard to detect errors because it allowed liberal casting between types that are used for completely different things.
- fixed: IsVisibleToPlayer and optimized it a bit more.
- moved SourceLumpName to PClass, so that it can also be used for non-actors (there's a lot of non-Actor classes already.)
- separated the serializer for PClassPointer from PPointer. Even though not doable, a pointer to a class type is something entirely different than a class pointer with a restriction so each should handle its own case.
- added a few access functions for FActorInfo variables.
With PClassActor now empty the class descriptors can finally be converted back to static data outside the class hierarchy, like they were before the scripting merge, and untangle the game data from VM internals.
For these fields maps have no advantage. Linearly searching a small array with up to 10 entries is nearly always faster than generating a hash for finding the entry in the map.
- 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.
This reinstates the old FActorInfo as part of the meta data a class can have so that the class descriptor itself can be freed from any data not directly relevant for managing the class's type information.
This is not needed anymore because classes do not need to be replaced. The only reason this was implemented was the original design with the class descriptors taking on all the metadata themselves.
- made CameraHeight a modifiable actor property - it was readonly before.
- allow accessing the type constants from ZScript, this required quite a bit of explicit coding because the type system has no capabilities to search for basic types by name.
Making this an object had little to no advantage, except being able to remove the deleter code. Now, with some of the class data already being allocated in a memory arena so that freeing it is easier, this can also be used for the drop item lists which makes it unnecessary to subject them to the GC. This also merges the memory arenas for VM functions and flat pointers because both get deleted at the same time so they can share the same one.
Now all actors have the same metaclass and therefore it will always be the same size which will finally allow some needed changes to the type system which couldn't be done because it was occasionally necessary to replace tentatively created classes due to size mismatches.
As it stood, just compiling the internal ZScript code created more than 9000 DObjects, none of which really need to be subjected to garbage collection, aside from allowing lazy deallocation.
This puts an incredible drag on the garbage collector which often needs several minutes to finish processing before actual deletion can start.
The VM functions with roughly 1800 of these objects were by far the easiest to refactor so they are now. They also use a memory arena now which significantly reduces their memory footprint.
