Ability to define pointer for A_JumpIf

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies
BBCode is OFF
Smilies are ON
Topic review
   

Expand view Topic review: Ability to define pointer for A_JumpIf

Re: Ability to define pointer for A_JumpIf

by NeuralStunner » Fri Nov 07, 2014 12:57 pm

Well, it looks like [wiki]SetActivator[/wiki] already supports pointer options. Assuming you'd be able to use TID 0, you could get actor values from the caller's pointed-to actors without needing any extra tinkering Decorate expressions. The function even returns false if the pointer is invalid, so that's your NULL check right there.

Make sure SetActivator can take TID 0 for current activator, and you can do some things:
Spoiler:
Not as clean-looking (especially once you have to convert ACS fixed point), but it would only require one small change to an ACS function (if that). You can even get elaborate and grab data there's no Decorate expression for.
Graf Zahl wrote:I think they could be grafted on the current parser and expression evaluator.
So on that note, I could go either way on this. Maybe it'd be good to do both (for the sake of ACS functionality as well).

Re: Ability to define pointer for A_JumpIf

by FDARI » Fri Nov 07, 2014 3:26 am

I think the people who do not handle that case at all, will have to accept a 0 for any numeric expression. If that's not right... they'll just have to check. We can't throw them an error, but if they don't define a specific behaviour for non-existent actor, they don't have one. That will never be the fault of zdoom.

For those who do care, {pointer}->exists might be a handy bool. A_JumpIf(target->exists && target->health < 1, "smellsdead"). Or exists(int ptr_selector). Similar notion.

I don't know if C++ pointer-resolution-member-reference syntax is ideal. Is it? As long as we're not letting modders work with pointers and data as different concepts, we'd only need one member syntax. No matter, I suppose. I'm used to C#. That's all.

Re: Ability to define pointer for A_JumpIf

by Graf Zahl » Fri Nov 07, 2014 2:24 am

NeuralStunner wrote:Really, I wouldn't mind not being able to access uservars for non-self pointers. (True pointer members like "target->health" are totally WFDS, so limitations are a given!) However, it's quite a lot more limited than something we already have that's partly able to do it!

I think they could be grafted on the current parser and expression evaluator. The real problem here is, how to handle NULL pointer checks with expressions, knowing full well that erroring out is out of the question because most developers won't understand the intricacies of 'real' programming and forget to add them themselves to every expression using such pointers...

Re: Ability to define pointer for A_JumpIf

by NeuralStunner » Thu Nov 06, 2014 5:15 pm

Really, I wouldn't mind not being able to access uservars for non-self pointers. (True pointer members like "target->health" are totally WFDS, so limitations are a given!) However, it's quite a lot more limited than something we already have that's partly able to do it!

I believe ACS can already access any and all of the data you can get from Decorate expressions. (Any exceptions? They can be added.) Then do a [wiki]SetActivatorToTarget[/wiki] expansion, so you can change activator to the tracer/master/etc. of the activator or TID match. Then it's a case of liberal CallACS use, for more or less the same end. You'd even be able to do cross-pointer work (E.G. comparing tracer's health to target's) which a simple pointer selector would lack.

So that's what has my vote.

Re: Ability to define pointer for A_JumpIf

by Major Cooke » Thu Nov 06, 2014 3:10 pm

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.

Re: Ability to define pointer for A_JumpIf

by Graf Zahl » Thu Nov 06, 2014 3:01 pm

Yuck...

Re: Ability to define pointer for A_JumpIf

by Major Cooke » Thu Nov 06, 2014 2:45 pm

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

EDIT: Nevermind.

Re: Ability to define pointer for A_JumpIf

by Graf Zahl » Thu Nov 06, 2014 2:32 pm

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.

Re: Ability to define pointer for A_JumpIf

by Major Cooke » Thu Nov 06, 2014 2:28 pm

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?

Re: Ability to define pointer for A_JumpIf

by Graf Zahl » Thu Nov 06, 2014 1:49 pm

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.

Re: Ability to define pointer for A_JumpIf

by Major Cooke » Thu Nov 06, 2014 10:04 am

@FDARI: Alright then, example time.
Spoiler:
So that's why I'm hesitant.

Re: Ability to define pointer for A_JumpIf

by FDARI » Thu Nov 06, 2014 1:53 am

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?

Re: Ability to define pointer for A_JumpIf

by Major Cooke » Wed Nov 05, 2014 5:28 pm

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

Re: Ability to define pointer for A_JumpIf

by NeuralStunner » Tue Nov 04, 2014 11:29 am

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

Re: Ability to define pointer for A_JumpIf

by StrikerMan780 » Tue Nov 04, 2014 1:37 am

NeuralStunner wrote: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])

Top