- switched the types of the internal 'self' and 'stateowner' parameters so that they get assigned correctly. I can't tell if this will error out if fields get accessed from the caller with the wrong class, but for actual scripting to work these must be correct.
The committed 'actor.txt' can be parsed successfully, with the exception of a few subclass references that cannot be resolved yet.
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.
The way this was done was a major headache inducer, requiring reconstruction of the function each time the value was changed and in general made actor damage a major hassle.
There was a DECORATE wrapper to mimic the original behavior but this looked quite broken because it completely ignored the different semantics of both damage calculation types.
It also made it impossible to determine if damage was a function or a value.
This accessor has been reverted to what it should be, only returning the constant, which now is -1 for a damage function. I am sorry if this may break the odd mod out but a quick look over some DECORATE-heavy stuff showed that this was never combined in any of them so that accessing 'damage' in DECORATE code depended on an actual damage function.
To get proper damage, a future commit will add a DECORATE function which calls AActor::GetMissileDamage.
This will get rid of useless casts like 'if (isPointerEqual(x))'
It will also allow for proper casting in parameters like using a state as a boolean which is allowed in if statements for example
- This reverts commit c90a1c0c96.
- DECORATE looks to be very dependant on functions that take strings as
parameters receiving those strings as constants and not as expressions,
so being able to declare string variables with DECORATE is pretty much
useless.
- This is "support" in the very most basic sense. You can declare them,
but you can't actually do anything with them, since the decorate parser
can't handle expressions when it's parsing string arguments. However,
they seem to be getting properly initialized and destroyed, which is
what this was added to test. If it doesn't look like too much trouble, I
might try to turn them into something actually worth something.
- Since DECORATE's return statement can only return the results of
function calls (I do not want to spend the time necessary to make it
return arbitrary expressions), here are three functions to get around
this limitation:
* A_State - Returns the state passed to it. You can simulate A_Jump
functions with this.
* A_Int - Returns the int passed to it.
* A_Bool - Returns the bool passed to it.
- e.g. If you want to return the number 3, you use this:
return A_Int(3);
If you want to jump to a different state, you use this:
return A_State("SomeState");
- The A_Jump family of action functions now return the state to jump
to (NULL if no jump is to be taken) instead of jumping directly.
It is the caller's responsibility to handle the jump. This will
make it possible to use their results in if statements and
do something other than jump.
- DECORATE return statements can now return the result of a function
(but not any random expression--it must be a function call). To
make a jump happen from inside a multi-action block, you must
return the value of an A_Jump function. e.g.:
{ return A_Jump(128, "SomeState"); }
- The VMFunction class now contains its prototype instead of storing
it at a higher level in PFunction. This is so that
FState::CallAction can easily tell if a function returns a state.
- Removed the FxTailable class because with explicit return
statements, it's not useful anymore.
With late resolving it cannot be guaranteed at this point and caused some incorrectly compiled code. Since the cast gets optimized away anyway when not needed there's no point being this selective with applying it.
If done as before, forward-declared classes cannot be found, and the immediate resolving is only needed for constant expressions, so explicitly enabling it in the 4 places where it is needed ensures that those unresolvable expressions remain intact until the final processing pass righr before the code generator is started.
- Member variables are now declared all in one place: InitThingdef(). They
are not partially defined in thingdef_expression.cpp and further refined
in actor.txt.
- This left ParseNativeVariable() parsing only functions, so it has been
renamed to ParseNativeFunction().
- Note that their declarations in InitThingdef() are expected to be
temporary.
Conflicts:
src/CMakeLists.txt
src/b_think.cpp
src/g_doom/a_doomweaps.cpp
src/g_hexen/a_clericstaff.cpp
src/g_hexen/a_fighterplayer.cpp
src/namedef.h
src/p_enemy.cpp
src/p_local.h
src/p_mobj.cpp
src/p_teleport.cpp
src/sc_man_tokens.h
src/thingdef/thingdef_codeptr.cpp
src/thingdef/thingdef_function.cpp
src/thingdef/thingdef_parse.cpp
wadsrc/static/actors/actor.txt
wadsrc/static/actors/constants.txt
wadsrc/static/actors/shared/inventory.txt
- Added register reuse to VMFunctionBuilder for FxPick's code emitter.
- Note to self: Need to reimplement IsPointerEqual and CheckClass, which
were added to thingdef_function.cpp over the past year, as this file no
longer exists in this branch.
- Constants can be strings, but the existing PSymbolConst couldn't handle
them. The old PSymbolConst is now PSymbolConstNumeric, and the new
PSymbolConst is a now a baseclass for it and PSymbolConstString.
- The type systems used by PField and FxExpression are completely
incompatible, but I think I got the differences taken care of as far
as ParseNativeVariable(), ParseUserVariable(), and FxClassMember are
concerned.
- Support for declaring native bool variables has been removed for the time
being. It wasn't used anyway.
- Removed PSymbolVariable.
- For the purposes of getting constant values from expressions, the only
class where Resolve doesn't duplicate the functionality of
EvalExpression was FxConstant. So, every other class has had its
EvalExpression taken away, and FxConstant has had it renamed to GetValue.
- After StateParams was removed in commit 4a1fbdb, the expressions for
default paramaters that ParseActionDef() created went nowhere and were
lost. Properly throw them away by deleting them as soon as they've been
parsed.
- This all became vestigial code after the relevant information was all
moved into FStateTempCall. Now that the MBF code pointer code has been
converted, I can be sure it wasn't still used anywhere.
