It's about time this stuff is getting cleaned up seriously. Both a_pickups.cpp and a_artifacts.cpp are so overstuffed that it has become a chore finding stuff in there.
- Changed the glass shards so that they do not have to override FloorBounceMissile. It was the only place where this was virtually overridden and provided little usefulness.
- made 'out' variables work.
- fixed virtual call handling for HandlePickup.
- added a String class to allow attaching methods to the builtin string type. This works by checking if the left side of the member accessor is a string and just replacing the tyoe in this one place, all the rest is automatic.
- fixed issues with the refactoring of the recent commits. This one starts again.
- added builtins for TextureID.
Note about builtins: Currently they are just hacked into the compiler backend. They really should be made part of the respective types to keep matters clean and allow more widespread use of builtins to create more efficient code.
- refactored the ModifyDamage interface to be more scripting friendly.
In general it should be avoided having to call directly into chained inventory functions because they are very problematic and prone to errors. So this got wrapped into a single handler (on AActor, not AInventory!) which will later make it easier to refactor the parameters of ModifyDamage to work better for scripting and avoid the chaining.
Two reasons for this:
1. if this has to be routed through the VM each recursion will cost 1000 bytes of stack space which simply is not good.
2. having the virtual function only care about the item itself but not the entire inventory chain is a lot less error prone for scripting.
Since the scripting interface needs a separate caller function anyway this seemed like a good time to change it. The same will be done for the other chained inventory handlers as well.
Interesting tidbit: The damage calculation in P_MinotaurSlam had been incorrect for the Heretic version since the friendly Hexen Dark Servant was added, but nobody ever noticed in 14 years...
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
- scriptified all Effect functions of Fastprojectile's children
- implemented access to class meta data.
- added a VM instruction to retrieve the class metadata, to eliminate the overhead of the function call that would otherwise be needed.
- made GetClass() a builtin so that it can use the new instruction
Important note about this commit: Scriptifying CFlameMissile::Effect revealed a problem with the virtual function interface: In order to work, this needs to be explicitly enabled for each single native class that may be used as a base for a scripted class. Needless to say, this will end up way too much work, as there are over 100 native classes, excluding those which will be scriptified. But in order to fix the problem this partially broken state needs to be committed first.
- renamed APowerMorph::Player to avoid accidental confusion with AActor::player, which in scripting is the same due to case insensitvity.
- renamed save key for above variable.
This prevented any kind of error check on them.
Unfortunately, due to backwards compatibility needs, on DECORATE the missing class may not be fatal so a workaround had to be added to clear those bogus pointers later if they are discovered to be broken.
For ZScript, though, this will result in a compile error, which was the intention behind this change.
- 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()'
- changed Dehacked weapon function lookup to check the symbol table instead of directly referencing the VM functions. Once scriptified these pointers will no longer be available.
- removed all special ATAGs from the VM. While well intentioned any pointer tagged with them is basically unusable because it'd trigger asserts all over the place.
- scriptified A_Punch for testing pass-by-reference parameters and stack variables.
- instead add a list of SpecialInits to VMScriptFunction so this can be done transparently when setting up and popping the stack frame. The only drawback is that this requires permanent allocation of stack objects for the entire lifetime of a function but this is a relatively small tradeoff for significantly reduced maintenance work throughout.
- removed most #include "vm.h", because nearly all files already pull this in through dobject.h.
- added a DActorIterator class.
- fixed: It was not possible to have functions of the same name in two different classes because the name they were searched for was not qualified by the class. Changed so that the class name is included now, but to avoid renaming several hundreds of functions all at once, if the search fails, it will repeat with 'Actor' as class name.
This commit contains preparations for scriptifying Hexen's Dragon, but that doesn't work yet so it's not included.
- added an 'exact' parameter to FThinkerIterator's Next function. This is mainly for scripting which allows to do a lot more checks natively when running the iterator while looking for one specific class.
- fixed emission of the self pointer in FxVMFunctionCall. I did not realize that the self expression only sets up a register for the value, not pushing it onto the stack.
- split FinishActor into several functions. While DECORATE can, ZSCRIPT cannot do all this in one go.
- split the state finalization into several class-specific virtual functions.
* everything related to scripting is now placed in a subdirectory 'scripting', which itself is separated into DECORATE, ZSCRIPT, the VM and code generation.
* a few items have been moved to different headers so that the DECORATE parser definitions can mostly be kept local. The only exception at the moment is the flags interface on which 3 source files depend.
This uses the same property and flag tables as DECORATE with a few changes:
* it sets the parse mode to strict, so that several DECORATE warnings are now errors.
* trying to change a deprecated flag will print a warning.
* setting of editor numbers, spawn and conversation ID id not possible. Use MAPINFO to do this.
* all subclass flags must use the qualified name now (e.g. +ALWAYSPICKUP will print an error.)
* the scriptable Damage property is not yet implemented. This will require a special case with a differently named property in the processing function because in the AST it is no longer possible to distinguish between a damage value and a constant damage function.
After testing with a savegame on ZDCMP2 which is probably the largest map in existence, timing both methods resulted in a speed difference of less than 40 ms (70 vs 110 ms for reading all sectory, linedefs, sidedefs and objects).
This compares to an overall restoration time, including reloading the level, precaching all textures and setting everything up, of approx. 1.2 s, meaning an increase of 3% of the entire reloading time.
That's simply not worth all the negative side effects that may happen with a method that highly depends on proper code construction.
On the other hand, using random access means that a savegame version change is only needed now when the semantics of a field change, but not if some get added or deleted.
- do not I_Error out in the serializer unless caused by a programming error.
It is better to let the serializer finish, collect all the errors and I_Error out when the game is known to be in a stable enough state to allow unwinding.
- fixed a few errors in the ACS module serializer.
- reordered a few things to how they were in the old code.
- optimized serialization of the level.Scrolls array to happen within the sector. This is to allow skipping 0-entries which normally constitute the vast majority of them.
- Trails now copy pitch, and set the projectile as the target.
- Added GETOWNER flag. Using it sets the owner of the fast projectile as the target instead, if it has an owner.
- Crashes occurred if a particular actor was a tracer to the player and the actor was not gone by the time the player unmorphs.
- Failed unmorphs occur if tracer was manipulated through means like A_RearrangePointers, etc.
This reverts commit 5ff0abe568.
- use STAT_INVENTORY only for held items.
Seems this was causing some strange issues with hubs, but for items placed in the world it still cannot be allowed to have them in a different statnum.
This was causing issues with sprite sorting. For this to work as intended, all actors in the world that display sprites need to remain in spawn order, including inventory items.
The only thing this statnum was used for were some bot related search actions which are simply not worth breaking actual maps for some very minor performance gain.
The reason this is not set by default is because before that anyone could call A_WeaponReady within their Deselect state which would have allowed players to fire even when dead
In this case the PSprite animation won't be changed, only the ReadyWeapon. But in order to work, the PSprite's caller needs to change as well so that the next weapon check does not fail.
- removed the sector loop for deleting skybox references in ASkyViewpoint::Destroy. Since this only refers to the sectorPortals array it is completely redundant as the following code will clear them just as well.
Since decals may have thinkers attached this will crash when such a savegame gets loaded, because the thinker lists get reset in P_SerializeThinkers, deleting any thinker that already was processed.
I also added an error message that immediately aborts the save process if such an out-of-sequence thinker is attempted to be written out.
This obviously breaks savegame compatibility again...
In some places, P_UndoPlayerMorph was called with the 'force' argument placed in the 'unmorphflag' parameter, so that 'forced' unmorphs would be not completely forceful.
I hope no mod relied on this weirdness...
The only reason this even existed was that ZDoom's original VC projects used __fastcall. The CMake generated project do not, they stick to __cdecl.
Since no performance gain can be seen by using __fastcall the best course of action is to just remove all traces of it from the source and forget that it ever existed.
