ACS: GetActorZ always returns 89 when above activator

[D00MWolf]

I've been getting some models into a little stand-alone iwad TC I've been working on, and ran into the following error:

I wrote a script to make an actor adjust it's pitch to face it's target.
The code works great, but whenever I (it's target) am higher than the monster in question,
the monster's angle locks at 89 degrees.
I've narrowed it down to the ACS function GetActorZ, which is what's giving a faulty Z when I'm above it.
Has anyone else experienced this issue? Any potential solutions would be great.

The code is:
Decorate:

---

REIN A 0 A_SetUserVar(user_zdif,CallACS("GetTargetZ"))
REIN A 0
{
if(user_zdif>0)
{
A_SetPitch(atan(abs(CallACS("GetTargetZ")-z)/GetDistance(false,AAPTR_TARGET))*-1,SPF_INTERPOLATE | SPF_FORCECLAMP); //An attempt to prevent the issue
//A_LogInt(atan(CallACS("GetTargetZ")-z/GetDistance(false,AAPTR_TARGET)),false);
}
else
{
A_SetPitch(atan(CallACS("GetTargetZ")-z/GetDistance(false,AAPTR_TARGET)),SPF_INTERPOLATE | SPF_FORCECLAMP);
//A_LogInt(atan(CallACS("GetTargetZ")-z/GetDistance(false,AAPTR_TARGET)),false);
A_LogInt(atan(CallACS("GetTargetZ")-z));
}
}

And the ACS script:

---

Script "GetTargetZ" (void)
{
int ActorZ = GetActorZ(0);
if(SetActivatorToTarget(0))
{
int TargetZ = GetActorZ(0);
if(TargetZ-ActorZ<0) //This is another failed attempt to prevent this issue.
{
ACS_NamedExecute("GetActivatorZ",0);
//SetResultValue(TargetZ*-1);
}
else
{
SetResultValue(TargetZ);
}
}
Else
{
SetResultValue(false);
}
}

[krokots]

Probably because you are using integer istead of double / float / fixed. Change the variable type to double in Deco or fixed in ACS.

Code: Select all

fixed ActorZ = GetActorZ(0);

[KeksDose]

int is fine and the only possibility in acc. You can use a fixed type in gdcc but even then, int is still usable the same way.

atan gets closer to 90° the steeper the slope you enter is. I think you have to divide the callacs result by 65536 (or shift right by 16 using >>). It's because GetActorZ returns a fixed which, in acs, is actually an interpretation of a really really huge number to allow decimals, and the script will just return that really huge value which decorate won't sanely interpret for you. (Unless if you change the user var type to float it calls another version that does just that for you, then nevermind that.)

I think you might get unnoticeable precision issues which can be avoided by typecasting the callacs result to float or something before dividing. It's kinda messy.

[D00MWolf]

Dividing it by 65536 has worked.
Though it's upwards angle doesn't exceed 89 degrees, the monster will be floating above the player
most of the time, so it won't be a problem.