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.
For now, the code is conditional on BARGETHROUGH
being defined, while it gets tested further. While behavior is
different with and without BARGETHROUGH defined, savefiles
are the same either way.
After this patch is applied, only the riders have the M3_DISPLACES
bit set, but the Wizard and Vlad probably should too. Any others?
An optimization.
Split the patterns into two chains, one for things you want "always picked up", and one for things you want "never picked up". That way, the
entire exception list isn't being checked twice, once for each type of
check. The check for things to "always pick up" only checks the
chain at the AP_GRAB index, and the check for things to "never
pick up" only checks the chain at the AP_LEAVE index.
- Also modifies the toggle autopickup '@' message
appropriately for the AUTOPICKUP_EXCEPTIONS build.
(it just tacks on ", with some exceptions" if there are some)
[ 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.
An enhancement to the original to allow
two types of exceptions:
always pickup
never pickup
To specify "never pickup", begin the pattern string with '>'
which is NetHack's down direction symbol (for "leave it down")
To specify "always pickup", begin the pattern string with '<'
which is NetHack's up direction symbol.
For example, to pick up all arrows, regardless of the pickup_
types setting:
autopickup_exception = "<*arrows"
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.
There was code higher up that could destroy the obj,
so this eliminates any risk of trying to dereference a
bad pointer in the deferred silver message by saving
a copy of the name earlier on.
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.
Acknowledge Schroedinger's cat at end of game.
- determine cat's status:
- give points for the animal which accompanied
you.
or
- include dead cat in the box contents.
Schroedinger's cat is the only ordinary creature
that could actually ascend with you.
This patch doesn't deal with any supernatural creatures
including:
- djinn in bottles
- ghosts in bottles
Follow suit with what <Someone> did for the object name buffers,
so that this sort of statement can work correctly:
pline("%s hits %s.", Monnam(mtmp), mon_nam(mtmp2));
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.
> 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.
Allow '*' with control-g to create a random monster species,
or several different monster species if a multi count was specified
on the control-g command.
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().
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.]
- store the variety of tin at tin creation time
rather than at tin-opening time (as a negative
value in spe just as homemade was; spinach
is still spe 1)
Allow wishing for a particular variety of tin
from the tin variety list:
"deep fried", "boiled","broiled","candied"
"dried", "french fried", "homemade"
"pickled", "pureed", "rotten", "sauteed"
"smoked", "soup made from", "stir fried",
"szechuan"
Example: "tin of soup made from orc"
non-debug player could randomly fail on the
variety specification 1 in 4 times
the message history saver needs the windows to stick around until save
is completed. This usually the case, but end_of_input() was calling
exit_nhwindows prematurely. This is actually an old bug (calling it early,
but wasn't harmful until other recent changes).
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.
There were still some significant startup message problems
with win32tty.
I've spent a lot of time in the debugger tracing through them all.
I think I've got them all worked out now, certainly the ones that
I was aware of. There may be some I haven't discovered.
Testing welcomed of course!
This patch also attempts to diagnose the error where someone tries
to execute NetHack directly out of a zip file, and provide
them with a (hopefully) helpful message similar to what we
might end up telling them if they wrote in. If you want
to test that part, you can comment out the line in the
Makefile that adds "dungeon" to nhdat, and delete the nhdat
in your binary and src directories, and "make install".
Then add the value of your TEMP environment variable as a
DATADIR statement in defaults.nh (here's mine):
DATADIR=C:\DOCUME~1\ALLISO~1\LOCALS~1\Temp
The diagnostic code engages if the game fails to open
dungeon. It then checks to see if it the game dir is the
TEMP directory for your system, and if so it prints the
message.
<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.
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.
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.
