ZScript Discussion

[Major Cooke]

Alright. Back to my original question, so would strings be best then, and performing:

Code: Select all • Expand view

String bc = (bloodcolor & 0xffffff)

Or is there something else?

[Graf Zahl]

That won't work. You can assign integers to colors so 'color bc....' should work.

[Major Cooke]

It turns out Actor doesn't have a set bloodcolor. And apparently, DefaultBloodColor isn't working.

Code: Select all • Expand view

Class C : Actor
{
   Color P1;
   Default
   {
      +NOINTERACTION
   }
   States
   {
   Spawn:
      TNT1 A 1;
      TNT1 A 0
      {
         A_CheckProximity("Null","PlayerPawn",32767,1,CPXF_SETTARGET|CPXF_ANCESTOR);
         if (target)
         {
            P1 = target.bloodcolor;
            for (int i = 0; i < 50; i += 2)
            {
               A_SpawnParticle(P1,SPF_RELATIVE|SPF_FULLBRIGHT,35,10,0,0,0,i);
            }
         }
         
      }
      Stop;
   }
}

Expecting the color to be red, but it's black. That's because BloodColor is not defined in Actor. The moment it's added, it works as expected.

[Graf Zahl]

No, most actors do not have a blood color. That implicitly means 'use untranslated blood sprites and the default colors for particles and decals'.

[Marrub]

Three Two questions:

Note: Due to how ZScript is processed, it is possible to name a file which conflicts with other mods or the internal files. I.e. ZScript/Const.txt will prevent the game loading as this file is already defined internally. To avoid such conflicts, it is recommended to have another subfolder or have the ZScript folder name changed

Why? D:

Actor names must be valid identifiers (i.e. be composed of only letters, numbers, and underscores; and must start with a letter or underscore). Most notably, this means that actor names may no longer begin with a number.

Could there be some way to externalize actor names as strings? I kinda like being able to have actors named whatever for ACS. Not really important, of course.

Some warnings such as missing actors are treated as errors. All actors must be defined.

Is there any way to do cross-mod compatibility with this, without resorting to the usual usage of DECORATE or ACS?
This is answered in a previous post and wow that is better than previous hacks.

[Graf Zahl]

Is there any way to do cross-mod compatibility with this, without resorting to the usual usage of DECORATE or ACS?

If you want to use a class you are not sure it is present you can do

Code: Select all • Expand view

 string classname = "UnknownClass";
 class<Actor> cls = classname;


That prevents compile time conversion, but of couse you are responsible for checking that the class exists if you want to use it.

[Major Cooke]

Can there be a gameinfo option to set the blood color? Like, SetBloodColorProperty?

If you want to use a class you are not sure it is present you can do

Code: Select all • Expand view

 string classname = "UnknownClass";
 class<Actor> cls = classname;


That prevents compile time conversion, but of couse you are responsible for checking that the class exists if you want to use it.

Wait, so it has to be UnknownClass? Or is that supposed to be replaced with the actor? If the latter, how should the check be done?

[Graf Zahl]

It's actually quite simple:

If you write 'class<Actor> = "Name"' the conversion is done at compile time and if it fails an error occurs.
But if you put a string variable in between the compiler cannot do the conversion itself, instead it has to call a runtime conversion function. And that returns null if the class cannot be found.

[Edward-san]

So, now that zscript got merged to master, it won't be possible for Zandronum's zdoom-sync repository, which managed to keep the code up to gzdoom, to update and include zscript.

There are some reasons for this (not exhaustive):

1) zandronum's code contains a lot of network handling, because of how the client/server system works;
2) even if zandronum could add zscript support, the zscripted functions (the non-native ones) in zandronum.pk3 would inevitably look different from zdoom's because of 1);
3) so, zscript, as is, wouldn't make it possible for modders to work on both zdoom and zandronum.

So, unless somebody could help investigate the code and find some solutions to this, now that zscript is not yet considered stable.

Of course this must be expanded with concrete data and suggestions, but I can't look at it at the moment.

[Graf Zahl]

That was to be expected, but it's really not something I can deal with. If you want to keep mods compatible you'll have to find solutions that can be integrated into the native interface in an unobtrusive way, if you start hacking apart the scripted functions you will lose all compatibility with future mods using similar code - and rest assured: They will come.

I think the best course of action would be to make anything critical read-only and allow changing only through setter functions where Zandronum can hook in - or define something like C# properties that can hide a function call behind an assignment.

[Edward-san]

How about preprocessor-style '#if Engine == zdoom ... #else ... #endif', which would allow inserting engine-specific code (and then solve also the problem for mods)?

[Gez]

Zandronum needs to factorize its netcode as much as possible and create a small set of functions it uses for that. ZDoom can then be made to just ignore calls to these functions, treat them like a nop or even like a comment.

[Graf Zahl]

How about preprocessor-style '#if Engine == zdoom ... #else ... #endif', which would allow inserting engine-specific code (and then solve also the problem for mods)?

I can promise you outright that modders will declare you insane with such an approach. You will inevitably have to try to find a solution that is mostly transparent to the user. I guess with a bit of thinking most of what needs to be done can be done better but if the entire low level scripting affair becomes an unwieldy clunker it will inevitably result in less compatible mods in the future.

Some quick notes:

Both SpawnMissile and S_Sound have an additional parameter on Zandronum. The only way to handle this would be to make it default to 'send data', i.e. true and add this to ZDoom as well so code can remain compatible. In any case, I route all sound calls through A_PlaySound which is doing this anyway, so no problem in this case.

But stuff like:

Code: Select all • Expand view

      // [BC] Tell clients to spawn the tracers.
      if (( NETWORK_GetState( ) == NETSTATE_SERVER ) && ( spray ))
         SERVERCOMMANDS_SpawnThing( spray );


surely won't fly anymore. Spawn should queue the actor for sending and you definitely will need some means to track all the properties that need to get sent along. Deferring this kind of stuff to the modders will only result in broken mods.

[Major Cooke]

How can I check to see if an actor's fullbright again? I'm looking for the post on how to do so safely since I remember it being said curstate is not the way to go?

[Cherepoc]

How can I check if an actor is standing on floor or on another actor? I did not dig deep into the sources, but I see there are P_CheckOnmobj function and MF2_ONMOBJ flag, but can't find such things in zscript files.
Also, I want to make projectiles transform into non-projectiles if they hit anything they cannot damage (floors, walls, solid decorations, actors of same species as the shooter). Is there a function I can override and do the checks?