ZScript Discussion

[Major Cooke]

What you need, Zombie, is P_SlideMove exported... or P_XYMovement.

[Major Cooke]

Actually I got it to work. I even got the camera to keep perfectly aligned over the helmet while moving. The beauty of power that is ZScript at your fingertips~.

• The camera no longer updates its own position. At all. Ever. Only the player does now, but the player still retrieves the proper z info from the camera itself.
• If movement is blocked, only give velocity to the player so it won't shimmy around like nuts. Still a little shimmer when sliding along the wall but I believe it's to the point where I wouldn't even care for it during gameplay.

The lesson to learn here is... If you want synchronized movements, let ONE class handle actor moving because all their function calls are processed at the same time.

[The Zombie Killer]

There were still some issues with the above, but it gave me quite a few ideas on how to fix it. After a short read-through of MC's example, and some messing around, I've finally managed to get it working properly.
It still gets a little buggy if you try to enter a small gap between an actor and a wall, but I'll need to wait for SlideMove to get exposed (if it ever does) to improve on this any further.

[ZZYZX]

What's "transient"? It seems to be a new keyword in the latest GZDoom devbuild, used among these.

[Graf Zahl]

It is for variables that are not to be stored in savegames, i.e. stuff that's only needed for temporary calculations.

[ZZYZX]

So we can now detect savegame loading by transient variable suddenly becoming null

[Graf Zahl]

There's already ways to detect savegame loading by checking some specific fields in Actor, so it's hardly anything new. But this flag is needed, for example, if a class contains some large work array that would bloat the savegame otherwise.

[ZZYZX]

I wasn't like "I found a way to slip through the SECURITY". Simply noted that it's quite useful, for example for doing some HUD effects after savegame loading (think doom4, which displays the current level progress).

[Nash]

Code: Select all

class Shadow_ZombieMan : ZombieMan
{

    Default
    {
        YScale 0.1;
        RenderStyle "Stencil";
        StencilColor "Black";
        Alpha 0.5;
        +DORMANT
        +NOINTERACTION
        -COUNTKILL
    }

    // reference to owner
    Actor ownerRef;

    override void Tick(void)
    {
    }
}

class ZombieMan_WithShadow : ZombieMan replaces ZombieMan
{
    // reference to shadow
    Actor shadowRef;

    override void BeginPlay(void)
    {
        Super.BeginPlay();

        // spawn the shadow
        Actor sh = Spawn("Shadow_ZombieMan", pos, NO_REPLACE);

        if (sh != null)
        {
            // store reference to owner in the shadow
            sh.ownerRef = self; // ERROR

            // set spawn angle to owner's angle
            sh.Angle = Angle;

            // store reference to shadow
            shadowRef = sh;
        }
    }
}
 

Help, why can I not access ownerRef? How do I get access to it correctly?

[ZZYZX]

Also, why is the concept of "private" and "protected" fields/methods introduced?
I can understand why these exist in C++, as public interfaces are supposed to be binary compatible and using undocumented/internal things will fail on slightest modifications.
But here in ZScript it will mean that it won't be possible to duplicate the behavior of existing stuff while a bit altering it. (/me looks at partially rewritten AActor::Tick)

#freethedata #pythonrules

bump. Apparently this got lost in the post stream.

[Graf Zahl]

Because some functions are just a small part of a larger non-separable chunk of code that shouln't be called from the outside. The fact that C++ conventions have abused these qualifiers to hell and back doesn't make them pointless.

As an example have a look at the code for Hexen's Wraithverge. It consists of several functions but in reality is just one large thing where external code shouldn't call the single functions.

[ZZYZX]

Now imagine if I want to slightly change the behavior of A_CHolySeek, while reimplementing the rest of the function.
Example: CHolySeekerMissile(args[0], args[0]*4.);
CHolySeekerMissile is private and quite large. Copypaste? What's the point exactly?
Among other stuff I can also tell that hexen/flies.txt has some nice private functions too Not like I'd personally try to inherit that, and corpses are in the blockmap now, but still.

Perhaps use protected instead, if it's present? Protected actually makes a lot more sense IMO.

[The Zombie Killer]

-snip-

Help, why can I not access ownerRef? How do I get access to it correctly?

Code: Select all

Shadow_ZombieMan(sh).ownerRef = self;

Although I'd just change the line you spawned the actor with:

Code: Select all

let sh = Shadow_ZombieMan(Spawn("Shadow_ZombieMan", pos, NO_REPLACE)); 

[Nash]

The Zombie Killer:

Thanks. For reference, what is the act of doing Class(Variable) actually called? I don't quite understand why this even works in the first place.

[Xaser]

@Nash: the term you're looking for is "type casting" (or just "casting"). See here (and also here -- zscript casting is basically c++'s dynamic_cast) for some info.

Without going too far into programmer geekdom, the gist is that ZScript knows that the variable "sh" is an Actor (since that's what Spawn returns), but it doesn't know that your Actor is also a Shadow_Zombieman until you explicitly tell it that it is -- which you'll have to do in order for the code to find any of the new stuff (like ownerRef) you've defined in the Shadow_Zombieman class.