ZScript Discussion
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!)
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!)
-
- Posts: 8196
- Joined: Sun Jan 28, 2007 3:55 pm
- Preferred Pronouns: He/Him
- Location: QZDoom Maintenance Team
Re: ZScript Discussion
@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.
@Enjay: The only limitation is, it appears, via inheritance.
-
-
- Posts: 17934
- Joined: Fri Jul 06, 2007 3:22 pm
Re: ZScript Discussion
Basically, ask yourself this question: what do you absolutely need to know to initialize the currently-parsed actor:Enjay wrote: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.)
- 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
-
-
- Posts: 26574
- Joined: Tue Jul 15, 2003 4:58 pm
- Location: Scotland
Re: ZScript Discussion
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.
-
- Posts: 219
- Joined: Sat Dec 05, 2015 2:18 pm
Re: ZScript Discussion
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?
-
- Lead GZDoom+Raze Developer
- Posts: 49184
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: ZScript Discussion
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.
You can do gameplay control with ZScript but it's a lot more complex than ACS and not everything relevant has been exported yet.
-
- Posts: 219
- Joined: Sat Dec 05, 2015 2:18 pm
Re: ZScript Discussion
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?
-
-
- Posts: 10773
- Joined: Sun Jul 20, 2003 12:15 pm
Re: ZScript Discussion
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.]
[*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.]
-
- Posts: 219
- Joined: Sat Dec 05, 2015 2:18 pm
Re: ZScript Discussion
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.
-
- Posts: 386
- Joined: Thu Jun 11, 2015 8:38 am
Re: ZScript Discussion
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
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
-
-
- Posts: 10773
- Joined: Sun Jul 20, 2003 12:15 pm
Re: ZScript Discussion
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.
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.
-
- Posts: 386
- Joined: Thu Jun 11, 2015 8:38 am
Re: ZScript Discussion
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..?
I can't actually seem to find the code for Doom1's world map either..?
-
- Lead GZDoom+Raze Developer
- Posts: 49184
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: ZScript Discussion
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.
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.
-
- Posts: 20
- Joined: Thu May 11, 2017 7:22 am
Re: ZScript Discussion
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)
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)
Last edited by Illasera on Sat May 13, 2017 12:57 pm, edited 1 time in total.
-
- Lead GZDoom+Raze Developer
- Posts: 49184
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: ZScript Discussion
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.
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.
-
- Posts: 20
- Joined: Thu May 11, 2017 7:22 am
Re: ZScript Discussion
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 languageGraf Zahl wrote: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.
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.