aba500b482
back into play with bad data I don't have a test case to verify the fix, and I'm not absolutely certain that the cause has been correctly diagnosed, but I think the problem was caused by a guard being sent into limbo because the map was too full to place it, then while it was on the migrating monsters list waiting for a chance to come back the fuzzer executed #wizmakemap. If the hero left the level and subsequently returned, the guard would arrive back but monst->mextra->egd contained data for the previous incarnation of the level that's invalid for wizmakemap's replacement. Treat any shopkeeper, temple priest, or vault guard who is not on his 'home' level like the Wizard has been treated since 3.6.0. When leaving the level they're on, put them on the migrating monsters list scheduled to return to present position instead of stashing them in the level's data file. That way they can be accessed from any dungeon level, so wizmakemap can pull ones for the level it's replacing off the migrating monsters list when removing the old level's monsters, handling both migration-pending and already-arrived-on-another-level. Bonus fix: put monsters who are on the migrating_mons list solely in order to be accessible from other levels back first when returning to the level they're on so that pets and the hero can't hijack their spot when those arrive. The Wizard has been vulnerable to that. Not fixed: #wizfliplevel command needs to flip parts of shk->mextra-> eshk and priest->mextra->epri for shk or priest on migrating_mons. Vault guards don't contain anything flippable when migrating, but do have coordinates that need fixing up while they're maintaining a temporary corridor to/from the vault.
127 KiB
127 KiB