Slaughter Map Performance Booster

[Rachael]

I got LZDoom working so that will appear in the next version, all I had to do was bump down the ZScript version.

[thugsta]

This is fantastic. Any chance you can make this work on LZDoom also? It seems to almost work as is, other then a thinker error on death

I will take a shot at it later when I get some time.

Just wanted to say thank you and thanks again for the mod, genius work

I got LZDoom working so that will appear in the next version, all I had to do was bump down the ZScript version.

Unless i am misreading, the zscript error on startup was the easy part to bypass. I meant when you die in game using this there is a thinker error and you can't resume.

[Rachael]

Should be fixed now.

New release done - it should fix both issues (hopefully).

[stainedofmind]

Finally back home, tried the updated version and am glad to verify that the error is gone. I see you changed the zscript from just EventHandler to StaticEventHandler. I might just be missing something painfully obvious, but why exactly did that fix the issue, if I may ask?

[Rachael]

EventHandlers are saved to the game file, while StaticEventHandlers are not. StaticEventHandlers are loaded as part of the engine, not the map.

The reason why this is important is because the iterator is saved between calls. And when you save the game, that can be problematic because the iterator is not an actor inside of the map, so it doesn't come back.

With a StaticEventHandler, the reference to the ThinkerIterator is no longer saved, instead it is now part of this running instance of GZDoom rather than the map, so if it gets destroyed a new one will be made and will no longer cause a crash for an invalid pointer reference.

[stainedofmind]

Yup, I was right. It was pretty obvious. I didn't even give the iterator a second glance when I first had the error, so no wonder why I couldn't figure out what was wrong. Thanks for the explanation, mod and fixing it quickly!

[Fishytza]

So in other words ThinkerIterators can't be in a savegame?

[Rachael]

Yup, I was right. It was pretty obvious. I didn't even give the iterator a second glance when I first had the error, so no wonder why I couldn't figure out what was wrong. Thanks for the explanation, mod and fixing it quickly!

You're welcome.

So in other words ThinkerIterators can't be in a savegame?

Correct.

[Marisa the Magician]

Could you use freezetics instead or incrementing actor tics? I feel that the latter can make some things janky.

[Rachael]

It's possible to do, but, the reason why I don't do it is because velocity calls (i.e. projectiles) don't really impact the game sim too terribly outside of collision/linecross checks, but if I were to do freezetics projectiles would be slowed down and that would be problematic for imps at a distance. One of the big goals of this was to try and minimize the impact on game balance (hence, increasing distant monster aggression). Options never hurt anyone though so I suppose it might be possible to add it, it just never crossed my mind as something anyone would actually want though because of the side effects.

[vsonnier]

Hello Rachael, this is an interesting piece of code you have here. I have a question, if I may :

As far as I understand, the ThinkerIterator covers every Actor of the level, and you simply test the euclidian distance (squared) for all of them, not too often though ( tic % swlowdown speed) and it works despite the slaughter-like levels having ton of Actors.
How does it compare perfomance-wise compared to : Using a BlockThingsIterator (not -reinitable, +BLOCKMAP) and using the checkradius to limit the search cost ?

I've use the later method on my own mod, but I would happily switch to a more brute-force approach if it is actually faster.
Symetrically to your goal here, I use it to 'mark' the monsters around the Player limited to a surrounding bubble were the Player can actually see some effects (say 1000-2000 units).

[Rachael]

I honestly do not know, actually. I have not tried it. I don't think it ultimately would be that much better though, because if you ask for the limit on search distances, would that not just put you back at square 1? It still has to iterate through every actor in order to find the ones it needs to adjust.

Nevertheless - if you can plug your method into this addon and run a side-by-side comparison, I would be interested in seeing the results.

If you can't reinit BlockThingsIterator, it'd still be fair for the test to simply delete it after you're done and create a new one. I've heard that this thrashes the GC, but the GC has been improved lately, that hopefully this won't be too much of a problem.

[phantombeta]

As far as I understand, the ThinkerIterator covers every Actor of the level, and you simply test the euclidian distance (squared) for all of them, not too often though ( tic % swlowdown speed) and it works despite the slaughter-like levels having ton of Actors.
How does it compare perfomance-wise compared to : Using a BlockThingsIterator (not -reinitable, +BLOCKMAP) and using the checkradius to limit the search cost ?

A single ThinkerIterator that only runs once per tic isn't gonna particularly affect your performance. You also can't just use a BlockThingsIterator here, it's slowing down monsters that *aren't* in range, so BlockThingsIterator straight up wouldn't work. At best, you could get it to work with some hacky workarounds, but chances are those workarounds it'd need would result in worse performance.
(Now, if this were part of a mod with all enemies replaced, then it'd be a different deal- then you could give all monsters a flag that gets checked for and reset every tick in the monster's Tick function, then have the players set that flag on all monsters around them. But that approach can't be used by something that's supposed to be universal)

I honestly do not know, actually. I have not tried it. I don't think it ultimately would be that much better though, because if you ask for the limit on search distances, would that not just put you back at square 1? It still has to iterate through every actor in order to find the ones it needs to adjust.

BlockThingsIterator works through the blockmap directly, so it only needs to check actors in any of the blockmap blocks it overlaps. (The flip side, of course, is that it can't see actors not on the blockmap at all because of that)

One thing to note, though, that I've seen a lot of people misunderstand, though- BlockThingsIterator does not do any checks on actors, checkradius only tells it the radius to check blocks at. So a checkradius of 0 would iterate only through the block right at those exact coordinates, while a checkradius of 1000 would check all blocks in a 1000mu radius. It always iterates through every actor in those blocks, though, so if you want to limit actors checked to a circular or square radius around the position you put in, you still have to do that check yourself.

If you can't reinit BlockThingsIterator, it'd still be fair for the test to simply delete it after you're done and create a new one. I've heard that this thrashes the GC, but the GC has been improved lately, that hopefully this won't be too much of a problem.

You generally need to be creating a ton of them for it to cause problems, even creating a couple hundred in WorldTick wouldn't be much of a problem for the GC, even back when it would misestimate the amount of memory allocated/garbage created.

[DELTAtheDboi005]

HOW DID I NOT KNOW ABOUT THIS SOONER?

This is going to be VERY helpful!.. Thanks!

[bLUEbYTE]

Great idea, thanks for the mod.

Would it be feasible and a good idea to add a setting to toggle it on and off dynamically, based on the current alive monster count?
For example, if I know my PC maxes at around 2K monsters, I could set that as the threshold and only when there are at least that many monsters alive, the mod would kick in.