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.
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.
to $(CC) by default.
Necessary for C++ builds where the C++ compiler driver must be used
to link, adding libraries that the C compiler driver does not know
about.
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.
Incorporate a mod submitted by <Someone> to implement the TODO in the
class genocide code by walking thru the species to find a class to genocide
if the user input does not match the class description.
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.
Reported to the list a while back by <Someone>. The Knight's quest
messages are inconsistent in the use of royal pronouns. Capitalize them all.
Another option would have been to remove all royal capitalization (since such
Capitalization didn't come into use until relatively recently).
<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.
Make the instructions a bit more blow-by-blow. Re-order them so they
correspond to the Install.unx step numbers. Explicitly refer to
Install.unx and Install.X11 where appropriate.
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"
