ZScript Discussion

[D2JK]

AAPTR_PLAYER_GETTARGET, for example is equivalent to simply calling AimTarget() for the player actor.

Thanks! I was now able to replace the remaining A_CheckFlag functions.

However, it seems I cannot flat-out replace the old pointer name inside functions, such as GetDistance():

Code: Select all

A_LogInt(GetDistance(1, AimTarget()));
-> error message: "Numeric type expected".

But I guess it's not supposed to be used like that anyway.

[Graf Zahl]

Of course not. The AAPTR system is a crutch because it had to work around the lack of real pointers. AimTarget returns a pointer, not a constant.

Calling AimTarget is roughly the same as calling GetPointer(AAPTR_PLAYER_GETTARGET), i.e. you get the actual pointer the engine would get if called with the AAPTR constant.

[XxMiltenXx]

2 Questions.

Code: Select all

Accessing deprecated member variable X

What would be the "new" way to access the coordinates in ZScript?

And that leads me to the 2nd qs:
If the engine informs you about a deprecated feature, couldn't it also tell what it has been superseded by, or would that be too much work?

[D2JK]

Coordinates are now pos.x, pos.y and pos.z in ZScript.
Similarly, velocities are now vel.x, vel.y and vel.z.
Look here: Converting DECORATE code to ZScript

[Accensus]

Will user variables work properly with weapons in ZScript?

[Graf Zahl]

You have means to access them but the limitations that made them a problem in DECORATE still exist, namely that 'self' points to the player, not the weapon.
You have to refer to them with 'invoker.variable'.

[Major Cooke]

Is SpecialMissileHit it a one-time trigger until the actors stop touching, and begin retouching?

[MaxED]

Some ZScript - DECORATE interoperability questions:
1. Is this a thing (e.g. can a mod use both ZScript and DECORATE)? If this is not a thing, you can ignore the rest of the questions.
2. What's the parsing order? ZScript first, DECORATE second?
3. Can ZScript class be inherited from DECORATE actor?
4. Can DECORATE actor be inherited from ZScript class?
5. Can DECORATE actor be spawned from ZScript class (for example, using Spawn() or A_SpawnItemEx())?
6. Can ZScript class be spawned from DECORATE actor?
7. Can DECORATE actor replace ZScript class (using "replaces" keyword)?
8. Can ZScript class replace DECORATE actor?
9. Can consts and enums defined in DECORATE be used in ZScript? Can the opposite happen?

[Rachael]

1. Yes, it is a thing. And yes, a mod can use both ZScript and DECORATE.
2. ZScript first.
3. No. DECORATE can inherit from ZScript actors, but not the other way around.
4. Yes. See above.
5. It should be possible, but Graf will have to confirm that for me. I don't see any reason why not.
6. Yes.
7. Yes.
8. No.
9. No. Not sure about the opposite, though.

[Player701]

Is it possible right now to set default values for local variables and make them overridable in subclasses? I.e. something like this:

Code: Select all

class BaseClass : Actor
{
  int Test;
  
  Default
  {
    Test 1;
  }
}

class DerivedClass : BaseClass
{
  Default
  {
    Test 2;
  }
}

Right now it says

Code: Select all

'test' is an unknown actor property

Maybe the syntax is different from the one that is used with existing properties? If there is no way at all, will it become possible in the future?

[Graf Zahl]

Some ZScript - DECORATE interoperability questions:
1. Is this a thing (e.g. can a mod use both ZScript and DECORATE)? If this is not a thing, you can ignore the rest of the questions.
2. What's the parsing order? ZScript first, DECORATE second?
3. Can ZScript class be inherited from DECORATE actor?
4. Can DECORATE actor be inherited from ZScript class?
5. Can DECORATE actor be spawned from ZScript class (for example, using Spawn() or A_SpawnItemEx())?
6. Can ZScript class be spawned from DECORATE actor?
7. Can DECORATE actor replace ZScript class (using "replaces" keyword)?
8. Can ZScript class replace DECORATE actor?
9. Can consts and enums defined in DECORATE be used in ZScript? Can the opposite happen?

1. Yes. An actor is an actor is an actor. Unknown references are being resolved after everything has been parsed.
2. All of ZScript first. DECORATE afterward
3. No. Since DECORATE is parsed last the info is not available.
4. Yes, in fact all current DECORATE is essentially doing that.
5. Yes. See 1.
6. Yes, See 4.
7. Yes, See 4.
8. No. See 2.
9. Partially. See the following remark. Opposite: Yes, to the extent that DECORATE can handle constants in the desired context.

In short: DECORATE has complete access to everything defined in ZScript. ZScript only can access things from DECORATE that have deferred initialization. The compiler backend only runs after both ZScript and DECORATE have been parsed, so everything inside a function won't get resolved until after all data has been created. This means you can refer to DECORATE-defined classes and their constants inside script code. Stuff outside functions is different, this gets mostly resolved at parse time, with the sole exception of class types.

[ZZYZX]

Is it possible right now to set default values for local variables and make them overridable in subclasses?

Defaults block is a gross hack to support DECORATE properties. I highly doubt it works with own variables.

[Graf Zahl]

Not yet. The thing with the defaults is that the entire actor construction system is based on a defaults block stored somewhere. Most of the properties in there directly translate to a same-named variable, but some are more complex, others need a bit of postprocessing. Long story short: It was kept for editing friendliness, because otherwise all this would have to be written out as script code (not desirable)

There will have to be some means to declare a newly added variable a 'property', but that's for ZScript phase 2.

[Major Cooke]

Is SpecialMissileHit it a one-time trigger until the actors stop touching, and begin retouching?

Since it appears this one was missed.

[ZzZombo]

IIRC, it's a virtual method that allows missiles to perform custom actor impact logic, like the hooking attack of the Loremaster.