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: 10773
- Joined: Sun Jul 20, 2003 12:15 pm
Re: ZScript Discussion
Regarding crashing, it's worth disambiguating something: If the "crash" in question kicks you out of the game to the console, that's called a "VM Abort" and it's generally indicative of user error (9 times out of 10 it's a missing null check ;), so further self-investigation is a good idea first. If it's a full-on crash showing that a "submit a report" error dialog, then definitely report that though.
-
- 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
"Crashes on exit" made me think of this, so I didn't even consider the possibility he was talking about a VM crash to console.
Re: trusting contents of gzdoom.pk3 to be stable-ish: Things seem to be a lot more stable now than they were at the beginning of the year, but I'd keep my mind open for alternative methods and workarounds for anything that's too obscure or possibly relying on an oversight in the original implementation.
EDIT:
Re: trusting contents of gzdoom.pk3 to be stable-ish: Things seem to be a lot more stable now than they were at the beginning of the year, but I'd keep my mind open for alternative methods and workarounds for anything that's too obscure or possibly relying on an oversight in the original implementation.
EDIT:
Spoiler:EDIT: Nevermind, this part of Phantombeta's respose on the other thread finally got through my skull:
Added a (possibly overly large) note to the wiki page on ZScript functions.the same behaviour as C/C++ regarding uninitialized variables. (i.e. whatever garbage data was in the memory already becomes the variable's value)
Last edited by Matt on Mon Sep 11, 2017 5:15 pm, edited 1 time in total.
-
- Posts: 32
- Joined: Tue Mar 25, 2014 2:35 pm
Re: ZScript Discussion
Thanks for attention involving the crash issue. It has been a confusing thing and I'm not sure if I'll manage to replicate it - it could very well be a missing null check regarding target pointer after an A_Look triggering. The thing is, GZDoom crashed on my command to exit, with regular Windows "program stopped working" window. Definitely wasn't a case of the built-in report request, I think I stumbled upon that long ago and it looked more thorough. What really concerned me about the crash was that... weird moment to trigger. If I'll get there again, I'll show you the code, but after spending some time trying to regenerate it I don't think it's worth it in this particular case, since it was very likely my error anyway.
Any further information on the reason for VM function calls being hard on computers and status of gzdoom.pk3 definitions is welcome.
One thing that I forgot last time is the "user_"-prefix convention. Since it's seemingly still on, what does it cover? The apparently logical assumption would be that the code parser itself should potentially be able to distinguish the stuff I've seen it used on (class fields, custom functions) from later standardized usage except when concerning new keywords (ignoring version declaration at the moment) due to declarations making the intent clear, while the places where resolution problems would seemingly be outright impossible to prevent without flipping the table on current usage schemes - class names, and especially state labels with their automatic overriding - seem to universally abstain from it.
Since the map issue has came up, facility allowing a mapping of anything, erm, mappable, to integers combined with an array of pointers to everything and a stack of empty slots result in alright facility allowing a mapping of anything mappable to everything. This is probably a trivial thought but it doesn't hurt to say it aloud.
----
Regarding variables initializing to zero, my C++-originating assumption is that a low level variable that is not initialized is not initialized. You rented a memory cell and you may want to look on thrash left inside for some silly reason. I remember some affair with someone utilizing such thrash in security RNG of a commonly used software thing and someone else screwing it up by explicitly initializing it thinking that was a mistake.
Additionally it appears that ZScript, like ACS, does not (unfortunately, but understandably) really have block scoped variables, which suggests a thing or two about implementation. The declaration is probably shifted in the process to the internal equivalent of the top of the function, a'la old C. With an initialization, an assignment remains (?) where the declaration was, without one, nothing is left.
Any further information on the reason for VM function calls being hard on computers and status of gzdoom.pk3 definitions is welcome.
One thing that I forgot last time is the "user_"-prefix convention. Since it's seemingly still on, what does it cover? The apparently logical assumption would be that the code parser itself should potentially be able to distinguish the stuff I've seen it used on (class fields, custom functions) from later standardized usage except when concerning new keywords (ignoring version declaration at the moment) due to declarations making the intent clear, while the places where resolution problems would seemingly be outright impossible to prevent without flipping the table on current usage schemes - class names, and especially state labels with their automatic overriding - seem to universally abstain from it.
Since the map issue has came up, facility allowing a mapping of anything, erm, mappable, to integers combined with an array of pointers to everything and a stack of empty slots result in alright facility allowing a mapping of anything mappable to everything. This is probably a trivial thought but it doesn't hurt to say it aloud.
----
Regarding variables initializing to zero, my C++-originating assumption is that a low level variable that is not initialized is not initialized. You rented a memory cell and you may want to look on thrash left inside for some silly reason. I remember some affair with someone utilizing such thrash in security RNG of a commonly used software thing and someone else screwing it up by explicitly initializing it thinking that was a mistake.
Additionally it appears that ZScript, like ACS, does not (unfortunately, but understandably) really have block scoped variables, which suggests a thing or two about implementation. The declaration is probably shifted in the process to the internal equivalent of the top of the function, a'la old C. With an initialization, an assignment remains (?) where the declaration was, without one, nothing is left.
-
- 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
If (say) you called something requiring target.health before the calling actor had any target, it should just crash to the GZDoom console.
The only way I've been able to crash out of GZDoom completely in a way that's clearly attributable to an error in my code is either
1. a syntax error (usually a semicolon at the end of a Decorate line) that causes GZDoom not to start at all;
2. an infinite loop;
3. a bug in GZDoom that happened to affect only one specific sort of code; or
4. an uninitialized variable.
(Aside re: 4: I was able to get an instant total crash using an uninitialized class<inventory>. The code immediately before that update would crash in the latest GZDoom development versions (but not 3.1.0 release) if I removed all armour. I'm beginning to suspect there are more examples of this sort of thing elsewhere in my code that is causing other, much harder to reproduce problems.)
The last time I recall a crash on exit was identified and resolved it involved a problem with GZDoom not knowing where to write config information in Linux, and was definitely a GZDoom bug.
The user_ prefix, as far as I'm aware, is not used at all in ZScript and is purely a Decorate method of declaring actor-specific variables. I don't think it should ever be used in ZScript unless you specifically want to organize all your variable names that way.
The only way I've been able to crash out of GZDoom completely in a way that's clearly attributable to an error in my code is either
1. a syntax error (usually a semicolon at the end of a Decorate line) that causes GZDoom not to start at all;
2. an infinite loop;
3. a bug in GZDoom that happened to affect only one specific sort of code; or
4. an uninitialized variable.
(Aside re: 4: I was able to get an instant total crash using an uninitialized class<inventory>. The code immediately before that update would crash in the latest GZDoom development versions (but not 3.1.0 release) if I removed all armour. I'm beginning to suspect there are more examples of this sort of thing elsewhere in my code that is causing other, much harder to reproduce problems.)
The last time I recall a crash on exit was identified and resolved it involved a problem with GZDoom not knowing where to write config information in Linux, and was definitely a GZDoom bug.
The user_ prefix, as far as I'm aware, is not used at all in ZScript and is purely a Decorate method of declaring actor-specific variables. I don't think it should ever be used in ZScript unless you specifically want to organize all your variable names that way.
-
- Posts: 165
- Joined: Tue Nov 24, 2015 1:58 pm
- Graphics Processor: nVidia (Modern GZDoom)
- Location: Inwood, WV
Re: ZScript Discussion
ZScript looks similar to the source code of GZDoom and it confuses me, so I wouldn't know how to implement it without learning, but can it and ACS interact?
I assume without checking the documentation that it can't get ACS’ variables and vice versa. Also, what things in ZScript are limited to the tic rate other than DECORATE?
I assume without checking the documentation that it can't get ACS’ variables and vice versa. Also, what things in ZScript are limited to the tic rate other than DECORATE?
-
- Posts: 20
- Joined: Thu May 11, 2017 7:22 am
Re: ZScript Discussion
Unsure if its a "code suggestion", But i would like to suggest to extend the zscript prototytpe (as well the internal engine function) of
"RoughMonsterSearch" and "p_RoughMonsterSearch" to allow the acceptance of : "white-list/black-list of species" arguments and/or accepting/rejecting actor indices that will allow us to ignore/search for monsters that are not the first to be found by the function.
Of course, you can give such prototypes , default arguments not to break existing compatibility.
"RoughMonsterSearch" and "p_RoughMonsterSearch" to allow the acceptance of : "white-list/black-list of species" arguments and/or accepting/rejecting actor indices that will allow us to ignore/search for monsters that are not the first to be found by the function.
Of course, you can give such prototypes , default arguments not to break existing compatibility.
-
- Posts: 7402
- Joined: Fri Oct 22, 2004 9:22 am
- Graphics Processor: nVidia with Vulkan support
- Location: MAP33
Re: ZScript Discussion
ZScript can call ACS scripts in the same way that DECORATE can, and ACS can call methods from a ZScript class using [wiki]ScriptCall[/wiki].Xane123 wrote:ZScript looks similar to the source code of GZDoom and it confuses me, so I wouldn't know how to implement it without learning, but can it and ACS interact?
For a simple-ish real-world example of this, look at zscript.txt and the TITLEMAP in Juvenile Power Fantasy - when it comes time to display the TITLEPIC image, the script uses ScriptCalls to a ZScript actor to get the image's width and height, to accomodate mapsets that used higher-resolution TITLEPICs.
-
- Posts: 1606
- Joined: Mon Jun 12, 2017 12:57 am
Re: ZScript Discussion
Major Cooke wrote: I've converted D4D over to zscript for those who want to test it out (you'll need to build zdoom yourself unless someone posts one). Load order is as follows (click links to download):
D4DResources.pk3
D4D.pk3
Code: Select all
Execution could not continue.
No player classes defined
-
- Posts: 8196
- Joined: Sun Jan 28, 2007 3:55 pm
- Preferred Pronouns: He/Him
- Location: QZDoom Maintenance Team
Re: ZScript Discussion
That thing is old as hell. Here, go get the new one from the appropriate thread.
Also removed those from the OP as they're no longer relevant.
Also removed those from the OP as they're no longer relevant.