Redo the fix that prevents hangup from putting hero on top of water
if it occurs during magic mapping or object/gold/trap detection. Instead
of copying u.uinwater into another field in struct u so that it can be
reset during restore, copy it into a new field in struct iflags and reset
it during save so that no fixup upon restore is needed.
Noticed while looking at the magic mapping code: u.uinwater is
cleared during mapping and detection so that map updating isn't suppressed
due to underwater vision restrictions, and it was possible for a hangup
save to take place before that state field was reset. After restore, the
hero would end up standing on water, then fall in on the next turn. This
saves it in struct `u' rather than in a local variable, so that the stored
value is accessible during restore.
The u.uburied flag was being ignored, but presumeably it would also
impose severe vision restrictions if it ever gets implemented, so it is
now saved, temporarily cleared, and restored along with u.uinwater during
monster/object/gold/trap detection and magic mapping.
There was an issue reported where save files between different
versions of a manufacturer's compiler were incompatible because the time_t
ubirthday field was changed from 32 bits to 64 bits.
32 bit time_t implementations will break at 19:14:07 on January 18, 2038.
64 bit time_t implementations will break at 23:59:59 on December 31, 3000.
This removes the dependency on the size of time_t from the save file.
The ubirthday field is no longer embedded in struct you.
This also adds two general purpose routines to hacklib.c, one to convert a time
value to a 14 character char representation and the other to convert that
back to time_t. Those are used by the save/restore routines.
This is a savefile breaking change, so editlevel in patchlevel.h was
incremented.
Remove a couple of false comments about Luck, and an unreachable
switch case based upon them. I don't know if the comment in you.h was ever
true, but it was false by the time Kevin brought across assorted changes
from slash'em however many years ago. Full moon does not change the range
of possible Luck values, and ``rn2((Luck + 6) >> 1)'' produces a value
between 0 and 8 for prayer result, never 9. Natural luck is always within
the range of -10 to +10, and extra luck from carrying blessed or cursed
luckstone can add or subtract another 3. Full moon and Friday the 13th
change the equilibrium point for luck timeout but do not change the overall
range of possible values, which remains at -13 to +13.
<email deleted> sent a report with
subject "Vampire-dancing can give you unlimited maxhp/maxmp" about how you
can manipulate your hit points and spell energy by using equipment to
lower Con and Wis prior to deliberately losing a level, then switching to
alternate gear to raise them prior to gaining the trivial 1 XP needed to
regain the lost level. With Stormbringer (to toss up so that it falls on
your head) or spell of drain level (to cast at yourself), you can do this
level toggling as much as you like since it doesn't consume any resources
in the process. All you is a supply of non-threatening monsters to kill
for the regaining half.
In March he sent "vampire-dancing (patch)" which didn't include a
patch but did give a URL ( http://nethack.angband.pl/vampdance.patch )
for one. That contained his suggested fix: recording the hit points and
energy points given each time you gain a level and then using those exact
amounts when you lose the corresponding level. It's still possible to
manipulate HP and Pw by losing multiple levels after you've boosted Con
and Wis to ascension ready status (you'll lose the original values but can
expect to get better ones when gaining levels back), but can only gain a
modest improvement and repeating it doesn't augment the effectiveness.
Plus it's much harder to regain multiple levels than it is to get just one.
His patch had a couple of bugs which I've fixed. I suppose that there
could be additional potential problems but the idea and its implementation
are both pretty straightforward. (This doesn't address the other recently
reported situation of using polymorph into "new man" while at level one to
multiply HP and Pw.)
Introduce a new set of functions to manage delayed killers in the trunk, used
in addressing the various reports of delayed killer confusion. Since existing
delayed killers are related to player properties, the delayed killers are
keyed by uprop indexes. I did this to avoid adding yet another set of
similar identifiers.
- the new delayed_killer() is used for stoning, sliming, sickness, and
delayed self-genocide while polymorphed. Some other timed events don't
use it (and didn't use the old delayed_killer variable) because they
use a fixed message when the timeout occurs.
- A new data structure, struct kinfo, is used to track both delayed and
immediate killers. This encapsulates all the info involved with
identifying a killer. The structure contains a buffer, which subsumes the
old killer_buf and several other buffers that didn't/couldn't use killer_buf.
- the killer list is saved and restored as part of the game state.
- the special case of usick_cause was removed and a delayed killer list
entry is now used in its place
- common code dealing with (un)sliming is moved to a new make_slimed function
- attempted to update all make dependencies for new end.c -> lev.h
dependency, sorry if I messed any up
This patch gives game and savefile compatibility
whether GOLDOBJ is defined or not.
You can build with GOLDOBJ defined or not, and
still load your saved games. Rebuild with the
opposite, and load the same game.
That way GOLDOBJ can be experimented with
more easily.
1. Leave the "you" struct and the "monst"
struct the same under the hood between
GOLDOBJ and !GOLDOBJ.
2. Always write out gold as an
object on the player and monster
inventory chains.
On a restore of the savefile with GOLDOBJ
not defined, take the gold objects out of
the inventory chains and put it into u.ugold
or mtmp->mgold as appropriate.
On a restore of the savefile with GOLDOBJ
defined, nothing special is done.
Prevent burying a ball from ending your punishment.
When you bury the ball, internally NetHack Punishment
ceases, but a new trap type of TT_BURIEDBALL immediately
kicks in (acting similar to TT_INFLOOR in some ways).
You can eventually work the ball free (or teleport, etc.),
but that will just return you back to normal Punishment.
