CleverRaven
Can't place Balthazar Bunker
Describe the bug
When I activate the modified radio, I get the following bug after the message:
DEBUG : Couldn't find placed overmap special balthazar_bunker???
REPORTING FUNCTION : find_or_create_om_terrain C++ SOURCE FILE : D:\a\Cataclysm-DDA\Cataclysm-DDA\src\mission_util.cpp LINE : 208 VERSION : cdda-experimental-2025-12-09-0810-dirty
Attach save file
Steps to reproduce
Activate modified radio.
Expected behavior
I expect to not get an error message, and probably to get a quest.
Screenshots
No response
Versions and configuration
- OS: Windows
- OS Version: 10.0.26200.7171 (25H2)
- Game Version: cdda-experimental-2025-12-09-0810-dirty [64-bit]
- Graphics Version: Tiles
- Game Language: System language []
- Mods loaded: [ Dark Days Ahead [dda], Disable NPC Needs [no_npc_food], Portal Storms Ignore NPCs [personal_portal_storms], Magiclysm [magiclysm], No Hope [no_hope] ]
Additional context
No response
/Confirmed
There is something weird going on here, which has to be investigated further. The target location has been allocated and it exists, but for some reason it hasn't been registered in the data structure where it is expected to be found, so the code finds that it has been placed, but then fails to find where, which the code obviously doesn't expect to happen (hence the "???" in the error report.
For some reason, teleporting to a revealed location in the overmap it's located causes radio activation to find the location, so maybe data isn't recorded in the data structure until the PC visits it? Needs to be investigated.
Anyway. the location is NNW of Westhampton, at a distance a bit less than the one between the current location and Westhampton. North of Westhampton you'll find an isolated J shaped piece of road. If you manage to get there and activate the modified radio it should work correctly.
Edit: The reason the location isn't found is that the overmap data file isn't found, for some reason. The data is in the file, but that doesn't really matter if it's not read. Teleporting to the target OM and back to the original OM does find the file and the location, so it's some kind of issue with the overmapbuffer::has() operation, as it falsely claims the OM data is nonexistent, while teleporting there causes the data to be fetched correctly, so it's available on return ("has" fails to find any of the OMs except for the one the PC is loaded into originally, and after the teleport back and forth it finds first its own and then the target one).
My guess is that it has to do with zzip somehow, as the placement of the overmap files is in an overmaps directory when zzip is used, but in the save directory directly when it's not used. I tried the hack to copy the overmap zzip files to the top directory to see if it would work, but it didn't (and I've got the unpacked files there as well, in order to be able to verify the target location is actually recorded in it). I don't trust that I would be able to figure out how to change the saving format to unpacked and get it all correct, so I haven't tried to do that.
I would like to ask @akrieger to have a look at this, with apologies if I'm bothering you incorrectly.
I'm some busy and dunno when I can get to it, but I promise when I have time this is what I'll spend it on.
I've dug a little bit further, and it seems overmapbuffer::get_existing() (called from overmapbuffer::has()) bails out due to the known_not_existing.count (p) > 0 check. My attempt to find where that structure is populated (only place is later in overmapbuffer::get_existing()) seems to indicate it's set if the corresponding o.x.y file isn't found in the save directory, i.e. .../NH Mag/o.x.y rather than .../NH Mag/overmaps/0.x.y.zzip.
Hacking around to place files there doesn't seem to work around the symptom, though.