'w$' reported "you can't wield gold" but
'w*$', choosing from inventory and picking gold, let you wield gold.
The old code checked whether gold had been picked before checking
whether '?' or '*' had been picked to request selection from inventory.
This wasn't an issue with 3.4.3's !GOLDINV configuration (but probably
was for anyone who explicitly switched to GOLDINV) because getobj()'s
callers only inserted gold into inventory when they intended to accept
it as a valid choice.
Fix is just to swap two adjacent 'if' blocks in getobj() so that '*'
is processed before the test of whether '$' has been chosen. Most of
the diff is indentation and other minor reformatting.
wiz_identify (^I) is supposed to bring up the inventory list
with the items identified, in contrast to the regular (I)
inventory, but only for that inventory display.
It is intended that if you then hit ^I again while at that
wiz_identify inventory menu, you'll trigger permanent
identification of itemsand any other key is supposed to
leave them as they were.
In tty however, <space> was doing the same thing as the
second ^I, and permanently identifying everything.
So, for those that like to <space> through menus (like
me) this makes it work as originally intended and
requires a deliberate second ^I at the menu to permanently
identify. (It might also allow trigger permanent ID if you hit
underscore, but nobody "underscores" through menus,
so that's ok.)
Changes to be committed:
modified: src/invent.c
modified: src/options.c
Apparently we need this based on Pasi's segfault. We just
don't yet know why we need them.
Also fix a warning:
..\src\options.c(1282) : warning C4101: 'tmp' : unreferenced local variable
Allow the 'I' command to show inventory of known blessed items via
pseudo object classes B, C, U, and X. That's instead of an showing
inventory of specific object class. The two can't be combined
because 'I' operates on single character input.
I had to modify tty_yn_function to prevent it from forcing a BUCX
character into lower case (simply using lower case would cause a
conflict with 'u' and 'x' for inventory of shopping bill), and did
that by checking whether any of the acceptable response characters
are upper case. Pretty straightforward and shouldn't impact any
other uses that don't specify upper case choices.
I did the same thing for X11. Other interfaces most likely need
to do something similar. If they don't, a response of 'B' or 'C'
(for menustyle:traditional or menustyle:combination) will simply
not work, without causing any problems, same as typing an invalid
choice, and 'U' or 'X' will give shop feedback instead of the
requested subset of inventory.
The Guidebook revisions are untested.
- honor blindness and hallucination
- honor ability to see one of the mergees
- provide audible feedback if appropriate
- merging inside pack gets special-cased so player knows something
different/unusual is happening
Adds the "sortloot" compound option, with possible values
of "none", "loot", or "full". It controls the sorting of
item pickup lists for inventory and looting.
it should be possible to wish for globs now; also hero's
inventory, containers, ground, monster inventories will all
honor the globbiness.
basically, any way you bring two globs together (adjacent on floor,
same inventory, same bag) should cause them to merge, combining
weight and nutrition as appropriate.
20 seems low-ish on nutrition for a pudding (kelp fronds are 30!)
at first glance but this is easy enough to fix later; don't really
want players to be able to stock up on food _this_ way and accidentally
obsolete all the other food-generation methods.
flooreffects() covers most dropped/thrown/etc. cases, and the hooks in
invent and mon handle "deathdrops" along with picking up items.
still need to check putting into/removing from containers
From a bug report, dropping a lit
(burning) potion of oil while levitating can produce an explosion which can
destroy inventory. If in the process of dropping multiple items, the ones
after the oil might be gone, resulting in use of stale pointers and possibly
triggering an "extract_nobj: object lost" panic or even a crash. While
testing my fix, I discovered that being killed by an exploding potion of oil
could produce an "object_is_local" panic if bones are saved (and reproduced
with unmodified 3.4.3).
From a bug report, dropping and selling a container that had some things owned
by the hero and some already owned by the shop, you could get "You sold
some items inside <a container> for N gold piecess." Shop handing for
containers has been changed significantly since 3.4.3, but the typo
"pieces" that then optionally gets plural "s" appended was still there.
While testing the trivial fix, I noticed suboptional feedback in the
prompt about selling. For a container owned by the shop, it said "items"
even when there was just one hero owned item inside. Fortunately this
potentinal can of worns only seemed to have one tiny weeny worm in it....
The revised version of count_buc() that I've had laying around for
a while is also included.
The fixes entry is for "piecess", not escaped/captured/exterminated
worms, and goes into fixes34.4 despite this patch being labeled "trunk
only". Separate patch for trunk to follow.
Use the grave accent (back tick) character as the keystroke for a
new command which prompts for an object class and then shows a subset of
the discovered objects list covering just the selected class. Similar
to the 'I' variant of 'i' for viewing inventory, and mainly useful once
the '\' discoveries list has grown long.
From a bug report, the 'D'
command would list 'u' as an item category choice if you were carrying
unpaid items inside a container, but if those were the only unpaid items
then nothing would happen once the dropping stage was reached. Applied
to all menustyles (except partial, which bypasses categories and goes
straight to a menu listing all items). There were two alternatives for
the fix: suppress 'u' as an applicable category when it only applies
to container contents, or include the container among the drop candidates
even though it isn't an unpaid item itself. I went with the latter; it's
simpler to implement and also feels a little more intuitive than behaving
like there aren't any unpaid items present.
When dragon scales or dragon scale mail becomes embedded in poly'd
hero's skin, the '[' command would report "you are not wearing any armor"
but the '*' command showed "a set of <color> dragon scales (embedded in
your skin)". The '[' feedback is more accurate but the '*' feedback is
probably more useful. This changes '[' to be more specific when lack of
worn armor is accompanied by embedded dragon scales/scale mail.
I put the fixes entry in the new features section since the old
behavior wasn't a bug.
Reported recently by <Someone>: probing feedback while engulfed
shouldn't claim that the monster is not carrying anything when the hero
is inside of it. The simple case where it's not carrying anything else
was a trivial one line change; handling inventory plus hero was trickier
and I wouldn't have bothered if I'd realized what it was going to take.
But it's done now; trivial case
The purple worm is not carrying anything besides you.
and harder case
The purple worm's possessions:
Weapons
a - an uncursed dagger
Swallowed Creature
> - human archeologist called wizard
Three years ago <email deleted> reported that
stepping off the end of inventory via typing space to go to the next menu
page wasted his identify scroll. He suggested that some people might do
that because they don't know how to back up in a multi-page menu. I
pointed out the Guidebook section that describes < and ^ to go back one
page or back to start and left things at that. However, traditional mode
reprompts if you step through all of inventory without choosing something,
so this changes identify-via-menu to do likewise. You can dismiss the
menu with ESC to really avoid choosing anything.
This also makes identification of N items when you're carrying N or
fewer unID'd things behave the same as identify all: identify everything
without any prompting.
I suspect--but have no way to test--that there is a subtle difference
in game play between perm_invent and !perm_invent involving object merging
or other activity that depends on whether or not object->dknown is set.
For objects pickup up while blind, where object->dknown is left as is,
the perm_invent config would have such items marked as seen sooner (since
there are umpteen places that call update_inventory() which will end up
setting the seen bit while formatting objects). Non-perm_invent wouldn't
have that done until the user examines invent (or asks to see a list of
objects at the "which object?" prompt for various commands). This patch
effectively examines inventory whenever blindness ends, so both modes get
dknown set as soon as possible. And if we ever add an "effect known" flag
for unseen objects which are used while blind, this would be a suitable
place to perform deferred object discovery.
A bug in some post-3.4.3 code made attempting to remove a worn ring
when wearing two skip inventory the selection and give "you don't have
anything else to remove" if you were wearing gloves and weren't wearing
an amulet or blindfold. The intent was that rings wouldn't be included
as likely candidates in the list of inventory letters to choose from if
you were wearing cursed gloves, but had a copy+paste mistake in the
argument controlling whether to consider the gloves curse state and was
in the wrong section of getobj()'s "ugly hacks". Also, it makes more
sense to require that the player know that those gloves are cursed, so
inaccessibe_equipment() got changed too. [Not knowing that the gloves
are cursed leaves rings listed as candidates; picking a ring will get
removal failure feedback later and mark the gloves as known cursed then.]
Newsgroup discussion about the devnull tournament which started
today has pointed out that ``d4294967296$'' would cause getobj() to create
a gold piece object with quantity 0 which then got dropped to the floor.
(It's specific to gold; other types of objects don't behave that way.)
Also, wrapping which went past negative and zero all the way to positive
again (like 429496729*10+7, yielding 1) wasn't detected.
For GOLDOBJ configuration, relax the 52 object limit for inventory
when gold uses the special $ slot instead of a letter. Takes care of an
old buglist entry from the beta testers. [It will need to be revisited
if we ever implement multiple coin types that can't all fit in one slot.]
Also for GOLDOBJ, prevents nymphs and monkeys from stealing coins,
since allowing that made their steal-item attack be a complete superset
of leprechaun's steal-gold attack.
Reported to us by <email deleted>:
'You are beginning to feel hungry. You trip over it.'
and also recently in the newsgroup by "<Someone>":
There is ice here. *You see here an electric eel corpse.*
Bib hits the electric eel. Bib misses the electric eel.
Bib misses the electric eel. The electric eel misses Bib.
The electric eel misses Bib. *You trip over it.*
slip_or_trip() was oversimplifying things by assuming that if there
is one object at the hero's location, a message about what that object is
has just been given. Any timeout message which precedes Fumbling (lots
of candiates besides hunger) could intervene, as could monster activity
between the hero's move and timeout handling. Aside from the reported
cases, that code hadn't been updated to account for the new pile_limit
option which could be set to 1 and force a popup display instead of the
usual "you see <an item> here". This fix adds a flag that can be used
to track the most recent message. It is cleared by pline for every
message, so pline's caller sets it _after_ the message of interest has
been displayed.
Noticed while looking at something else: doorganize() goes out of
array bounds for alphabet[] when inventory contains something in the '#'
slot, or in the '$' slot for GOLDOBJ config. Both # and $ pass the
(let <= 'Z') test, then produce a negative result for (let - 'A' + 26).
In my case, it was harmlessly clobbering the tail end of buf[] but it
could potentially be a lot worse.
Implement <Someone>'s menu-mode for #name, primarily because it
is the natural place to add [re]naming entries in the discoveries list,
something that was requested in the newsgroup ten or so years ago. The
latter allows changing the type name of something which has previously
been named and is no longer being carried.
This also makes the C command become a synonym for #name or vice
versa; one or the other could now be reassigned to something else.
#name
What do you want to name?
a - a monster
b - a particular object in inventory
c - a type of object in inventory
d - a type of object on discoveries list
Menu group accelerators provide unseen alternate choices: C for monster,
y for individual object, n for object type (and d for discoveries, but
that's only interesting if inventory is empty so that usual b & c are
omitted and discoveries entry moves up to b). These alternates allow
`#name y' and `#name n' to work the same as before, for users who have
trouble retraining their fingers. Using C to name a monster now takes an
extra keystroke, but using `C C' for it could make that be less annoying.
Something that pops up in the newsgroup periodically, with <Someone>
inevitably pointing out the bit of code that the user needs to tweak,
about control of feedback when hero is walking across floor objects.
Implement new option ``pile_limit'' which allows user to set the point
at which the game switches from listing the objects to giving "there are
several/many objects here". Default is 5, same as previous hard-coded
value (1 object gets listed via pline, 2..4 are listed in a corner popup,
5 or more objects yields a pline message instead). Setting pile_limit
to 0 means no limit, so objects will always be listed regardless of pile
size. Setting it to 1 effectively forces no listing since any non-empty
pile size is always at least that big, so can produce "there is an object
here" even though that's no briefer than a pline() to show one object.
