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

Re: ZScript Discussion

Post by Major Cooke »

For that matter you don't even need the \n too I take it?
User avatar
Nash
 
 
Posts: 17446
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia

Re: ZScript Discussion

Post by Nash »

You still do if you're closing the quotes. Otherwise it just treats each quoted section as being side-by-side. Have a look at the MAPINFO LANGUAGE lump inside GZDoom

EDIT: sorry not MAPINFO, I mean the intermission strings inside GZDoom's LANGUAGE lump
User avatar
Nash
 
 
Posts: 17446
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia

Re: ZScript Discussion

Post by Nash »

Hello I need some advice, I really hope to get some useful answers. I want to make a class that can exist in the world, and can also exist as just data.

Let's call the class Container. You can use it to put things inside, like a treasure chest or a box. Let's say the Container can hold Inventory inside it.

In addition to being able to be placed in the map editor/in the world, I also want the player to be able to pick up the container, which means it will be removed from the world and into the player. And I want every item stored inside the container to continue living on inside the Container (NOT transferred to the player!!!).

I want to be able to go, "let's check what's inside the Container that the player is currently carrying. Oh, I see a Pistol, a Shotgun, and some Shells".

And then of course, the player can drop the Container back into the world and it'll spawn back into the world, along with whatever was stored into it.

How would I set this up? Please and thank you.
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine

Re: ZScript Discussion

Post by ZZYZX »

Inventory item that has own inventory using invoker pointer?
User avatar
Matt
Posts: 9696
Joined: Sun Jan 04, 2004 5:37 pm
Preferred Pronouns: They/Them
Operating System Version (Optional): Debian Bullseye
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia

Re: ZScript Discussion

Post by Matt »

Can this recursion go on indefinitely? :shock:

(And would this also mean each unit of ammo a player is carrying can have its own inventory?)
User avatar
Major Cooke
Posts: 8182
Joined: Sun Jan 28, 2007 3:55 pm
Preferred Pronouns: He/Him
Location: QZDoom Maintenance Team

Re: ZScript Discussion

Post by Major Cooke »

So intermissions are next then, Graf? Or is it the sbarinfo stuff?
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49090
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: ZScript Discussion

Post by Graf Zahl »

Right now it's just a preliminary cleanup pass on the intermission stuff. It needs some serious refactoring before getting exported.

I'm a bit short on time right now to think about the statusbar, and this is something that can be done in small pieces.
User avatar
Nash
 
 
Posts: 17446
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia

Re: ZScript Discussion

Post by Nash »

Thank you Graf, _mental_ and ZZYZX for the very fast fixes to the ZScript and EventHandlers issues I've been reporting recently, and thanks for putting up with my lame questions and pleas for help, and ZZYZX thank you for taking a look at the files I sent you and helping figuring out what the problems were. I have everything I need in working condition and ready to trash all my cringey ACS-based systems. :D

Now the long process of re-writing all my crap begins... it's going to take a long time... :D
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine

Re: ZScript Discussion

Post by ZZYZX »

Graf: we should probably do something about various event structs and enums in ZScript.
Right now we have parallelly your direct copy of C++ event struct (which is really lame and non-user-friendly with it's data1/data2/data3), and my nice representation of the same data in UiEvent, most likely because my events and your menus were developed in parallel and unconnected way as well.
As with any feature duplication, I think one of these needs to be thrown out before the release of 2.4 and I hope that UiEvent can stay.

1. ui event in event system (note the proper and intuitive field names): https://github.com/coelckers/gzdoom/blo ... ts.txt#L40
2. event in menu system (why is it in base.txt anyway?): https://github.com/coelckers/gzdoom/blo ... ase.txt#L1
3. code that generates an UiEvent: https://github.com/coelckers/gzdoom/blo ... s.cpp#L955

Also, my reasoning behind having UiEvent fixed was mainly that I didn't want to construct and destruct thousands of DObject's every tick, instead I assume that the event processing is singlethreaded anyway (and the event struct is not needed outside of event processing function), so I constructed it once and reused.
If such massive construction and destruction is actually ok, then we can actually make all stuff inheriting from BaseEvent non-fixed and constructible/copyable/non-transient, and reuse the same object for menu system and whatever other places we'll ever need key/mouse events in.

My system also clearly distinguishes between UiEvent and InputEvent, because InputEvent is playsim, whereas UiEvent isn't.
(also going to finish the separation thing and submit as PR in near future)
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49090
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: ZScript Discussion

Post by Graf Zahl »

ZZYZX wrote:Graf: we should probably do something about various event structs and enums in ZScript.
Right now we have parallelly your direct copy of C++ event struct (which is really lame and non-user-friendly with it's data1/data2/data3), and my nice representation of the same data in UiEvent, most likely because my events and your menus were developed in parallel and unconnected way as well.
In the menu the creation of event objects is totally irrelevant. This isn't even remotely time critical code. Of course, generally converting events to objects is not a good idea, when the game runs this really can add up. The main reason I left it unchanged is that I wanted to port the existing code 1:1 and any change in variables is an added source of errors. Now that it's all done it may be prettified.

One thing that really bothers me about the parser is that it can't do character constants, though, because it used up the single quotes for names. Do you have any good idea that doesn't involve string hacks?
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine

Re: ZScript Discussion

Post by ZZYZX »

Use `` for char constants. That's really weird but better than nothing, and most keyboards have it, which fits the requirements for a programming language.
Although honestly if it was up to me I'd use `` for name constants instead, because it's names, not char, that's the new concept to ZScript relatively to other programming languages, and there's an already established way to denote char constants.
Alternatively we may as well just use strings for characters like Python and PHP do it without noticeable performance regressions.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49090
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: ZScript Discussion

Post by Graf Zahl »

Hm. I could allow one-character strings or names to pass as integers (or just reserve names 1-127 for the respective characters - this should be deliberately restricted to ASCII to avoid problems should a transition to UTF-8 take place), that's really all that is needed. But that will definitely require a bit of testing to find all places in the compiler that need fixing.

In retrospect I don't get it why the grammar had so many odd conventions. Some I was able to fix when I noticed them, but this just never registered as a problem until it was too late.
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine

Re: ZScript Discussion

Post by ZZYZX »

I disagree with limiting it to 127, should be 0-255. People use one-byte non-ASCII encodings a lot, more specifically russian mods that use single-byte windows-1251 cyrillic encoding, which works perfectly with ACS, LANGUAGE and FONTDEFS.
Also, utf-8 won't be affected because utf-8 is two chars, and trying to support utf-8 natively is a bad idea IMO — ZDoom itself has nothing to support it.
User avatar
arookas
Posts: 265
Joined: Mon Jan 24, 2011 6:04 pm

Re: ZScript Discussion

Post by arookas »

But the point was to avoid transition problems from ASCII to Unicode. The first 255 code points in Unicode are Latin-1, which corresponds to code pages such as Windows-1252, not Windows-1251. I agree with 0-127 being a better choice.
Gez
 
 
Posts: 17836
Joined: Fri Jul 06, 2007 3:22 pm

Re: ZScript Discussion

Post by Gez »

UTF-8 is a variable number of chars, from 1 to 4, depending on the glyph. So a standard ASCII character like 'z' is one byte in utf-8 (7a), while an extended ASCII symbol like '°' is two bytes (c2 b0), then when you get to more exotic letters like 'শ' (Bengali character "sha") you get three bytes (e0 a6 b6) and eventually when you get to stuff like ancient Byzantine musical symbols then yeah you'll need four bytes.

For Russian-language stuff utf-8 will be two-bytes, but it's not the generic case. The advantage of utf-8 is that it's remarkably backward-compatible with ASCII, contrarily to utf-16 and utf-32.

Return to “Scripting”