Fix the problem From a bug report, so finding it in a bones file yielded a fully functional magic
lamp. Fix as user suggested: convert the lamp first.
It also left the djinni who would normally have disappeared right after
the wish. Water demons from fountains have that problem too. Unfortunately
my fix is a bit buggy: when removing the monster before granting the wish,
the player can notice. Is there a straightforward way to display a monster
where none is present on the map? Or do we need something comparable to the
obj->in_use flag for monsters, so that the bones code can discard particular
ones?
Pointed out by <Someone>: engraving with a cursed wand should pose a
risk of having it explode just like zapping does. [At the moment when one
explodes, any existing engraving doesn't get changed.] Suggested by someone
(<Someone>?) some time back: explosion due to recharging could be consolidated
with explosion due to zapping cursed wands. And noted by <Someone> in the
newsgroup: '+' in an engraving--perhaps written by someone trying to leave
bones file notes--should have a chance of being partially rubbed out to '-'.
From a bug report, using stone to flesh to
reanimate a petrified monster who was carrying gold (in his case, it was
a shopkeeper) resulted in gold in the monster's inventory. Somehow it was
also being duplicated in the mgold field--I didn't try to figure that part
out--so killing the monster produced double gold. More significantly,
probing such a monster prior to killing it caused a panic when the monster
inventory was being massaged for formatting.
Fix is trivial: use a routine which knows about special handling for
gold when transferring statue contents to resurrected monster. Both aspects
of the problem only occurred for the !GOLDOBJ configuration (which is our
default). However, any objects which confer something special when simply
being carried would have also been misbehaving--automagic animation of
cursed figurines is the only applicable situation; too rare for anyone to
have noticed.
Implement the suggestion that Fire Brand avoids damage from rust traps
by boiling away the water. Rather than making this be trap-specific, it
applies to all types of erosion which go through erode_obj(). That includes
hitting rust monsters but not dipping into potions or fountains, nor falling
into moats. And it doesn't provide 100% protection, just a high chance of
avoiding rust damage. Also, Frost Brand gets similar protection by freezing.
The message handling needed some rewriting for the branch version.
That compiles ok but hasn't been tested. It would have been simpler just to
move Yobjnam2() over even if nothing else was changed to use it yet....
While wearing EotO, ";" and selecting a monster behind a wall would display
"normal vision" as well as "astral vision". This is because cansee() gets
set for things seen via astral vision. However, couldsee() is only set for
things that could be seen normally, so check both values.
When confused remove curse acts upon an object to randomly bless or
curse it, clear the bknown flag. Do this for all objects which get subjected
to the effect, even ones which are already blessed or cursed and hence don't
change state.
<Someone> reported that when levitating and blind, he was getting
"You float over the hole" without it showing up on the map. Easiest way
to reproduce: zap a wand of digging downwards while levitating blind,
move off the spot and back over it.
Make sure that all traps created by the player are mapped. For other
traps, it was about 50:50 whether the trap triggering message yields enough
information to warrant forcibly mapping the trap when blind.
A few weeks ago someone in the newsgroup posted how he got an intrinsic
value for increased damage up to something like +74 via eating rings (on his
way to killing the Riders a zillion times for maximum score--he wanted to be
sure to kill them in a single hit each time so that his use of keystroke
macros wouldn't get out of sync by extended combat). Make it moderately
difficult to get beyond +20 and impossible to get past +40 for corresponding
attribute when eating rings of increase damage, increase accuracy, and
protection. Since you could also wear a pair of +7 rings you can still get
an awfully high total, but it won't be unlimited any more and most people
willing and able to go to such extreme lengths would undoubtedly prefer to
be wearing other types of rings.
From the newsgroup: non-cursed dunce cap or helm of opposite alignment
which would glow black and become cursed if worn by the hero wasn't doing
the same when worn by a monster. Fixing this gives players a new way to
recognize bad hats--drop on altar, then drop in front of approaching goblin
or other wimpy monster capable of wearing armor--but I think that's fair.
Since helms of opposite alignment are usually already cursed it won't make
much difference for them; most players seem to avoid all conical hats so it
won't make much difference for dunce caps either.
When 3.4.0 added the shop price to inventory display of unpaid items,
it resulted in showing that price twice if you used the `I u' command while
carrying just one unpaid object.
k - a potion of object detection (unpaid, 150 zorkmids) 150 zorkmids
With two or more unpaid objects it uses a menu style display and explicitly
suppresses "(unpaid, N zorkmids)" from the inventory formatting. Do the
same suppression when there's one item.
k - a potion of object detection 150 zorkmids
[This ought to be suitable for the branch version too but I'm not going to
spend the effort to migrate it there.]
Recently From a bug report, reducing
the value of a shop object via cursed enchantment was ignored by shopkeeper.
This replaces the existing costly_cancel() routine with costly_alteration()
which performs a similar task: bill for any item whose value has been made
less. The hero owns the resulting object but must pay for the original one
before being allowed to leave the shop.
This covers the majority of cases where bill_dummy_object() was already
being used: cancelling a charged or enchanted item, casting drain life at
same, diluting potions or blanking scrolls or books by dipping them into a
potion of water, dulling a weapon by engraving with it, eating unpaid food
or opening unpaid tins, applying a cream pie to hit yourself with it in the
face, applying a wand to break it, burning something by dipping it into lit
potion of oil, and clearing potions by dipping a unicorn horn into them.
The shop billing behavior for those actions hasn't been changed, just
consolidated into one place which delivers a common message for them.
This also covers many cases which weren't being handled: stripping
wand or magic tool charges via cursed scroll of charging, reducing a charged
ring's enchantment via same, reducing weapon or armor enchantment via cursed
scroll of enchant weapon or armor, stripping an item's rustproofing via
confused enchantment, making a crysknife revert to a worm tooth, unblessing
potions of holy water or uncursing potions of unholy water. (That last one
won't be billed if it's the result of prayer rather scroll, spell, or #dip.)
And this tries to handle the reverse situation more thoroughly too:
many actions which improve the value of an unpaid item now also cause the
shop bill to be updated to reflect its new higher price. Aside from the
basic enchanting and charging magic, it covers converting dragon scales into
dragon scale mail and worm tooth into crysknife. Some things which might be
expected to inflate shop prices, like rustproofing or increasing the number
of charges in a wand, don't actually affect the price. And there are bound
to be cases where the price is affected but I've overlooked.
Various actions (potion dilution, igniting candles or oil, dulling a
weapon by engraving) on an unpaid object can modify it in such a way that
a shopkeeper will force the hero to buy it. bill_dummy_object() is used
to make a copy for the shop bill; play continues with the modified item
now owned by the player. bill_dummy_object() was setting the no_charge
flag unconditionally on the modified object but the flag shouldn't be set
for items in inventory. It was possible to drop the object and sell it,
pick it back up for free due to that flag setting, then drop it and sell
it again. One easy way to reproduce is to zap yourself with a wand of
cancellation while carrying unpaid positively enchanted armor or weapon.
The no_charge flag gets cleared when you pick something up off the
floor or take it out of a container, so this sell-it-again case would only
repeat once. Selling a dropped item ought to clear the flag, but my head
is still spinning after looking at the shop code to see about implementing
that. This fix just prevents bill_dummy_object() from mis-setting the
flag in the first place; sellobj() still can't fix it up after the fact.
From a bug report, it is possible for the hero to
appear embedded in the wall after destroying the drawbridge. This is because
The variable "lev1", which was the entity's location, was being referenced
after e_died, but e_died can change the entity's location. So, as <Someone>
suggested, refer to the current location directly.
While auditing nomul() I noticed unconscious() treats (multi < 0 && !nomovemsg)
as unconscious. This explains the behavior in M29 (unconscious message
while performing #turn). I checked all the places with this combination,
and found a few that did not appear to fall under the "unconscious" category.
Most I changed to use You_can_move_again to ensure the same display w/o the
unconscious behavior. Also:
- found another string that unconscious() should have considered
- vomit() now sets nomovemsg, one caller was also doing this redundantly
- vomiting_dialogue() was calling stop_occupation() after vomit(), which can
reset multi. I reversed the order and removed a doubly-redundant nomul call.
tele() still has a problem: some cases where multi < 0 should probably take
a branch like the unconscious() branch but with a different message.
doturn()'s behavior - turn then wait - is also less than perfect, but I
think this is a known problem.
Finally apply the patch sent by <Someone> in 11/2003 for slashem-Bugs-799278,
updated to match the current code and handle additional cases. The fix
is brute force: always ensure nomovemsg is set when nomul is called with
a negative value. I also scanned the code for places manually setting
multi negative, they all set nomovemsg. It would be nice to have a function
that did the right thing, but there are several special cases and I was
not feeling creative.
From the newsgroup: player offered the Amulet with a pet adjacent
to his character, and instead of getting "You and Fido ascended" he got
"Fido is still eating" followed by "You ascended". Make all adjacent pets
eligible to accompany an ascension even when they're in circumstances where
they'd be prevented from coming along on a normal level change.
When testing drawbridge stuff recently I ended up with an unseen
monster who evidently cast the aggravation spell repeatedly, yielding a
steady stream of "you feel that monsters are aware of your presence"
messages. This patch makes monsters tend to avoid repeating that spell
once everyone on the level has already been woken up. It also extends
the spell effect so that it will wake monsters like quest nemesis and the
Wizard who ordinarily wait until you get close before they become active.
<Someone> reported: You kill it! A potion of invisibility shatters!
Change the rule in hero_breaks() to avoid giving info for things out of
sight, except when from_invent is set, to preserve desired behavior.
Several places were not using safe_qbuf or anything equivalent to avoid
overflowing a QBUFSZ buffer. Add more uses plus one special case. For
the current max lengths returned by xname(), I think this is
sufficient. This addresses a reported buffer overflow for a
"thoroughly rusty thoroughly corroded helm of opposite alignment", plus more.
As From a bug report, twice. Change max_passive_dmg to multiply the
result by the number of direct attacks the aggressor can make. This way, a
tame mind flayer, for example, will avoid pounding on a spotted jelly and
dying as a result of the Nth passive response.
Suppress "Mr" or "Ms" title for shopkeepers when they're going by a
first name rather than a surname. The bug report was for Izchak, but it
would have happened with the two last resort names (which I've never seen
in actual use) and for the "hippie names" used in post-3.4.x health food
shops. I have not attempted to specify gender for those, just flagged
them as first names. This prepends a prefix character to the name string
(see comment in shknam.c) to specify gender and/or first name vs surname.
Shop items stolen or destroyed without being in inventory were handled
inconsistently compared to simply picking up unpaid items because different
criteria got used to decide whether the shk cares about something. Last
December a hack to deal with this for container contents was introduced but
that left the problem for ordinary items. This patch attempts to address
it by using a common check for theft and for pickup's add-to-bill.
It hasn't had nearly enough testing and I won't be very surprised if
one or more new obscure shop bugs have now come into being, but perhaps
they'll at least be consistent bugs as far as shop billing is concerned....
Neither nymphs nor monkeys can steal a ring worn underneath gloves
since they can't see them. If such rings are randomly targetted, try to
take gloves instead.
Succubi trying to take worn ring of adornment will attempt to take
off worn gloves first. (Presumeably they can sense magic rings hidden
beneath gloves better than nymphs can; they're about to try to take all
worn armor off anyway....) If the glove removal fails, ring theft will
too. Likewise for incubi, remove gloves before trying to force the hero
to put on ring of adornment.
At the moment succubi and incubi can't remove gloves which are
blocked by a welded weapon, but they can manipulate rings then if there
aren't any gloves involved. I don't think that's right. The latter is
nymph-like and could be attributed to magic, but if that's the case why
aren't they able to remove gloves from under cursed weapons too?
Prevent monkeys from stealing any ring which the hero can't remove due
to it being stuck inside the grip of a cursed weapon. Nymphs can still do
so though. From a bug report.
Fix the two problems that <Someone> reported about stale pointer use
after a bag of holding has exploded. use_container() passed the wrong
variable for quantity when calling useupf(), and doapply() had no way to
tell if the object being used had been destroyed so could use an invalid
pointer when checking for speaking artifact. The fix for the latter is
much simpler than what <Someone> suggested.
Someone in the newsgroup mentioned that there is no warning from blessed
food detection if you attempt to eat a tin of Medusa meat. touch_petrifies()
isn't enough to catch that. A warning was given about Medusa's corpse, but
only if you lacked poison resistance. Eating a tainted Medusa corpse had a
similar problem; the check to override food poisoning so that petrification
takes effect missed it. This makes the petrification checks be consistent,
including hypothetical case of Medusa egg.
When a wish request for "<foo> armor" fails to match anything, check
whether it matches "<foo> mail" before resorting to selecting a random piece
of armor. Most of the suits are named "mail", and while I don't think many
people will ask for "ring armor", I do think that "crystal plate armor" and
"gray dragon scale armor" are sometimes tried.
This also greatly simplifies the handling for spelling variant "armour"
by rewriting it to "armor". Unfortunately "grey" vs "gray" can't be handled
the same way since both spellings are used by the program.
A user recently complained that he started an activity such as
searching and specified a repeat count, right after getting--and not
realizing the significance of--the first message in the countdown
sequence for turning into stone. He suggested that subsequent messages
interrupt multi-turn activity so that the player has a chance to do
something to prevent imminent death. This implements that, with the
added wrinkle that it won't interrupt if the activity is something that
might save the character's life: attempting to eat a tin that is either
sure to help (if ID'd as food that cures stoning) or a desparate gamble
(if unID'd). Some hooks for similar behavior for other conditions like
turning into slime are included, although no tins can help for anything
other than petrification so far.
Shouldn't fatal illness have an end-is-near countdown too?
Implement a user suggestion that tame humanoids should avoid eating
corpses of their own species. Prevent them--except for kobolds, orcs, and
ogres--from doing so unless starving. Arbitrary: tame elves won't eat
other elves even when starving. A polymorphed character will incur the
effects of cannibalism when eating either his/her underlying race _or_
the current one (player orcs and cavemen aren't affected though).
o Add support for zlib compression via ZLIB_COMP in config.h (ZLIB_COMP
and COMPRESS are mutually exclusive).
o rlecomp and zerocomp are run time options available if RLECOMP and
ZEROCOMP are defined, but not turned on by default if either COMPRESS
or ZLIB_COMP are defined.
o Add information to the save file about internal compression options
used when writing the save file, particularly rlecomp and zerocomp
support.
o Automatically adjust rlecomp and zerocomp (if support compiled in)
when reading in an existing savefile that was saved with those options
turned on. Still allows writing out of savefile in preferred format.
o In order to support zlib and not conflict with compress and uncompress
routines there, the NetHack internal functions were changed to
nh_uncompress and nh_compress as done in the zlib contribution received
in 1999 from <Someone>.
I tagged the sources NETHACK_3_5_0_PREZLIB prior to applying these
changes.
As reported, you'd get the "float gently to the ground" message even while
riding a flying steed. Rearranged the code and added a new case for this.
I found it odd that Hallucination protected you from falling out of the
saddle due to the Sokoban air currents. The message implied otherwise, so
I've made the sokoban_trap code apply in both cases.
<Someone> reported that if you polymorph into a flying monster while in a
pit, you must take u.utrap turns to first climb out before you can fly. Of
course, once you're out, you can swoop down into the pit to pick things up
w/o delay. Rather that have you automatically fly out (e.g. like quaffing
a potion of levitation), I thought it was better to take a turn to fly out,
so that's what I've implemented.
The code to deal with exiting a pit is moved to a new climb_pit function
and the "up" command now lets you climb from a pit too (something I've
found non-intuitive in the past).
Finally, I noticed that non-moving monsters could still go up/down even
though they couldn't move around. Added non-moving checks in doup/dodown.
move the message so it's before the mintrap test. newsym's are needed
to ensure the display is correct if a --More-- prompt results. I left the
"frighten" message alone, except for tense. As per Pat's suggestion, I
changed the wording to future-proof the message.
<Someone>, I think, noticed there was no copyright on the window.doc.
Add one. I don't recall when I originally wrote it, but I last changed
it in 2003, so that's the year I'm putting in. Anyone else that wants to
share the blame, please add your name and update the year as needed.
On Mon, 03 Jan 2005 12:04:29 +0000, <email deleted> wrote:
> Dear NetHack win32 developers,
>
> This bug does not affect the win32 binaries that you distribute but it
> does affect NetHack 3.4.3 if I build it from source. The difference may
> be due to different compilers or whatever. I'm using mingw32-gcc v3.2
>
> I don't quite understand what's going on (I never was much good at
> win32 programming), but it appears that the WM_KEYDOWN message for
> AltGr-4 is being translated into a WM_CHAR message with a wParam of
> 128. I don't understand why that should be, but anyway. The problem
> then occurs when NetHack casts wParam to char which, since char is
> signed, gives -128. onListChar() then passes -128 to isdigit() which
> causes the crash. The fix appears to be to simply drop the cast:
Also
> <email deleted>
> Newsgroups: rec.games.roguelike.nethack
> Subject: Changing tile set for item list?
> Date: 1 Jan 2005 20:03:08 -0800
> <email deleted>
>
> I'm using the windows interface for Nethack 3.4, and I've successfully
> changed the tileset used by changing defaults.nh. The only problem is,
> the item list (i.e. The list that comes up when I press "i") still uses
> the old tiles. Is there any way to change the list so it uses the new
> tiles? I've searched the guidebook to no avail. I'm debating if it is
> even possible.
>
> Thanks for the help,
> -Zmann
trunk patch:
- menu: display custom tiles if map is not ASCII
- menu: display '-'/'+'/'#' in place of a tile if map is ASCII
- fix isdigit() crash on AltGr-4 with mingw
It looks kinda weird with huge tiles (e.g. absurd96) but that could
be just me. Comments/suggestions are welcome.
-<Someone>
