- removed Self parameter from FxFunctionCall. Actual member function calls through an object require quite different handling so lumping these two together makes no sense.
- added a workaround to deal with ACS_NamedExecuteWithResult to both the compiler and FindClassMemberFunction. The way the ZScript compiler sets this up means that it will call the builtin, not the actual action function, so the parser needs to do some explicit check to get past the same-named action function.
- pass a proper self pointer to FxActionSpecial. Although it's still not being used, propagating design shortcuts through several function levels is a very, very bad idea.
* explicitly require passing the owning class when creating it.
* extract self pointer class when adding a variant.
* put the flags on the single variants, we can not fully rule out that they will be 100% identical, if variants ever get allowed.
* Allow PFunction to work without a VMFunction being attached.
* The Variant for a function must store the prototype itself instead of relying on the VMFunction it points to. Otherwise it would not be possible to reference a prototype during compilation of the function because it does not exist yet.
* Give the variant a list of the function's argument's names, because these are also needed to compile the function.
* create an anonymous function symbol when the function gets registered to the builder. At this point we have all the needed information to set it up correctly, but later this is no longer the case. This is the most convenient info to have here because it contains everything that's needed to compile the function in the proper context, so it has to be present when starting compilation.
* added some preparations to implement special handling for weapons and custom inventory items, which can run action functions in another actor's context. This part is not active yet but the basics are present in SetImplicitArgs.
- use FScriptPosition's error counter throughout the compiler so that there is only one counter for everything, not two.
Parts of the compiler use FScriptPosition, so this is easier to handle than having a separate counter in the compiler class. It also avoids having to pass the compiler object to any function where an error may be output. The TreeNodes contain sufficient data to be converted to an FScriptPosition and using that for error message formatting.
It looks like the setup of the action function and the adding of the states got inverted by something I tried, leaving the ActionFunc member empty on the real states.
- fixed a few problems that were encountered during conversion:
* action specials as action functions were not recognized by the parser.
* Player.StartItem could not be parsed.
* disabled the naming hack for PowerupType. ZScript, unlike DECORATE will never prepend 'Power' to the power's name, it always needs to specified by its full name.
* states and defaults were not checked for empty bodies.
* the scope qualifier for goto labels was not properly converted to a string, because it is an ENamedName, not an FName.
- started with the AST converter. So far it only deals with direct function calls with simple constants as parameters.
- added an error condition for the defaults block to get rid of some asserts.
- fixed uninitialized counter variable in DECORATE parser.
- allow dottable_id of xxx.color so that the property parser can parse 'powerup.color'.
- fixed crash with actor replacement in script compiler.
- add the lump number to tree nodes because parts of the property parser need that to make decisions.
- removed test stuff.
- converted inventory.txt, player.txt and specialspot.txt to ZSCRIPT. These were the minimal files required to allow actor.txt to parse successfully.
- removed the converted files from the DECORATE include list so that these are entirely handled by ZSCRIPT now.
- 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.
