ensure critters are loaded around explosion

[PatrikLundell]

Summary

None

Purpose of change

Correct issue mentioned in comment on #75567 after it was closed, i.e. creatures around far explosions are not (always) directly affected by it.

While looking at the code, it was cleaned up a little by making use of operation to get absolute critter positions. This operation didn't exist when the code was written, I think. That reduced the need to juggle with the reality bubble (there's still a need to determine whether player feedback should be printed).

Describe the solution

Add loading of critters on the explosion map before processing the explosion.
It was a bit tricky to track that one down, as the loading isn't performed by anything directly map related, but rather as a result of PC movement.

Describe alternatives you've considered

Testing

Created a test setup with breathers around a barrel bomb (breathers don't move from their locations). Saved it.
Activated the bomb and then walked well over 100 steps east and then returned.
Verified that some critters near the PC were injured, but those at the far side of the explosion weren't, and those around the barrel were injured only as a result of falling.

Made the changes and repeated the test.
Verified many breathers were gone, and all of the remaining ones were injured.
Also, as part of this test, a breakpoint was set in creature_tracker::remove to verify the "extra" critters placed into the creature tracker were removed properly. This was done by walking back towards the explosion, stop when the explosion happens and set the breakpoint, and then walk away again, verifying the number of loaded critters dropped to the "ambient" number before walking back to the explosion site.
Before:

After:

Additional context

[PatrikLundell]

@GuardianDll: In case you're not notified and are anxious to continue with your PR: The relevant change is the addition of a single line that you can hack into your code during the testing phase and then remove when done. That would let you continue while this PR goes through the test and acceptance process.

[moxian]

Don't we generate some of the terrains (craters?) via explostions? Would that mean there would be fresh critter corpses in those now? Or do those already have the critters loaded since they are close enough?
(I don't think that's a big enough problem to remotely block the PR even if true, just wondering)

[PatrikLundell]

This should actually repair a partially broken functionality, as the explosions are triggered by the reality bubble covering the explosion location, or covering the near side of the OMT the explosion on the remote side of the OMT resides on.
This means that previously, you'd get fresh corpses on the near side and untouched/fallen critters on the far side (and the next OMT, if that one's touched). And yes, the previous implementation did generate reports about damage and death of critters visible by the PR.
Now all the critters around that should be affected by the blast area will be.

Speculations about what might be possible in the future:

I think it might be possible to "age" corpses generated by blasts by setting the corpse generation time to the time at which the blast is supposed to have gone off to get them to decay very rapidly.

It might also be possible to locate the OM generation code and have it trigger the corresponding explosions at that time, which would produce pre-aged corpses and (usually) provide time for injuries to heal on survivors as well as ready to rise zombies, at the cost of early generation of some of the OMTs.
Triggering crater explosions early could allow us to have larger craters (almost a reality bubble in diameter) without risking blowing up the PC on entry or have a high speed vehicle plunge over the edge of a huge crater opening underneath. However, a crater center at the edge of an OM would be bad, so that would have to be avoided. Also, the explosion logic for large craters could somehow change the OMT terrain of affected tiles to indicate they're converted into parts of a large crater, unless that would be done statically, in which case you'd mark a basically round area as a large crater, possibly with the center marked differently from the periphery. Note that large craters wouldn't be the same as the crater fields we have now: they'd probably be a new thing, not a replacement.

[GuardianDll]

Super funky things are going on:
@ above is me with mortar, cursor is at destination point

step 1: manually walk to the destination
step 2: spawn ton of zombies for test purposes at destination point

step 3: manually walk away from the zone
step 4: fire a shell at point of shooting
result: all monsters disappear from the point

Repeated twice, happened both times
i once had a case, where bunch of zomibes appeared at the edge of reality bub, at least 5 overmap tiles afar from where they should be

If you find it hard to reproduce, i can make a draft PR so you can see it yourself

[Brambor]

i once had a case, where bunch of zomibes appeared at the edge of reality bub, at least 5 overmap tiles afar from where they should be

To me, this sounds like a wrong coordinates conversion was used. I would guess mortaring the place loaded the critters and the loading loads them at the wrong coordinates.

Just a hunch. I haven't looked at the code.

[PatrikLundell]

Please provide a draft PR, as there's currently nothing in the game that does what you do. The current functionality only triggers the explosion as it's loaded by the reality bubble activities, while you're actually causing it to explode at the impact point while far away from it.
Also, what's your mortar called, so I can debug spawn it (and its ammo)? I believe I can use my save for this PR as the starting point.
And finally a different question: Where's the crater?
Anyway, if there's a draft available tomorrow (my time) I'll try to investigate the issue.

Oh, another question what may be generally useful: How do you make the zombies to stay put? They have the advantage over breathers in that they don't melt away, but rather leave corpses behind, which would be useful to try to track down the corpse teleportation issue.

[GuardianDll]

Here's the one: #79303
Just spawn mortar_m224 item and activate it to put as furniture, and spawn a bunch of rounds, 60mm_shell_m720a1 uses debug explosion value of 25000, 60mm_shell_m768 uses proper value that matches the round, ~350

Where's the crater?

the test was performed using 60mm_shell_m768, which deals the damage similar to a grenade, and can't create a massive crater
here's me testing it with round that does create craters, i again spawned bunch of zeds and shot the tile - all zeds are gone, crater is here

How do you make the zombies to stay put?

I used quick setup, which gives a speed mutation, which increases your speed ten times, so even when i walk, zombies have no time to spread much