- 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.
