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.
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.
> From the newsgroup: an egg carried by the hero hatched and the
> resulting monster was placed in hiding underneath an adjacent object.
> The silly hatching message given was "You see it drop from your pack."
> (Player said he was using 3.4.1, but the relevant code hasn't changed
> since then.)
If a long worm's head is on the drawbridge and a tail segment is at the
portcullis and you raise the drawbridge, bad monster handling occurs
because of some recursion that occurs before set_entity is called again.
Not sure when this last worked; it's broken in 3.4.2 as well. Modified
e_died to ensure both entity objects for the same monster get cleaned up
so subsequent e_at calls behave as expected.
The default symbol for lit and unlit corridors are the same. This makes
the lit_corridor option a no-op where the defaults are used and also means
that using a light scroll/spell a corridor has no obvious effect. To
address that, I special-cased the lit corridor symbol and change its color
to bright white when its the same symbol as the unlit corridor symbol (I
didn't change the default color since I thought that made the lit corridor
look strange using the windows console interface).
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.
[ 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.
Add config.h experimental option AUTOPICKUP_EXCEPTIONS.
It's an interface-only change which allows you to add lines to your
config file to selectively avoid autopickup of items based on their
text description that is displayed when you pick them up. It does
it by matching a pattern against the xname singular return value.
For example:
autopickup_exception = "*corpse" will avoid picking up corpses, even if
food (%) is in your pickup_types.
autopickup_exception = "*brown*"
will avoid picking up any brown items (why, I do not know)
autopickup_exception = "*loadstone"
will NOT avoid picking up loadstones, unless they are already
identified, because the xname string will be "gray stone", so no
match there.
The matching has no knowledge of in-game objects, it is just
a text pattern match, thus it is an interface change, not a gameplay
change, and it is meant as a convenience for players.
From the newsgroup:
> <email deleted> (<Someone>)
> Newsgroups: rec.games.roguelike.nethack
> Subject: Question: Why don't silver wands give silver damage?
> Date: 9 Nov 2003 09:18:50 -0800
> Organization: http://groups.google.com
> Lines: 7
> <email deleted>
>
> I had a character cornered by a werejackal the other day. I'm not too
> bothered by the death but why didn't the silver wand he desperately
> wielded in his final moments do extra damage? I mean, silver rings do
> so why not wands? I realise this is a pretty minor problem since not
> that many people will be going around wielding wands, but still.
>
> ~<Someone>
There was a code path for objects such as wands that avoided
all the silver checks. Now fixed.
A trapped monster with one step between you and the monster (@.@) would
repeatedly switch between a ranged and hand-to-hand weapon if carrying both.
Since the monster switches each turn, it will not make ranged attacks.
Modified the test in dochug to prefer a ranged weapon in this case.
<Someone> wrote:
> The new ^V wizmode menu is nice, but it is rather misleading; most of
> the levels it lists are "you can't get there from here". Would it be
> possible either to make it only list levels that can be reached
> directly, or alternatively to allow you to reach the ones you
> ordinarily couldn't (maybe by forcefully changing u.uz.dnum to yoink
> you into the right branch, and even summarily issuing you with an
> Amulet if you ask to teleport to the endgame).[...]; being able to bamf
> quickly to Minetown from DL 1, for example, would be damn useful in > testing stuff.
Allow fairly free roaming of the dungeon via the wizard mode teleport menu.
<Someone> wrote:
> You start bashing monsters with your 2 cockatrice corpses.
> You hit the foo with the cockatrice corpse (note singular).
> The foo is slowing down. The foo turns to stone.
> Also: Your cockatrice corpses rots away.
It appears that vtense() has a problem recognizing "corpses"
as plural. This doesn't fix that, it just switches to using
otense() in this particular case.
Pat verified something I had wondered about, that various tests of mcanmove
in shk.c should have also been testing mcanmove. There may well be other
tests of mcanmove in other files that need fixing.
when msleeping is set, mcanmove is not cleared. mcanmove applies only to
mfrozen. So, mattackm needs to test both mcanmove and msleeping.
mattackm will not wake the defender if the attack misses.
<email deleted> wrote:
> When wielding greyswander and a black light explodes, the
> message is still "You are freaked by a blast of kaleidoscopic
> light!" giving no indication that you are immune to
> hallucination. Maybe something like "You see a blast of color,
> but seem unaffected" would be more appropriate?
return the changed status back to the caller from
make_hallucinated().
Use a new flush_screen(-1) call to toggle 3rd screen update in goto_level.
This keeps the 3rd screen state unchanged, no matter what happens at higher
levels, ensures the map window cursor stays on the hero, ensures the
hero's showrace colors remains bright white, and so on.
<Someone> suggested and I agree (mostly, if you're a Monk poly'd to a
strict carnivore, I think it should still smell delicious):
> "You smell the odor of meat." (if herbivorous)
> "You smell a delicious smell." (otherwise)
> I think that if your character is a monk or still veg(itari)an, you should
> also get the first message. Even if you're not intentionally vegitarian,
> the first message is still appropriate.
Reported a really long time ago (June 2001) by <Someone>:
- stand on the upstairs and engrave Elbereth with a /oFire
- create Demogorgon and e.g. a tame dragon
- cause conflict
- Dragon will kill Demogorgon and Demogorgon will never ever attack Dragon.
All monsters could still attack Demogorgon without response via fightm().
Modified fightm() to include a bit of code in m_move and dog_move, allowing
response to an attack. Testing this in action, Demogorgon still usually
did things detrimental to the player, mostly summoning nasty monsters.
<email deleted> wrote:
- When polymorphed into a quantum mechanic, it is possible to jump in
the water on a no teleport level and instinctively teleport.
- When an engulfing monster is teleported away on a no teleport level
when the hero is polymorphed into a quantum mechanic, there is no
message displayed like "You are no longer engulfed!" because
u_teleport_mon is passed FALSE for give feedback. But maybe this is
for a good reason...
>Hemmed in by one invisible wererat?
><Someone>: Should I feel hemmed in if I can see that a wererat summons
>zero rats? Can the invisible wererat hem me in all by itself? And
>even if it had summoned anything, wouldn't a different message had
>been clearer (for isntance, "Rats appear around you!"); after all,
>I could see *what* was hemming me in.
>I agree that the current messages (and even the ones aspired to by the
>comment) are non-ideal.
<Someone>'s suggested set-up:
Seen summoner, seen help : "The wererat summons help!"
Seen summoner, unseen help: "The wererat summons help! You feel hemmed in."
Seen summoner, no help: "The wererat summons help! But none comes."
Unseen summoner, seen help: "(A rat appears|Rats appear) from
nowhere!"
Unseen summoner, unseen help: "You feel hemmed in."
Unseen summoner, no help: No message.
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.
To reproduce: disable lit_corridor, enter a corridor, read a scroll of
light, then read a cursed scroll of light. The corridor won't darken again.
A test of flags.lit_corridor in newsym was at fault. I'm guessing this was
never noticed because lit_corridor is on by default on Windows and the
default lit and unlit corridor symbols are the same on most other platforms.
Cutting a shopkeeper poly'd as a long worm would generate strange messages
and could result in a crash. cutworm didn't deal with all the intricacies
of duplicating a monster. Fixed by changing cutworm() to use clone_mon()
to do most of its dirty work. It seems to me that without this change,
cutting a tame long worm could also have similar bad effects.
Other side effects of this change:
- clone_mon now takes x,y coordinates, 0,0 results in previous behavior
- clone_mon no longer always makes cloned monsters tame/peaceful if player
caused the clone, using the same formula previously in cutworm. Someone
else may wish to tweak this for gremlins.
- clone_mon will christen the new mon with the old shopkeeper's name, even
though clones are never shopkeepers (game can't handle 2 for a shop)
- cutworm can now be called during conflict or pet combat, although I
added no such calls (yet)
Incorporate a slightly modified version of a patch submitted by <Someone> back in June. The basic problem, which I noticed again this past
weekend, is that pets with a high apport value can still try to get to
objects when there's no path to the object. The patch extends the
can_reach_food function to be used for any object, renaming it to
can_reach_location, and adds a could_reach_item function for doing point
checks. This also removes any chance of a pet dragon, for example, eating
something underwater.
When changing levels, the state of rndmonst() is reset, causing the monster
choices to be recalculated. However, the frequency counts for initial
uncommon() monsters were never cleared. Thus, if the first non-extinct
monster were a hell monster, and you returned to the main dungeon, the hell
monster will remain in the list and could be selected.
From Newsgroups: rec.games.roguelike.nethack :
> <email deleted>
> Subject: question for windows tty users
>
> I am trying to hunt down a bug, and want to know if I have
> encountered another one of those bizarre "features" that only
> occur on my computer (I seem to get a lot of them).
>
> I can reproduce this bug, or whatever it is, in the official
> Windows binary like this: Start the tty version of NetHack by
> double clicking on the program. You won't see the bug if you
> start it from the command line. When the game asks, "Who are
> you?" press ^C. NetHack will respond with "^C abort. Hit
> <Enter> to end," and then it hangs. Pressing Enter does
> nothing, and the program does not end.
>
> Can anybody else reproduce this behaviour? Thanks in advance.
>
> -- <Someone>
Calling rehumanize directly when u.mh > 0 doesn't consider Unchanging
(perhaps it should?). But, it's probably better to call losehp anyway.
Also, part of a buglist item: .5PD didn't affect rust trap damage on iron golem
I wrote to the devteam early last week:
> Given my understanding of travel, it's supposed to be somewhat intelligent,
> and "convenient", and should, therefore avoid walking into water, lava,
> traps, or other things that distant movement would avoid, even if you're
> right next it. Unless... the travel destination is the "bad" location
> next to you when the travel starts.
To that end...
- add a context (iflags in 3.4.3 to maintain savefile compat) flag to
differenciate the first travel step from later steps, to allow the
detection of the final sentence, above.
- several changes to set/reset the travel1 flag as needed
- add code to findtravelpath to treat the first step specially if it's
the only step, allowing forced travel into a "bad" location
- correct the "don't travel over traps" code, which was getting confused
because hero's starting location was being avoided
- add code to avoid traveling into water and lava, duplicating
checks used for non-travel running
- fix some strange "guess" travel behavior: avoid zigzag paths when there's
a more direct path (even though the number of moves is the same)
- trunk change adds a new DISP_ALL tmp_at type, and uses it in some debug
code for travel, debug changes not added to the 3.4.3 branch
This hack simply causes ^C to be ignored completely by the gnome interface.
Gnome really cannot handle interrupts, and the window port interface does
not currently provide a way for the gnome interface to just quit. Allowing
the gnome interface to prompt would require a complete overhall to the the
way window ports work.
<Someone> wrote:
- If I set the 'boulder' option, shouldn't I be able to give the
symbol I define for them at the crystal ball "object or
monster symbol" prompt and have it work?
- Could ']' be added as a synonym for 'm', as with genocide?
- set boulder symbol to '3'; use '/' or ';' to examine a
boulder. Result is "unknown creature causing you disquiet
co-located with a boulder" even though there's no warning
glyph '3' there.
Another buglist entry.
<Someone> wrote:
- There appears to be no way to detect ghosts-and-shades; the
space key just "Never mind"s. (Not that they'd be particularly
visible on the resulting screen under ASCII, unless you've
changed the 'monsters' option.)
Allow space; display results in inverse using detected_mon_to_glyph()
<Someone> wrote:
- You currently appear to be able to specify '~' and have it try
to detect monsters (though it won't detect any long worms)
Show the entire worm when specifying either '~' or 'w' now.
> over the water, then polymorphed into a non-flying creature
> leaves you standing on the water (you can kill the creature
> too and you're still on the water when you shouldn't be).
> - When floating from levitation over water and being held and
> removing levitation, you will fall into the water and drown or
> crawl back onto land. If you crawl back onto land you're no
> longer being held.
> The first situation seems to be a bug, the second a possible
> exploit. Both situations don't seem very correct, if you're
> being held it seems you should not fall into the water/lava
> until you are no longer being held. [patch contributed] It
> will keep the hero held up on over the water until released if
> his size is smaller than or equal to the size of the monster
> holding him. [<email deleted>, patch
> supplied]
>
A recent patch ensured that you ended up in the water when
polymorphed.
This patch is less ambitious than <Someone>'s
contribution, where he actually had the monster hold you up.
Perhaps that can be tackled for the trunk later.
