ZScript Discussion

[JPL]

How to check for ZScript support thru ACS and use a fallback way if it isn't supported?

You could define a ZScript EventHandler that runs a particular ACS script that sets an ACS global bool to true, then check that bool from ACS? Haven't tried it but seems like it would work.

[ZZYZX]

Just try executing a ScriptCall that returns 1. If it doesn't return 1, there is no ZScript. (default value for unknown functions is 0)

[AFADoomer]

Graf, is it safe to introduce our own STAT_ numbers for thinkers? (I.e. using 7 for a stat number) Also, is there a set range for thinkers where the Tick function is not automatically called, besides 1 through 6 (STAT_INFO to STAT_STATIC)

A partial answer, from the troubleshooting thread for Blade of Agony performance, when I asked something similar:

Yes. You only have to be careful where to put stuff. Normally, anything between 80 and STAT_DEFAULT should be fine if it's actually thinking. Higher numbers than STAT_DEFAULT should be used with care, though. because the stuff in there depends on running after the game actors.
The numbers between STAT_DLIGHT and 80 should be left alone in case the engine needs to allocate new numbers.

I'm using "STAT_DEFAULT - 1" through "STAT_DEFAULT - 5" for several of the custom actors in BoA in order to limit the impact of ThinkerIterators, and there's at least one actor that is set to A_Warp to the position of another ACS-controlled actor that is specifically set to "STAT_SCRIPTS + 1" so that it will Tick *after* the ACS positioning happens so that the movement will interpolate more closely.

I'm 99% sure that the first actual "thinking"/ticking statnum is STAT_FIRST_THINKING, so anything below 32 won't Tick automatically...

[Graf Zahl]

Graf, is it safe to introduce our own STAT_ numbers for thinkers? (I.e. using 7 for a stat number) Also, is there a set range for thinkers where the Tick function is not automatically called, besides 1 through 6 (STAT_INFO to STAT_STATIC)

No, at the moment there are no reserved user ranges - but these will need to be properly defined to ensure that future engine additions do not cause problems.
Currently the first thinking statnum is 32, everything below will not get ticked.

[Major Cooke]

Only curious, but what happens if one goes over the maximum stat number + 1? Is that undefined behavior?

[Xaser]

Quick question: Is it actually necessary to prefix function names to prevent name collisions? What happens if I define a function named "SummonFlubalapo" on a custom actor and GZDoom later adds a "SummonFlubalapo" native function to Actor?

[Major Cooke]

Yes, it would cause a collision with your mod. The only time it won't cause one is if it's private (maybe protected too) on the parent, which leaves you open to redefine the function as if it was never done so since it's not visible to the child.

[ZZYZX]

This is why object versioning exists. It won't break if done right.

[Gutawer]

Just noticed that there's a map type which gives an unimplemented error when trying to use:

Code: Select all • Expand view

map<int, int> test; // test: Map types not implemented yet


- can I expect this to be added at some point in the near future? Would be quite useful for a small project I'm working on.

[Graf Zahl]

No, not really. The problem is that each possible map type needs to be backed by a native variant. With arrays and 7 basic types that was manageable. However, with maps it gets a lot more tricky. The traits of the key need to be abstracted and on top of that, instead of 7 basic types resulting in 7 arrays, you'll end up with 7*7 maps unless you put some severe restrictions on what and how the key can be used.

[Matt]

What in the world does "Class Actor cannot be found in the current translation unit." mean?

"translation unit" == "archive".

No, that is not correct. A translation unit is one ZSCRIPT lump with all its includes. If you have two of them in a single archive it's two translation units.

I found at least one exception to this, resulting in a translation unit error in which I've got a play-scope struct and an extension of it in another text file, both of them included in the same ZSCRIPT lump.

Should I attempt to report a bug?

[Graf Zahl]

It's probably just an incorrect error message. Structs are not supposed to be extensible.

[stan423321]

Here's, uhh, stuff I came up after some experimentation with ZScript and reading up what's on wiki right now.

What is the reason for discouraging of functions calling functions? Does it help at all to disassemble functions with common prologue into two functions called from states, or is that useless, or useless after bracing? Are there changes on the horizon? I like splitting things up, especially if they repeat heavily.

Experiments with passing Vector3 as parameter and a return value of a function lead to crashes on exit of GZDoom. Does that count as a bug? Are vectors not supposed to be passed like that at all? Could that be caused by functions calling functions being a relatively untested funcionality? Or perhaps pos isn't a Vector3 despite the similarities and getting it in as a parameter for such a function was an accident? Or does it sound like something completely different altogether that just got activated and deactivated by my experimental funcion? (It did nothing but return the parameters, by the way...)

The wiki recommends looking at gzdoom.pk3 contents for inspiration, but does it only concern code feel, or can I rely on features defined there to stay stable(-ish)? I am specifically interested in access to untagged level geometry, simplifications arising from just programatic reading of that sound highly usable. Running the native functions on them could prove very useful too for specific use scenarios.

[phantombeta]

@stan423321
(About function calls)
It's because function calls in the VM are VERY expensive. This doesn't matter much for things that only get called once in a while (for example, when you pick a weapon up), but it can be a problem if it gets called thousands of times per tic by hundreds of actors.
I kinda wish there were an "inline" keyword to force inlining of functions. (If the ZScript compiler even does inlining of functions at all, anyway)

(About crash)
Uhhhhh... GZDoom should never crash. If it does, either it's user error (by the mod author) or a bug in GZDoom, and the latter should be reported.

[Matt]

Experiments with passing Vector3 as parameter and a return value of a function lead to crashes on exit of GZDoom. Does that count as a bug? Are vectors not supposed to be passed like that at all? Could that be caused by functions calling functions being a relatively untested funcionality? Or perhaps pos isn't a Vector3 despite the similarities and getting it in as a parameter for such a function was an accident? Or does it sound like something completely different altogether that just got activated and deactivated by my experimental funcion? (It did nothing but return the parameters, by the way...)

Please make a ZScript that does nothing but replicate this crash and post it to the bugs forum.