Ability to define pointer for A_JumpIf

[NeuralStunner]

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.

[Graf Zahl]

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

[FDARI]

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.

[NeuralStunner]

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:

---

Sample scripts:

Code: Select all

Script "GetExists" (Int PtrWho)
{
	SetResultValue ( SetActivator(0, PtrWho) );
}

Script "GetHealth" (Int PtrWho)
{
	If ( SetActivator(0, PtrWho) ) SetResultValue ( GetActorProperty(0, AProp_Health) );
}

// Etc.

Using from Decorate:

Code: Select all

TNT1 A 0 A_JumpIf (CallACS("GetExists", AAPtr_Target) && (CallACS("GetHealth", AAPtr_Target) <= 0), "Gotcha")

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.

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