ZScript Discussion

Ask about ACS, DECORATE, ZScript, or any other scripting questions here!
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.

Re: ZScript Discussion

Postby JPL » Tue Jul 11, 2017 11:00 am

UsernameAK wrote: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.
User avatar
JPL
 
 
 
Joined: 09 Apr 2012

Re: ZScript Discussion

Postby ZZYZX » Tue Jul 11, 2017 6:11 pm

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)
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine

Re: ZScript Discussion

Postby AFADoomer » Tue Jul 11, 2017 7:25 pm

Major Cooke wrote: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:
Graf Zahl wrote: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...
User avatar
AFADoomer
 
Joined: 15 Jul 2003

Re: ZScript Discussion

Postby Graf Zahl » Wed Jul 12, 2017 6:52 am

Major Cooke wrote: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.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: ZScript Discussion

Postby Major Cooke » Thu Jul 27, 2017 10:20 am

Only curious, but what happens if one goes over the maximum stat number + 1? Is that undefined behavior?
User avatar
Major Cooke
The road to Hell is paved in the carrion she leaves behind.
 
Joined: 28 Jan 2007
Discord: Major Cooke#0846

Re: ZScript Discussion

Postby Xaser » Tue Aug 08, 2017 9:48 am

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?
User avatar
Xaser
anarchivist
 
 
 
Joined: 20 Jul 2003

Re: ZScript Discussion

Postby Major Cooke » Tue Aug 08, 2017 10:46 am

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.
User avatar
Major Cooke
The road to Hell is paved in the carrion she leaves behind.
 
Joined: 28 Jan 2007
Discord: Major Cooke#0846

Re: ZScript Discussion

Postby ZZYZX » Sun Aug 20, 2017 5:42 am

This is why object versioning exists. It won't break if done right.
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine

Re: ZScript Discussion

Postby Gutawer » Wed Aug 23, 2017 3:35 pm

Just noticed that there's a map type which gives an unimplemented error when trying to use:
Code: Select allExpand 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.
User avatar
Gutawer
User Accounts Assistant
 
Joined: 16 Apr 2016
Discord: Gutawer#3431

Re: ZScript Discussion

Postby Graf Zahl » Thu Aug 24, 2017 1:54 am

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.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: ZScript Discussion

Postby Matt » Thu Aug 24, 2017 9:32 am

Graf Zahl wrote:
Gez wrote:
Vaecrius wrote: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?
User avatar
Matt
Putting the XD into *xdeath since 2007
 
 
 
Joined: 04 Jan 2004
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia

Re: ZScript Discussion

Postby Graf Zahl » Thu Aug 24, 2017 11:01 am

It's probably just an incorrect error message. Structs are not supposed to be extensible.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: ZScript Discussion

Postby stan423321 » Sun Sep 10, 2017 6:35 pm

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.
stan423321
 
Joined: 25 Mar 2014

Re: ZScript Discussion

Postby phantombeta » Sun Sep 10, 2017 8:38 pm

@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.
User avatar
phantombeta
In the meadow of sinful thoughts, every flower's a perfect one
 
Joined: 02 May 2013
Location: The United Soviet Socialist Dictatorship of Hueland
Discord: phantombeta#2461
Twitch ID: doom2fan

Re: ZScript Discussion

Postby Matt » Mon Sep 11, 2017 1:24 pm

stan423321 wrote: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.
User avatar
Matt
Putting the XD into *xdeath since 2007
 
 
 
Joined: 04 Jan 2004
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia

PreviousNext

Return to Scripting

Who is online

Users browsing this forum: No registered users and 2 guests