ZScript Discussion

[Nash]

Curious. Would it be possible to have local vars on players that could be saved when transitioning from one map to another, like inventory?

I hope this would be possible in future, too. In Unreal Engine, the class is called PlayerController and it stays persistent across maps. Only the PlayerPawn is the physical thing that you see running around the level, and those get created and destroyed per level. You would store things like the player's experience points on the PlayerController and those would never get destroyed between levels.

[Nash]

Code: Select all

class Z_Player : DoomPlayer
{
    Default
    {
        Player.StartItem "Fist";
    }

    override void Tick()
    {
        A_SetAngle(angle + 0.0025, SPF_INTERPOLATE);
        A_SetRoll(roll + 0.0025, SPF_INTERPOLATE);
        Super.Tick();
    }
}

How do I use the Tick function correctly? Just trying to make a quick test for now by making a silly test player that's supposed to change its angle and roll by itself every tic. But it's not working. And yes, the player class is defined correctly because when I run the game, I start with a player who only has his fists.

EDIT: I forgot that the angles in DECORATE is in degrees. The correct way is:

Code: Select all

class Z_Player : DoomPlayer
{
    Default
    {
        Player.StartItem "Fist";
    }

    override void Tick()
    {
        // roll the view 1 degree every tic. wheeeee
        A_SetRoll(roll + 1.f);
        Super.Tick();
    }
}
 

ZScript version of QTilt.pk3 incoming!!! >8D

[Major Cooke]

Suggestion: Don't do it on the doom player itself. Have something else do it instead. I.e. have an ACS script spawn an actor which then grabs the player(s) immediately, and performs stuff on them. The ACS would be merely to spawn the actor, nothing more.

Otherwise, it'll be far less mod compatible. Just look at all the players who complained qtilt done fucking broke with D4D.

Curious. Would it be possible to have local vars on players that could be saved when transitioning from one map to another, like inventory?

I hope this would be possible in future, too. In Unreal Engine, the class is called PlayerController and it stays persistent across maps. Only the PlayerPawn is the physical thing that you see running around the level, and those get created and destroyed per level. You would store things like the player's experience points on the PlayerController and those would never get destroyed between levels.

Please and thank you.

[Ed the Bat]

Is there a method yet to retrieve the class name of a player? I have a set of ACS scripts that are named after player classes (with the word "Spawner" on the end; concatenation would hopefully help me address that), and would like to call them just based on what classes are being played, so I'll need the names in a format I can give to CallACS().

[Graf Zahl]

I hope this would be possible in future, too. In Unreal Engine, the class is called PlayerController and it stays persistent across maps. Only the PlayerPawn is the physical thing that you see running around the level, and those get created and destroyed per level. You would store things like the player's experience points on the PlayerController and those would never get destroyed between levels.

Actually, the PlayerPawn in ZDoom is carried over a level exit. You only lose it when you die and respawn.

[Nash]

Suggestion: Don't do it on the doom player itself. Have something else do it instead. I.e. have an ACS script spawn an actor which then grabs the player(s) immediately, and performs stuff on them. The ACS would be merely to spawn the actor, nothing more.

Otherwise, it'll be far less mod compatible. Just look at all the players who complained qtilt done fucking broke with D4D.

Qtilt was always meant to be a modder's resource/learning example... I didn't make it as a modular autoload thing. Not my fault that I can't control what players do with mods.

Making mods that alter the player's angle/pitch/roll be modular and play nice with each other is kind of difficult/impossible because ideally, the actual angle changes should only be handled at the end/close to the end of the "pipeline" and only called once. Everything that happens before this point in time should only collect a "buffer" of the angle changes. Good luck getting every mod to agree with this... :O

But yeah, point taken. Can you show me how to make another actor control the player pawns in their Tick method? I don't quite understand how to establish the relationship.

[D2JK]

About the Tick() function: if it's fairly simple to have the constant actions on an actor execute within states, are there any benefits in moving these actions into the Tick() function instead, such as (slightly) better performance?

[Graf Zahl]

No, it's about better control for some things. Tick() is the main driving function in the game, it gets executed once each tic. Which means it's better do do stuff that needs to be independent of states.

[Major Cooke]

So with this round of internal scripting conversion done, what's next?

[Graf Zahl]

I am goinfg though the source right now to see what function still need to be exported. After that, benchmarking. The VM currently allocated memory like crazy and I want to see where I can somehow get that under control and make faster. A scripted function call is a horrendously inefficient affair right now and the can cause problems later when code gets more complex.

[Major Cooke]

Here's one you can do.
Hmm, you did talk about attempting to export P_DamageMobj directly but that sounds like hell. It would be nice if something could be done about pain and/or wound functions.

[Major Cooke]

Oh snap. Local arrays are in now? Can they accept the same types as their constant counterparts?

[Nash]

@Major Cooke:

Can you show me how to make another actor control the player pawns in their Tick method? I don't quite understand how to establish the relationship.

Help me help you. I'm going to convert everything I've ever released into ZScript and I don't want to end up making stuff that will break your mods. :P

@Graf Zahl:

I have some C++ actors that do things like this:

Code: Select all

//===========================================================================
//
//===========================================================================
IMPLEMENT_CLASS (APrecipitation)

void APrecipitation::Tick ()
{
    Super::Tick ();

    if (tracer == nullptr)
    {
        return;
    }

    // hide rain from other players
    if (tracer != nullptr && tracer != players[consoleplayer].mo)
    {
        renderflags |= RF_INVISIBLE;
    }
}
 

Will ZScript allow scripted access to consoleplayer?

[Major Cooke]

D'oh fuck I forgot. Okay. I'll get to it in the morning.

[Edward-san]

Will ZScript allow scripted access to consoleplayer?

'consoleplayer' should work on you. But in any case that code would break with coop spying, so you should use '!tracer.CheckLocalView(consoleplayer)' in place of 'tracer != players[consoleplayer].mo'.