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
Major Cooke
Posts: 8196
Joined: Sun Jan 28, 2007 3:55 pm
Preferred Pronouns: He/Him
Location: QZDoom Maintenance Team

Re: ZScript Discussion

Post by Major Cooke »

Graf Zahl wrote:Because the grammar cannot recursively include other lumps. For that it'd need a full preprocessor.
This is a spot that definitely needs some work. I don't like it either but so far it was ok for testing this stuff. It's also one of the main reasons why I haven't merged it yet. This definitely needs a proper fix before going officially public.
And it's stuff like that which makes me hold off the documenting until after it's ready. Because I had no idea this was temporary.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49183
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: ZScript Discussion

Post by Graf Zahl »

I just changed how includes work to do it properly with a dedicated #include command.
The old way was mostly a hack, that came to be when I noticed that having ZSCRIPT just being a file list would be a constant source of annoyance because you'd always need two lumps.
The file list was done because a grammar cannot do recursion like this without massive changes to how files are being read.

But since I have since then written the compiler to work in a mostly order-independent fashion all those considerations are relatively moot, if the parser finds an include, it gets stored in a list. If the same file is found twice, the second occurence will be ignored. The next item on the list will then get processed after its predecessor is complete. This will continue until there' s no more entries left in the list.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49183
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: ZScript Discussion

Post by Graf Zahl »

BTW, this should make the first iteration feature complete. This, the missing duplicate variable error and the proper exception reporting were the last 3 items I deemed essential for it.
I also think we can now declare most of what is there final with no more need to change. This also means, once a decision is made, nothing in there can be changed anymore.

So this is the time where I have to ask the users: Is there anything that appears to rough, too unfinished, too clumsy or cumbersome to use? Now is the final time to speak up. Once this is made somewhat official it has to be set in stone so that existing mods won't break.
ZzZombo
Posts: 317
Joined: Mon Jul 16, 2012 2:02 am

Re: ZScript Discussion

Post by ZzZombo »

I hope then you won't make any decisions before I'll wake up next morning... I just finished playing with the new Perl 6, so I'll have time for checking this out too.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49183
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: ZScript Discussion

Post by Graf Zahl »

Don't worry. I'll wait one week until considering a preliminary merge to master (i.e. still considerered 'moving target under review') and Christmas as the earliest for making it an official part.
User avatar
Major Cooke
Posts: 8196
Joined: Sun Jan 28, 2007 3:55 pm
Preferred Pronouns: He/Him
Location: QZDoom Maintenance Team

Re: ZScript Discussion

Post by Major Cooke »

That's the best Christmas gift I'll be receiving from anyone this year.

+1 vote to Graf Zahl for best Santa. HO HO HOly SHIT. This Christmas will be amazing! And even if it comes out later than that, Graf still has my vote. :mrgreen:
User avatar
Nash
 
 
Posts: 17465
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia

Re: ZScript Discussion

Post by Nash »

No objections from me, syntax-wise - everything is acceptable. Then again, I haven't done anything ultra complex yet but so far this all seems very much a nice thing (it's familiar enough to DECORATE, yet it gives me almost the power of C++... how can I complain?!). :) Thanks once again, Graf.
User avatar
Player701
 
 
Posts: 1685
Joined: Wed May 13, 2009 3:15 am
Graphics Processor: nVidia with Vulkan support

Re: ZScript Discussion

Post by Player701 »

Problem: I'd like to define my own virtual function for a weapon, similar to GetUpState / GetDownState etc., let's call it something like GetReloadState. My state code has to be like this it seems:

Code: Select all

States(Weapon)
{
  Reload:
    TNT1 A 0
    {
      return GetReloadState();
    }
}
The default implementation of GetReloadState returns a state which is of course not called Reload but something different; let it be a convention to be followed when deriving from my class. It also performs some ammo checks to determine whether the weapon actually needs to be reloaded, and jumps to Ready state if it doesn't.

According to the information posted in this thread, functions called from weapon states must have the "action" qualifier, for otherwise I get the following error:

Code: Select all

Call to member function GetReloadState with incompatible self pointer.
However, if I do add that qualifier, I cannot make the function virtual:

Code: Select all

Invalid combination of qualifiers GetReloadState on function virtual, action.
Without it being virtual, there is little sense for such a function since it is designed specifically to be overridden in derived classes. The state code above may look like a hack, but I don't see any other way since there is no native GetReloadState() function to override.

I could create a separate function which should be called in the beginning of the Reload state by every derived class, but this would break encapsulation, since I wanted the ammo-checking logic to be built into the base class but with the possibility to change it if necessary.

What should I do here?

Upd: Resolved. Should use "invoker.GetReloadState()" in state code.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49183
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: ZScript Discussion

Post by Graf Zahl »

Yes, the 'invoker' part is crucial here. Action functions were blocked from being virtual because they can lead to subtle errors that are very hard to detect.
Accensus
Posts: 2383
Joined: Thu Feb 11, 2016 9:59 am

Re: ZScript Discussion

Post by Accensus »

From what I see in the Closed Feature Suggestions, the whole Feature Suggestions forum is going to go out of business. ZScript seems overpowered and unlocks almost everything that's been suggested and not added.
User avatar
Rachael
Posts: 13793
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: ZScript Discussion

Post by Rachael »

That is totally not true.

While a lot of the game logic will be definable in ZScript, there's still a lot of internal engine code that will not be exported. Examples include the renderer, certain action functions, the ACS VM (although some functions might be exported, who knows, we'll see), UDMF parser, etc. So there's plenty of room for feature suggestions, still.

At the very least, completion of ZScript will help keep Major Cooke out of the feature suggestions forum, for the most part, until he needs to tinker with the renderer, itself. :P (/hides from MCooke's wrath for that statement! :P)
Last edited by Rachael on Sun Dec 04, 2016 9:18 am, edited 1 time in total.
D2JK
Posts: 545
Joined: Sat Aug 30, 2014 8:21 am

Re: ZScript Discussion

Post by D2JK »

It's still a mystery to me how to "ZScriptificate" functions using AAPTR_PLAYER_GETTARGET as the actor pointer, for example:

Code: Select all

A_CheckFlag(<flag>, <state>, AAPTR_PLAYER_GETTARGET);
A_GiveInventory(<item>, <count>, AAPTR_PLAYER_GETTARGET);
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49183
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: ZScript Discussion

Post by Graf Zahl »

All the AAPTR stuff is encapsulated by a single native function called GetPointer. Of course in ZScript you shouldn't use this stuff to begin with, there's normally better ways to get the pointers.

AAPTR_PLAYER_GETTARGET, for example is equivalent to simply calling AimTarget() for the player actor.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49183
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: ZScript Discussion

Post by Graf Zahl »

Lud wrote:From what I see in the Closed Feature Suggestions, the whole Feature Suggestions forum is going to go out of business. ZScript seems overpowered and unlocks almost everything that's been suggested and not added.
What I cleaned out today was suggestions that would have been clumsy to be added engine side but should be relatively simple when being able to write a script function.
Obviously scripting will mean that a lot of DECORATE related suggestions can be closed on sight now because they are directly achievable with scripting. As was one of the main driving points here to allow modders to do stuff without requesting engine changes.
User avatar
Major Cooke
Posts: 8196
Joined: Sun Jan 28, 2007 3:55 pm
Preferred Pronouns: He/Him
Location: QZDoom Maintenance Team

Re: ZScript Discussion

Post by Major Cooke »

Eruanna wrote:At the very least, completion of ZScript will help keep Major Cooke out of the feature suggestions forum, for the most part, until he needs to tinker with the renderer, itself. :P (/hides from MCooke's wrath for that statement! :P)
Spoiler: Eruanna...
When it all becomes available, that will be the case. But that's a loooooooong way to go. Silver lining, it won't take 20 years this time. :twisted:

Return to “Scripting”