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.)
Since traps can no longer provide an infinite supply, and people were
complaining that they always ran out of ammo before, make it less likely
to break enchanted and blessed ammo, and more likely to break eroded
ones.
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.
>Steps to reproduce problem:
>1) make sure you don't have race, role, gender specified in your
> defaults.h, then add
> OPTIONS=role:Valkyrie,race:Human,gender:male,align:lawful
>2) start a new nethackw.exe game
>3) Uncheck "Random" from gender box, now you can select from male
> or female, not only female.
>4) Select male and click OK.
>5) When game begins press shift+O (Options) and look to gender.
> Your valkyrie is male.
defaults.nh values were not used the dialog initialization. That's
why both male/female options were available for Valkyries. This is
now fixed.
Also added: checking for consistency of the initial settings and
resetting all incompatible values to ROLE_NONE.
"You can't loot or pick up containers on the floor if you're not
skilled enough to reach them from your saddle, but you can check
for and disarm traps on them; this seems a little odd. (Likewise,
being able to set land mines and beartraps while riding.)"
A core fixup if the the port startup code sets an invalid flags.female when
starting a new game. The old comment regarding being unable to change
flags.female was not completely correct. The flags.pantheon can be used to
differenciate new games from a restored game.
this particular fix has been sitting around my inbox for a while although
we've had reports of FreeBSD build problems for a long time. While it's
untested, it certainly looks like the unfixed system.h had a case that
could not be reached. bsdi seems like it needs to be handled the same way.
When attempting to disarm a trapped chest, wisdom should only be exercised
when not confused. It stands to reason that even if you manage to find a
trap in a confused/hallucinating state, wisdom shouldn't be exercised.
Since monster cancellation sticks, it doesn't makes sense for Magicbane to
cancel a monster more than once. Tweaked the messages to deal with this fact.
I decided to not make Magicbane's random effect "intelligent", which is what
changing it to use some other attack against a canceled monster would be.
Several cases in the trap block of code in dosit() were caused by utraptype
being set to values not corresponding to an actual trap. <Someone>
reported back in 12/02 that the "sitting in lava" killer message could not
occur, but the special-case sit messages for TT_INFLOOR and TT_BURIEDBALL
couldn't occur either.
Several cases in the trap block of code in dosit() were caused by utraptype
being set to values not corresponding to an actual trap. <Someone>
reported back in 12/02 that the "sitting in lava" killer message could not
occur, but the special-case sit messages for TT_INFLOOR and TT_BURIEDBALL
couldn't occur either.
<Someone> pointed out a disagreement between the comment and code in
throwing_weapon(): comment says daggers & knife can be thrown, but
code also allowed short swords. Assuming the comment was correct, changed
the code to match.
<Someone> (also later forwarded by <Someone>) reported that choking
while eating non-food always resulted in calling it a "quick snack".
lesshungry() depends on an occupation to tell if you are actually eatig or
not, but since non-food is eaten in one turn, no occupation was set. Took
his suggestion of setting the occupation temporarily to cause lesshungry()
call choke() appropriately in this case.
The bug report referred to greased hands, but that doesn't affect the
behavior. If you drop an object while swallowed or engulfed in a shop, and
that object had previously been picked up from the shop floor, the object
was treated as costly. In some cases, this could result in impossible
errors later on. Perhaps object ox & oy should be modified when in
player/monster inventory, but this fix addresses the specific problem by
not doing the costly check while swallowed.
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.
This solution is mostly a band-aid. Make sure information set by join_map
that is overlaid by the MAP is cleared out. This ensures that place_branch
will never consider invalid data. A new function, remove_rooms(), with a
helper, remove_room(), takes care of this, but only for rooms created by
join_map, which addresses the only known case that causes this problem.
There's a possibility that some other strange behavior, especially in
minetn-6, will be fixed by this as well. The problem of disconnected caves
on minetn-6 is not yet addressed.
Also, add a check to lev_comp.y to make sure the required fg semantics of
joined levels (fg must be ROOM or CORR) are actually met. Doesn't affect
any levels currently included in the distro, but might address levels
others are trying to make.
add another bit to the flags passed to launch_obj so it can print
the initial "rumbling" message at the appropriate time rather than
having the caller print the message, possibly out of order.
Write "died of starvation" on the tombstone, not just "starvation".
Suggested by <Someone> a couple weeks ago, although his suggested
prefix was different and didn't work as well for the "exhaustion" case.
> While looking at the tiles.bmp file, I've found some more mistakes like
> this : the Wizard of Yendor's shadow is touching Croesus' tile, and one
> of Orcus' wing is touching Yeenoghu's tile.
<Someone> suggested a scroll to counteract an unknown scroll of charging
that had negative effects. Scroll of punishment already costs the same,
so that unknown behavior is already covered. Plus, a cursed scroll of
charging already has negative effects, except in the case where the player
was confused where no negative effect from reading a cursed scroll of
charging occured. Added such an effect (since the curse should still cause
something bad, even though the reader is confused), to drain the player's
energy.
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.
Proposed by Michael Allison.
Seconded by Pat Rankin.
(it can always be withdrawn if there is a later objection)
-Author of Spanish NetHack
-Author of some NT keyboard internationalization fixes
-Author of "Hell patch"
On January 20, 2002 Ken Arromdee wrote:
>I dug this out of my files. (Well, it didn't take a lot of
>digging; I already copied the disk in question to my PC long ago.)
[...]
>I may or may not have another one of these but I'd actually
>have to go install a 5 1/4 inch drive to check.
When polymorphed, only attacks involving hands/feet/weapons should result
in damage to object. Theoretically, hug and butt attacks should affect
objects too, but no forms with such attacks currently allow wearing armor.
This is my final src mod to ensure that a qbuf does not overflow due to
a lengthy named object. These recent patches, coupled with the core yn_function() patch earlier, should make it much rarer for a QBUFSZ
buffer overflow to occur in a window port routine (unless the window
port routine has its own bugs, but that isn't the core's fault).
By naming the candelabrum as long a name as the game will allow, and by naming a candle the longest name also, a qbuf overflow and crash is
triggered when you attach the candle to the candelabrum.
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.
<email deleted> wrote:
> The game crashed badly when I made some experiments with items
> with very long names:
>
> You have much trouble lifting a blessed greased thoroughly rusty >thoroughly corroded +3 plate mail named terribly long killer longer than my
>ong long-worm called long. Continue? [ynq] (q)
tty_yn_function(const char * 0x0012fa50,
const char * 0x00572ddc _ynqchars, char 113) line 379 + 6 bytes
lift_object(obj * 0x009e8970, obj * 0x00000000,
long * 0x0012fcd0, char 0) line 1131 + 20 bytes
pickup_object(obj * 0x009e8970, long 1, char 0) line 1258 + 19 bytes
pickup(int 0) line 474 + 28 bytes
dopickup() line 1853 + 11 bytes
rhack(char * 0x005c0d50 in_line) line 1908 + 3 bytes
moveloop() line 406 + 7 bytes
main(int 3, char * * 0x009e2ac0) line 102
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.
Make exploding bags of holding be less mysterious, and perhaps cut
done on the number of claims that they've vanished for no reason. There
wasn't any feedback other than the explosion message itself; in particular,
the message about putting something into the bag didn't occur since that's
handled by the didn't-explode case.
Recently discussed in the newsgroup, and it sounded familiar so may
have been reported directly earlier:
You fly through the trap door. You fly down along the stairs.
when polymorphed into a flying creature or riding a flying steed. It
only happens at the castle, and only happens because the go-down code is
explicitly setting the arrival point to be the Valley stairs. That's how
the castle trap doors used to work as traps too, but they were changed to
dump you randomly near the stairs quite some time ago. Fix it by making
intentional triggering work the same now; this also prevents the false
feedback (even if you happen to arrive on the stairs by coincidence).
<Someone> reported that encumbrance feedback when removing GoP
was delayed until the next turn. Several other places call encumber_msg()
to provide immediate feedback. Call it in Gloves_off() too.
Change the monster constants to match the current position of the switch
statement. Also test canseemon(), since the message isn't needed if you
see the change. I didn't make any other change to the message frequency.
If it's too frequent, then perhaps the changes themselves are too frequent.
