Add putmixed() to the window port. It allows map symbols to
be included in the string by encoding them in a unique fashion.
This was done because Unicode symbols, for instance, could be
longer than the size of a char.
The encoding of the map symbols in this patch is done by
prefixing a glyph value with \GXXXX, where XXXX is a
random value for the current game. The reason for the random
prefix is to minimize the possibility that a player can trigger
the escape sequence processing within text under their control
(dog names, etc.) the way they could if the sequence was fixed
in the source code. The random prefix remains the same throughout
the lifetime of a game because message window strings are
saved in the save file.
(There was actually a bug present because of the embedded
character even before the recent symbol changes, because if
someone was using a different set of characters between games,
the saved messages would reflect the original characters, rather
than the current. That bug was introduced with the ability to
save messages to the savefile.)
A window port does not have to supply an XXX_putmixed() routine,
it can use genl_putmixed() which uses the old behavior of
embedding the sequence as a character within the string
and calling putstr(). genl_putmixed() takes care of the decoding
of the escape sequence.
This also #ifdef's out code in pager.c for converting a glyph
to a character, and uses mapglyph() to do that instead. Does
anyone see a problem with doing that through mapglyph instead
of repeating similar code within pager.c?
From the newsgroup: if you were wielding a cockatrice corpse without
gloves while polymorphed into something capable of doing that, then were
turned to stone when rehumanizing, you'd be left wielding the untouchable
corpse if life-saving kept the game going. This causes it to stop being
wielded if you get that far. Likewise for monsters.
From the newsgroup: it was possible to saddle, mount, and ride on a
sleeping jabberwork without it ever waking up. Movement was checking for
timed sleep (!mon->mcanmove, set when mon->mfrozen contains a timer count
for either sleep or paralysis) but not indefinite sleep (mon->msleeping).
This moves the checking into its own routine which handles both types.
And it gives monsters a chance to wake up when they get saddled or mounted.
Extend the identifying information used to prefix paniclog entries
from version + date to version + date + time + userid + mode (where mode
is 'D' for wizard mode, 'X' for discover mode, and '-' for normal play).
hacklib.c ended up getting more of a revision than I intended, but
the date/time handling routines now have less clutter. I hope I didn't
break anything in the process.
There is a quote in data.base for squeaky board traps:
A floorboard creaked. Galder had spent many hours tuning them,
always a wise precaution with an ambitious assistant who walked
like a cat.
D flat. That meant he was just to the right of the door.
"Ah, Trymon," he said, without turning, and noted with some
satisfaction the faint indrawing of breath behind him. "Good
of you to come. Shut the door, will you?"
[ The Light Fantastic, by Terry Pratchett ]
This patch makes each squeaky board trap on a level produce
a unique sound. If you had visited the trap yourself prior
to hearing a monster on it, you could actually know where
a monster was by the unique pitch of the squeak.
If someone wants further refinement of the roles, this could
be adjusted to only work for musically adept roles/species,
with the others only hearing a generic squeak. As it stands
right now, everyone benefits. Does anyone thing the
separation by role or species would be good? If so, which
roles/species are musically proficient, and which are not?
Since this patch increments editlevel anyway, it also sneaks in a
context structure change for an upcoming patch.
From a bug report: if you
attempted to eat a Rider corpse and got the 1/7 chance that non-yet-rotten
food will be treated as rotten, then also got "the world spins and goes
dark" result for rotten food, you would both survive the eating attempt
and also end up with a partly eaten Rider corpse. This patch treats Rider
corpses like lizard and lichen corpses; they'll never yield rotten food
effects. That way, they'll always be fatal to eat. They'll still end up
being partly eaten if you are life-saved, but since they'll immediately
revive, the only way you'll know that is to use probing or stethoscope to
discover that they've revived at less than full health.
Nearly two years ago, <email deleted>
suggested that lembas wafers and cram rations be treated like fortune
cookies and never yield the rotten food result. I'm guessing that cookies
are handled that way so that rotten food feedback doesn't override false
rumor delivery when they're cursed, rather than because they're considered
to be rot-proof. This implements <Someone>'s suggestion, except that cursed
lembas and cram will still behave like rotten food.
One from the way-back machine. A nurse would hit you-as-cockatrice repeatedly
and never turned to stone. With this change, nurses will turn to stone (and
also don't heal cockatrices, which seems fair). I considered giving them
gloves, but that seemed like too much effort. There are other cases where a
monster "hits" but will not petrify. However, it doesn't seem like passiveum
detects all the specific ways the monster "hit" you so I left them alone.
Fido grows up into a large dog.
The soldier becomes a sargeant.
Similar feedback was previously given only when the monster was going to be
killed off due to its new form having been genocided.
The shortest extended commands were being formatted differently in
Guidebook.txt than longer ones, looking a little odd. Force them to seem
longer so that they all end up with similar formatting.
Untested; based on how short option names are handled. And I have no
idea whether the TeX version ought to have something similar done; I lack
the means to view it. (In theory I could format it into Postscript,
transfer the result to a PC [a different one than what I'm using as a
terminal], convert it into PDF there, then use Acrobat to look at it. In
practice, that's more effort than I care to expend for something so minor.)
<Someone> pointed out that bugles, although noisy, only affect soldiers.
This didn't make sense to me either. Added code so they will also affect
monsters near the bugler.
Pat wrote:
> <Someone> has a patch (we've added a couple of
> his earlier ones) which changes the statue display from a single
> one size fits all "`" to a gray monster symbol instead.
> But I think the idea is a good one, and along with the
> bouldersym option could make the fairly hard to
> distinguish back-tick character go away.
Sources tagged before applying NETHACK_PRE_STATUE,
and afterwards with NETHACK_POST_STATUE for easy
rollback.
- reduce the number of symbol tables for each graphics
set {PRIMARY, ROGUESET} from three {map, oc, mon}
tables for each of the display symbols, the loadable symbols,
and the rogue symbols, to one continguous table for
each:
showsyms: the current display symbols
l_syms: the loaded, alterable symbols
r_syms: the rogue symbols
- Modify mapglyph so that the index into the symbolt table is
available as a return value (it was a void function), rather than
just the char converted from the glyph.
- That makes it possible for a window port to use the same
index value to extract from another table (perhaps a unicode
table) for a different set of display symbols. The index
is much more useful than trying to convert the character
into another type of symbol, as some contributed patches
have done.
- It is much easier to load a single alternative flat table to
make substitutions, since the corresponding value just
has to get placed into the same index offset in the
alternative table.
This also fixes a bug I found in botl.c, where you could
go to the rogue level, and the bottom line gold symbol
was not being updated with the new character as it should.
The reason was because the gold value had not changed,
only the field symbol used had changed.
This updates multiple ports to place a (void) cast on
the mapglyph call, now that it returns a value, so this
is going to generate a lot of diff e-mails.
About six weeks back, <email deleted> suggested that
bear traps should deal out damage and be escapable via opening magic.
This doesn't do anything about the first part, but it does allow opening
magic (wand of opening, spell of knock, blessed Bell of Opening) to get
the hero out of bear traps and webs if zapped either at self or downwards.
Zaps across the floor which hit monsters will free them from such traps,
with a chance that releasing a hostile monster will pacify it (using
existing #untrap code). Conversely, if you are at a web or bear trap
location but not currently trapped, closing magic (wand of locking, spell
of wizard lock) will cause the trap to activate; you may or may not become
trapped. Likewise for zaps at monsters who are at such locations, which
is treated as an attack.
Opening magic which hits the hero or a monster located at a trap door
or falling rock trap spot will cause the trap to activate; as above, it's
an attack for the monster case. At the moment, zapping opening magic
downwards at the hero's location (but not zapping at self or at monsters)
will also cause holes, pits, and spiked pits to activate. (Zapping down
triggers falling rock traps and zapping up doesn't; that'll need to be
changed.) Zapping opening down while mounted will untrap, if stuck in a
web or bear trap, and will trap, for the falling cases, in precedence over
releasing the saddle and forcibly dismounting. The latter still occurs
when there is no applicable trap present though.
Zapping locking magic downwards at a hole location will convert the
hole into a trap door. Zapping breaking magic (wand of striking, spell of
force bolt) down at a trap door location will convert the trap door into a
hole. (Neither conversion currently alters the made-by-you flag for the
trap. However, the rationalization that distinctive style is what makes
made-by-you recognizable suggests that conversion should clear the flag.)
Lastly, the old behavior (which pre-dated bare holes) of destroying trap
doors when zapping down at them with locking magic has been removed--it
didn't seem to fit very well with the new cases. I'm starting to have
second thoughts about that but am going to commit this before discovery of
some more niggling details drags it out for another six weeks.
From a bug report: you could end up with
gravestone/logfile result of "burned by burning" or "drowned in a drowning".
If you get life-saved when drowning in water or burning in lava, the game
tries to teleport you to safety. If the teleport fails for some reason--
such as lack of unoccupied non-water or non-lava locations--you drown or
burn again. But life-saving was resetting the killer reason and the repeat
drowning/burning wasn't setting it up again, so the default got used and
produced a silly result.
<Someone> wrote:
> I can' t find this bug in the known bug list. If I missed I do apologize.
> It occurs on the standard windows nethack.exe. Just wield a cream pie
> and then apply it. Press x to switch weapons. Program in disorder.
> s - 1752440940 glorkum 32 26485 101's named ? (alternate weapon; not wielded).
> Greetings, <Someone>
It crashed with an access violation for me.
More explicit control over the behavior of spoteffects() is probably
the way to go in the long run, but this much simpler fix handles the case
at hand. I'm not sure what `thrownobj' was intended to be used for in the
first place, but it came in handy here. (It was being left as a dangling
pointer when thitmonst() reports that the missile has been used up; that's
fixed now.)
Fix the reported problem of lookhere/autopickup not seeing the missile
which just killed the engulfing monster whose death caused the hero to be
put back onto the map and so look/pickup upon arrival. Normally the missile
gets placed after damage has been dealt and the throw has finished. This
overrides that so that the missile is put into the engulfer's inventory as
it is being killed (which will then put that inventory onto the floor prior
to expelling the hero on top of same). If the monster happens to get
life-saved it just ends up collecting the thrown-from-inside object a little
sooner than usual.
This wouldn't correctly handle the same case for a kicked object, if
that were possible. But it isn't possible to kick objects while engulfed,
so that's moot. Other calls to thitmonst() and hmon() don't appear to have
any objects in transit so shouldn't need any comparable fix (I hope...).
Recently reported to the list, a fireproof container dropped in lava would
catch fire and burn. Add the missing check; this looks an oversight when
the idea of fireproof was added, since other fireproof objects get handled
later in the cascading if().
<Someone> reported the longstanding behavior that when dragging, the chain
does not always remain directly between the player and the ball. This occurs
when the player zigzags. Added a check to the simple drag code to try to
keep the chain directly between the player and the ball. But, don't do this
if the player is walking thru rock or if it would move the chain into rock.
Pat recently forwarded a discussion that Elbereth was ignored unless there
was an object on its location. Mostly. It was also respected if the hero
was Displaced, no matter where the hero was. No one commented on his
message, which I took for assent to address this. Removed the qualifiers, so
now Elbereth is always respected, just like a scroll of scare monster.
<Someone> noticed that when a monster escaped upladder in the wizard
tower, it ended up outside the tower. This is due to the "wander" code in
monster migration. Rather than add code to try to keep the monster from
crossing the undiggable wall, just add REGIONs on the tower levels within the
area, which then utilizes the existing in-a-room constraint behavior of
monster migration. Of course, one can still fill a tower level with fodder,
and then when another monster climbs the ladder, it will still end up
outside the tower.
stinking clouds extend their timers, causing the "ttl == 0" check in
visible_region_at to be inappropriate; technically it was never quite
right, since the ttl is set to 0 one turn before removal is considered. But
with the Eyes on, this caused a visible change in the region although the
region still existed. Introduced a new -2L value to designate that the
region is being removed (-1L means it's permanent), which is what
visible_region_at was really trying to test.
This is an overhaul to the NetHack drawing mechanism.
- eliminates the need to have separate lists in drawing.c
for the things and their associated explanations by grouping
those thing together on the same inializer in a struct.
- replaces all of these options: IBMgraphics, DECgraphics, MACgraphics,
graphics, monsters, objects, boulder, traps, effects
- drawing.c contains only the set of NetHack standard symbols for
the main game and a set of NetHack standard symbols for the
roguelevel.
- introduces a symbols file that contains named sets of
symbols that can be loaded at run time making it extensible
for situations like multinational code pages like those reported
by <Someone>, without hardcoding additional sets into the game code.
- symbols file uses names for the symbols, so offsets will not break
when new things are introduced into the game, the way the older
config file uchar load routines did.
- symbols file only contains exceptions to the standard NetHack
set, not entire sets so they are much less verbose than all of
the g_FILLER() entries that were previously in drawing.c
- 'symset' and 'roguesymset' config file options for
preselecting a symbol set from the file called 'symbols'
at startup time. The name of the symbols file is not under the
users control, only the symbol set name desired from within the
symbols file is.
- 'symset' config file option loads a desired symbol set for
everything but the rogue level.
- 'roguesymset' config file option loads a desired symbol set
for the rogue level.
- 'SYMBOLS' config file option allows the user to specify replacement
symbols on a per symbol basis. You can specify as many or as few symbols
as you wish. The symbols are identified by a name:value pair, and line
continuation is supported. Multiple symbol assignments can be made on
the same line if each name:value pair is separated by a comma.
For example:
SYMBOLS = S_bars:\xf0, S_tree: \xf1, S_room:\xfa \
S_fountain:\xf4 \
S_boulder:0
- 'symbols' file has the following structure:
start: DECgraphics
Handling: DEC
S_vwall: \xf8 # meta-x, vertical rule
S_hwall: \xf1 # meta-q, horizontal rule
finish
start: IBMgraphics
Handling: IBM
S_vwall: \xb3 # meta-3, vertical rule
S_hwall: \xc4 # meta-D, horizontal rule
finish
- 'symbols' file added to the source tree in the dat directory
- Port Makefiles/scripts will need to be adjusted to move them into
HACKDIR destination
> Give demon lords and other monsters who teleport to your location a
> oneshot arrival message. [...]
> The fixes entry is deliberately a bit vague (and I put it in the new
> feature section rather than the fix section).
And apparently I neglected to commit it with the rest of that patch last
week.
<Someone> wrote:
>>comments:
>>When you commit suicide with a potion of oil (lit), sometimes nethack
>>reports an `obj_is_local' error just after disclosing all the game
>>variables. This has been found in-game (don't ask) and reproduced in
>>wizard mode and in-game (start-scumming).
>
> 0) a neutral human wizard (the scrolls/spellbooks burning, potions boiling ;))
> 1) wish up 3 potions of oil (so that the 2 remaining will definitely kill you)
> 2) a'pply one of them
> 3) stand 1 square away from a wall, like "| @"
> 4) throw the lit potion into the wall (`h' in this case)
> 5) answer `yes' on all prompts.
The thrown potion of oil, which was extracted from any chain
during the throw, still had its timers attached when the call to
splatter_burning_oil() was made. If that killed the hero, a
panic would result during bones file creation (saving timers)
because (obj->where == OBJ_FREE) on the potion.
Remove the timer prior to splattering the oil inside.
Turn being unconscious (via several reasons, including fainted from
hunger) into a pseudo-property named `Unaware' and use it in several
places where only being asleep was checked. #H202 was about a stunned
character who got the recovery message when it timed out while fainted.
This suppresses messages for several difficulties when they begin or end
while hero is Unaware. Messages about fatal illness, sliming, or
petrification aren't suppressed; they're too important to hide from the
player. "You feel ..." messages come out as "You dream that you feel ..."
when Unaware; fairly lame but hopefully adequate.
From a bug report, being hit with a
yellow light explosion while fainted from lack of food caused blindness
but being hit while sleeping did not. Make being in fainted state become
a protection against light-induced blindness.
From a bug report, the fallback selection criteria
(used when everything is extinct?) in rndmonnum() was excluding hell-only
monsters when outside of Gehennom, but failed to exclude never-in-hell ones
when inside. [Some of the never-in-hell monsters are Angels, but the rest
are all cold based creatures. That must date to when fire resistance was
required for the hero, which is no longer the case. Should those cold
monsters retain their never-in-hell setting?]
This also fixes a latent copy/paste bug in the unused mons[] definition
of Cerberus (it was the only unique monster which failed to specify G_NOGEN).
<Someone> says he reported this five years ago, but I don't think I ever
saw it. Receiving an artifact as the result of #offer would add it into
the discoveries even if the hero was blind and never saw it. It either
needed to have the dknown bit set, as if it had been seen, or else should
not be added to the list. I've opted for the latter.
From a bug report, having hallucination time out while
mimicking an orange (instead of gold, after eating a mimic corpse), you'd
still get the hallucinatory end-of-mimicking message about not wanting to
be peeled. If hallucination state is toggled, update the pending message
and change the hero's appearance. In practice, only the orange-to-gold
case can occur. Anything which might trigger gold-to-orange will have
terminated the hero's mimickery befort that happens.
<Someone> reported being swallowed by his pet purple worm during
Conflict, then being stuck inside once Conflict ended. I'm not entirely
sure what dog_move() intended by the "swallowed case handled above" comment.
It returns without letting the pet move when the distance between pet and
hero is 0; that wasn't much in the way of "handling" being swallowed.
Grabbing pets did let go, but peaceful monsters didn't until you actually
attempted to move away from them. Now all four combinations (grabbed or
swallowed by tame or peaceful monster) are handled the same: the monster
will let the hero go next time it gets a chance to try to move, using up
its move in the process.
When the hero arrives on a level and a monster at his destination can't
be relocated to make room for him, goto_level() would place the hero on top
of the monster. From a bug report, who said that the
game panicked (without providing specifics, at least so far). I wasn't able
to reproduce a panic but get a pair of impossible warnings and can confirm
that there is a monster on the same spot as the hero, which could easily
lead to strangeness depending upon what actions the monster attempts to
perform. This fix causes a non-relocateable monster in that situation to
be moved to the migrating monsters list for later arrival back on that same
level. That's inconsistant with the migrating monster arrival routine,
which kills off any monster it can't place; I'm not sure which action is
more reasonable, deferred arrival or outright removal.
There are three or four dozen ``(void) rloc(mon)'' calls which don't
do anything special when rloc fails to move the monster. Those need to be
reviewed and the ones where it's making a space for some other monster have
to do something about failure. (Failed teleport attempts can simply leave
the monster in place, so most of those calls won't need any extra handling.)
Forwarded from the newsgroup by <Someone>: temple priest might
abandon his post via teleport if conditions are obscure enough. Change
rloc_pos_ok() to only accept spots inside the same shop or temple when a
shopkeeper or temple priest is teleported to a random destination. rloc()
tries rloc_pos_ok() 500 times before reverting to goodpos(), so this will
usually succeed for a large room; it may fail for a small one (reverting
to the current behavior, more or less). Shopkeepers or priests who get
polymorphed into a critter which teleports to the stairs when in need of
healing will still leave their shop or temple if wounded (no change).
Priests resist if the player tries to teleport them, but shopkeepers
don't. So for direct attack by the player, this only affects shopkeeper
destination. But it affects both types as far as being hit by quantum
mechanics (probably caused by player's use of conflict) or if polymorphed
into monsters which steal and then flee (again, probably caused by the
player since those strong monsters won't voluntarily polymorph).
From a bug report...): pushing a boulder onto a level teleporter trap
could repeat the
You push the boulder and suddenly it disappears!
message. That would happen whenever the teleport destination was the same
as the current level (20% chance). The boulder wasn't being moved onto the
trap location so was still present when the pushing code tried to handle
the next one in the pile. I've changed so that pushing stops whenever a
pushed boulder is affected by a trap, and also so that the boulder gets
moved as usual when a level teleporter fails to send it somewhere.
I've always thought it's pretty strange that pushing ever operates
on more than one boulder in the same turn in any situation, but I haven't
changed that for the non-trap cases. (Usually the first boulder pushed
ends up blocking the second one, so you get a "you try to move it, but
in vain" message which seems odd since you just moved one. But if there's
a pool of water or lava in the path, you can actually push multiple
boulders successfully.)
From <Someone>:
Pet picks up 8 spears.
Pet wields 8 spears.
Pet thrusts its spear at Foe.
The routine to handle a monster attacking the hero are already uses "mon
thrusts one of its spears" in this case, so make monster against monster
messages do the same. Also, it's no longer necessary to save one monster
name before formatting another when using two monster names in the same
message, so switch to the more straightforward usage here. (The Blind
check is needed in the mhitu case but not in the mhitm one, where it's
redundant because the caller has already verified that both monsters'
locations are visible, but I left it in.)
From a bug report, it was possible
to fall from above the quest locate level to below it even though it has
nondiggable floors (hence no trapdoors or holes to pass through). Since
the game can't verify that it is nondiggable (which could vary on a role
by role basis depending upon their quest descriptions) when it is not the
current level, restrict falling past it only when it hasn't been visited
yet. Impose the same restriction for random level teleport. This enforces
proper sequencing of the quest feedback, which was the more significant
thing that went wrong in the reported case (player finally got the full
locate level message on a return visit, when descending from above, after
having already cleared out that level on his way back up from falling).
Once the locate level has been reached or passed, it is no longer a
barrier to falling or random teleport. (When it is eventually visited,
there's no attempt to remember whether it allows holes, since that
information and the corresponding fall check would need to be extended to
every level in the dungeon. Also, controlled teleport is still allowed to
bypass it even when it hasn't yet been visited, so the "enforces proper
sequencing" claim above is an exaggeration.)
From a bug report, applying a pick-axe will
wield it in place of the primary weapon but wouldn't update the alternate
weapon. Make objects which become wielded when applied (pick, lamp, whip,
grappling hook, pole-arm) honor the pushweapon option (where the previously
wielded weapon becomes the alternate weapon without use of 'x' command) the
same as when explicitly wielded. Old behavior matched the documentation,
but that seemed overly restrictive.
<Someone> wrote on Tuesday, July 27, 2004 at 06:46:15
> In the region.c function rest_regions allocates storage for the possible
> enter_msg and leave_msg strings. But the function free_region does not relese
> this storage.
Also ensures that some code that is currently ifdef'd out
makes copies of the strings into memory from alloc()
to ensure that no problems with free() result if the function
gets passed a literal string.
> NetHack feedback form submitted by
> <email deleted> on Friday, June 30, 2006 at 17:31:12
> ---------------------------------------------------------------------------
>
> mailversion:1.35
>
> nhversion:3.4.3
>
> nhfrom:Our 3.4.3 source release, unmodified
> comments:
> telnet nethack.alt.org with the terminal set to 21 rows.
> Choose to pick a char, not accept pot luck, and game segfaults.
> (same happens from linux console)
I was able to reproduce something similar in win32 by setting
the console to 21 rows. As he stated, don't let the game pick you
character for you to reproduce the problem. As soon as I chose
Archeologist the problem occurred:
Where:
In hack.c, weight_cap()
if (Levitation || Is_airlevel(&u.uz) /* <email deleted> */
#ifdef STEED
|| (u.usteed && strongmonst(u.usteed->data))
#endif
)
Variables:
carrcap 200
u.usteed 0x00000000
&u.uz 0x005e54aa
youmonst.data 0x00000000
Examination of the preprocessor output of that section
of code reveals that
"Levitation" becomes:
(u.uprops[47].intrinsic || u.uprops[47].extrinsic ||
((youmonst.data)->mlet == 5))
so it is the is_floater(youmonst.data) causing the crash.
Call stack:
weight_cap() line 2300 + 24 bytes
inv_weight() line 2342 + 5 bytes
calc_capacity(int 0) line 2354 + 5 bytes
near_capacity() line 2365 + 7 bytes
bot() line 607 + 5 bytes
docorner(int 47, int 19) line 2378
erase_menu_or_text(int 5, WinDesc * 0x00a22550, char 0) line 994 + 25 bytes
tty_dismiss_nhwindow(int 5) line 1664 + 15 bytes
tty_select_menu(int 5, int 1, mi * * 0x0006fc40) line 2248 + 9 bytes
tty_player_selection() line 442 + 16 bytes
pcmain(int 3, char * * 0x00a20eb0) line 457
main(int 3, char * * 0x00a20eb0) line 91 + 13 bytes
This adds a check for a valid youmonst.data in
bot().
From a bug report, attempting to attack
a hidden monster who is revealed by ongoing monster detection (blessed
potion or skilled spell) gave "wait! there's a <monster> hiding there"
response and prevented the attack. Make it behave the same as when the
hidden monster is revealed by telepathy; the monster comes out of hiding
and the hero's attack proceeds.
<Someone> reported that he applied an unID'd bag and it became
discovered as a bag of tricks even though a spellbook appeared on the floor
next to him rather than having a monster show up (the monster was a mimic).
Suppress the bag discovery unless you can see or sense a monster appear.
(This doesn't really achieve much for most players, who'll recognize the
bag because they know that only one type of container doesn't prompt to
take things out and/or put things in, but I think it does make sense.)
While mucking with bag of tricks I decided that to be consistent with
the behavior of other containers, the #tip command should release all the
monsters in the bag instead of just one.
And after doing that, I realized that horn of plenty ought to behave
much the same, so #tip will operate on it now. However, it won't be listed
as a likely candidate in the "which item?" prompt unless/until it has been
discovered. (Attempting to empty any other type of horn yields "nothing
happens", same as for a horn of plenty with no charges left.) Emptying a
horn of plenty in a shop can be extremely verbose, but I don't think that
qualifies as a bug and don't currently have any plans to alter it.
From a bug report: [ slashem-Bugs-1206099 ] Torches are not extinguished with rust traps).
A rust trap that hits the torso candles causes all lit objects being carried
to be extinguished, but one which hit the weapon arm didn't have same affect
on a wielded light. This fix causes wielded candles or lamps (not Sunsword)
to go out if affected by any rust, such as hitting a rust monster with one,
rather than use his patch that just handled the trap case. It also excludes
wielded lights from the existing torso splash since having them be hit by
both instances is too obviously buggy.
I think brass lanterns ought to be exempt from being extinguished by
water (at least splashing which is less drastic than total submersion) since
there are references to them operating by batteries rather than fire, but I
didn't want to track all the places which would be affected.
<email deleted> wrote:
> - when in a hardware store, I put a glass wand out of a sack (the glass wand
> will cost you 266 zorkmids) and threw it in the shop => shattered into a
> thousand pieces BUT if I try to pay, I do not owe the shopkeeper anything !!!
> If I break a potion with a /oS, I have to pay !
