Fixes#125
When a random grave included some gold among whatever treasure was
generated, that gold was left on top of the grave instead of being
buried inside it like other treasure.
I'm sure this was intentional but only because mkgold() puts the
gold on the ground and merges it with other gold if there is already
some present. Keeping an existing stack of gold distinct from the
new one in order to bury the latter is feasible but clumsy. Just
make a new gold object directly, bypassing mkgold(), and bury that.
Fixes#123
Make sure wallification doesn't go out of bounds when operating
near the map edge. The top and left edges were ok (although the
left edge could uselessly try to wallify unused column 0) but the
right and bottom ones weren't validating the map boundary. None
of the 3.6.x levels were affected.
I've done this a little differently from the suggested commit in
the pull request.
Special levels with FLAGS:inaccessibles could trigger a panic if
a large enough area was subjected to floodfill handling. The buffer
intended to be enough to hold an entire level wasn't big enough when
individual coordinates were being added multiple times. I don't
really understand what this code is doing but the recommended fix
does work to prevent the panic.
None of the levels included with 3.6.x were affected.
Remove an extra space from Val 00021.
This does not address github issue #124 where the extra space shown
on the message line is the result of combining two separate plines
rather than coming from the data.
Noted on rgrn, after being told that you don't fit upon discovery
of a hole or trap door you could then immediately use '>' to
proceed down.
The deliberate situation remains possible and has some
inherent risk.
Interrupt seduction if the hero gets moved away from the seducer, or
if both of them move to another level. Loss of levitation can drop
the hero onto a trap which sends him/her somewhere else, but seduction
was continuing as if nothing had happened. In theory it could continue
despite level change because succubus and incubus are level followers,
but there's no way of knowing whether seducer and victim will arrive
next to each other until they get delivered and that doesn't happen
until long after the attack needs to finish.
I don't think theft has the same problem because it is a multi-turn
activity operating on one item at a time, but I didn't check it out.
Unlike cloak_simple_name() and helm_simple_name(), suit_simple_name()
wasn't guarding against Null. Current usage never trips up against
that, but when I added a new use in doseduce() [pending], it caused
a crash.
Various seduction messages with a verbal component were being given
to hero even when deaf. This uses alternate messages if some cases
and bypasses the message in others. In particular, if hero is deaf
then he or she will not be given the choice to decline removing a
piece of armor--or taking off or putting on a ring of adornment--
that can ordinarily occur (based on die roll against Charisma).
The seduction code was also using '!Blind' to test whether the hero
could see his/her seducer, ignoring the possibility that it might be
invisible. I think the only ramification is that "It" would appear
in messages instead of the "She" or "He" that are explicitly used
when not seen due to blindness.
Fixes#120
The one-line summary [for inclusion in message history] of the priest
quest's block message when bringing the quest artifact back to leader
misspelled "congratulations".
Fixes#102
This is a simplified version of the code in pull request #102,
which replaces "You feel like Popeye!" with "You feel like {Olive
Oyl or Bluto}!" if eating spinach fails to provide a strength gain.
I think you should still feel like Popeye if the lack of gain is
due to already being at maximum, so I left out the change to make
gainstr() return a value which indicates whether a change took place.
Unfortunately, if you're both already at maximum and have attribute
changes suppressed by Fixed_abil, the latter overrides and you'll
feel like Olive Oyl or Bluto. I think that situation is too obscure
to bother with the complexity of figuring out if you're at maximum
for the purpose of a silly message.
Fixes#116
Farlook in 3.4.3 used xname() and just described any corpse as
"corpse" whether you knew the monster type or not. 3.6.x switched
to doname() and describes it as "<mon-type> corpse", but if it isn't
there anymore, the fake object contructed for it would have a random
corpse type.
For corpses and statues, the map glyph provides enough information
to give the fake object the same type as the original. For other
items that have a monster component (figurines, tins, eggs) it does
not, nor for other doname attributes of objects in general (which
might be picked up by monsters rather than rot away). So this fixes
the rotted-away-corpse-seems-to- become-random-corpse issue but not
the general case of the details for a remembered item which isn't
there anymore.
Redo how updates of permanent inventory window are suppressed during
restore. Reverses part of e9f1e03271
which included a simpler attempt to deal with this.
It looks like we should have been getting impossible "unpaid_cost:
object wasn't on any bill" but segfault was reported; I haven't tried
to figure out why. The band in xname() ought to be redundant now but
is included for bulletproofing.
Fixes#113
Incorporate the contents of pull request #113 to fix shopkeeper setup
for irregularly shaped shop rooms. Code intending to adjust the Y
coordinate was erroneously incrementing the X one instead. (I'm not
sure whether we have any irregular shops at all but if so, they don't
have the necessary orientation to trigger this bug.)
And add a couple of formatting tweaks in the vicinity....
Wearing a negatively enchanted ring of increase <foo> would enhance
the bonus gained from eating another ring of the same type when you
got "the magic spreads through your body" effect so could be eploited.
Conversely, wearing a positively enchanted one would make you lose
that worn amount when gaining any bonus from eating one.
Fixes#114
Report and contributed fix described lack of support for room type
"ant hole" in the code that loads special levels (and mentioned that
none of our des files attempted to use that room type so it isn't
noticeable in unmodified version of the game). The fix overlooked
a couple of other missing room types (leprechaun hall and cockatrice
nest) so I didn't use the pull-request's commit (so not sure what
github's automated updating will make of 'Fixes #114').
Fixes#111
Casting stone-to-flesh at a random statue animates it as a monster
(created via direct call to makemon()) at an adjacent or nearby spot
if there is already a monster at the statue's spot, but doing so on
a statue of a petrified monster (create attempt via montraits() which
called makemon() without the ADJACENTOK flag) turned it into a corpse
instead. Pass an extra argument to montraits() so that it behaves
the same normal statue animation for stone-to-flesh without changing
how it behaves when reviving corpses for undead-turning.
Handle suppression of 'score' from the 'O' menu for viewing and
setting hilite_status rules differently so that the count of the
number of rules will always match the number of rules shown by the
'a - View all hilites in config format' choice. If there are score
rules in the config file for a game running under !SCORE_ON_BOTL
configuration, list 'score' normally but if player picks that menu
entry, the followup menu will have the existing rule(s) and 'X -
remove selected hilites' but not 'Z - Add a new hilite'. If there
aren't any score rules--or there were some but they've now all been
'X'd--then 'score' won't be listed as one of the status fields.
When built without support for SCORE_ON_BOTL (the default), suppress
'score' field from 'O' menus for adding/removing hilite_status rules.
Also, add "encumbrance" as field name synonym for "carrying-capacity"
and "experience-points" for "experience". Relevant for rules set in
config file or via NETHACKOPTIONS.
The formatted value for attributes of condition highlights was
reporting 'normal' (aka no attributes) even when the highlight
rule specified some other value. It initialized a bitmap variable
to ATR_NONE, which is not 0, and then or'd other bits to that.
Then during formatting it checked whether the ATR_NONE bit was set
and returned 'normal' without examining the other bits. Actual
highlighting wasn't affected, just the strings in the rule set
shown by the 'O' command.
This is a separate issue from the earlier 'bonus fix' where the
attributes of previous condition rules got clobbered if a
hilite_status:condition/any-color&normal rule was added.
Take a step towards eliminating merging hilite_status rules during
highlighting by creating a single rule instead of multiple ones
when specifying multiple attributes for the same highlight via the
'O' command's menus.
Old:
(pick_one menu to pick a color) + (pick_one menu to pick an attribute)
| hilite_status:title/always/red&bold
(pick_one menu to pick a color) + (pick_one menu to pick an attribute)
| hilite_status:title/always/red&blink
New:
(pick_one menu to pick a color) + (pick_any menu to pick attributes)
| hilite_status:title/always/red&bold+blink
At present, rule selection during highlighting still merges multiple
applicable rules instead of finding the best one first, with the
problems that entails.
Bonus fix: a hilite_status rule for status conditions which specified
"no attributes" would clear attributes for all previous condition
rules rather than just the one(s) in that "no attributes" rule.
Fixes#110
NetHack dumped core while qsort was executing for sortloot. Fix a
logic error introduced by adding filtering capability to sortloot()
which could result in a sparsely populated array instead of having
the number of elements be less than the list size.
I don't know why this didn't show up sooner.
Fixes#109
Spells of healing and extra healing cast at monsters were handling
monster blindness differently from other forms of healing. (Potions
also work differently when drunk by monsters but I haven't changed
that since it seems to be intentional.)
Hero:
potion of healing cures blindness if blessed; spell of healing
cast at skilled or better now behaves likewise;
potion of extra healing cures blindness if not cursed; spell of
extra healing is inherently not cursed and already behaved
likewise;
potion of full healing always cures blindness even if cursed.
Monsters quaffing potions:
plain healing cures blindness if not cursed;
extra healing and full healing always cure blindess.
Hero casting healing spell at monster:
plain healing behaves like the hero plain healing case: cures
blindness as if blessed when cast at skilled or expert level;
this is a change in hehavior--it used to cure timed blindness
even if unskilled and not cure 'permanent' blindness at all;
extra healing cast by hero is inherently not cursed so always
cures blindness.
Wishing for "<size> glob of black pudding" worked, and wishing for
"black pudding glob" worked, but wishing for "<size> black pudding
glob" didn't work. Fix that.
Also, remove a bit of spaghetti introduced by the previous patch.
And once we know we're wishing for a glob, we can skip a big chunk
of wish parsing and special case handling.
Fixes#108
"small"/"medium"/"large" prefix was being stripped off during wish
parsing so that it could be used to control glob size. But those
are also prefixes for monster and/or object names. Wishing for
"small mimic corpse" or "large mimic" corpse failed with "nothing
matching that description exists" when it tried to satisfy "mimic
corpse". (Asking for "giant mimic corpse" worked as intended.)
Not mentioned in the report: wishing for "large {dog, cat, kobold}
corpse" produced the corpse of corresponding normal sized critter
instead of that of a large one.
Noticed while testing the fix: wishing for "glob" failed rather
than pick a random glob type. Wishing for "glob of grey ooze"
failed even though "grey ooze" is recognized as a variant spelling
for the gray ooze monster. Wishing for "<monster type> glob" also
failed even when the monster type was viable for globs. This fixes
all of those even though no one will ever notice....
Wishing for "small box" (and "medium box") no longer yields a large
box, it fails with "nothing matching..." instead. I was ambivalent
about the earlier change which had the unintended side-effect of
making them synonyms for "large box" so haven't tried to revive it.
The earlier change for 'fix github issue #106' could result in a
polymorphed weapon being worn in multiple weapon/alt-weapon/quiver
slots. Reorganize the relevant code more thoroughly this time.
