Trap doors saved their destinations as an absolute level, rather than a
relative one, so if you loaded bones from a special level their
destinations would reflect the dungeon layout from the bones player's
game. For example, die on the Oracle level, on dlvl5, with a trap door
that goes to dlvl6. Another player gets those bones on their Oracle
level, which is dlvl8... the trap door would still go to dlvl6. Pretty
amazing trap door -- something you might see in a funhouse!
Include relative rather than absolute destinations in save and bones
files, much like stairs do, to avoid this problem.
I bumped EDITLEVEL because although this won't break save files in an
obvious way, it will interpret the (absolute) destinations in existing
save and bones files as relative, leading to some crazy long falls. :)
* Incrementing EDITLEVEL can be used to force invalidation of old bones
* and save files.
*/
-#define EDITLEVEL 64
+#define EDITLEVEL 65
/*
* Development status possibilities.
if (nhfp->structlevel)
mread(nhfp->fd, (genericptr_t)trap, sizeof(struct trap));
if (trap->tx != 0) {
+ if (g.program_state.restoring != REST_GSTATE
+ && trap->dst.dnum == u.uz.dnum) {
+ /* convert relative destination to absolute */
+ trap->dst.dlevel += u.uz.dlevel;
+ }
trap->ntrap = g.ftrap;
g.ftrap = trap;
} else
register struct trap *trap2;
while (trap) {
+ boolean use_relative = (g.program_state.restoring != REST_GSTATE
+ && trap->dst.dnum == u.uz.dnum);
trap2 = trap->ntrap;
+ if (use_relative)
+ trap->dst.dlevel -= u.uz.dlevel; /* make it relative */
if (perform_bwrite(nhfp)) {
if (nhfp->structlevel)
bwrite(nhfp->fd, (genericptr_t) trap, sizeof *trap);
}
+ if (use_relative)
+ trap->dst.dlevel += u.uz.dlevel; /* reset back to absolute */
if (release_data(nhfp))
dealloc_trap(trap);
trap = trap2;