Ability to define pointer for A_JumpIf

[StrikerMan780]

Functions like A_JumpIfHealthLower now support defining a pointer so you can perform checks on other actors for your state jumps, however, A_JumpIf lacks this.

As an example of it's usefulness, say... you make a gun that fires bullets for targets in the air, but if a target is under water and you're above, it fires a small under-slung harpoon gun at the target instead.

Another example, could be a gravity gun, that can only pick up objects under a certain mass.

[NeuralStunner]

What you basically mean is pointers for [wiki=DECORATE_expressions]Decorate expressions[/wiki]. I believe it's come up before, and isn't something we're going to see until ZScript.

(Unless of course someone manages to implement and submit it, and it's accepted.)

[Major Cooke]

I could try giving this a shot... Let's just hope it's not as painful as it sounds.

[Snarboo]

I thought a few of these pointers were supported in decorate already? I vaguely recall waterlevel is in any case, but I may be misremembering.

Edit:
Whoops, misread the conversation!

[StrikerMan780]

What you basically mean is pointers for [wiki=DECORATE_expressions]Decorate expressions[/wiki]. I believe it's come up before, and isn't something we're going to see until ZScript.

(Unless of course someone manages to implement and submit it, and it's accepted.)

No.

I mean being able to define whatever pointer(AAPTR_TARGET, AAPTR_TRACER, etc.) of the calling actor to forward the check to. I thought I was clear about this by posting an example of a function that does this already.

Example of a function that has it already: A_JumpIfInTargetInventory (str "item", int count, str "state"[, pointer forward])

But, for I want this for JumpIf:

A_JumpIf (expression, str "state"[, pointer forward])

[NeuralStunner]

That's vastly more limited given the nature of A_JumpIf, but okay. It would be better than nothing.

[Major Cooke]

Yeah, for the sake of sanity Neural, that's exactly what I was thinking: just checking the code pointer's decorate expressions via AAPTR_ only, as Striker said. It'll be a lot less ugly that way. Despite the drawbacks, I still think it'll be a huge leap forward regardless.

My only concern is user variables and arrays. I'm thinking the easiest thing to do here is to just outright disallow user vars and arrays, simply because mixing arrays and vars with an A_JumpIf statement already throws an error when trying to load up. But, at the same time, ACS doesn't seem to have that issue of checking... I wonder...

[FDARI]

OT, but: What? Mixing vars and arrays how? Mixing two valid (integer) expressions that do not by themselves throw errors (on load/parse)? If that is true, surely it must be a bug. As long as you speak of combining them with the use of appropriate operators. What errors have you seen?

[Major Cooke]

@FDARI: Alright then, example time.

---

This was done when performing A_JumpIf(user_immo[0] == 0,1) when user_immo was not declared as an array. It's just a user variable instead.

Decorate parser also errors if the user variable/array is undefined (i.e. no 'var int user_blah' on the actor).



It might not for ACS, but DECORATE is surely having some checks done.

So that's why I'm hesitant.

[Graf Zahl]

And now take a good guess why this needs a solid fundament, and not some tacked on hack to circumevent the problem of a missing scripting language...
There's good reasons why these user variables would not be accessible, and trying to work around this will completely undermine the class hierarchy system (a.k.a. won't add.)

Even if it all were actually typed, target, tracer and master are AActor pointers and AActor doesn't know anything about subclasses' user variables. You'd have to add proper type casts and a rat's tail of other things to make this a stable approach.

[Major Cooke]

Yeah. I figured there was something more complex. Thank you for explaining that.

But, what do you think about the rest of the DECORATE expressions, graf? Just the simpler stuff like mass, velx/y/z, tid, etc.

Or would it actually be better to develop something like target.velx, tracer.mass, master.tid?

[Graf Zahl]

Adding a pointer type parameter is not the biggest problem, but you have to make sure that the expression gets processed in an AActor context, not one of the defining class. Obviously this will disable access to all user_* variables, but I really see no decent means to handle that case.

[Major Cooke]

Yeah, the more I think about it, the harder this is going to be. Hmmm...

EDIT: Nevermind.

[Graf Zahl]

Yuck...

[Major Cooke]

Yeah, I figured it would be gross as well. Unless someone else wants to try it, I'm pretty much going to assume this will just be WFDS.