This is a security fix, intended to avoid a DoS attack (that has
been used in practice against public servers) in which a situation
is created in which the same short loop of commands can be run
over and over indefinitely; this causes a lot of CPU usage on the
public server as it simulates the game turns, and requires hardly
any network or CPU usage for an attacker.
Once the turn counter goes above 100000, the average prayer timeout
increases by 1 for every additional 100 turns spent. Thus, even
with a ring of slow digestion, nutrition prayers will no longer
be possible after turn 2 million or so. This is unlikely to have
any noticeable effect on any strategy that does not rely heavily
on prayer for nutrition; even in an implausible 200000-turn game,
prayer timeout will only be increased by 1000 or so, which should
be easily manageable for a character that powerful.
Before this commit, attaching a lit candle would reduce the amount
of fuel in the candelabrum to 0, 15 or 75 turns due to a failure to
account for time stored in the candle's burn timer. Fixing this is
very important because a time of 0 turns on the candelabrum is not
supposed to be possible.
This may have happened in a 3.7 game on Hardfought. Even if it didn't,
I'm still uncomfortable with the potential for the game to potentially
become unwinnable as a consequence of age field corruption. Add an
impossible() for when this situation happens, and code after the
impossible() to repair the game by removing the candles.
It's a gameplay-affecting action (it updates the character's
memory of the map), and there's no way to spam it without using
resources, so rn2 is safe.
This is based on the multiple-RNGs code fron NetHack4, but using
only the parts relevant to the display RNG (and with substantial
changes, both because of post-3.4.3 changes, and because Nethack4's
display code is based on Slash'EM's rather than NetHack's).
If we do it the other way round, then mimics will forget what
they're mimicking without a seemimic() call, meaning that the
line-of-sight calculations can get confused if the mimic was
mimicking something opaque.
Discovered while writing the previous commit. If you dipped a sack
full of potions into an uncursed potion of water, the potions would
dilute but you wouldn't lose the original potion, letting you repeat
until all were diluted.
Allowing people to do this trick to blank multiple potions from one
potion of water seems like it's not an abuse, given that it can be
done in a more tedious way with water walking or the like and it
costs resources, but it's definitely abusive to make it possible
entirely for free.
We can identify them by elimination in this case (they're the only
bag-like container that doesn't produce a message, the others all
do), so it's probably best to be more explicit as to what's going
on (for user interfaces and TDTTOE purposes).
Some windowports that are currently being written by third parties
need more information about the engine than they currently have.
Two specific reported problems: a) needing to know whether a
putstr() call relates to a count (so that it can be placed in a
different part of the user interface from the message area); b)
needing to know whether a request for a character relates to
command input (some hangup handling routines need this so that
they can determine what behaviour is potentially exploitable).
Knowing whether or not you're inside parse() fixes both of them.
This would be cleaner to do by changing the windowport API, but
that'd break existing windowports, which isn't really ideal.
Setting a globalish variable that the windowport can inspect, but
can ignore if it prefers, means that existing windowports will
continue to work fine, but new windowports will have more
information and thus more flexibility in how they handle command
entry.
Some windowports that are currently being written by third parties
need more information about the engine than they currently have.
Two specific reported problems: a) needing to know whether a
putstr() call relates to a count (so that it can be placed in a
different part of the user interface from the message area); b)
needing to know whether a request for a character relates to
command input (some hangup handling routines need this so that
they can determine what behaviour is potentially exploitable).
Knowing whether or not you're inside parse() fixes both of them.
This would be cleaner to do by changing the windowport API, but
that'd break existing windowports, which isn't really ideal.
Setting a globalish variable that the windowport can inspect, but
can ignore if it prefers, means that existing windowports will
continue to work fine, but new windowports will have more
information and thus more flexibility in how they handle command
entry.
These are elven /adventurers/, so they get sleep resistance at
experience level 4 (not immediately), and so there's an outside
chance they'll be killed by a sleeping gas trap. This commit
reduces the probability, though.
The hero isn't the only adventurer seeking the Amulet. It's clear
from various other events in the game that others have been there
beforehand. As such, we can expect many of the traps on the first
few levels to already have been triggered repeatedly by questing
adventurers.
This commit allows for the creation of adventurer corpses in
early-game traps, together with a small amount of cursed junk
(i.e. a miniature bones pile) and any items created by the trap
itself. On dungeon level 1, this is guaranteed for the vast
majority of harmful traps, in order to avoid near-unavoidable
deaths in the very early game due to not having enough max HP to
survive a trap hit.
Wizard mode testing shows that this case doesn't trigger very
often; maybe once a game on average. (Traps are rare on filler
levels, at least early on, and many types of trap would leave no
evidence, e.g. a teleportation trap won't kill people on its own
square.) As a result, the balance impact from the actual items
here is likely to be minimal (it may help out ranged combat roles
slightly but they could do with the boost). The main change,
therefore, is to reduce the number of unfair very early deaths
(replacing them with fairer "you shouldn't have investigated
what created that corpse!" deaths).
Right now, the punishment for being hit more than twice by a level
drainer pre-Quest is disproportionate; grinding back up to level
14 from level 13 takes a long time, and yet isn't particularly
difficult, just slow, and a potion of full healing will only
regain one of the lost levels (as only half the lost levels can
be regained this way).
Meanwhile, potions of restore ability are currently automatically
blanked by almost all spoiled players; they don't do anything that
doesn't have more convenient sources (unicorn horn or the spell),
so they're only useful in the very early game for getting poison
resistance.
This commit aims to fix both problems, by allowing potions of
restore ability to restore lost experience levels, in addition to
lost attribute points; an uncursed potion restores one lost level
(with multiple potions making it possible to hit the cap), a
blessed potion restores all of them. That gives players an
incentive to keep them around rather than blanking them. (Notably,
the spell and tool were not changed the same way; for restoring
levels, you need to use the potion.)
Telling people to #quit due to something going wrong internally is
probably a bad idea; the game might or might not be corrupted, but
even if it is, most players will want to play on rather than lose
their game entirely.
Instead, advise saving and reloading; this will fix the underlying
cause of many impossible()s (which are normally related to
inconsistent internal structures; the save file format has much
less redundancy, therefore less chance of inconsistency, than the
in-memory format).
Thanks to AmyBSOD for reminding me to do this.
One of the huge strengths of NetHack is that there's a lot of
mechanical content in it; you can continue learning about the game
more or less continuously, and when you die, it's usually possible
to figure out what you did wrong and avoid that for future games.
There are two parts to this: a) a death should only happen if the
player didn't play perfectly, b) the nature of the problem should
be clear.
FoodPois status meets a) just fine, but not b); food poisoning
mechanics tend (based on my research) to actively give the wrong
impression to new players. (Normally, something along the lines of
"corpses are sometimes randomly dangerous", which is insidious in
the sense that it'll cause players to leave them as a last resort
and thus never discover what they're doing wrong.) The easiest way
to fix this is to explain what the rule is explicitly.
Additionally, this should hopefully go some way towards changing
the incorrect perception many people who haven't played (any/much)
NetHack have that the game is arbitrarily cruel... It's important
to get the "everything happens for a reason" attitude across from
an early stage, by tying it to an event like this that's commonly
seen by new plyers.
Experienced players should not be affected much if at all by this
change, because they hardly ever get food poisoning anyway.
(Note: there are actually two main mechanics related to food
poisoning, one widely applicable, one much more subtle. The message
here is focused mainly on the common case, but doesn't actually
contradict the rare case, and attentive players may be able to
deduce both mechanics from the one message. Most likely, players
will hit the common case, see the message, learn the common case,
and some time later hit the rare case, get the message again, and
read it more carefully this time.)
My compiler was understandably concerned about a potential buffer
overflow here. I don't think the string could get long enough to
cause that to happen, but it's hard to be certain. It's much safer
to limit the length of the string so that it fits in the buffer, as
done here, and if there really wasn't a problem the change will
cause no harm at all. (If there was, the string will be truncated
rather than corrupting memory. This code is in showing the
config-file version of a status highlight, something where
truncated text will probably be obvious to the user.)
This change was coded by FIQ, who suggested it by email.
The main change here is related to monster anti-oscillation code.
When a monster believes it's stuck in an AI loop, it looks for an
alternative strategy. That applies to pets too. However, if the
pet is currently near the player, we can typically assume that it's
there because it wants to be there, and an oscillation is not
because it's stuck but because it's already in the best possible
place. This commit causes pets to be "allowed" to stay near the
player, rather than running the wrong way down a corridor because
it's the only way to do something different than what they're
currently doing.
If the pet is far from the player, we use the old behaviour unless
the pet is leashed or the player tried to call it with a whistle
or the like, in order to avoid the risk of a genuine AI loop trying
to get back to the player. (Whistling happens rarely enough that it
won't cause AI loops of its own - the player isn't going to whistle
every turn - and it makes flavour sense that a pet might interpret
it as "you're going in the wrong direction!".)
The previous version of this would lead to big warnings and
impossibles. This doesn't seem like a useful case, but it's still
better to have better warning messages just in case it does
happen.
The previous behaviour was to mention the missing file, but then to
try and fail to lock the nonexistent file 10 times, which rather
obscured the original cause of the error as it took up so much more
room on the screen.
This patch also changes the error message. Failure to lock a
nonexistent file is almost always the result of a mistake during
the install process (e.g. running from the wrong directory, or
running without an install). We should give the user a hint about
that.
Having selectable base indexes for the monster list doesn't seem
likely to be needed in the future any more, now that the code for
the monster list is stable. Additionally, the functionality in
question has bitrotted heavily (e.g. many "loops over all
permonsts" start at a hardcoded 0, which wouldn't work with a
1-indexed monster list). As a result, removing the relevant code
in makedefs makes it clearer what can and can't be assumed about
the code, reducing the risk of bugs in the future.
Thanks to FIQ for mentioning that this could be an issue.
This fixes melee kiting more comprehensively (it now doesn't work
against slower monsters either), and prevents you doing things like
opening up a gap when running from an imp (you couldn't do that in
3.4.3).
If you attack a monster under Elbereth protection, and it wasn't
scuffed by the attack itself, then it'll be automatically removed
with an alignment penalty. It no longer fades from scaring monsters;
only from being abused to attack monsters while protected.
setmangry() and wakeup() were being used for multiple purposes. Add an
extra parameter to track which. This fixes several minor bugs (e.g.
whether monsters with no eyes were angered by (useless) gaze attacks
against them previously depended on the state of a UI option, and
the Minetown guards would be annoyed if you used a cursed scroll of
tame monster on a shopkeeper). It's also a prerequisite for the
Elbereth changes I'm working on.
Elbereth now has to be on a square by itself; it's hard to justify
why text before it would prevent it working if text after it fails
to prevent it working.
Alex Smith