Part 4 of implementing wish spreading. (This is now a complete
implementation, although the details are likely to change - but it
makes sense to commit something with the right balance properties,
and then tweak it based on feedback from playtesting.)
This helps to make the Amulet of Yendor feel special, and restores
approximately the same average number of wishes per game as existed
prior to the nerf to wands of wishing.
Placing the wish in allmain helps to avoid the wish happening at an
awkward place in the game's control flow, and is simpler than
testing every possible mechanism for gaining items for bugs (message
order is a common issue when trying to place it in addinv-related
functions, and this also avoids issues with the wished-for item
immediately invalidating an assumption that was made by the calling
code).
It is possible that this would be better as an invoke effect,
although I like the impact of picking up the Amulet and immediately
being given a wish.
This is partly for balance reasons (so that clearing the Castle
helps towards the level 14 Quest unlock) and partly as a clue to
players spoiled on previous versions that the Castle wand now works
differently.
Part 3 of implementing wish spreading. These items are each worth
most of a wish for non-illiterate games (most games wish for a
magic marker, and a magic lamp gives a wish 80% of the time).
The placement of the random item could be better (currently it is
purely random, which is occasionally interesting but often boring),
but this will serve as a base for experimenting with the balance
properties of the moved wishes.
Part 1 of implementing wish spreading. Vlad's throne is now
guaranteed to eventually give a wish, but has a range of other
powerful (and mostly bad) effects, like removing intrinsics, that
can be much harder to deal with than typical throne effects.
This causes the difficulties to get out of sequence, but we agreed
that this is a less important rule than keeping monster IDs stable.
Breaks save and bones files, because it changes monster IDs.
This is both a bugfix (the hero would be unlikely to aim their
throw at what appeared to be an object) and a balance fix (it was
possible to, somewhat tediously, defend yourself from mimics by
throwing gold pieces at them, and for many players this became
standard strategy in shops, negating the threat from mimics).
These two types of monster were extreme outliers in terms of where
they appeared versus how lethal they were (3-4 times as deadly as
other monsters that appeared at similar depth, based on statistics
from actual play), so their generation depth has been manually
modified.
Breaks save and bones files (because monster type IDs have to be
sorted numerically by difficulty, and changing difficulties thus
changes the IDs, but the IDs are used to identify the monsters in
save files).
These were unbalancing the game a) in the Castle and b) if they
woke up unique monsters (most notably the Wizard of Yendor).
I considered adding a difficulty check, but this commit instead
just directly fixes the symptoms. (It doesn't make sense for the
Castle to contain a monster that would kill or be killed by its
inhabitants: they should have died long before the hero arrived.
So for liches/zombies to exist in the Castle at all, there must be
a truce.)
+15 wasn't very impactful in the late game and late mid-game, but
was much too lethal in the early game (wearing the ring for a while
near the start of the game would make the game unwinnable as very
out-of-depth monsters spawned, and they would still be there even
after removing the ring and usually capable of one-shotting an
early-game character). This commit changes it to a doubling of
level difficulty rather than a flat increase: that makes it more
relevant in the late-game where a +25 or +50 might potentially have
an impact, and more survivable in the early game (although it still
spawns monsters that are difficult for the point in the game, there
is now a chance that you might survive long enough to be able to
take the ring off and clear off all the out-of-depth monsters that
spawned).
Previously, the code for monster healing was repeated every time it
was needed; this commit sends it all through a common function, which
will make it easier to make changes to how monster healing works in
the future.
This is just a code reorganisation and won't have any gameplay
effect unless I made a mistake.
Luck from sacrificing is now limited by the value of the sacrifice.
This fixes two exploits, both of which rely on getting luck up to
maximum as soon as you have an altar, a luckstone, and a few
rations, via altar-camping until you accumulate enough luck. One of
them is to use the resulting luck to throw off the balance of combat
via using it to make hit chance calculations irrelevant. The other
is to use it to get crowned early in the game; in particular,
getting crowned pre-Sokoban is often viable and, especially for
chaotic characters, solves most of the game's difficulty at that
point (because the intrinisics and weapon are enough to carry a
character to the Castle given even mediocre luck with finding armor).
After this commit, becoming crowned very early in the game is more
difficult (likely requiring unicorns and identified gems), and the
hit chance gain from luck becomes a more gradual gain over the
course of the game rather than all happening immediately upon
finding the altar and luckstone.
In addition to making the game more balanced, this also discourages
grinding by reducing the incentive for altar-camping, so it will
hopefully make it more fun as well.
In 3.6, artifact gifts are often either a) entirely useless or
b) gamebreaking, neither of which is really ideal from a balance
perspective.
This commit aims to make artifact gifts more useful in the early
game by greatly increasing the chance for situational artifacts to
generate positively enchanted. However, the most powerful
artifacts will now only be gifted if you offer a high-value corpse,
meaning that they are only likely to be accessible later in the
game. The selection of which artifact to gift has become more
complicated in order to a) increase the chance that it fits the
character and b) reduce cheese strategies (e.g. it is no longer
possible for elves to force the gifting of Stormbringer as the
first sacrifice gift).
gnome-terminal was recently fixed to work correctly with
TTY_TILES_ESCCODES (and other similar private-use terminal code
sequences), and thus this isn't an incompatible combination any
more.
The new "riding blocks stealth" code was reading u.usteed at an
early point in the restore process, before its value was reliable
(dorecover()->restgamestate()->set_uasmon()->steed_vs_stealth());
because restgamestate() happens prior to restlevelstate(), the
value of u.usteed will be a stale pointer from some previous game,
and attempting to determine whether the steed is flying will crash
the game.
steed_vs_stealth() doesn't actually need to be called during the
restore process (because BStealth is saved in the save file), so
this can be easily fixed by omitting the call to it during the
restore.
The new formula is: (xlevel + Con)% chance of regenerating 1 hp
each turn.
This formula has been extensively playtested throughout the whole
game (including two ascensions). The intention is to make late-
game combat more interesting: early game the HP regeneration rate
is potentially slightly faster but not significantly changed, but
in the midgame and lategame is substantially slower because there
is no longer a big regeneration boost once the character's xlevel
is in the double digits.
With the new formula, I'm finding that my characters have to heal
with potions (rather than by waiting) in places that they never
had to before (e.g. lower Dungeons, and upper Gehennom), which in
turn means that fighting efficiently is now more important than it
was before. (In fact, in one of the games I wished for potions of
full healing on Astral for safety, although I think I would still
have won without.) It's also generally the case that you can no
longer regenerate "mid-fight": you need to disengage in order to
heal up. This made the game more fun as it meant that escape items
became more relevant, and I was using a greater range of items
throughout the game than I normally would.
The ring of regeneration has also been slightly buffed: it now
heals an extra 1hp per turn unconditionally (rather than becoming
less effective as the character levels). In both my test
ascensions, I found a ring of regeneration, but intentionally
refrained from using it in order to ensure that the new HP
regeneration rate would be tolerable even without one.
The recent commit to interpret walking into a shopkeeper as a "pay"
command was triggering in too many circumstances. Check to ensure
that the monster that we're walking into is a known shopkeeper
before activating the special case.
Prior to this commit, there was no good way to deal with swarms of
weak, good-AC enemies using magic; trying to play a wizard as a
pure spellcaster would make bees and ants very difficult to deal
with (because they would usually dodge force bolts).
This commit adds a new spell designed to be very good against
swarms of weak enemies: "chain lightning", which does 2d6 lightning
damage to every monster around you. It has an initially short range,
but can chain from monster to monster to cover potentially large
distances (as long as none of the monsters en route are shock
resistant or tame/peaceful; the spell can't chain past shock
resistant monsters and avoids peacefuls). Monsters within one
space of the visible lightning bolts are affected. Unlike other
lightning effects, this one does only 2d6 damage, not enough to
blind affected monsters.
This commit breaks existing save and bones files (thus the
EDITLEVEL increase).
The change to Sokoban difficulty calculation introduced a balance
issue: previously the Sokoban prize was obtainable before item-
destruction attacks became common and would protect from them,
whereas now they commonly appear in Sokoban itself, before the
prize is accessible. This makes scrolls and potions much less
usable as escape items, and potions of healing less usable for
HP recovery, because they either get stashed or destroyed (and
in either case aren't usable by the character in time-critical
situations).
This commit attempts to alleviate the problem by adding a way to
protect items from cold and fire in the early game. It's a
little unreliable, and requires equipping an item that has bad
stats and generally isn't otherwise used, but which is generally
easy to find early on.
Not included in this commit, but probably necessary for a
"finished" version of the feature: some way of letting players
know the new mechanic. It shows up in enlightenment, but there
should probably be at least rumors (and maybe even a major Oracle
consultation) hinting at the mechanic. We might also want to
change the unIDed description of the dwarvish cloak as a hint,
although that would require, e.g., new database entries.
The same checks were being repeated for every damage type; this
sends them through two centralised functions (one for checking
whether an extrinsic blocks a specific instance of item destruction
and one for the enlightenment message), so that new mechanisms of
item destruction prevention will need to change only one point in
the code.
Wizards now start out recognising all level 1 spellbooks, making
it possible to write a low-level spellbook in order to start
training a spell skill of choice.
As such, it shouldn't be affected by the heat of the ground in
Gehennom (which is hot enough to boil but not to burn). The oil
still heats but won't break its bottle.
In Gehennom and on the Plane of Fire, the ground is hot enough to
boil potions (although not hot enough to, e.g., burn scrolls).
The potions sometimes survive this (almost always if it's your
potion, it's blessed, and you have maxed Luck), but often don't.
In addition to making a lot of flavour sense, this serves a
gameplay purpose in that it reduces the number of potions that
are deathdropped by monsters in the late game. In Gehennom,
monsters often generate with potions to use defensively, but then
get killed before they have a chance to use them: this produces a
surfeit of potions that players tend to convert into holy water or
potions of full healing (and in general it doesn't make much sense
that the basic potion of healing primarily generates in Gehennom).
This commit approximately halves the number of useful potion
deathdrops, whilst still allowing monsters access to their
potions; when the monster dies, it drops the potion and this has a
chance of destroying it.
The previous commit makes things somewhat harder for vegetarian
characters. Normally, making a conduct harder isn't a huge issue,
but vegetarian Monk is an intended/encouraged combination. As such,
compensate by adding some additional food rations to Monk games
specifically; the Quest home level is early enough to provide the
extra food, and as the level is Monk-specific, it will provide the
food only to Monks specifically. (Although the Quest generally
requires level 14 to enter, the Quest home level specifically
doesn't.)
Playtesting has shown that there is too much permafood in the game
at present: in the late-game the only food-related problem is how
much to carry in order to avoid burdening yourself. In the early
game, food could previously have been a problem prior to
Minetown/Sokoban (thus the recent commit to add a guaranteed ration
in the upper dungeons), but past that point, there is easily enough
food generated on the ground. Additionally, the recent commits to
make healing sources more available in the early game reduce the
amount of time that needs to be spent waiting to heal, thus
further reducing food requirements.
The main purposes of food as a mechanic are to given an incentive
to press onwards and to discourage grinding. However, if monsters
are deathdropping non-corpse permafood, then beyond the very
early game, grinding actually generates more food than it uses up,
so the nutrition mechanic doesn't do its job properly.
Playtesting (including a full ascension!) has shown that there is
still plenty of food available even without deathdrops available
(my test game had 8 spare non-deathdrop food rations upon reaching
the Castle, at which point nutrition is no longer an issue due to
the Castle food stores and the huge numbers of C- and K-rations
dropped by the soldiers). I will address the potential problems
this causes for vegetarian Monks in a future commit.
With potions of healing becoming much more common, the multi-step
alchemy recipe from potion of healing to potion of extra healing to
potion of full healing is likely to become even more overpowered
(and it was somewhat unbalancing even beforehand).
This change restricts alchemy involving diluted dipped potions to
alchemize only two potions at a time. This means that potions of
healing can stil be alchemized into potions of extra healing as
efficiently as before this commit, and so can potions of extra
healing into potions of full healing; but the multi-step recipe
is now limited by requiring a lot of potions of gain level or gain
energy. As such, this is intended to make potions of healing into
an item primarily useful in the early game, and discourage hoarding
them for the late game.
At present, potions of healing generate primarily in Gehennom,
which causes significant balance issues (e.g. you don't have them
to heal in the early game, or even if you do, you can't identify
them in time to use them). In this series of commits, I'm aiming to
make potions of healing a more viable early-game healing source,
which means making them both (much) more likely to generate, and
easier to identify so that they are actually usable in the early
game.
This commit radically increases the generation chance of potions
of healing (reducing the chance of most other potions slightly to
compensate), and gives them a unique base price. This should make
them fairly easy to identify either by price-ID or quantity-ID
(and the unique base price is chosen to be fairly easy to figure
out even for unspoiled players).
These are primarily in chests (apart from one guaranteed good food
item on the Mines branch level), and are quite likely to be potions
of healing, although other items that are useful for early-game
survivability are also possibilities.
This is part of a series of commits that aim to make the early game
less about waiting to heal up and more about pressing forwards. In
particular, this means that characters need likely access to
healing sources other than waiting/backtracking/hiding in closets.
In a future commit, I plan to make permafood generate primarily
through exploration (rather than drops from monsters) in order to
deter waiting around or grinding; the early guaranteed food drop is
present to give the more nutrition-intensive characters (e.g. orc
wizard or vegetarian Monk) a fair chance to reach the more abundant
food sources in Minetown or Sokoban.
In particular, Wizards now get a magic marker guaranteed (but with
fewer charges than magic markers naturally generate with). This is
intended to improve the game in two ways: it reduces the incentive
for startscumming, and it gives Wizards a method to gain an
additional low-level spell early if they wish (but the marker does
not have enough charges to get higher-level spells quickly using
this method).
Previously, Wizards got a boost to the chance of writing unknown
spellbooks based purely on being a Wizard (with the chance still
luck-based), leading to a very large power spike when the Wizard
gained access to a luckstone and the ability to max out luck.
This had two main issues: this power spike came *after* the major
early-game difficulty spike, often leaving Wizards forced to deal
with it without having appropriate spells; and it promotes
grinding (for Luck and for Magicbane) at an early point in the
game, meaning that the Wizard early game effectively followed a
sequence of extreme difficulty -> grinding -> minimal difficulty,
which isn't very good balance-wise.
With this commit, Wizards lose their advantage to writing unknown
spellbooks by guessing, and instead learn spellbook IDs based on
their spell skills (advancing a skill gives knowledge of higher-
level spellbooks). This means that writing unknown spellbooks
becomes guaranteed with sufficient skill, but has no advantage
over non-Wizards in schools where the Wixard does not have
sufficient skill.
Due to Wizards' skill caps, there are two spells which they can't
ever write guaranteed: create familiar and charm monster. Create
familiar is a fairly niche spell (that doesn't match the Wizard
playstyle that well) and being unable to write it is not a major
problem. The inability to easily write charm monster is
intentional.
NetHack has historically had problems (both in terms of interface
and in terms of gameplay exploits) caused by unidentified items
not stacking with identified items. The 3.7 change to cause items
picked up by monsters to become unidentified has exacerbated this,
e.g. there's an undesirable strategy in which players give
ammunition to hostile monsters in order to unidentify it, allowing
it to stack with other unidentified ammunition so that the whole
stack can be enchanted with a single scroll.
This commit makes it possible to stack items with different
identification statuses (unles Blind), in effect causing the
unidentified items to be identified by comparing them to the
identified items (this is consistent with the mechanic via which
two stacks of unidentified items can be determined to be the same
as each other). The hope is that this will prevent any gain from
exploits involving intentionally unidentifying (or intentionally
failing to identify) items, that it will prevent interface clutter
caused by (e.g.) a Ranger's main projectiles becoming partially
unidentified as a nymph picks them up and subsequently failing to
stack, and that it will reduce the incentive to backtrack to an
altar to merge, e.g., a stack of formally-known-uncursed and a
stack of informally-known-uncursed food rations to stack.
If the game ended while the player was in the middle of a repeated
command (that was not cancelled), this would spuriously cause a
"while helpless" to appear in the death message and logfile entry.
This bug is hard to observe because most things that can kill the
character also cause repeated commands to stop repeating, but is
easy to reproduce by command-repeating the #offer command that's
used to ascend (as "n20#offer" or "20#offer" depending on the
control scheme): doing so produced "ascended, while helpless"
prior to this patch.
This is a well-defined operation, so bwrite() should be able to
handle it. However, when running under glibc, fwrite() produces an
unexpected return value for 0-byte writes, which makes bwrite()
think that the write failed (causing a panic).
This change implements 0-byte writes by not calling into libc at
all, so that we don't have to worry about how to decode the return
value of fwrite().
This fixes the messages displayed when, e.g., the hero becomes
unburdened as a consequence of a corpse rotting away. (There are no
gameplay changes; the effective burden level is fixed between turns
under both the old and new mechanisms, and any other use of it will
recalculate it prior to using it.)
Not changed: the interaction of overexert_hp with burden changes due
to timeout. You were holding the corpse during your turn, so even if
it rots away at the end of the turn, you can still pass out from the
exertion you applied during that turn.
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