ZScript Discussion

[Xaser]

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.

[Matt]

"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:

---

I might as well copypaste this here (with a few modifications for clarity) since it seems to be more a discussion thing about what we should or should not assume about ZScript than a how-to:

I've got this code:

Code: Select all • Expand view

...
        thinkeriterator it=thinkeriterator.create("HDWeapon");
        HDweapon hdw;
        while(
            hdw=HDWeapon(it.Next())
        ){
            if(hdw.owner==self){
                int blx;
                if(hdw is "Lumberjack"){
                    blx+=100;
                    if(hdw.weaponstatus[1]>=0)blx+=BLOX_BATTERY_LOADED;
                }else if(hdw is "HDPistol"){
... 

and so on, with each "HDWeapon" owned by the caller adding a different value to "blx".

Which works fine, except this ends up with "blx" being some obscenely high number unless I explicitly reset it with "int blx=0". It seems that the value of "blx" is preserved for the next weapon every time it is declared.

Why is this? Shouldn't that int be re-initialized every time that "if(hdw.owner==self)" block is run?

EDIT: Nevermind, this part of Phantombeta's respose on the other thread finally got through my skull:

the same behaviour as C/C++ regarding uninitialized variables. (i.e. whatever garbage data was in the memory already becomes the variable's value)

Added a (possibly overly large) note to the wiki page on ZScript functions.

[stan423321]

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.

[Matt]

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.

[Xane123]

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?

[Illasera]

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.

[Kinsie]

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?

ZScript can call ACS scripts in the same way that DECORATE can, and ACS can call methods from a ZScript class using ScriptCall.

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.

[Apeirogon]

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 • Expand view

Execution could not continue.

No player classes defined

What wrong? Or this version only for example?

[Major Cooke]

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.