Poly'd into a giant with a full inventory that already contains at
least one boulder, moving onto a boulder (that can't be pushed due
to a wall or other obstacle) yielded
You try to move the boulder, but in vain.
However, you can easily pick it up.
You are carrying too much stuff to pick up another boulder.
You see here a boulder.
The second and third statements contradict each other. Make the
code that dishes out the second message smarter. If autopickup is
set for it and you will pick up the boulder:
However, you easily pick it up.
If autopickup is not set for it but would have worked if it was:
However, you could easily pick it up.
If your inventory is full and you have a boulder (or are in Sokoban)
However, you easily push it aside.
That last one is instead of "however, you can squeeze yourself into
a small opening" that you'd get if not a giant and not carrying much.
Reported directly to the devteam. Set hilite_pile on, become
invisible, pick up all but one item from a pile on the floor,
the pile symbol was still there afterwards.
This is yet another case of evil hack, because the gbuf doesn't
distinguish between object piles and single items, see
commit 854fe40609
Add support for filtering by unpaid status for container-in and
container-out actions. When taking out of a container, it works as
expected if you're carrying the container while in a shop, but won't
find any unpaid items if the container is on the floor. That's
because they're only flagged as unpaid while in the hero's inventory.
(And when it doesn't find any unpaid items it won't list 'unpaid' as
a category of item to manipulate, so while that might be suboptimal
for taking items out of shop containers, it shouldn't be a problem.
Typically all the contents are shop-owned anyway, so using unpaid as
a filter wouldn't gain any advantage over just taking stuff out.)
The different menustyle settings have been offering different degrees
of support for BUCX filtering:
Full : multi-drop, container-in, container-out
Trad, Combo: multi-drop
Partial : none (to be expected; it explicitly jumps past class
filtering, where BUCX gets handled, to a menu of all objects)
This adds pickup, container-in, container-out, multi-unwear/unwield,
and object-ID for Trad and Combo, and multi-unwear/unwield for Full.
(Full behaves like Partial for pickup--not sure why--and for object-ID,
bypassing filters to go straight to a menu of all applicable items.)
There are probably several new bugs--this stuff is very convoluted....
Report #5426 was classified as not-a-bug, but the underlying issue
can be improved.
For item selection where BUCX (bless/curse state) filtering is
supported (mostly for menustyle:Full, but there are a few actions
where Traditional and Combination handle BUCX too), 3.4.3 took the
union of object class and bless/curse state (so ?!B gave all scrolls
and all potions and every blessed item from other classes) but 3.6.0
changed that to the intersection (so ?!B gives blessed scrolls and
blessed potions, period). Since gold is inherently not blessed or
cursed it has been getting excluded during intersection handling
when that includes BUCX filtering. Report #5426 was from a player
who was used to choosing $X when putting newly acquired loot into a
container asking to have the old behavior reinstated.
The ideal fix would be to support both union ($ | X) and intersection
(?! & B), but implementation would be bug prone and the interface,
especially when done for menus, would be cumbersome. Instead, this
adds new boolean option, goldX, to allow the player to decide whether
gold is classified as uncursed--even though it is never described as
such--or unknown. The new-loot-into-container issued can be solved
either via $abcX, where abc lists all classes that have any X items
(when gold is included as one of the classes, its BUCX state is now
ignored for the current selection), or by setting the goldX option
and then just picking X for the types of items to put into the
container (or drop or whatever other action supports BUCX filtering).
The situations where menustyle:Full allows BUCX filtering during
object class specification and styles Traditional and Combination
don't should to be fixed (by extending BUCX support to Traditional
and Combination rather than removing it from Full, obviously).
Autopickup for pickup_types is disabled for unpaid shop goods, but
always-pick-up autopickup_exception still picked things up, as did
pickup_thrown for thrown objects. Now they'll only work in shops
for no_charge items (dropped by hero and shk didn't want, or hero
declined to sell).
costly_spot() was being recalculated for every item which passed
pickup_types. This changes autopickup to check it once for a given
autopickup operation and cache the result. [Whenever the hero moves,
a room entry check is performed. That ought to be extended to cache
costly_spot() for <u.ux,u.uy> in iflags or u.]
The #tip command tries to reduce verbosity by formatting drop messages
with just the object name instead of with full sentences, yielding
Objects spill out: obj1, obj2, obj3, ..., objN.
where the trailing comma or period is included with each successive
object. If an intervening message occurs, such "25 zorkmids are
added to your credit", the rest of the objects will no longer be
extending the original sentence and end up looking silly.
Objects spill out: obj1, obj2,--More--
25 zorkmids are added to your credit. obj3, ..., objN.
This fix causes the post-interruption messages to revert to verbose
format.
Objects spill out: obj1, obj2,--More--
25 zorkmids are added to your credit.--More--
obj3 drops to the floor.--More--
...
objN drops to the floor.
The interrupting message still follows the comma of the partial
sentence, but I don't see any sane way to fix that other than to
abandon the terse format altogether, and doing that makes #tip way
too verbose when the container has a lot of items in it. But #tip
inside shops now does that, since there will always be buy/not-
interested feedback interrupting the terse format in that situation.
For other situations, a full sentence message might end up following
a partial sentence list of dropped items.
There was a more significant bug. Dropping a hero-owned container
with gold in it onto shop floor sold the gold to shk, giving hero
credit. Subsequent #tip gave the hero credit for that same gold
when it spilled out. addtobill(obj) relies on obj->ox,oy to
determine whether events are taking place in a shop, and #tip was
relying on placement onto floor to set those, too late for shop
billing. The fix yields suboptimal results: you're given credit
when you drop the container, then during #tip when you spill the
contents, credit for the gold is removed, then new credit for it
is given. That's down to shop insanity, not tipping behavior.
Previous fix was 'me' to eat from inventory without checking current
location for edible items. The report describing the need for that
also mentioned that you could #loot while blind and without gloves
and not touch any objects except for the container you pick to loot.
This adds a corpse touch check, plus `m#loot' to skip floor containers
and go directly to using #loot for adjacent saddled creature. That,
as well as the open command, will reveal adjacent container in some
circumstances but I'm going to pretend that that doesn't matter.
doloot() has turned into spaghetti. We should probably add #unsaddle
or something of the sort and return #loot to container-access only.
After some permutation of commands which displayed items, the 'd'
command presented a prompt with the list of letters scrambled (in
loot order or pack order rather than invlet order), so explicitly
sort when getobj operates. Done for ggetobj too.
For menustyle:Traditional, ',' followed by 'm' presented a pickup
list in pile order even when sortloot was 'l' or 'f'. That was an
unintentional change during the 'revamp'.
Reported directly to devteam for recent git code, the "sortloot
revamp" patch could trigger an object lost panic after calling
query_objlist() when menustyle was full or partial and player
picked up a subset of available items. Modified head-of-list was
not being propagated to its source in pickup(). Use an extra layer
of indirection.
When removing items from a container via menu, list gold as '$'
instead of 'a' when it is the first item. Requested during beta
testing last year....
When gold isn't first ('sortpack' false, or custom 'inv_order[]'),
it uses the next letter in sequence instead of '$', otherwise it
would be the only item out of sequence.
Change the sortloot option to use qsort() instead of naive insertion
sort. After sorting, it reorders the linked list into the sorted
order, so might have some subtle change(s) in behavior since that
wasn't done before.
pickup.c includes some formatting cleanup.
modified:
include/extern.h, hack.h, obj.h
src/do.c, do_wear.c, end.c, invent.c, pickup.c
This fixes a bug where the hero could accidentally donate the contents
of their bag to a shopkeeper if they put it in another bag on the shop
floor that also belonged to the hero. To reproduce:
1. Drop a sack on the floor, but don't sell it.
2. Get another sack and put in hero-owned objects.
3. Put the sack with objects into the sack on the shop floor.
4. Take out the sack with the objects from the sack on the shop floor.
The shopkeeper will claim you owe them for the objects in the sack, and
view the contents of the sack will show them as belonging to the
shopkeeper.
This fix is what those previous fixes for `SELL_DONTSELL` were for.
Based on DynaHack commit f91ce0b (Fix billing/credit when hero nests
their containers on a shop floor) by me.
"Looting many containers via menu cannot be stopped". When the
player uses #loot command at a location with multiple containers,
a menu of which ones to loot is presented and player can pick any
or all of them. But if you terminate the looting of a particular
container with ESC, it goes on to the next selected one rather than
stopping the loot action because that's what the 'q' choice does.
The simplest fix would be to allow choosing only one container
from the "loot which?" menu, but this retains the ability to loot
multiple containers on a pile in one turn. It makes looting
stoppable by extending the ":iobrsq or ?" prompt, adding 'n' for
"next container" and changing 'q' from "done with this container"
to "done looting" (with ESC still a synonym for 'q'). When just
one container is being looted, or when on the last of N containers,
'n' is not shown but is still accepted (and treated as 'q').
Also, use_container() was using a menu for ":iobrsq" if player had
menustyle set to Full when it was intended to be for Partial (name
confusion...). This switches Partial to use menu for loot action,
and leaves Full with that since that's how 3.6.0 has been behaving.
Traditional and Combination use the prompt string and single char
response.
Reported directly to devteam, with patch: tipping corpses out of an
ice box wasn't restarting their rot timers, producing corpses that
would last indefinitely.
Putting gold into a hero-owned container on a shop's floot gave credit
for the amount of the gold but also set the gold object no_charge, so
it could be taken out without taking away the credit. Then put back
in and taken out as many times as the player liked, doubling the gold
each time until the shopkeeper was out of cash.
I think the proper fix would be to avoid giving credit instead of not
marking the gold no_charge, but that would require multiple additional
changes so I took the easy way out.
Most of the changes to pickup.c are reformatting that it escaped prior
to release. The changes to shk.c are cosmetic and not part of the fix.
Somewhere along the line I started removing redundant parentheses from
return statements, but only in files that needed continuation fixups
so it's not comprehensive.
Add macros W_WEAPON and W_ACCESSORY, similar to existing W_ARMOR, bitmask
of all the relevant worn bits. Just for code readability; there should
be no change in behavior.
Also, reformat the "ugly checks" portion of getobj(). Slightly better
readability and fewer continuation lines, but only a modest improvement.
rather than always use a menu. Only affects menustyle:traditional and
can be overridden at the time by using the 'm' prefix before the #tip
command.
When using the menu, add an explicit pick-from-inventory choice. The
behavior there stays the same: ask about inventory if no floor container
is chosen.
If there is more than one container, the #tip command will show a menu;
if there's just one container, prompt for tipping.
As per Boudewijn's suggestion, remove the superfluous
"There is a container here" message.
'Du' in a shop was listing hero-owned containers that didn't contain
any unpaid items. At least one unpaid item must be carried; bug
manifested iff one or more unpaid items followed the container in
the invent list.
Recently revised allow_category() was using count_unpaid() for
container contents incorrectly, inadvertently checking the rest of
inventory after the container in addition to its contents.
I'll push a formatting guide at some point. There may still be
outstanding changes, but please feel free to resolve those as you arrive
a them.
To the best of my knowledge, there is no changes to the actual code
content, but the formatter does have the occasional bug. If you run into
an issue, please fix it!
Fix filtering used by the 'D' command, and a few other activities that
allow both object class filtering and bless/curse state filtering, so
that when both class(es) and state(s) are specified, objects need to
match both rather than either. D?C will present the player with cursed
scrolls to drop rather than all scrolls plus all other cursed objects.
This also fixes another instance when gold could end up with its bknown
flag set.
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.
Instead of just "while helpless", the death reason will tell
more explicitly why the player was helpless. For example:
"while frozen by a monster's gaze"
