Constant expressions for decorate properties

[FDARI]

Issue: Named constants are not usable in decorate actor properties such as "Health" and "VisibleFilter" (viewtopic.php?f=34&t=31497). This also applies to "Activation" and some morph property I've never actually tried to use, but these have had a special solution in the zdoom-engine, allowing them to be written as a series of strings with | separators.

Added syntax for decorate: const(expression) returns the result of any constant float/integer expression. Here's an example where the goal is to have proportionate amounts of health:

Spoiler: Standard

Code: Select all • Expand view

actor a1
{
    health 300
}
actor a2
{
  health 600
}
actor a3
{
 health 900
}

Spoiler: New (optional style)

Code: Select all • Expand view

const BaseHealth = 300; // you can update the health of the lot of them here
actor a1
{
    health const(BaseHealth)
}
actor a2
{
    health const(BaseHealth*2)
}
actor a3
{
    health const(BaseHealth*3)
}

The patch contains a very simple demo where THINGSPEC_... flags are set using const(expression) syntax. Old syntax is still available.

Note on constants: I had to update the constant definitions for decorate, as they were not up to date with the most recent flags in zdoom. If this patch is applied, I suppose that the zdoom list of flags will no longer be updated, since it would exist merely for compatibility purposes.

Why wrap the expression in CONST()?

I could not just call the expression parser without knowing that there would be a terminator for that expression. The normal decorate assignments do not have a line terminator; they just get the first number and check for a comma. If I called the parser on something unterminated, it would try to read the next property/token as part of the expression. So it was either to put something ahead (const) that announced the alternate syntax, or a more complex check for an optional line-terminator that would support expression evaluation. I went with the easier one.

Why not just enclose it in parenthesis?

Because that has a meaning for some properties. 1) I didn't want the semantic mixup. 2) You can use const(expression) to set an amount of damage, so it really needs to be distinct from the (formula)-syntax. It is also not necessarily a bad thing that the text says const() explicitly.

The main purpose of this feature is to make the addition and expansion of Flaggish features easier (Activation, Morph-stuff, VisibleFilter). A secondary purpose is to let modders define and use constants for any centrally defined values they need.

I did struggle a bit with the scanner (I first tried a sc.GetToken()/sc.MustGetAnyToken() that would return directly if a numeric token was identified, process const if TK_Const if that was encountered, and reevaluate otherwise. Reevaluation consisted of sc.UnGet() and sc.MustGetNumber()/sc.MustGetFloat(). But if the string on entry was "-1", the token would be '-', and ungetting would make "-" the string, instead of restoring scanner status with the "-1" string. So I gave that up.). Also, my error messages may not be the brightest and best. Those, and other issues, I will handle if it is required to get the patch in.

EDIT: An updated patch applies exactly the same logic to state frame durations and offset specifications.

[Nash]

I've been waiting for this for so long!

Question: Would it be difficult to add expression support to state frame durations?

[FDARI]

Perhaps (it would) not (be difficult). It is likely that the same principle applies.

[FDARI]

Did it for state durations and decorate (weapon) sprite offsets. I just moved stuff and compiled it; proper testing should follow. I'll get around to my own tests eventually, but it would be nice if you could try it out in lots of thinkable ways in the meantime.

[Graf Zahl]

Why wrap the expression in CONST()?

I could not just call the expression parser without knowing that there would be a terminator for that expression. The normal decorate assignments do not have a line terminator; they just get the first number and check for a comma. If I called the parser on something unterminated, it would try to read the next property/token as part of the expression. So it was either to put something ahead (const) that announced the alternate syntax, or a more complex check for an optional line-terminator that would support expression evaluation. I went with the easier one.

... and here's the reason why it was never implemented. And the solution is so simple...

[Nash]

Will do some extensive testing over the next few days...

[Nash]

Tested this with my GZDoom fork... it doesn't seem to handle expressions with floating point numbers.

Code: Select all • Expand view


gravity const(1.0 / 8.0)
 

Code: Select all • Expand view


gravity const(1.0 / 8)
 

Code: Select all • Expand view


gravity const(1 / 8)
 

None of these work...

(haven't seen FDARI post much lately... hope he's still around!)

[FDARI]

I'm still here, but with very little time and energy to spare. Strange that floats don't work well... I don't know when I'll look into it (feel free to try it on your own).

[FDARI]

Tested this with my GZDoom fork... it doesn't seem to handle expressions with floating point numbers.

Code: Select all • Expand view

gravity const(1.0 / 8.0)

Code: Select all • Expand view

gravity const(1.0 / 8)

Code: Select all • Expand view

gravity const(1 / 8)

I have reviewed my patch and your examples. As far as I can tell I have not introduced a constant resolution bug. I have also tested the const settings you submitted, and they are exactly the same as 0.125 in all tests; with the exception of the one where both values are integers. Decorate evaluates that as integer divided by integer and rounds down; that's not really a bug.