ZScript Discussion

[Major Cooke]

For that matter you don't even need the \n too I take it?

[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

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

[ZZYZX]

Inventory item that has own inventory using invoker pointer?

[Matt]

Can this recursion go on indefinitely?

(And would this also mean each unit of ammo a player is carrying can have its own inventory?)

[Major Cooke]

So intermissions are next then, Graf? Or is it the sbarinfo stuff?

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

[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

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

[Graf Zahl]

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?

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

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

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

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

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.