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.

Re: ZScript Discussion

Postby Major Cooke » Fri Dec 02, 2016 2:06 pm

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
Major Cooke
Do unto others as you would have unto you. Judge yourself first.
 
Joined: 28 Jan 2007

Re: ZScript Discussion

Postby Graf Zahl » Sat Dec 03, 2016 6:20 am

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 Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: ZScript Discussion

Postby Graf Zahl » Sat Dec 03, 2016 6:23 am

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.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: ZScript Discussion

Postby ZzZombo » Sat Dec 03, 2016 8:57 am

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.
ZzZombo
 
Joined: 16 Jul 2012

Re: ZScript Discussion

Postby Graf Zahl » Sat Dec 03, 2016 9:31 am

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
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: ZScript Discussion

Postby Major Cooke » Sat Dec 03, 2016 10:12 am

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
Major Cooke
Do unto others as you would have unto you. Judge yourself first.
 
Joined: 28 Jan 2007

Re: ZScript Discussion

Postby Nash » Sat Dec 03, 2016 11:13 am

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
Nash
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Github ID: nashmuhandes

Re: ZScript Discussion

Postby Player701 » Sun Dec 04, 2016 4:06 am

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 allExpand view
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 allExpand view
Call to member function GetReloadState with incompatible self pointer.

However, if I do add that qualifier, I cannot make the function virtual:

Code: Select allExpand view
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
Player701
 
Joined: 13 May 2009
Location: Russian Federation
Discord: Player701#8214
Operating System: Windows 10/8.1/8 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: ZScript Discussion

Postby Graf Zahl » Sun Dec 04, 2016 5:44 am

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.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: ZScript Discussion

Postby Lud » Sun Dec 04, 2016 9:06 am

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.
Lud
 
Joined: 11 Feb 2016

Re: ZScript Discussion

Postby Rachael » Sun Dec 04, 2016 9:17 am

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.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: ZScript Discussion

Postby D2JK » Sun Dec 04, 2016 9:18 am

It's still a mystery to me how to "ZScriptificate" functions using AAPTR_PLAYER_GETTARGET as the actor pointer, for example:
Code: Select allExpand view
A_CheckFlag(<flag>, <state>, AAPTR_PLAYER_GETTARGET);
A_GiveInventory(<item>, <count>, AAPTR_PLAYER_GETTARGET);
D2JK
 
Joined: 30 Aug 2014

Re: ZScript Discussion

Postby Graf Zahl » Sun Dec 04, 2016 10:10 am

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 Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: ZScript Discussion

Postby Graf Zahl » Sun Dec 04, 2016 10:12 am

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
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: ZScript Discussion

Postby Major Cooke » Sun Dec 04, 2016 10:21 am

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:
User avatar
Major Cooke
Do unto others as you would have unto you. Judge yourself first.
 
Joined: 28 Jan 2007

PreviousNext

Return to Scripting

Who is online

Users browsing this forum: No registered users and 1 guest