Page 123 of 123

Re: ZScript Discussion

PostPosted: Mon Sep 11, 2017 2:17 pm
by 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.

Re: ZScript Discussion

PostPosted: Mon Sep 11, 2017 4:39 pm
by 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:
Spoiler:
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.

Re: ZScript Discussion

PostPosted: Mon Sep 11, 2017 5:11 pm
by 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.

Re: ZScript Discussion

PostPosted: Mon Sep 11, 2017 7:22 pm
by 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.

Re: ZScript Discussion

PostPosted: Sun Sep 17, 2017 8:23 am
by 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?

Re: ZScript Discussion

PostPosted: Mon Sep 18, 2017 4:19 pm
by 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.

Re: ZScript Discussion

PostPosted: Sun Oct 01, 2017 12:38 am
by Kinsie
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?
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.

Re: ZScript Discussion

PostPosted: Wed Oct 18, 2017 8:22 am
by Apeirogon
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 allExpand view
Execution could not continue.

No player classes defined


What wrong? Or this version only for example?

Re: ZScript Discussion

PostPosted: Thu Oct 19, 2017 1:44 pm
by 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.