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.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.
ZScript Discussion
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!)
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!)
-
- Posts: 8196
- Joined: Sun Jan 28, 2007 3:55 pm
- Preferred Pronouns: He/Him
- Location: QZDoom Maintenance Team
Re: ZScript Discussion
-
- Lead GZDoom+Raze Developer
- Posts: 49182
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: ZScript Discussion
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.
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.
-
- Lead GZDoom+Raze Developer
- Posts: 49182
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: ZScript Discussion
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.
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.
-
- Posts: 317
- Joined: Mon Jul 16, 2012 2:02 am
Re: ZScript Discussion
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.
-
- Lead GZDoom+Raze Developer
- Posts: 49182
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: ZScript Discussion
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.
-
- Posts: 8196
- Joined: Sun Jan 28, 2007 3:55 pm
- Preferred Pronouns: He/Him
- Location: QZDoom Maintenance Team
Re: ZScript Discussion
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.
+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.
-
-
- Posts: 17465
- Joined: Mon Oct 27, 2003 12:07 am
- Location: Kuala Lumpur, Malaysia
Re: ZScript Discussion
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.
-
-
- Posts: 1682
- Joined: Wed May 13, 2009 3:15 am
- Graphics Processor: nVidia with Vulkan support
Re: ZScript Discussion
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:
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:
However, if I do add that qualifier, I cannot make the function virtual:
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.
Code: Select all
States(Weapon)
{
Reload:
TNT1 A 0
{
return GetReloadState();
}
}
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.
Code: Select all
Invalid combination of qualifiers GetReloadState on function virtual, action.
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.
-
- Lead GZDoom+Raze Developer
- Posts: 49182
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: ZScript Discussion
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.
-
- Posts: 2383
- Joined: Thu Feb 11, 2016 9:59 am
Re: ZScript Discussion
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.
-
- Posts: 13791
- Joined: Tue Jan 13, 2004 1:31 pm
- Preferred Pronouns: She/Her
Re: ZScript Discussion
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. (/hides from MCooke's wrath for that statement! )
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. (/hides from MCooke's wrath for that statement! )
Last edited by Rachael on Sun Dec 04, 2016 9:18 am, edited 1 time in total.
-
- Posts: 545
- Joined: Sat Aug 30, 2014 8:21 am
Re: ZScript Discussion
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);
-
- Lead GZDoom+Raze Developer
- Posts: 49182
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: ZScript Discussion
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.
AAPTR_PLAYER_GETTARGET, for example is equivalent to simply calling AimTarget() for the player actor.
-
- Lead GZDoom+Raze Developer
- Posts: 49182
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: ZScript Discussion
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.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.
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.
-
- Posts: 8196
- Joined: Sun Jan 28, 2007 3:55 pm
- Preferred Pronouns: He/Him
- Location: QZDoom Maintenance Team
Re: ZScript Discussion
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. (/hides from MCooke's wrath for that statement! )
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.