ZScript parser doesn't notice missing state label

[MartinHowe]

I was making a custom teleport fog actor for HeXen and forgot to put the "Spawn:" state label in, but the parser didn't catch it.

Code: Select all

class DummyFog : Actor
{
    default
    {
        SeeSound "misc/teleport";
        RenderStyle "Add";
        +NOBLOCKMAP;
        +NOTELEPORT;
        +NOGRAVITY;
        +ZDOOMTRANS;
    }

    States
    {
        TELE A 6 Bright;
        TELE B 6 Bright;
        TELE C 6 Bright;
        TELE D 6 Bright;
        Stop;
    }
}

To reproduce: Copy and paste this code into a file zscript.zs and start HeXen with it using -file
Expected result: Engine aborts with a parse error
Actual result: Engine loads the game with no error. Spawning one of these actors silently does nothing.

Log:

Code: Select all

martin@luna:~/Downloads$ gzdoom -iwad hexen -file $PWD/zscript.zs
GZDoom g4.14.2 - 2025-01-29 01:31:37 -0300 - SDL version
Compiled on Jun 17 2025

OS: Linux Mint 22.1, Linux 6.8.0-83-generic on x86_64
Log started: 2025-09-22 10:11:58
GZDoom version g4.14.2
W_Init: Init WADfiles.
adding /usr/local/games/gzdoom/gzdoom.pk3, 692 lumps
adding /usr/local/games/gzdoom/game_support.pk3, 3308 lumps
adding /usr/local/share/hexen/hexen.wad, 4270 lumps
adding /usr/local/games/gzdoom/game_widescreen_gfx.pk3, 214 lumps
adding /home/martin/Downloads/zscript.zs, 1 lumps
S_Init: Setting up sound.
I_InitSound: Initializing OpenAL
  Opened device USB audio Rear Line Out
  EFX enabled
Using video driver x11
Number of detected displays 1 .
Creating window [3072x1728] on adapter 0
Vulkan device: NVIDIA RTX A4000
Vulkan device type: discrete gpu
Vulkan version: 1.3.277 (api) 550.652.64 (driver)
Max. texture size: 32768
Max. uniform buffer range: 65536
Min. uniform buffer offset alignment: 64
Resolution: 2160 x 3840
I_Init: Setting up machine state.
CPU Vendor ID: AuthenticAMD
  Name: AMD Ryzen Threadripper PRO 5955WX 16-Cores 
  Family 25 (25), Model 8, Stepping 2
  Features: SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 AVX AVX2 F16C FMA3 BMI1 BMI2 HyperThreading
V_Init: allocate screen.
ST_Init: Init startup screen.
Checking cmd-line parameters...
S_InitData: Load sound definitions.
G_ParseMapInfo: Load map definitions.
Texman.Init: Init texture manager.
ParseTeamInfo: Load team definitions.
LoadActors: Load actor definitions.
script parsing took 304.82 ms
R_Init: Init Hexen refresh subsystem.
DecalLibrary: Load decals.
M_Init: Init menus.
P_Init: Init Playloop state.
ParseSBarInfo: Loading custom status bar definition.
D_CheckNetGame: Checking network game status.
player 1 of 1 (1 nodes)

----------------------------------------

MAP01 - Winnowing Hall

Line 1750's right edge is unconnected
]summon dummyfog
martin@luna:~/Downloads$ 

[Blue Shadow]

The Actor class has a Spawn state sequence which every actor inherits normally. It consists of one state: TNT1 A -1. Considering your actor doesn't override that state sequence, it inherits it as is. When you attempted to spawn the actor, it did actually spawn. It was just invisible.

Also, states can exist on their own without state labels.

[MartinHowe]

OK thanks, Blue Shadow.

Though states existing with no label and Actor having a dummy spawn state is counter intuitive, and I would argue even illogical; for me this seems like it should be an error, as such an actor is useless in practice.

But since we're stuck with it in order to not break existing mods, maybe there should be a warning on the console when this happens. I mean, who would deliberately not override the inbuilt Spawn state of the root Actor class, and for what purpose?

[Enjay]

An actor that spawns, is invisible but via ACS (or something) the actor is forced into a different state during gameplay?
I've never done it but, in theory at least, I can see it being done.

[phantombeta]

It's useful if you're making a base class. Those are pretty useful for monsters, where you might wanna provide generic deaths (say, fire deaths) and other such things. Inventory tokens and many uses of CustomInventory also don't need a Spawn state, and starting weapons usually don't need one either.
Either you'd have to hardcode it to only warn you if it inherits directly from Actor (which makes it significantly less useful), or you'd get useless warning spam that'd just encourage people to ignore warnings.

[MartinHowe]

Either you'd have to hardcode it to only warn you if it inherits directly from Actor (which makes it significantly less useful), or you'd get useless warning spam that'd just encourage people to ignore warnings.

Thanks phantombeta; that explains it for me