Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow explosions outside of the reality bubble #75567

Merged
merged 6 commits into from
Aug 20, 2024

Conversation

PatrikLundell
Copy link
Contributor

@PatrikLundell PatrikLundell commented Aug 10, 2024

Summary

None

Purpose of change

  • Fix Craters are spawning partially #73950 (craters are spawning partially).
  • Allow the code to trigger explosions outside of the reality bubble.
  • Allow explosions at the edge of the reality bubble to affect is surroundings (i.e. the issue above).
  • Allow for the usage of larger explosions without risking the PC being blown up or vehicles traveling at speed to suddenly fall into a crater opening up just in front of them.

Describe the solution

Check whether the radius of the explosion would fall outside of the reality bubble. If not, it's triggered on the reality bubble map. If any part of the explosion radius would fall outside of the reality bubble a new map (i.e. full 11*11 submap one) is generated centered on the explosion and the explosion processing is done on that map. Note that this causes further OMTs to have their contents generated as a result on falling inside the new map, and so potentially be generated a little earlier than they should have been otherwise.
Note that the modified code allows for usage with a target location outside of the reality bubble, but the current code does not call it with any such locations.

The code required some juggling to handle creatures, since the related code only deals with the reality bubble's coordinates.

Loading of another map on the explosion location recursively would trigger actualization of all submaps within that area, and and actualization of the target submap itself would recursively trigger explosion processing again. In addition to that, actualization would also trigger pending explosions of any submaps loaded, which would, again, lead to recursion. Blocking recursive explosion handling doesn't work, because actualization doesn't only trigger the explosion, but also removes the trigger, so while it would work for the primary explosion itself, it would remove any follow on explosions, so those would never be triggered. Thus, actualization was blocked for the map loaded by the explosion handling.

Describe alternatives you've considered

Continue to encounter half craters.

Testing

  • Set a 100L barrel bomb at the edge of an overmap tile, lit it, and walked 100 tiles away from the border and then back. Observed the resulting half crater with the master code.
  • Repeated the above with the modified code, observing a full crater.
  • Generated Crater map specials and visited them. Didn't see any significant difference between the two versions (I guess I didn't happen to get any half crater cases).

Bomb crater with original code.
Screenshot (622)
Bomb crater with modified code.
Screenshot (624)

  • Debug create a crater map extra on a tile outside of the reality bubble and another one on the next tile away. Approach and verify the explosions are triggered separately (both visually and via the debugger).
  • Debug create two crater map extras beside each other on tiles outside of the reality bubble. Approach and verify they are both triggered at the same time (this can fail if one is on the near submap and the other on the far one, but it worked in my test).

Additional context

I see two expanded usages of the functionality:

  • Usage of "artillery" to immediately (or with a delay, if you can find a way to get the triggering timer checked by do_turn) affect a larger remote area with an explosion.
  • Usage of some kind of "proximity sensors" around large explosives (or, really, craters that should already be there) on every submap surrounding the outer boundary of an explosion radius triggered by the loading of a map with such a trigger. That would then trigger the explosive in the center, as well as the removal of all other triggers around the explosive. That would have the effect of allowing for quite big craters without blowing up the PC, and it would also mean the explosion happened out of sight so the PC would not get the weird explosions we currently get, just come across the resulting crater.

@github-actions github-actions bot added [C++] Changes (can be) made in C++. Previously named `Code` <Bugfix> This is a fix for a bug (or closes open issue) astyled astyled PR, label is assigned by github actions json-styled JSON lint passed, label assigned by github actions labels Aug 10, 2024
@github-actions github-actions bot added the BasicBuildPassed This PR builds correctly, label assigned by github actions label Aug 10, 2024
@Fris0uman Fris0uman mentioned this pull request Aug 11, 2024
@Brambor
Copy link
Contributor

Brambor commented Aug 12, 2024

So if you set up an explosion at the edge and another explosion at the explosion's edge etc. What happens? Do all the explosions get triggered? In what order? Or all at once? Can the user run out of memory with a sufficiently small amount of such explosions (255 maybe) and trigger a crash? Maybe it's not a problem for vanilla, but if I were to make a mod where the world is bombed everywhere, would it work or would it crash?

@PatrikLundell
Copy link
Contributor Author

PatrikLundell commented Aug 12, 2024

A very good question I hadn't considered.

Testing shows it doesn't work properly, and thus rework is required.

I tested to place two map extra craters in neighboring tiles and approached them so the second one was beyond the first one (as opposed to side by side), and the one further away wasn't triggered. Debugging shows that there was a single entry in the _explosions vector when process_explosions is called, but two when the processing loop is exited after a single pass. _explosions.clear() is then called, which erases both entries. I suspect something similar might happen if they were side by side.

Ideally, only the explosion(s) encountered by the reality bubble should be processed and removed, while those on submaps loaded by process_explosions should not.

Edit: This was addressed by moving the recursion block from the explosion handling itself to block the actualization of recursive load operations. The corresponding part of the solution description text has been changed to reflect this.

As to the question about the order in which explosions are triggered, it should be exactly the same as before, which seems to be whatever order submaps are loaded, and, within each submap, whatever order actualization happen to process the triggers in. This should also mean that an explosion destroying the item triggering a later explosion doesn't matter, because all explosion triggers are processed first, and all explosions after that. The exception would be when a creature is implied in the explosion, in which case an earlier explosion may blow up a creature, and the explosion handling would fail to find it, or the creature may have been moved to a different location. I haven't checked what the code does for those cases, but there is some kind of handling for the absence of the creature.

@PatrikLundell PatrikLundell marked this pull request as draft August 12, 2024 13:33
@PatrikLundell PatrikLundell marked this pull request as ready for review August 12, 2024 14:23
@Maleclypse
Copy link
Member

Conflicts sorry.

@PatrikLundell
Copy link
Contributor Author

No worries. I knew this one was coming.

PatrikLundell and others added 2 commits August 19, 2024 10:47
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
@github-actions github-actions bot removed the astyled astyled PR, label is assigned by github actions label Aug 19, 2024
@github-actions github-actions bot added the astyled astyled PR, label is assigned by github actions label Aug 19, 2024
@dseguin dseguin merged commit 2318742 into CleverRaven:master Aug 20, 2024
26 checks passed
@PatrikLundell PatrikLundell deleted the explosion branch August 20, 2024 20:40
@Procyonae
Copy link
Contributor

Nice one

@GuardianDll
Copy link
Member

GuardianDll commented Jan 21, 2025

Hey, i'm currently trying to implement mortar examine actor, am i correct in my understanding i need to use explosion_handler::explosion() function? i didn't spot it before, but it looks like it is extremely conservative into what it can do outside of reality bub, meaning the only it can do is damage terrain. Monsters are not affected, shrapnel is not used, the only damage monster gets is from falling down the story or two when they are spawned again, and explosion created a hole;
image

@PatrikLundell
Copy link
Contributor Author

I'm trying to remember...

As you say, you "plan" explosions with one of the explosion operations, and then they're applied through process_explosions(). The intention is that there should be no difference in the effects depending on whether the explosion effects happen in the reality bubble or one "centered" (i.e. that submap, not the exact map square) on the explosion.
If that doesn't work (as you indicate it doesn't), I would guess some of the operations implementing effects (such as shrapnel) are implemented using a hidden assumption that they're operating on the reality bubble map, rather than the one they're actually on.
I'll try to look into it tomorrow.

And thanks for bringing it to my attention.

@PatrikLundell
Copy link
Contributor Author

PatrikLundell commented Jan 22, 2025

This is weird...
I've set up a test situation using breathers (they have the advantage of not moving around so you can place them and they'll stay put as you move around) and a barrel bomb.

I see three weird effects:

  1. The critters directly adjacent to the barrel only take falling damage.
  2. The critters within a crater(?) range take no damage unless they're falling, in which case they take falling damage only (really a general case of 1).
  3. Only critters on the near side (towards the PC) beyond the protection range of point 2 take shrapnel damage (so shrapnel damage does happen).

I think I've found the cause of the issues, but there's need for further investigation to figure out how to solve it.
The reason seems to be that the creature_tracker only contains the creatures currently on the reality bubble map. This means that no critter on the remote part of the explosion map are affected, but rather spawn when their areas are loaded into the reality bubble (and thus take any potential fall damage at that time). It also has a bizarre effect if the explosion happens at the far side of an OMT, because the OMT is loaded and explosions are triggered, but the critters are only loaded at the near side.
This also means that the crater range of point 2 above is incorrect: its a submap boundary issue.

Presumably this means there is something missing in the explosion map loading, as critters should be loaded and unloaded with the map.

Edit:
Yes, the critter loading normally happens through PC movement on the map, so it had to be added specifically for the explosion usage. This is something that's worth keeping in mind for any further non reality bubble activities that may affect critters.

PR generated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
astyled astyled PR, label is assigned by github actions BasicBuildPassed This PR builds correctly, label assigned by github actions <Bugfix> This is a fix for a bug (or closes open issue) [C++] Changes (can be) made in C++. Previously named `Code` json-styled JSON lint passed, label assigned by github actions
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Craters are spawning partially
6 participants