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

[PatrikLundell]

Hm, this is tricky.

I've managed to block critters from teleporting into the reality bubble (when monster movement is processed), but dealing with corpses is a lot trickier, because the code drops items on the reality bubble map (and probably does nothing when the position isn't inbounds), far removed from anywhere the actual map used is known.

[GuardianDll]

do you mean it happens because all zombies hit by explosion die? doesn't sound plausible, single shot deal damage equal to a grenade, it has no ability to kill every single zed in a range

[PatrikLundell]

No. I'm saying I've dealt with critter teleportation, but now, when critters die, they don't leave anything behind because the death handling code drops items at the bubble map, or, rather at the bubble map coordinates of the absolute position of the critters, which are usually off the bubble map. The surviving critters now appear approximately where they should ("approximately" as I'm using zombies now, and they move a little on their own).

[PatrikLundell]

I've made some further progress, at the cost of a lot of changes (passing the appropriate map along to eventually end up where corpses and stuff are placed).
I've now managed to kill monsters and have their stuff and corpses end up where they should.
However, spawned NPCs are unscathed, so that remains to hunt down. There are also quite a lot of potentially loose ends, such as firing of magic effects on death and corpse activation (trying to activate corpses blows up because the code assumes they're within the realty bubble, and it seems unsafe to change the activation code to deal with their proper location, so that step is currently skipped if a corpse is generated outside of the reality bubble).
I suspect I won't be able to finish this today.

[PatrikLundell]

I think I've got it, finally, and #79336 is the resultant PR.

One thing I've noted from the mortars draft is that there doesn't seem to be any dispersion (which is very useful for testing purposes). The actual impact point should probably vary dependent on the operator's mortar skill, resulting in an impact point that both hit an adjacent tile, and land somewhere which isn't the center of a tile. The dispersion should probably be calculated in map squares from the tile center and then translated as OMTs and map squares (i.e. a distribution curve in map squares that's then translated for the purpose of determining the impact point in map squares within the impact OMT).
Also, I think it would be useful to define a debug mortar that has no dispersion for testing purposes, as I suspect there are going to be additional issues to solve going forward: I don't think everything has been found yet.