ZDoom

Does this mod use visual thinkers by chance? There was an oversight where destroyed ones were getting into the render list on load including from snapshots. It's possible it could've been this since the conditions for it were fairly random

I've posted the link in another thread, but here it is anyway for anyone that wants to take another shot at it.

https://www.moddb.com/mods/dragon-secto ... 2-released

The full pack brings everything current. On the bundled version of GZDoom 4.14.0a we are able to play all the way through. Drop in your debug build if you care to take another stab at it. The manual has recommended settings, which will further dial it into how we're configured.

Thanks for the care and time, everyone. I really mean it.

Sorry for not getting back to this thread. Life has been hectic.

Anyway, I have no idea how to do that, and my perusal over my code hasn't tuned up anything that throws up a red flag for me. But there are a lot of moving parts here, so yeah, extraordinary measures are going to be needed.

I'm going to put up an updated build with minor fixes this week, and then everyone can be on the same page. Since the last release I've updated the KAI library, and PB has done some stuff as well.

Either way. Sorry for the inactivity. It's kind of been a bit hard here.

Realistically I think the easiest way to track this down is gonna just be hooking the debugger up to a Debug build and playing until it freezes. This is probably too difficult to find by eyeballing without shear luck playing a part

I'm going to read over my code with a critical eye. I will see if anything sticks out at me. There's a few things specifically I do that I might need to re-evaluate. I may post some stuff if I'm not sure it couldn't cause a problem.

So then indeed there is likely a problem within the GZDoom code itself. But now we need to know what sets it off in order to fix it. Consider both monsters and ambient objects in this case. Especially consider obscure functions that you don't commonly see used in mods - since they're tested less they tend to be more buggy than other functions.

The plot seems to be thickening. I don't think it's a 0 tick loop. With the test build we didn't get any of those warnings. We did however experience freezing and crashing to desktop. I don't know if it is with Zscript or GZDoom at this point, but something is definitely up. Again, none of this happens on 4.14.0a. I am wondering if this could have anything to do with the thread handling that came in on 4.14.1.

The other person we've got testing this also mentioned that none of his mods would load with 4.14.2. I'm not sure why that would be, so I have to chalk that one up as an error on his end somewhere.

At this point, though, I'm still as mystified.

Hey, sorry for the delay in getting back.

So I deliberately created an actor with a 0 state loop to test out the behavior, and I see that you've got it setup to remove the actor after printing the console message. Once we've got some more time, we'll do a full test through the maps with this build and see what happens.

We are using the latest build of PB, which as far as I could tell, hasn't changed that much, but I should rule that out, too. I know that the version that's bundled with our mod will freeze up, though, as that's what we were using when we tested 4.14.1.

I'll report back when I have more info.

Thanks y'all!

Are you using the version of Project Brutality bundled with your mod or the latest build? If using the latest, it wouldn't hurt to test it with the bundled one to rule out a possible bug that got introduced by the mod itself

If it still freezes on that build and doesn't give you the message about infinite states, then there's an infinite loop in the code somewhere instead - either in the ZScript or inside GZDoom itself.

I've downloaded the test build and I'm going to give it some testing. I'll report back if/when I find something.

If you can get it to a point where I can reliably trigger it, even with a save file, I can force a break inside of a debug build and figure out where it's causing problems.

Alternatively, you can try and trigger it in this build: https://drive.google.com/file/d/10UUU6y ... sp=sharing
Compile source: https://github.com/madame-rachelle/gzdo ... 567c4acca0

Daryn wrote: ↑Thu Jun 05, 2025 9:53 pm Either way, Rachael, I want to thank you for the help, and for helping bring GZDoom to us. We really appreciate it. We could have never made this mod on any other port, period. Whatever the cause is, we'll get to the bottom of it.

Thank you, I always strive to make GZDoom better.

While I and many other mods use 0 tic states, I can't think of any instance where I would loop that. I do know of some problems in PB a while back where 0 tic death states causes issues.

We're also not talking a jump of major versions here. From .0 to .1, and I honestly couldn't say if anything changed in the state checker in that update. You would have a better idea there.

But if it is mod specific, it is going to be a nightmare to track down. A cvar like that, would be helpful. Or maybe some kind of key combination to force a break and dump to file.

I'm just spitballing here, because thus far, it is happening pretty consistantly in this map, but it is happening with different monsters and weapons in play. So trying to eyeball it and figure out a pattern is proving impossible.

Either way, Rachael, I want to thank you for the help, and for helping bring GZDoom to us. We really appreciate it. We could have never made this mod on any other port, period. Whatever the cause is, we'll get to the bottom of it.

Keep in mind that the actor state checker will always run while any actor's "tics" value is 0. So that means if there are a chain of 0-tic states, especially if they are looped, it will just run forever. Older versions of GZDoom were not just magically immune to this. It's possible there's a bug in the mod itself that is hidden until you run it on a more recent version of GZDoom.

Other than that, I couldn't tell you what could possibly be going wrong here. I could possibly add a cvar to the state checker that forces it to track how many state transitions it has done for the current actor on the current tick and error out to the console after it's reached an abysmally high value. But doing that would likely require it being exclusive to debug builds of GZDoom; the state checker is a performance concern because it runs for every actor on every tick while the game is running, meaning it runs hundreds if not thousands of times per second even on the original Doom1/2 mapsets.

Just to add, we loaded from an autosave, and it froze up not long after. On 4.14.2 release. I'll get the save file to you asap, but I am not sure if you'll be able to load it. Still, I'll provide it.