"How do I ZScript?"

[Blue Shadow]

Is there a way to access zscript variables via ACS?

If you mean local class variables, then use [wiki]GetUserVariable[/wiki].

[Major Cooke]

Wait, that actually works? I somehow have my suspicions...

Anyway... Now I have a question.

Code: Select all

Overlay.View:
"####" "#" 0
{
    
    if (player == null)    return ResolveState("Null");
    let plr = self.player;
    PSprite pspr = plr.GetPSprite(OverlayID());
    
    pspr.Sprite = GetSpriteIndex("M022");
    
    
         if (ustoff >= 32)    { pspr.Frame = 23;    }
    else if (ustoff >= 31)    { pspr.Frame = 22;    }
    else if (ustoff >= 29)    { pspr.Frame = 21;    }
    else if (ustoff >= 27)    { pspr.Frame = 20;    }
    else if (ustoff >= 26)    { pspr.Frame = 19;    }
    else if (ustoff >= 25)    { pspr.Frame = 18;    }
    else if (ustoff >= 23)    { pspr.Frame = 17;    }
    else if (ustoff >= 22)    { pspr.Frame = 16;    }
    else if (ustoff >= 21)    { pspr.Frame = 15;    }
    else if (ustoff >= 19)    { pspr.Frame = 14;    }
    else if (ustoff >= 18)    { pspr.Frame = 13;    }
    else if (ustoff >= 17)    { pspr.Frame = 12;    }
    else if (ustoff >= 15)    { pspr.Frame = 11;    }
    else if (ustoff >= 14)    { pspr.Frame = 10;    }
    else if (ustoff >= 13)    { pspr.Frame = 9;    }
    else if (ustoff >= 11)    { pspr.Frame = 8;    }
    else if (ustoff >= 10)    { pspr.Frame = 7;    }
    else if (ustoff >= 9)    { pspr.Frame = 6;    }
    else if (ustoff >= 7)    { pspr.Frame = 5;    }
    else if (ustoff >= 6)    { pspr.Frame = 4;    }
    else if (ustoff >= 5)    { pspr.Frame = 3;    }
    else if (ustoff >= 3)    { pspr.Frame = 2;    }
    else if (ustoff >= 2)    { pspr.Frame = 1;    }
    else                    pspr.Frame = 0;
    return ResolveState("HVWContinue");
}
 

I'm trying to change this psprite's sprite and frame but it keeps saying it's not flagged for use in weapons... The thing is though, this overlay isn't being called nor set upon a weapon, it's being called upon the player itself. No weapon has anything to do with this particular overlay. Bug?

[Matt]

Since we're on the subject, I think I'm having some kind of scope issues and/or misunderstandings. I've got a weapon, and it seems I can't get or manipulate certain variables in Tick(). Like, GetPlayerInput doesn't seem to return anything, I can't use variables like angle/pitch, etc. It seems those things only work in either anonymous or action functions?

Is Tick() running at all while the weapon is being carried? If so, what does work?

[Caligari87]

General variable manipulation works for variables defined on the weapon (at least while the weapon is active) namely all the stuff I'm doing here. But any action functions or seemingly anything like "angle" simply doesn't work. I can't do "newangle += GetPlayerInput" or "newangle = angle", etc.

By the way Vae, how do you keep track of rounds inside magazines while they're in the inventory or on the ground?

[AFADoomer]

Wait, that actually works? I somehow have my suspicions...

I had some actors in BoA that were converted to ZScript from Decorate, and Get/SetUserVariable certainly works for the original user_* variables... I haven't tried getting/setting a non-'user_'-prefixed variable with it.

EDIT: Just confirmed, something like "SetUserVariable(86, "nonmoving", 1);" in ACS, when 'nonmoving' is a ZScript bool works just fine.

[Matt]

If you want the player's angle on a setup like that see if "owner.angle" works - it might be interpreting self to be the weapon.

I don't keep track of mag amounts while they're on the player - it's all random. If I were to try it'll probably be similar to what you've got. On the ground, it's part of HD's custom pickup system: it tracks its own amount and on pickup passes it to the player. One can probably set up something similar for a more conventional manner of picking things up through +inventory.transfer.

[Caligari87]

So is it that simple if I want to put that angle tracking on the player instead? Just move all that "newangle += oldangle whatever" into the player's Tick state, and from the weapon use "owner.newangle"?

edit: Doesn't seem to work. Getting unknown identifier and ambiguous context errors.

[nazakomu]

(suggestions welcome, I guess)

Give me a better keyword and we're in business.

Can something like "ptrother" the context meaning to point to other non-actor states. Or if you want it to reference the invoker then it can be something like "omitinvokerptr" essentially in context meaning to omit (pass) the invoker pointer -- and even just to condense it for the purpose of minimalization, "omitinv" could be used in the same context as the previous one but instead 'inv' naturally shortening invoker unlike the latter—which of course that is to say—the wiki will explain what it all means and its usage(s) respectively.

Hope these are plausible or can incite more ideas for anyone else whom wants to offer suggestions. It's quite tricky to come up with a fitting term considering this is ad hoc and it can be a diminutively difficult to come up with something rather short and sweet.

[Xaser]

Give me a better keyword and we're in business. BTW, the 'action' keyword was required for any action function until I realized that I only needed to make a minimal change to the code to lift the restriction

To parrot a classic joke: there are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors.

I've got nothing off the top of my head, but I'll noodle it for a while. A stepping stone may be coming up with a less jargon-y term for "non-actor state," though who knows if that's any easier.

Since we're on the subject, I think I'm having some kind of scope issues and/or misunderstandings. I've got a weapon, and it seems I can't get or manipulate certain variables in Tick(). Like, GetPlayerInput doesn't seem to return anything, I can't use variables like angle/pitch, etc. It seems those things only work in either anonymous or action functions?

Maybe this will help: When calling action functions from weapons, recall that "self" refers to the player actor (PlayerPawn), while "invoker" is a pointer to the weapon itself. Tick(), however, is not subject to this rule -- "self" is the weapon. Same for other virtuals, like BeginPlay(), etc. -- anything not marked "action", basically.

GetPlayerInput only works if you call it on the player actor, so in Tick(), you'll indeed need to use the "owner" variable to access the PlayerPawn who owns it.

However, keep in mind that the type of the "owner" variable is Actor, so if you have a custom player class and wish to access any variables on it, you'll need to cast it first. Something like "let player = MyPlayerPawn(self.owner);" followed by a null check will probably solve all your troubles (and let you keep all the logic in the weapon, if you desire).

[Mikk-]

Okay stupid question but can 2D arrays not have a larger second dimension than the first dimension?
Say for example I have an array defined as test[8][11] - if I then assign index [1][9] I get an out of bounds error..? but if I assign index[1][7] I do not get an error, which is rather strange...

Code: Select all

class c_arraytest : actor
    {
    
    int c_testarray[8][11];
    
    override void postbeginplay()
        {
        super.postbeginplay();
        
        c_testarray[1][9] = 1;
        }
    } 

[Gutawer]

It's kinda weird, but the assignment order for the dimensions and the access order are actually swapped around, you probably want int c_testarray[11][8] instead. That little problem had me annoyed for at least half and hour when I ran into it, lol.

[Mikk-]

what, why? maybe it's because I'm no programmer but that seems simply absurd and completely random... not to mention illogical

[Gez]

I've got nothing off the top of my head, but I'll noodle it for a while. A stepping stone may be coming up with a less jargon-y term for "non-actor state," though who knows if that's any easier.

Was my suggestion of "proxy" or "indirect" missed?

[Xaser]

I've got nothing off the top of my head, but I'll noodle it for a while. A stepping stone may be coming up with a less jargon-y term for "non-actor state," though who knows if that's any easier.

Was my suggestion of "proxy" or "indirect" missed?

No -- I'm just not totally sold of either of those.

[EDIT] To explain a bit, "proxy" kinda makes sense technically, but "what am I proxying?" doesn't really have a satisfactory answer without knowing the technical specifics. "Indirect" ditto.

Names are hard.

[Nash]

It's kinda weird, but the assignment order for the dimensions and the access order are actually swapped around, you probably want int c_testarray[11][8] instead. That little problem had me annoyed for at least half and hour when I ran into it, lol.

WTF that sounds like a bug... why hasn't something this severely broken been reported yet?