From a bug report:
> If the Summon Nasties monster spell gates in two minions instead of one,
> the message still says "A monster appears from nowhere!"
The code wasn't counting any summoned monsters who had an opposite alignment
to the summoner. It also assumed that the 10% chance for demon summoning
in Gehennom always yielded exactly one monster even though that can produce
zero or more than one.
Add the extra feedback suggested by <Someone> so that being blinded
by moving into a stinking cloud is explicitly pointed out to the user. It
makes things more verbose but seems reasonable. You get blinded for 1 turn
with every step, so the message gets repeated each time too, but since you
also get a choking or coughing message on each step it's only a modest
increase in the overall verbosity.
From a bug report: when a black light explodes and triggers
hallucination, its own monster symbol--or warning marker for same--could
be seen changing. Since nothing is left after it explodes, you shouldn't
hallucinate anything at its location. Fix by killing it off (so removing
it from the map) before initiating Hallucination.
<Someone> reported that riding a steed into a magic portal can
give "steed is still eating" message, feedback normally used to explain why
you can't go down stairs. Rather than preventing portals from activating
in that situation, just force the meal to be finished in order to suppress
the message. Proper fix is probably to prevent all steed movement while
eating, but that would most likely result in no one ever riding again.
Fix the wizard mode crash From a bug report. Move the WIZKIT
message suppression to a lower level instead of trying to guard against
present and future pline() calls in the wishing code. The way that was
being handling wasn't suitable for dealing with quest feedback.
This also includes a couple of additional wishing synonyms.
Someone in the newsgroup expressed surprise that he didn't get any
special message after surviving the eating of a cockatrice corpse. Combine
the cliche that unconventional meat inevitably tastes like chicken with
the mythology that cockatrices are a bizarre hybrid of chicken and reptile
(or whatever). This will give a message about tasting like chicken for
corpses or smelling like chicken for tins when the hero has petrification
resistance (poly'd into a xorn, for instance) or is hallucinating.
A user reported that when breaking potions inside a box in a shop, he
wasn't charged for them. The code was calling stolen_value() as intended,
but that routine only charged for types of items which the shop normally
carries. That meant that breaking the contents of a box in a general
store would charge for them but doing so in a tool shop would, not even
though the tool shopkeeper would gladly sell such things when you picked
them up instead of causing them to go away.
When fixing this, I noticed that stolen_value() was only charging
for single items. Most of the time that was right, because throwing and
kicking things always split one off, but there are cases (such as zapping
a wand of teleportation at shop goods) where an entire stack gets stolen
as a group. This makes stolen_value() handle all quantities.
Eggs thrown straight up which don't splatter on the ceiling yield
"you've got it all over your face", so wearing a helmet shouldn't protect
against petrification from cockatrice eggs in that situation. This was
part of my delayed helm vs hat stuff; I can't remember whether it was done
before or after this same issue came up in the newsgroup.
Something from <Someone>'s list: some messages have hardcoded references
to "helmet" which sound strange when the character is wearing a hat or cap.
helm_simple_name() is comparable to the existing cloak_simple_name(). It
returns "helm" or "hat" depending upon whether the helmet provides the
same protection that yields the assorted repetitions of "fortunately,
you are wearing a hard helmet". This choice ends up categorizing elven
leather helm as a hat (which I think is ok given that its undiscovered
description is "leather hat"), contrary to <Someone>'s suggestion that the
distinction be made based on whether the helmet was made of cloth.
I started on this a year and a half ago but didn't commit it.
Unfortunately I don't remember why and haven't done any significant
additional work now--just recovered from some intervening bit rot and
confirmed that the patch as is seems to be working ok (in the trunk; the
branch side has not been tested). I suspect that I meant to look for
additional helmet messages which could benefit from conditional headgear
description. (Those "hard helmet" ones don't need it, although they
should perhaps be moved into a common routine instead of being replicated.)
Allow the #adjust command to be used to split an inventory stack
as well as for moving things to specific slot letters. Splitting is
accomplished by specifying a count along with the letter of the stack to
operate on, similar to when dropping a stack with 'd'. The comment above
doorganize() has more details.
This change will make it possible for users to split stacks of cursed
loadstones which they couldn't easily do before, but I don't see anything
wrong with that. It was always possible to have multiple stacks of load-
stones by starting with ones that had different curse/bless status, so this
hasn't introduced a totally new situation. On the other hand, I haven't
tested this with the GOLDOBJ configuration and am not sure whether there is
any need to prevent gold from being split there. The getobj() call doesn't
specify COIN_CLASS so perhaps it's irrelevant (unless it ought to be
changed the other direction by adding that to intentionally allow gold to
be split?).
I've cleaned up the #adjust routine somewhat while revising it to
support splitting stacks as well as moving them, then have separated the
cleanup from the more substantial changes. The most significant change
here is that #adjust will give up early if used when inventory is empty;
the user used to be forced to choose a letter from an empty list in that
case, then it gave up when no object was selected. There's also a minor
change for users who turn `fixinv' off; the prompt's list of likely
candidate letters for destination slot is reduced to one letter beyond
current usage instead of showing the rest of the alphabet. (Picking any
letter--which users can still do--beyond current usage results in moving
the adjusted item to the end of the list, although it ultimately ends up
with a different letter than the user chose because adjusting from some
other slot frees up that slot; all items past it--including the new last
element--effectively move up one letter [or more if merges occur].)
Despite lack of feedback from the beta testers about it, add the code
which tries to stack an object being added to inventory with the quiver
before trying with other carried objects. Only matters to user if quiver
is non-empty and one or more other slot(s) are compatible with it, but
that's not uncommon for someone who starts a rogue by splitting the initial
daggers into separate wield and throw slots. Firing a dagger from quiver
and then having it merge with wielded weapon instead of back into quiver
when picked back up leads to tedious inventory manipulation. Assigning
different names to the two stacks solves this, but can't help when picking
up an unnamed item which is otherwise compatible. (A rogue with starting
daggers wouldn't encounter that since unnamed ones won't be sufficiently
identified to stack, but any character who just gathers unID'd daggers and
uses them for both melee and throwing has a chance of running into the
"picked up into less desireable slot" trap whenever new ones are found.)
<Someone> reported that she got "your weapon slips from your hands" when
inflicted with slippery fingers while wielding multiple daggers. That
should be "weapons" plural and they're only being dropped from one "hand"
singular. Fix that and also give more specific feedback than "weapon"
for non-swords based on their weapon skill category names. This works
pretty well for most common weapons but might need some more tweaking for
ones where different types have gotten lumped together in the skills.
old feedback:
Your weapon slips from your hands.
Your tool slips from your hands.
Your food slips from your hands.
twoweapon:
Your sword slips from your hands.
Your other sword also slips from your hands.
new feedback:
Your daggers slip from your hand.
Your <one-hander> slips from your hand.
Your <two-hander> slips from your hands.
Your pick-axe slips from your hand.
The corpse slips from your hand.
twoweapon:
Your sword slips from your left hand.
Your other sword also slips from your right hand.
Since "weapons and spell skills" is grammatically suspect and
"weapons and spells skills" sounds odd, change to "weapon and spell skills"
in both the Guidebook and the game's online descriptions. The #enhance
command itself uses "current skills" and doesn't need any alteration.
From the newsgroup: if you were polymorped into a cockatrice and
a trapper attempted to swallow you, the 't' displayed at its location
would be left behind after it turned to stoned. This fixes that and a
much more serious issue as well: if you were punished at the time, the
game would panic on your next attempt to move because the ball&chain were
left in limbo. There would also have been strangeness (monster sharing
your location, stale u.ustuck setting) if the swallower was life-saved,
but I didn't try to make that happen so am not sure how bad things would
have been.
Per <Someone>'s request, make the game's description of the ``#enhance''
command be the same as in the Guidebook by mentioning spell skills.
Combining weapons plural with spell singular isn't right, but I'm not
sure which way to change that so am leaving it alone. On the other hand,
the poor grammar used to describe the ``#conduct'' command is easy to fix.
From a bug report, but pulls back" while successfully
praying. Gas spores' only "attack" is to explode when dying, so the code
that checks whether the monster has any attack needs to handle AT_BOOM as
a special case. Unfortunately this change means that you won't interrupt
an occupation when a gas spore approaches, and a subsequent kill by your
pet might end up causing you harm while still occupied. The callers of
`noattacks()' are messy enough that I didn't want to try to address that.
This also moves noattacks() from mhitm.c to somewhere more sensible.
Reported last December by <email deleted>. Using
a wand or spell of undead turning inside a shop used up corpses without
checking whether they were owned by the shop. Although the report didn't
mention it, using stone-to-flesh on statues had the same problem.
I'm not completely satisfied by some aspects of this code, but if I
don't commit what I've got now I probably never would. My original notes
are lost; I thought that there were some additional fixes present, but
looking at these diffs I don't see anything else significant enough to
warrant mention in the fixes file.
Fix the two minor grammar problems for messages given when eating
that were From a bug report: inappropriate or inconsistent
capitalization in mid sentence for
Ulch - That <object> was rustproofed!
and missing punctuation for the appended clause for cannibalism in
Ulch - that meat was tainted cannibal!
Objects which were destroyed by dipping them into lit potions of oil
didn't get unworn or unwielded in cases where that was needed. This left a
stale pointer which could result in various strange things (user saw it be
formatted as "glorkum" but that isn't guaranteed) and there was no update of
any attributes or intrinsics conferred by the item, so persistent levitation
or water walking or dexterity boost could occur.
Nothing to do with <Someone>'s recent list of missing entries, just
an amusing quote I like. The book itself isn't remotely nethackish; it's
about a teenage boy and a teddy bear who are operating as hardboiled-style
detectives in a land of sentient toys where nursery rhyme characters start
getting murdered.
Eliminate two minor anomalies in the behavior of the rnl() function
which returns a random number that is modified by the hero's Luck attribute.
Integer division by 3 on requests for small ranges and the fact that the
chance of making a modification was lower for good luck than for bad luck
meant that highest luck did not produce best chance to avoid worst result.
The actual effect on game play is sure to have been negligible. More
troubling is that the program has several rnl(3) and rnl(4) calls. These
practically guarantee a result of 0 when the hero has maximum luck. The
rnl() function really shouldn't be used for such tiny ranges (unless the
actual intent is that high level characters are expected to almost always
have the 0 outcome...).
A user pointed out that you lose pacifism conduct if you kill your
pet by displacing it into a trap but you don't gain any experience in
the process. Make this consistent with killing monsters in other ways:
if you get blamed for it then you should also get credit for it.
Probably minliquid() and mintrap() should take another argument so
they can call killed() instead of mondead() when necessary, but I didn't
go to that much effort....
From a bug report: fracture_rock() was unintentionally propagating
the boulder or statue's dknown flag to the resulting rocks, producing a
trivial but noticeable difference in description of "rock" vs "stone" if
the source object had been seen up close prior to being broken and the
rocks are then examined remotely or while blind.
The curse/bless state is propagating too, but this seems reasonable
so I've left it alone.
User reported the following incorrect feedback:
You drop Medusa's corpse. corpse falls down the stairs.
and apparently thought that the problem was a glitch in the middle of the
sentence; the actual problem is that the second sentence lacks its start.
This fix isn't perfect. You'll now get
Medusa's corpse falls down the stairs.
for the second sentence, but
The Oracle corpse falls down the stairs.
when dealing with a unique monster who doesn't have a personal name.
Either form seems acceptable to me, but mixing them appears inconsistent.
Probably all the uses of corpse_xname() (and its callers back up the
chain cxname(), aobjnam(), yobjnam()) need to be reviewed for usage. I
don't have the energy for that.
Fix the reported problem of being able to safely stand on lava after
taking off fireproofed water walking boots. The situation was more wide-
spread than that; the same thing happened when non-fireproofed boots were
burned off while walking over the lava in the first place. Now you'll
fall in and end up getting stuck (you have to have fire resistance for any
of this to happen and that resistance makes falling in be survivable).
Fix the situation <Someone> reported where the "You disturbed me, fool!"
result when releasing a djinni from a cloudy potion sometimes produced a
peaceful djinni for neutrals due to the usual randomness in how monsters
react to characters of the same alignment. Explicitly force it to be
hostile for that outcome.
Also, for the "it's about time" result, suppress the "It vanishes"
message when the character doesn't see the djinni depart.
Fix the situation <Someone> reported where a shopkeeper removing a trap
from the shop doorway yielded "you see the shop door reappear" instead of
reporting about the trap. It made sense if the door had been destroyed
but not when intact.
For trunk only, try to fix up the shop repair message situation when
multiple repairs occur at the same time. Some things were being treated
as mutually exclusive when they aren't. This part needs more testing,
probably using a debugger to force multiple pending repairs to all occur
on the same turn. At any rate, using wizard mode and hoping for some
simultaneous activity was ineffective.
Fix the situation <Someone> reported where requesting information about
the not too unlikely word "offering" would match the "ring" quote. I didn't
add a new quote for it but made "offer[ing]" and "sacrific[e|ing]" match the
existing altar quote. I also added one small quote I've had laying around
for a while.
Try to fix the report of a doppelganger (created from using stone-
to-flesh on a fake statue of Demogorgon) having 1700 hit points after
reverting to its native form. The problem was due to the special monster
level of Demogorgon rather than anything to do with shape changers; the
actual bug was use of `mdat->mlevel' where it should have been using
`mtmp->data->mlevel'. But the whole section of code was rather suspect
since it didn't attempt to handle other types of monsters (dragons, golems,
elementals) which have non-standard hit points, so I knocked some out.
Monsters who have gained or lost levels prior to changing form will no
longer carry that adjustment along; the new form will always be a brand
new one of its type. However, if the old form is injured at the time of
change, the new form will be too (same as before).
Fix the bug From a bug report. Subsequently removing
the item caused those attributes to be returned to an incorrect value
which was higher than the character started out with.
Implement the patch sent by <email deleted>
to make responding with '?' at the "what direction?" prompt ask again
after giving the `cmdassist' direction display. I did it slightly
differently than was done in the submitted patch but the result is the
same except that it also suppresses the message about how to disable
cmdassist in this case.
Fix the recently reported problem:
" If there is a corpse in a pit, you have to enter the pit in order to pick
" it up, however you are can eat it without being in the pit.
If pit bottoms aren't reachable, then can_reach_floor() needs to know
about it. I suspect that this change is likely to create some other
bugs though.
Fix the recently reported bug about the wording of trap messsages
when hero's steed has a name but hallucination prevents that name from
being used, yielding "You lead poor wombat into a pit!" and the like.
I accidentally deleted the message so can't reply to the sender.
[Before applying this patch, take a look at the POLY_TRAP case of the
switch statement in steedintrap(). A misplaced brace has drawn the
default case into one of its `if' statements. Evidently it's valid C
syntax, but someone among us must have access to a compiler or lint
checking tool which is capable to diagnosing such things.]
"You push the boulder into the pool" should be "Your steed pushes
the boulder into the pool" if done while riding since that's how other
boulder pushing messages are handled.
Mentioned in passing in the newsgroup: level teleporting in the
endgame--which is only possible in wizard mode--can crash if you're
confused. The change to make confusion sometimes override teleport
control means that sometimes a random destination will be chosen, and
the routine to choose a random level can call rn2() with a value less
than 1 in the endgame, possibly resulting in attempt to divide by 0.
There's something fishy about the min_/max_depth stuff for the
endgame, but I haven't attempted to figure that out. This just makes
the random destination always be the current level when in the endgame
so that the problem can't come up.
It was possible to get a shopkeeper to carry the Amulet from the
bottom of the dungeon up to the location of his shop, thereby bypassing
the usual labor of lugging it up yourself. [Drop the Amulet somewhere;
rob a shop so that the Kops are summoned and the shk comes after you;
when shk is next you, level teleport to the Amulet (probably two hops,
one to the Valley and another deeper into Gehennom); walk to the vicinity
of the Amulet; shk will eventually pick it up (shopkeepers like to pick
up magic items); now, pay him for the stolen goods--he'll be pacified
and migrate back to his shop, taking his inventory with him; lastly,
return to his shop and relieve him of his burder.] This patch makes
shopkeepers drop the Amulet or invocation tools if/when they set set to
migrate to their normal location.
Also fix another long standing risk that a monster that is sent
away (nurse when healing, Kops when you pacify a shopkeeper) might be
carrying the Amulet or one of the invocation tools and make the game
unwinnable. I doubt that that's ever actually happened but I think it'd
be possible if a monster that likes magic items ever got polymorphed
into a Kop. Such dismissed monsters will now drop the same stuff as
the shk above prior to leaving the game.
There was no feedback when gold was thrown or kicked at monsters
who weren't interested in catching it. Now it'll give the same "<obj>
misses <monster>" message as other thrown or kicked items objects which
don't hit.
Report was for scattering gold during a land mine explosion, but the
message was delivered by the widely used hit(). Bug was caused by a typo
in vtense() when handling a subject containing a space.
Fix the reported problem of bad inventory management if the user
specified a count (with traditional menu style) when attempting to drop
part of a stack of cursed loadstones. After the "you can't drop that"
message, it tried to undo the stack split, but splitobj was changed
sometime back and the undo hack wasn't adjusted to account for the fact
that it needed to merge with the previous object instead of the next one.
The result was that it would incorrectly increment the count of the next
item instead of the original loadstone, or crash in canletgo() if the
split off stone was the last item in the list.
This prevents cursed loadstones from being split (via getobj()'s
count handling) in the first place, so there's nothing to undo later.
It still uses a similar kludge so that the "can't drop that" message can
be adjusted, but it's now a simpler kludge and I hope a more robust one.
Try to address the problem From a bug report: turning the Wizard
of Yendor to stone preserves monster information with his statue and
presence of that information overrides the statue animation check
intended to prevent players from creating the Wizard (or other unique
monsters). That's ok for the current game--the monster had to have been
in play in order to be turned to stone--but is a problem if the statue
is found in a bones file. The report was for placing such a statue at
the location of an untriggered statue trap by a player who leaves bones,
but stone-to-flesh by the player who loads bones is a simpler way to
trigger this. (Aside from getting unique monsters earlier than usual
under some degree of player control they won't have their starting
inventory so special items like the Candelabrum might not get created.)
Using undead turning to revive corpses found in bones was another way to
get into the same trouble (I thought corpses of special monsters were
already excluded from bones?).
It looks like it's also possible to get strange quest behavior if
a corpse or statue of the leader or nemesis is brought into the dungeon,
left in bones, then revived by the second player, but I didn't attempt
to reproduce it. More work is probably needed; this tightens up leader
handling a bit but doesn't do anything about the nemesis. This patch
has already been spreading tentacles and I've got to cut it off....
The patch discards saved monster traits for corpses and statues of
unique monsters while saving bones; reviving or reanimating them will
produce doppelgangers instead of the original monsters, same as stone-to-
flesh on wished-for statues behaves. It also discards saved traits for
shopkeepers (also temple priests and vault guards--their traits weren't
saved in 3.4.2 though). That info might be useable when the corpse or
statue is on the same level as the monster started (ie, where its special
room is located), but that's a complication I'm going to bypass. This
patch also adds chameleon handling for statue activation--it wouldn't
have mattered in 3.4.2 since shapechangers didn't get their traits saved;
it does matter now but was omitted when trait-saving was extended to all
statues a while back. (It adds chameleon handling to corpse revival too,
but they still don't get their traits saved with corpses so that's just
protection in case of future modifications.)
Other bits: `cant_create()' is renamed to `cant_revive()' since
the latter is a more signicant use than wizard mode <ctrl/G> handling.
Now save traits with nymph corses so that cancellation can be propagated
if they're revived; that doesn't matter much but matches statue handling
(where it was more important since it dealt with succubi as well as with
nymphs). Explicitly initialize the shape-changer field of all monsters
instead of relying on implicit initialization to 0 (CHAM_ORDINARY).
There'll be a *much* shorter patch for 3.4.3 which will have to get
by with most of these obscure problems--fortunately they're unlikely to
impact many (any?) players.
Declare structure before using it in prototypes, and declare atol()
for configurations which don't have or don't use <stdlib.h>. (Some
#ifdef MICRO code for atoi at the end of system.h might need to be done
for atol too.)
<Someone> reported something along the lines of
"You are hit by a little dart."
[ "The dart was poisoned." -- this expected message was missing ]
"The poison doesn't seem to affect you."
Remove the overloading of ``chance for fatal poison'' and ``thrown weapon''
(which reduces that chance, among other things) for the arguments passed to
poisoned() and change how it decides whether feedback about being poisoned
is needed. Also, move poisoned() and poisontell() from mon.c to attrib.c.
DEC C warned about a problem and that caused make to quit.
| idx = (++idx % 2);
|........^
|%CC-W-UNDEFVARMOD, In this statement, the expression "idx=(++idx%2)"
|modifies the variable "idx" more than once without an intervening
|sequence point. This behavior is undefined.
Just From a bug report: getting interrupted and then
resuming would sometimes produce two instances of the "You finish" message
(and evidently consumed an extra turn in the process). I think this is
an old problem and that it's just coincidence that it showed up right after
the patch dealing with avoidance of stale context for 'A'; the interruption
has to occur when there is just one turn left in removing the final item
so doesn't happen very often.
Prompted by the report that it was possible to check a corpse at an
adjacent spot while levitating: substantially revamp the handling of
applying a stethoscope to corpses and/or statues. Aside from the missing
reachability check, the old code suffered from grammar problems when
multiple corpses were present and it didn't try to figure out the gender
of the monster who left the corpse.
This now lets non-healers check corpses and statues at any time
(previously that only worked for them while hallucinating). For healers
it gives some new feedback: when listening to a corpse, they'll be given
a hint if it (actually any corpse in the pile at that location) is going
to revive, and when listening to a statue they'll be given a hint if it
contains any items. The existing hint when a statue is actually a trap
is still only given to healers.
Groundwork for forthcoming stethoscope fix: add an object list
traveral routine (there must be something like this already, but I
couldn't find it...) and a couple of timer access routines.
[ Caveat: compiles ok on branch code but only play tested on trunk code;
the do_wear.c diff is a lot different between the two variants and the
trunk one includes some whitespace cleanup. ]
<email deleted> reported that having a spellcasting monster
destroy some armor while you're in the midst of using 'A' to take that
armor off would result in a crash. The problem was actually more
widespread than that: having a nymph steal worn items (accessories as
well as armor), or a succubus remove them, or being interrupted by monster
activity and then reading a scroll of destroy armor prior to resuming 'A'
could all produce a similar crash. 'A' relied on stale context and could
attempt to manipulate an equipment slot which had become empty, ultimately
leading to an attempt to dereference a null pointer.
The 'R' command didn't have this problem since any accessory gets
removed immediately. The 'T' command already had handling for this:
there's only one item to deal with and multi-turn take off only applies
to some of the slots; the donning() check followed by cancel_don() took
care of those. Only 'A' was vulnerable to the problem and it wouldn't
necessarily need to be interrupted and resumed; loss of the current
multi-turn item or any pending item would be enough--but I'm not sure
whether such item loss could occur without also interrupting the current
activity, so resumption of previous 'A' was probably a requirement for
triggering the crash.
This makes shield and shirt handling be similar to other types of
armor instead of relying on the fact that none of them need to have any
attribute adjustments when put on or taken off. However, there are
still assumptions (the `cancelled_don' stuff) that some slots don't have
any eligible items requiring more than a single turn to use; that should
probably be changed.
External names longer than 31 characters trigger a compiler warning
for me about truncation, and that causes make to quit. So shorten the
two long names. Also, call the cleanup routine for the FREE_ALL_MEMORY
configuration.
From the newsgroup: when invisible and unable to see invisible,
if successful prayer results in being given a spellbook you'll get the
message "an object appears at your feet" but the spellbook won't show on
the map. Add a newsym() to force its location to be updated. (I didn't
try to figure out why spellbooks use place_object() when all other divine
gifts use dropy() but that's why only this case has the display glitch.)
This also fixes up the message vs map update sequencing for a couple
of other "at your feet" cases so that all of them use the same ordering:
first the message is given, then the object drops.
[Timing is the only reason not to put this simple change into 3.4.3.]
Some newsgroup discussion recently pointed out that source comments
for scrolls of charging didn't match the actual charge increase performed
by that magic. This bumps the values a little bit
(uncursed: comment said 5 to 15, actual amount was 10 to 14, now 10 to 20;
blessed: comment said 10 to 25, actual amount was 16 to 25, now 15 to 30)
and adjusts the comments to match the code.
Barbarians start with either a two-handed sword and an ordinary axe
or a battle-axe and a short sword. The latter combination was the only
one among all the roles where the player couldn't enhance skills for
starting weapons to expert. Fix that by allowing barbarians to become
expert in short swords; reduce potential capability with pick-axe/mattock
from expert down to skilled to compensate for the increase.
This also addresses an earlier complaint that monks are no better in
martial arts than samurai even though the latter have lots of choices for
good weapon skills. Reduce the martial arts limit on samurai from grand
master to just master; likewise with bare-handed combat for barbarians
and cavemen. In this case there didn't seem to be any need to bump the
limit on anything else as compensation.
I still think non-rogues shouldn't be allowed to become expert in
daggers (which means that ranger and valkyrie starting gear would need
to change slightly) due to how powerful throwing them is, but I haven't
included that change here.
For the skills which have lower upper limits than before, existing
characters who have #enhanced their skills high enough with the previous
code will retain their higher-than-max skill ranking with the new code.
Characters who have exercised enough to advance to the old max but
haven't done so yet will be limited to the new max.
Using
gcc -Wall -Wshadow -Wpointer-arith -Wwrite-strings \
-Wmissing-braces -Wmissing-prototypes
with an old version of gcc.
mhitu.c: In function `hitmu':
mhitu.c:1176: warning: declaration of `buf' shadows previous local
options.c: In function `special_handling':
options.c:2712: warning: initialization discards `const' from pointer target type
options.c:2745: warning: initialization discards `const' from pointer target typ
trap.c: In function `dotrap':
trap.c:1111: warning: `saddle' might be used uninitialized in this function
The first one is no longer present in the trunk code. The last one is
bogus as its wishy-washy wording suggests.
Fix the reported bug of problems after casting stone-to-flesh spell
on self while wielding a statue. Pointers for worn items weren't kept in
sync and various potential symptoms could occur (most easily visible one
being that ')' falsely reported the no longer existing statue as still
wielded; report stated that one crash was observed). This bug predates
3.4.2 and was probably present ever since stone-to-flesh got introduced.
Described in the newsgroup a while back and recently reported: if
you had reflection and were invisible and had esp and were blind, Medusa
would turn herself to stone by looking at you. When you're invisible,
she shouldn't be able to see your source of reflection so shouldn't be
affected by the gaze; that's how things work when you aren't blind but
the relevant code was being skipped when you are.
Now esp is irrelevant for this and she'll see her reflected gaze
only when she can see you, regardless of whether you see it happen.
Prevent succubi from being fully restored via cycles of petrifying
and reviving. It wasn't just a matter of saving traits; cancellation is
one of the monster traits which is explicitly reset when a monster gets
revived. I think that probably makes sense, but this will override it
for succubi and incubi to prevent abuse; if they were cancelled at time
of petrification they'll remain cancelled when reanimated. Likewise for
nymphs; even though the abuse facter isn't present, the cancel effect is
pretty similar for them so keep revivals similar too.
This saves monster traits for every monster that gets turned into a
statue. Unlike with corpses there's no stacking involved to make players
notice that each has become unique, so all such statues might as well all
reanimate just like they were instead of as new replacment monsters.
Noticed when trying out the "heck patch", where the name of the file
for the sanctum level was changed and I neglected to update my Makefile to
reflect that: nothing was noticed if any files were missing when loading
them into a dlb container. Populating the playground directory for the
non-dlb configuration suffered a similar problem. Now the VMS playground
setup will issue a warning message if this happens (but not abort the
installation; perhaps it ought to do that as well...).
Other ports have the same problem. For example, Unix Makefile.top
relies on file globbing to build the dlb container; if a wildcard pattern
matches no files, dlb won't notice because the shell will have eaten the
offending pattern. Likewise for its non-dlb configuration, where cp won't
notice. However, this isn't a very interesting bug because it won't hit
when the distributed Makefiles correspond with the needed data files.
Make a sleeping or paralyzed shopkeeper wake up if you drop something
he's interested in buying (covers the recently reported case where dropping
gold failed to add credit, but picking it back up increased shop dept) or
if you use the 'p'ay command while owing money. Sleeping shopkeeper is not
affected if you drop something he doesn't care about, or use 'p'ay when
there is no debt, or pick up shop goods (latter case is handled normally--
you'll owe money for the item even though the shk remains asleep).
This makes shopping become a little easier--you aren't stuck waiting
for the shopkeeper to wake up if you actually want to pay for something--
in the rare case where the shopkeeper has been put to sleep, but it's an
awful lot simpler than any other reasonable way I could think of to deal
with the [lack of] credit problem.
This makes the snoring message handling moot--it no longer exists.
(It wasn't very reasonable to begin with, because the program can't tell
whether mon->mfrozen is for timed sleep or timed paralysis so avoided
giving that message for temporary sleep. There ought to be two separate
counters; probing is another case where vague messages are given because
the program can't tell the reason why a monster can't move.)
Guard against the pathological cases of ", <anything>" and
" called <anything>" strings that a user could type in to indirectly
trigger impossible(). Now they'll yield "no info about such things".
From newsgroup discussion: prevent monsters from level teleporting
to Moloch's Sanctum level unless the invocation ritual has already made it
accessible (same restriction player's character already has). Otherwise a
monster could pick up one of the invocation items and effectively take it
into limbo, making it become impossible for the player to reach that level.
Add missing handling for trapped containers and for Schroedinger's Cat
to the #tip command. Also, after tipping out the contents of a cursed bag
of holding, its weight would still reflect any items destroyed during the
process.
Releasing Schroedinger's Cat from a box which is being carried would
place the monster at the coordinates of wherever the box was last on the
floor instead of adjacent to the current location.
Also, the message sequence
The housecat inside the box is still alive!
The large box is empty.
seemed a little strange. This makes it say "is now empty" when a cat has
just been released.
Fix the reported problem of combat messages referring to Orcus as
"it" when the data.base entry uses "he"; extend use of gender-specific
pronouns to named and other unique monsters as well as to humanoids.
If any of those should stay as "it", they'll need to be M2_NEUTERed....
And prevent level followers from chasing you across levels if they
are fleeing at the time. It's an old change I've been sitting on which
is not related but happens to be right next to the pronoun code.
From the newsgroup: prevent monsters from level teleporting out of
the quest into the main dungeon. The player can't do that and monsters
weren't supposed to be able to, but from time to time the quest nemesis
has seemingly vanished after reading a cursed scroll of teleportation.
His disappearance was due to ending up on a random level between the
quest entrance and the top of the dungeon.
This also fixes an obscure bug that I noticed while trying to
reproduce that problem: uncontrolled level teleports by the player in
the quest had 80% or thereabouts chance of ending up on the quest home
level. All 12-15 main dungeon levels above quest entrance were included
in the random range of 1 thru current+3, then any choice which tried to
pick one of those was converted to quest level 1. (Monster destination
wasn't getting that adjustment.)
Mostly `gcc -Wwrite-strings' complaining about passing string
literals to safe_qbuf(). `gcc -Wformat' didn't catch the type mismatch
of formatting the return value of strlen() with %d, presumeably because
size_t is defined as unsigned int on this system and it treats int and
unsigned int as interchangeable as far as printf/scanf checking goes.
I'm not sure whether the sizeof() values being passed to safe_qbuf()
ought to have casts. Any system where size_t isn't the same width as
unsigned int is bound to support prototypes, but might possibly warn about
the implicit conversion of unsigned long (or even unsigned long long these
days) to unsigned int.
If the player gives the 'T' command while not wearing any armor,
don't suggest "use 'R' to remove accessories" unless the character is
actually wearing accessories. Likewise for 'R' while not wearing any
accessories, don't suggest "use 'T' to take off armor" unless wearing
some.
Add missing amulet case to the silly_thing() handling for 'W' and
'T'. Also handle boots, gloves, and lenses as plural in the message
there. silly_thing() has been simplified a little bit in the process.
Even though the in game help now lists the actual disclosure values
instead of "all" as the default value, implement support for "all" (also
for "none") since doing so is trivial.
Create an empty paniclog file during playground creation, so that it
starts with the same permissions as other writeable files. Without this,
it's liable to end up being owned by the first random user who triggers
a panic or impossibility rather than by the playground owner and probably
wouldn't be writable by any other user.
1) killer reason for scattered land mine shrapnel used "a" or "an" prefix
even when multiple projectiles hit as a group -- one of various things
From a bug report.oextra field) --
noticed while investigating #1 and later From a bug report.4.0 due to an unintentional side-effect of missile killer reason
handling in 3.4.1 (removal of redundant "poisoned" prefix by m_throw()
confused the poison handling routine) -- noticed while investigating #3.
From the newsgroup: leash found inside a bones level shop was flagged
as "in use". 3.4.0 had a fix for that which works for most cases, but not
when the shopkeeper has taken the dead character's inventory just before
saving the bones file.
This also adds an entry to the branch copy of fixes34.2 to synchronize
it with the trunk copy.
Noticed when investigating one of the killer reason bugs recently
reported: a land mine explosion shouldn't create a concealed pit trap;
make a revealed pit instead. And while testing that, I noticed that the
"Kaboom" message given when pushing a boulder onto a land mine was given
while the map still showed the boulder at its original location even
though it had actually been moved already. It's a little odd that you
get hit by shrapnel at your original position--as if you're shoving the
boulder ahead of you and then pausing a moment before stepping into its
former location--but that's trickier to fix; sometimes you won't advance
due to there being multiple boulders present (in that case you evidently
do shove the boulder instead of performing a steady push, so maybe the
current behavior is fine as it is).
"List of game options" from `? f' misaligns the entries for runmode
and scroll_amount (at least for tty display). Shorten their descriptions
so that they fit without squeezing out spaces.
nethack.rankin