Prevent overmap mongroups from spawning on top of faction bases

[eltank]

Summary

Balance "Prevent overmap mongroups from spawning on top of faction bases"

Purpose of change

As discussed in #49322 one of the blockers for making faction bases (e.g. Refugee Center) appear only once per gameworld is the concern that a faction base may spawn in a "broken" state (in particular, overwhelmed by ants, fungaloids, triffids or blobs spawned by a nearby anthill/spire/grove/pit). While I personally believe this is extremely unlikely, I agree that we should try to prevent it from happening. This PR makes faction bases "safe" from overmap mongroups placed at worldgen time. It does not prevent mongroups from moving into these bases if "wandering hordes" is turned on and the player makes enough noise to attract nearby hordes. It also does not prevent monsters generated by mapgen (such as the Refugee Center zombies) from spawning.

Describe the solution

• Introduce a SAFE_ZONE SAFE_AT_WORLDGEN JSON flag for overmap specials
• Tag faction bases with the flag
• Keep track of "safe" tiles when placing an overmap special tagged with the flag
• Change the overmap mongroup spawn code to check if the tile is safe
• Remove already-spawned mongroups when placing a new safe zone

Describe alternatives you've considered

Preventing monster-spawning map specials from being placed close to a faction base. That seems much more complicated to do.

I considered either persisting/reloading the overmap's safe_at_worldgen set or rebuilding it on game load using the already-persisted overmap_special_placements JSON attribute. But since safe_at_worldgen is only needed during worldgen (i.e. whenever a new overmap is generated) this is not necessary.

Instead of redirecting most of the existing add_mon_group calls to a new spawn_mon_group function, I considered adding a bool argument, i.e. changing the signature to something like add_mon_group( const mongroup &group, bool initial_spawn = false ). But I think a separate function is cleaner (easier to trace references, more intuitive invocation).

Testing

I boosted the spawn chance and area of effect of fungal towers to extreme levels, like so:

  {
    "type": "overmap_special",
    "id": "Fungal Tower",
    "overmaps": [ { "point": [ 0, 0, 0 ], "overmap": "fungal_tower" } ],
    "locations": [ "wilderness" ],
    "city_distance": [ 1, 90 ],
    "occurrences": [ 40, 100 ],
    "flags": [ "FUNGAL" ],
    "rotate": false,
    "spawns": { "group": "GROUP_FUNGI_TOWER", "population": [ 4250, 6750 ], "radius": [ 40, 50 ] }
  },

I then created a new world with default settings, used the evac shelter console to get the location of the Refugee Center and teleported there. As expected there was a fungal tower nearby.

I teleported to the south/north/west/east boundaries (where the fences are) and verified that there are plenty of fungal monsters outside the fence but none inside the fence:

In the refugee center building the only living creatures are the refugees and the back bay zombies.

Additional context

The following locations have been tagged with SAFE_AT_WORLDGEN:

• Refugee Center
• Bandit Cabin
• Bandit Camp
• Tacoma Ranch
• Hub 01
• Isherwood Farm

Did I miss anything?

[Venera3]

Anthills and sewers use a hardcoded monster placement in generate_sub(), you might want to reroute that through this check as well.

[eltank]

Anthills and sewers use a hardcoded monster placement in generate_sub(), you might want to reroute that through this check as well.

Already done. See changes to overmap.cpp L1600-1760.

[eltank]

Rebased after 0.F release. Could someone take a look at this change?

[esotericist]

sorry for delay, health has been terrible on my end, but since i'm the one who asked for this i definitely meant to respond sooner.

at a glance the code looks the right shape. i'm not sure if safe_zone is quite the right term for this (to me that phrasing implies a degree of persistence beyond mere worldgen time), but i also can't come up with anything better offhand and i definitely don't want quibbling over the label to delay this.

i wish i could provide a more concrete approval, but all i can do right now is say "i see nothing that concretely should prevent this from being merged"

edit: if someone else doesn't get to it first, i'm going to try to review it properly in the coming days, but i have prior commitments (like hopefully helping korggent fix the mouse support for the new graphical overmap tech)

[ifffrt]

at a glance the code looks the right shape. i'm not sure if safe_zone is quite the right term for this (to me that phrasing implies a degree of persistence beyond mere worldgen time), but i also can't come up with anything better offhand and i definitely don't want quibbling over the label to delay this.

Maybe it could be renamed to 'safe_at_worldgen', or 'cleared_at_worldgen' since that's basically what the process does, i.e. it sees that a group of spawned enemies is somewhere they shouldn't be and it erases them out of existence.

[eltank]

at a glance the code looks the right shape. i'm not sure if safe_zone is quite the right term for this (to me that phrasing implies a degree of persistence beyond mere worldgen time), but i also can't come up with anything better offhand and i definitely don't want quibbling over the label to delay this.

Maybe it could be renamed to 'safe_at_worldgen', or 'cleared_at_worldgen' since that's basically what the process does, i.e. it sees that a group of spawned enemies is somewhere they shouldn't be and it erases them out of existence.

'safe_at_worldgen' sounds good to me (if a bit verbose). 'cleared_at_worldgen' could be interpreted as removing all creatures or items or something else. [Done]

[jbytheway]

(Coming from #49980 where I made a similar mistake) It looks like you forgot to add serialization for the new safe_at_worldgen member, so it won't work after the game's first save/load cycle.

(This is an easy mistake to make, so I'm prioritizing my plan to add a clang-tidy check looking for missed serializations)

[eltank]

(Coming from #49980 where I made a similar mistake) It looks like you forgot to add serialization for the new safe_at_worldgen member, so it won't work after the game's first save/load cycle.

(This is an easy mistake to make, so I'm prioritizing my plan to add a clang-tidy check looking for missed serializations)

That was intentional. safe_at_worldgen is only needed during the generation of a new overmap. There's no need to persist it after that. [This is also mentioned in alternatives considered]

[jbytheway]

That was intentional. safe_at_worldgen is only needed during the generation of a new overmap. There's no need to persist it after that. [This is also mentioned in alternatives considered]

Cool. Sorry for the noise.

[esotericist]

(Coming from #49980 where I made a similar mistake) It looks like you forgot to add serialization for the new safe_at_worldgen member, so it won't work after the game's first save/load cycle.
(This is an easy mistake to make, so I'm prioritizing my plan to add a clang-tidy check looking for missed serializations)

That was intentional. safe_at_worldgen is only needed during the generation of a new overmap. There's no need to persist it after that. [This is also mentioned in alternatives considered]

does this mean if something with that tag generates at the edge of an overmap, then it won't be protected against things that generate in that next overmap over if there's a save/load cycle in between?

[eltank]

That was intentional. safe_at_worldgen is only needed during the generation of a new overmap. There's no need to persist it after that. [This is also mentioned in alternatives considered]

does this mean if something with that tag generates at the edge of an overmap, then it won't be protected against things that generate in that next overmap over if there's a save/load cycle in between?

Hmm, yes that is a thing that could happen with very low probability. Alright then, take a look at #50046 for a fix.