ZScript Discussion

Ask about ACS, DECORATE, ZScript, or any other scripting questions here!

Moderator: GZDoom Developers

Forum rules
Before asking on how to use a ZDoom feature, read the ZDoom wiki first. If you still don't understand how to use a feature, then ask here.

Please bear in mind that the people helping you do not automatically know how much you know. You may be asked to upload your project file to look at. Don't be afraid to ask questions about what things mean, but also please be patient with the people trying to help you. (And helpers, please be patient with the person you're trying to help!)
User avatar
Rachael
Posts: 13850
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: ZScript Discussion

Post by Rachael »

You won't displease me, I don't have strong preferences about this. It's a new system and no matter how it gets into place I'll have to learn it eventually and I am okay with that.

To be fair, though, I wouldn't be surprised if others find such intricacies with capitalization and flag names such as I have found. :P

While we're on the subject, however, there is one thing that concerns me - if you don't give the flags their own separate name space, that makes it harder to add flags to the engine without breaking mods. What if one day you decide to add a flag (hypothetically) called "InColor" but someone used a variable name "BinColor"?
User avatar
Major Cooke
Posts: 8197
Joined: Sun Jan 28, 2007 3:55 pm
Preferred Pronouns: He/Him
Location: QZDoom Maintenance Team

Re: ZScript Discussion

Post by Major Cooke »

Spoiler: Reaction
@Eruanna: Everywhere we turn, we're going to encounter something. Example: flagLightSector could be defined and taken up as well.
User avatar
Rachael
Posts: 13850
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: ZScript Discussion

Post by Rachael »

Major Cooke wrote:Example: flagLightSector could be defined and taken up as well.
True, but it's less likely than using a single letter which very quickly alters the meaning of words. :P

At any rate, like I said I'll just go along with what's decided, I'm not trying to put problems out there without proposing solutions, I am just anticipating what could be hurdles down the line. Something like that is actually a real show-stopper for expanding on DECORATE in the future.

Although, I suppose if it's like Lua, and the variables are explicitly declared in the context for which they are used, this is less of an issue because the actor can continue using the global copy for its flag and the local copy for its code.
Last edited by Rachael on Tue Oct 25, 2016 12:01 pm, edited 1 time in total.
User avatar
Major Cooke
Posts: 8197
Joined: Sun Jan 28, 2007 3:55 pm
Preferred Pronouns: He/Him
Location: QZDoom Maintenance Team

Re: ZScript Discussion

Post by Major Cooke »

I think this is why Graf wanted versioning specifications to avoid this sort of problem however. So not all hope will be lost. If someone defines a var or something from the past that happens to be the same name as a flag, perhaps it can auto-resolve itself based on version and determine the appropriate type for it.

And indeed, it'd only be a problem for the defined actor(s).

But I'm just guessing, correct me if I'm wrong.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49192
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: ZScript Discussion

Post by Graf Zahl »

In the future it should be possible for subclasses to use variable names that are present in the base class and the code of course select the subclass version.
Edward-san
Posts: 1774
Joined: Sat Oct 17, 2009 9:40 am

Re: ZScript Discussion

Post by Edward-san »

One thing: how would you call the base version of an overridden function? super.A_Blah()?
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49192
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: ZScript Discussion

Post by Graf Zahl »

That's the idea. Although, if you have the need to do that it's better not to name your own function A_Blah, too. I'd assume if there's name clashes they are because the child class was based on an older version of the base class so this should never become a factor.
User avatar
Major Cooke
Posts: 8197
Joined: Sun Jan 28, 2007 3:55 pm
Preferred Pronouns: He/Him
Location: QZDoom Maintenance Team

Re: ZScript Discussion

Post by Major Cooke »

Okay Graf, sent you two private download links for D4D's latest in-development super secret crap. I tried running the ZScript branch with it but it just ups and quits after spamming me with warnings.
User avatar
randi
Site Admin
Posts: 7749
Joined: Wed Jul 09, 2003 10:30 pm

Re: ZScript Discussion

Post by randi »

Graf Zahl wrote:I'd also like to hear a word from Randi about the whole thing.
The 'b' prefix is my first choice, too. For consistency though, I feel it should also be possible to (optionally) use the bName from the default block.
Eruanna wrote: if you don't give the flags their own separate name space, that makes it harder to add flags to the engine without breaking mods.
The same could be said about every single property one could potentially attach to a class. A derived class will be able to declare variables that obscure variables in a base class, so nothing should break if a conflict comes up later on. It'll probably be a warning, but it won't be an error.
User avatar
Leonard2
Posts: 313
Joined: Tue Aug 14, 2012 6:10 pm

Re: ZScript Discussion

Post by Leonard2 »

Eruanna wrote:but to be fair, the first implementation of this is what we're all going to be stuck with
Exactly. Terrible memories of DECORATE arise.
"Can't change x because old mods rely on y."
Especially considering that the branch is going to be merged so soon, this is a big concern.
We waited so long for this so that kind of stuff is the very last thing we'd want to see happen to zscript.
I really hope that this will only be enforced after an actual zdoom release (ie not dev versions) containing zscript so as to give it enough time.
If as a modder you use features that are in development then it is your responsibility to keep up to date until a proper release is made in my opinion.
Graf Zahl wrote:Which of course means that I cannot prevent stupid modders from using stupid capitalization.
Making it case sensitive is not possible?
I also hate reading things like "Int" and "If"/"Else" from ACS.
Major Cooke wrote:what about the ability to set/get the sprite and frame directly?
That could be interesting.
Maybe it could even supersede the current state syntax. I mean someone could just come up with a function in their actor that chooses the actor's sprite/frame based on whatever is desired and have it run each time said actor ticks.
User avatar
Major Cooke
Posts: 8197
Joined: Sun Jan 28, 2007 3:55 pm
Preferred Pronouns: He/Him
Location: QZDoom Maintenance Team

Re: ZScript Discussion

Post by Major Cooke »

Leonard2 wrote:
Major Cooke wrote:what about the ability to set/get the sprite and frame directly?
That could be interesting.
Maybe it could even supersede the current state syntax. I mean someone could just come up with a function in their actor that chooses the actor's sprite/frame based on whatever is desired and have it run each time said actor ticks.
Hell yes. This would be a blessing, covered in gravy if it could pair numbers to letters (or using a ToChar() converter of sorts.)
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49192
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: ZScript Discussion

Post by Graf Zahl »

randi wrote:
Graf Zahl wrote:I'd also like to hear a word from Randi about the whole thing.
The 'b' prefix is my first choice, too. For consistency though, I feel it should also be possible to (optionally) use the bName from the default block.
That can be decided later, if we will allow an alternative syntax there. As you may have noticed, I completely ripped out the initial implementation which was just regular code and instead plugged in the original DECORATE property dispatcher - and this of course should remain to make porting easier, but I am not against allowing regular assignments later, too, where the bXX syntax can be used.
Last edited by Graf Zahl on Wed Oct 26, 2016 2:21 am, edited 2 times in total.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49192
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: ZScript Discussion

Post by Graf Zahl »

Leonard2 wrote:
Eruanna wrote:but to be fair, the first implementation of this is what we're all going to be stuck with
Exactly. Terrible memories of DECORATE arise.
"Can't change x because old mods rely on y."
Especially considering that the branch is going to be merged so soon, this is a big concern.
We waited so long for this so that kind of stuff is the very last thing we'd want to see happen to zscript.
I really hope that this will only be enforced after an actual zdoom release (ie not dev versions) containing zscript so as to give it enough time.
If as a modder you use features that are in development then it is your responsibility to keep up to date until a proper release is made in my opinion.
This will definitely be considered work in progress until the implementation is sufficiently complete. While I think that some parts are complete, there's no guarantee that everything will remain stable. But if you take a look at the few functions I already ported you'll see that most of the basics are already usable - and very unlikely to change.

Leonard2 wrote:
Graf Zahl wrote:Which of course means that I cannot prevent stupid modders from using stupid capitalization.
Making it case sensitive is not possible?
I also hate reading things like "Int" and "If"/"Else" from ACS.
I believe keywords are case sensitive, I never checked, but identifiers are not, and this cannot be changed. That would have been possible if the name system that is the base of all this had been designed case-sensitively, but it is not and too much depends on it to be case insensitive.
Edward-san
Posts: 1774
Joined: Sat Oct 17, 2009 9:40 am

Re: ZScript Discussion

Post by Edward-san »

While testing zscript I got an assertion when A_CPosRefire is called (which is when a chaingun guy attacks):

Code: Select all

zdoom: /home/edward-san/zdoom/branch/zscript/src/scripting/vm/vmexec.h:927: static int VMExec_Checked::Exec(VMFrameStack *, const VMOP *, VMReturn *, int): Assertion `(unsigned)((pc[0].c)) < f->NumRegD' failed.
with pc[0].c = 4 and f->NumRegD = 2. It's easy to reproduce, just summon the actor and let it fire.
User avatar
Major Cooke
Posts: 8197
Joined: Sun Jan 28, 2007 3:55 pm
Preferred Pronouns: He/Him
Location: QZDoom Maintenance Team

Re: ZScript Discussion

Post by Major Cooke »

Graf, it still crashes upon trying to start up using the mod I sent you.

Return to “Scripting”