Page 52 of 123
Re: ZScript Discussion
Posted: Sun Dec 04, 2016 11:25 am
by 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.
Re: ZScript Discussion
Posted: Sun Dec 04, 2016 11:41 am
by 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.
Re: ZScript Discussion
Posted: Sun Dec 04, 2016 3:54 pm
by 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?
Re: ZScript Discussion
Posted: Sun Dec 04, 2016 4:09 pm
by 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
Re: ZScript Discussion
Posted: Sun Dec 04, 2016 5:52 pm
by Accensus
Will user variables work properly with weapons in ZScript?
Re: ZScript Discussion
Posted: Sun Dec 04, 2016 6:08 pm
by 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'.
Re: ZScript Discussion
Posted: Sun Dec 04, 2016 10:04 pm
by Major Cooke
Is SpecialMissileHit it a one-time trigger until the actors stop touching, and begin retouching?
Re: ZScript Discussion
Posted: Mon Dec 05, 2016 3:16 am
by 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?
Re: ZScript Discussion
Posted: Mon Dec 05, 2016 4:10 am
by 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.
Re: ZScript Discussion
Posted: Mon Dec 05, 2016 4:16 am
by 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?
Re: ZScript Discussion
Posted: Mon Dec 05, 2016 5:02 am
by Graf Zahl
MaxED wrote: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.
Re: ZScript Discussion
Posted: Mon Dec 05, 2016 5:12 am
by ZZYZX
Player701 wrote: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.
Re: ZScript Discussion
Posted: Mon Dec 05, 2016 6:03 am
by 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.
Re: ZScript Discussion
Posted: Mon Dec 05, 2016 8:38 am
by Major Cooke
Major Cooke wrote:Is SpecialMissileHit it a one-time trigger until the actors stop touching, and begin retouching?
Since it appears this one was missed.
Re: ZScript Discussion
Posted: Mon Dec 05, 2016 8:52 am
by ZzZombo
IIRC, it's a virtual method that allows missiles to perform custom actor impact logic, like the hooking attack of the Loremaster.