ZScript Discussion

[Major Cooke]

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.

[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.

[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]

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.

[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.

[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.

[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.

[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.

[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]

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.

[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. (/hides from MCooke's wrath for that statement! )

[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);

[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.

[Graf Zahl]

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.

[Major Cooke]

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! )

---

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.