ZDoom

Hello, I'm back with another obscure bug in relation to DRPG and it appears to be unrelated to HUDMessage this time.

So thankfully someone was able to send me a savegame that freezes seconds after loading, something I've been attemping to replicate for far too long.

AFAIK, It seems to be stemming from p_mobj.cpp#L495, and the do-while loop gets stuck and loops for infinity unless if I force line 497 to exit with x64dbg and in which case the engine resumes as normal and no more freezes are witnessed in the next five minutes.

I noticed that AActor::SetState barely registers on the CPU profiler until the freeze happens.
Another thing I noticed was that this freeze seems to go as far back as v3.7.2 and probably earlier.

Here's some info from VS profiler:
https://i.imgur.com/ok6ZuJQ.jpg

Links to save game and the VS profiler report.
https://www.mediafire.com/file/rgv0jux0 ... 0.zip/file
https://www.mediafire.com/file/06m1g854 ... 6.zip/file

I understand DRPG is a pain to setup and test, so feel free to tell me what to change.

Need anymore info? Please scream. Thanks!

How to run:

Spoiler:

---

Load save and do nothing and game should freeze seconds later.

WADS:
DOOM2.WAD
DoomRPG (https://github.com/WNC12k/DoomRPG-Rebal ... 13d7fc9f0f)
DoomRL Arsenal 1.1.2 + Monsters 7.2 (viewtopic.php?f=43&t=37044)
Precise Crosshair 1.3 (viewtopic.php?f=43&t=64788)
Flashlight (https://allfearthesentinel.net/zandronu ... hlight.pk3)
JPCP (https://www.doomworld.com/idgames/level ... awads/jpcp)

Load Order:
-file
DoomRL_Arsenal_1.1.2.pk3
DoomRL_Monsters_Beta_7.2.pk3
flashlight.pk3
precise-crosshair-1.3.pk3
JPCP.wad
DoomRPG-Rebalance\DoomRPG
DoomRPG-Rebalance\DoomRPG-Brightmaps
DoomRPG-Rebalance\DoomRPG-RLArsenal
DoomRPG-Rebalance\DoomRPG-RLMonsters

There is only one way that loop can get stuck and that is if some actor has a 0-duration state loop. This is one of those cases which cannot really be fixed in the engine because the only way to end the loop would be to set an arbitrary maximum loop count. Set it too low and other mods will break, set it too high and it becomes ineffective.

Thank you for the info, that's certainly interesting.

So how does one identify whether an actor is affected by a 0-duration state loop? Would it be in a the form of user error in decorate?

DRPG manages its monster compatibility via duplicating actors and basically forcing DRPGs MonsterInit to execute via state modification, could that possibly be an issue? I never did like having to duplicate actors for compatibility sake.
https://github.com/Sumwunn/DoomRPG/blob ... ers.txt#L8

While some obvious cases can be detected, those are rarely the problem. Where it goes wrong is often things that look correct on the surface but still do not work properly, like A_Jump combinations with no delays and conditions that evaluate to results that SetState never exits the loop.

If this helps, the actor in question is RLUniqueBossSpawner, and the state that loops endlessly is RLUniqueBossSpawner.102 which seems to be Succeed from the actor below.

Spoiler: RLUniqueBossSpawner

---

Code: Select all

ACTOR RLUniqueBossSpawner // PLS NO EXPLODE
{
    Radius 40
    Height 110
    Speed 15
	+NOBLOCKMAP
	+NOTIMEFREEZE
	+NOTONAUTOMAP

    var int user_helpiamtoobig;
	States
	{
    Spawn:
	    TNT1 A 0
		TNT1 A 0 A_JumpIfInventory("DRPGDRLAActive",1,"DoorpegOutpostCheck", AAPTR_PLAYER1)
//	    TNT1 A 0 A_Log ("DEBUG: Unique boss has spawned")
		TNT1 A 0 A_SetUserVar("user_helpiamtoobig", 525)
    SpawnLoop:
//Checks for space to spawn the boss, teleports to player 1 every 15 seconds if stuck
		TNT1 A 0 A_ChangeFlag ("NOCLIP", 0)
		TNT1 A 0 A_ChangeFlag ("THRUACTORS", 0)
		TNT1 A 0 A_JumpIf (user_helpiamtoobig <= 0, "MUSTESCAPECONFINESOFREALITY")
	    TNT1 A 1 A_Wander
	    TNT1 AAAAAAAAAA 0 A_Wander
		TNT1 A 0 A_ChangeFlag ("NOCLIP", 1)
		TNT1 A 0 A_ChangeFlag ("THRUACTORS", 1)
	SpawnCheck:
		TNT1 A 0 A_SpawnItemEx("RLUniqueBossChooser",0,0,0,0,0,0,0,SXF_CLEARCALLERTID)
		TNT1 A 0 A_JumpIf(tid==0,"Succeed")
		TNT1 A 0 A_SpawnItemEx("RLUniqueBossChooser",0,0,0,0,0,0,0,SXF_CLEARCALLERTID)
		TNT1 A 0 A_JumpIf(tid==0,"Succeed")
		TNT1 A 0 A_SpawnItemEx("RLUniqueBossChooser",16,0,0,0,0,0,0,SXF_CLEARCALLERTID)
		TNT1 A 0 A_JumpIf(tid==0,"Succeed")
		TNT1 A 0 A_SpawnItemEx("RLUniqueBossChooser",16,0,0,0,0,0,0,SXF_CLEARCALLERTID)
		TNT1 A 0 A_JumpIf(tid==0,"Succeed")
		TNT1 A 0 A_SpawnItemEx("RLUniqueBossChooser",-16,0,0,0,0,0,0,SXF_CLEARCALLERTID)
		TNT1 A 0 A_JumpIf(tid==0,"Succeed")
		TNT1 A 0 A_SpawnItemEx("RLUniqueBossChooser",-16,0,0,0,0,0,0,SXF_CLEARCALLERTID)
		TNT1 A 0 A_JumpIf(tid==0,"Succeed")
		TNT1 A 0 A_SpawnItemEx("RLUniqueBossChooser",0,16,0,0,0,0,0,SXF_CLEARCALLERTID)
		TNT1 A 0 A_JumpIf(tid==0,"Succeed")
		TNT1 A 0 A_SpawnItemEx("RLUniqueBossChooser",0,16,0,0,0,0,0,SXF_CLEARCALLERTID)
		TNT1 A 0 A_JumpIf(tid==0,"Succeed")
		TNT1 A 0 A_SpawnItemEx("RLUniqueBossChooser",0,-16,0,0,0,0,0,SXF_CLEARCALLERTID)
		TNT1 A 0 A_JumpIf(tid==0,"Succeed")
		TNT1 A 0 A_SpawnItemEx("RLUniqueBossChooser",0,-16,0,0,0,0,0,SXF_CLEARCALLERTID)
		TNT1 A 0 A_JumpIf(tid==0,"Succeed")
		TNT1 A 0 A_SpawnItemEx("RLUniqueBossChooser",16,16,0,0,0,0,0,SXF_CLEARCALLERTID)
		TNT1 A 0 A_JumpIf(tid==0,"Succeed")
		TNT1 A 0 A_SpawnItemEx("RLUniqueBossChooser",16,16,0,0,0,0,0,SXF_CLEARCALLERTID)
		TNT1 A 0 A_JumpIf(tid==0,"Succeed")
		TNT1 A 0 A_SpawnItemEx("RLUniqueBossChooser",-16,-16,0,0,0,0,0,SXF_CLEARCALLERTID)
		TNT1 A 0 A_JumpIf(tid==0,"Succeed")
		TNT1 A 0 A_SpawnItemEx("RLUniqueBossChooser",-16,-16,0,0,0,0,0,SXF_CLEARCALLERTID)
		TNT1 A 0 A_JumpIf(tid==0,"Succeed")
		TNT1 A 0 A_SpawnItemEx("RLUniqueBossChooser",16,-16,0,0,0,0,0,SXF_CLEARCALLERTID)
		TNT1 A 0 A_JumpIf(tid==0,"Succeed")
		TNT1 A 0 A_SpawnItemEx("RLUniqueBossChooser",16,-16,0,0,0,0,0,SXF_CLEARCALLERTID)
		TNT1 A 0 A_JumpIf(tid==0,"Succeed")
		TNT1 A 0 A_SpawnItemEx("RLUniqueBossChooser",-16,16,0,0,0,0,0,SXF_CLEARCALLERTID)
		TNT1 A 0 A_JumpIf(tid==0,"Succeed")
		TNT1 A 0 A_SpawnItemEx("RLUniqueBossChooser",-16,16,0,0,0,0,0,SXF_CLEARCALLERTID)
		TNT1 A 0 A_JumpIf(tid==0,"Succeed")
		TNT1 A 0 A_SetUserVar("user_helpiamtoobig", user_helpiamtoobig - 1)
		Goto SpawnLoop
    MUSTESCAPECONFINESOFREALITY:
		TNT1 A 0 A_SetUserVar("user_helpiamtoobig", 525)
	    TNT1 A 0 A_Warp (AAPTR_PLAYER1, 0,0,0, 0, 0, "SpawnLoop")
	    TNT1 AAA AAAAAAAAAA AAAAAAAAAA AAAAAAAAAA AAAAAAAAAA 0 A_Wander
		Goto SpawnLoop
	Succeed:
		TNT1 A 10
		Stop
//==============================================================================
  DoorpegOutpostCheck:
  HEYSTOPTHAT:
    TNT1 A 0
	Fail
	}
}

More like the stuff above "Succeed". Succeed is harmless, it just waits and ends, the SpawnLoop above is just horrible code.

Thanks for the actor name! It seems HEYSTOPTHAT is the culprit when DRPG is active which would explain why DRLA by itself does not freeze the game.

Changing TNT1 A from 0 to 1 avoids the freeze up, and judging from the function's structure it looks like RLDemonicBossSpawner is susceptible also.
I'm not sure about the other checks scattered around as they are a bit different from this case, however I managed to figure out VS debugger so if this happens again I can see the actor responsible.

I think this wraps things up assuming the above is the correct way to solve this.

EDIT:
I think I've properly fixed it, had to copy over the DoorpegOutpostCheck section from RLDemonicBossSpawner to RLUniqueBossSpawner's empty one, and a UniqueBoss spawned so I'm guessing that's the intended behaviour.

EDIT 2:
The fix will be included in the next DRLA update, so this can be closed.

Thanks guys.

What about a debug variable that can be set where modders can use this as a tool, Graf? If it's set to < 1 then it doesn't perform.