ZScript Discussion

[Major Cooke]

@Chl: A metric fuckton. Graf's advice: Learn how to program with Java and/or C++. Also check the wiki which has a bunch of stuff documented already, but more stuff is still being documented.

@Enjay: The only limitation is, it appears, via inheritance.

[Gez]

Sorry if this has been discussed already but there are 118 pages here.

I understand that on startup, ZScript is processed first, then DECORATE. What would happen if a ZScript actor made reference to a DECORATE actor in its definition (e.g. the ZScript actor spawned a DECORATE actor (say as a projectile), or had an inventory check for a DECORATE actor etc etc.)

Basically, ask yourself this question: what do you absolutely need to know to initialize the currently-parsed actor:

• Just the referenced actor's name: then it'll work, because you have the name already
• The referenced actor's properties and/or its state list: then it definitely won't work, because these things aren't known yet at this point

So, to spawn a DECORATE actor: just fine. To check inventory for a DECORATE actor: just fine. To inherit from a DECORATE actor: bzzzt! error.

[Enjay]

OK, that's clear enough, thanks. I haven't really started meddling with ZScript yet (not sure how far I'll get with it TBH) but I have some existing actors that I thought might be worth converting but they reference other actors that I didn't fancy looking at just yet.

[Chl]

So did I get this correct, ZS is not a substitute for ACS during gameplay but rather something used during the initialization of your mod?

[Graf Zahl]

No. ZScript is code that gets executed during gameplay, it is mostly a replacement for internal C++ code.
You can do gameplay control with ZScript but it's a lot more complex than ACS and not everything relevant has been exported yet.

[Chl]

Gotcha, so I can continue to use ACS for now, and when it's more fleshed out I can change it to ZS without having to be concerned about stuff not working later?

[Xaser]

ACS and ZScript are neither replacements for each other* nor intended to be used for the same thing. ACS is all about map control (moving sectors, changing sidedef textures, etc.), whereas ZScript is for "everything else" (monsters, weapons, players, status bars, menus, etc). Unless you're doing map-triggered stuff within a map, ZScript is the way to go these days.


[*sort of -- a lot of mods use combinations of DECORATE+ACS for scripted stuff since ZScript is pretty recent, and as Graf mentioned, you can do map stuff in ZS, but those features are in their infancy.]

[Chl]

Yes, this is for map specific manipulation. That's why I asked if I can continue to use ACS for now, because it would be horrible if I found out later that it won't work with stuff I plan to add with ZS. Just to be safe.

[camaxide]

I'd like a push in the right direction on how to add an event to the intermission between levels.
After the kill-count and time is done showing the numbers and stats I'd like to make a couple things happening.
In the old decorate code I used Enterpic, and I could chose between 1: Displaying a world map showing where the player had been and where he was going, or 2: Show a picture of the map he was about to enter.
Now I want to first Display the world map, then go on to show a picture of the next map. (Like going first to Enterpic, then going to a second enterpic after that)
Last in line the code will go by a cluster entertext (all my maps will do this).

I got the code working for all this, but with Decorate I have to pick either world map or picture, as the old code does not allow for both in succession while also showing a cluster entertext in the end.

Though with the new version of zDoom and GzDoom Graf has said this should now be possible through ZScript, but that such a function needs to be coded.

I've looked through the codes in the new GzDoom.pk3 looking for some hints on zscript codeing for intermission, and through zscript in the wiki, but I can't find where to start or anything to go by.

Is there a place I can find zscript version of the intermission in Doom1 and Doom2? Or is there any other place I can look to get closer to understanding how such a code can be done?

I know nothing about C++ or such, though ACS Scripting, Decorate etc. I've done plenty off. I hope someone can push me a bit in the right direction as I really want to get this working for my mod. - please ask if anything in my comment is not easily understandable

[Xaser]

If it helps, the ZScript code for the stat screen can be found in the "zscript/statscreen" folder in gzdoom.pk3 -- or here online. It's a bit complex, but it's a starting point.

You ought to be able to inherit from DoomStatusScreen and then start tinkering with things, though you'll need to be sure to register your new status screen class in MAPINFO, like so -- see the "statscreen_*" properties under the "gameinfo" block.

[camaxide]

Thanks Xaser, I had not found that screen actually. I'm not entirely sure if it has the code I look fore though, as it seem it only covers the actual score-count page, which I don't intend to alter, it's the "pages" coming up next (the ones usually placed in enterpic code) I'd like to change the behaviour of.
I can't actually seem to find the code for Doom1's world map either..?

[Graf Zahl]

DoomStatusScreen derives from StatusScreen which contains the rest. You still need one of the derived classes to inherit all existing functionality.
The important variable here is CurState. This defines which page is currently being displayed, so what you need to do is to give this a value not covered by the standard elements and then override the Drawer and Ticker methods and possibly a bit of other stuff, too, to get something new in there.

[Illasera]

Some questions regarding logging/IO , datatypes and structures

1.)Is there a memory set/zeroing function for variables of a given size (primitive datatypes/structures/arrays, all are the same pretty much), equal to the C memset standard function? so i won't have to use a pseudo-like copy constructor?

2.)Any support/plans for a "sizeof" operator?

3.)Any way to print high-resolution numeric datatypes such as "double" or int64/unsigned long long (if such datatype exists)

4.)For vector functions, is there any support for swizzling?

5.)For the "Arithmetic" type of variables (as refered to in the wiki page under "ZScript variable")
Is there any support for "unsigned" version of the datatypes above as well? if so
5a.)Any way to log/print unsigned datatypes?
5b.)Assuming that variables that aren't declared as "unsigned" are they "signed" by default?

6.)Is there any place except for the source code in which i can get more information on build-in datatypes/structs such as "Vector3" ?
for example, what "fields" is vector3 using and how can i access them. (this is a generic question related to all built-in datatypes/structures)

[Graf Zahl]

1): No. A memset equivalent is far too dangerous in the context of a scripted language and
2): Again no. Since type sizes can vary depending on the current platform, making this available runs a high risk of breaking things.
3): Double can be formatted with String.Format or Console.Printf. 64 bit integer types are currentlly not supported by the VM so it makes no sense implementing them in the language.
4): No. You have to rebuild the vector exoplicitly.
5): Unsigned types exist for bytes, shorts and ints. You format them just like in C: %u instead of %i.
6): The only non-integral built-in data types are Vector2, Vector3 and Color. Vector2 has fields x and y, Vector3 has x, y, z and xy (a Vector2 subvector of the first two components) Color has r, g, b, a.

[Illasera]

1): No. A memset equivalent is far too dangerous in the context of a scripted language and
2): Again no. Since type sizes can vary depending on the current platform, making this available runs a high risk of breaking things.
3): Double can be formatted with String.Format or Console.Printf. 64 bit integer types are currentlly not supported by the VM so it makes no sense implementing them in the language.
4): No. You have to rebuild the vector exoplicitly.
5): Unsigned types exist for bytes, shorts and ints. You format them just like in C: %u instead of %i.
6): The only non-integral built-in data types are Vector2, Vector3 and Color. Vector2 has fields x and y, Vector3 has x, y, z and xy (a Vector2 subvector of the first two components) Color has r, g, b, a.

Thank you for your answer, As far as the first 2 answers, They are bogus if you are going to emulate a C/C++ like languages as a scripting language
which promotes static typing, If that is actually the case in your first and second arguments, you are already going to run into problems
with zscript (if zscript could store/read compiled binaries) -> if one is to make a build under let's say the now dead ALPHA dec processor or the still alive and kicking powerPC/ARM processors using the "double" datatype (depends on the language gzdoom is compiled against and its version), you will run into accuracy discrepancies (And all of that would actually be the case if zscript was storing binaries, but it compiles the scripts in runtime as far as i know)
And compiling the scripts in runtime does actually give you another protection layer, because it will be compiled against the given architecture its running on
(if you are using any form of a C/C++ standard library and compiler when compiling gzdoom).

Your first two arguments would probably hold more water if zscript could store and load compiled data and not compile things at runtime.

If you are still worried about size, support for preprocessing directives and some macros to query the architecture will do just fine,
Now i can see the conflict here, it will add more of a headace to the scripters, But if you are guys are going for a pseudo-like C family language
what do you think that will happen? people will expect that.

Now of course, I think that the way zscript works is ok but describing some practices/methods as bad in the context of a SCRIPTING language, while the scripting language is trying to emulate a real low-level language, while claiming in the documentation that it handles things like in C/C++ , seems a bit inconsistent.