Cataclysm-dda: Holster encumbrance weirdness

Created on 4 Dec 2016  路  6Comments  路  Source: CleverRaven/Cataclysm-DDA

Still trying to fully suss this out, but drawing and replacing a gun in a holster seems to duplicate it for encumbrance purposes. It seems to happen if you have another item on the other leg. Draw a pistol, put it back, and suddenly both legs now have the encumbrance of the holster. If you go into the clothing layering GUI you'll see the holster listed on both legs. Switching the holster away from the incorrect side usually fixes it.

I'm not exactly sure of the circumstances that cause it, I'm new enough to the game that debug testing isn't something I'm too familiar with. I think, but can't be sure, that the holster is defaulting to a certain side when drawn, and/or reholstered and if the holster is actually on the other side the holster gets switched without clearing its previous position. Switching sides then causes a resync.

<Bug>

Most helpful comment

@keyspace Thanks for bisecting.
Now I know what causes the bug. item_location::obtain() calls item::on_takeoff() which sets set_side(BOTH).

All 6 comments

I was actually just coming here to report this. This seems to happen with the other "sided" storage items. I replicated it with the ankle holster, scabbard and leg ammo pouch.

To hopefully make the cause more clear, this bug occurs whenever [a]ctivating the storage item whether or not you draw/sheathe anything. It also only occurs after the 'a' activate command. The items retain their sidedness when activating them after selecting them in the inventory.

Can reliably reproduce on latest git (353880c51bf78fbbc8b28b39287532b277e10844).

@RBrandon has the issue outlined best: a worn item loses its "sidedness" when activated EDIT: through the [a]ction menu.

"Sidedness" is not lost when activating through the [i]nventory menu EDIT: or the [E]at menu.


false lead snipped

Simple bisection shows this is a regression introduced in 3b32c42607e514d8bc6461a39a9a9dcbdf584af8 (PR #19367). That code has been, however, replaced by e1de5da (PR #19532).

Pinging @codemime, since they're most likely to know that code. (Sorry if this is excessive.)

Not sure if another false lead - here's some notes I took while debugging.


The fact that it's present is weird indeed - whether the item is used through [i]nventory or [a]ctivate menu, it passes through game:use_item(int pos).

If used via [i]nventory, pos is already set to the item index (e.g. -11).

If used via [a]ctivation menu, pos will be INT_MIN, and pos = loc.obtain( u ) will be called to obtain the item index.

Guess that somewhere in item_location::obtain() (or down the call stack), the item is touched.

@keyspace Thanks for bisecting.
Now I know what causes the bug. item_location::obtain() calls item::on_takeoff() which sets set_side(BOTH).

Was this page helpful?
0 / 5 - 0 ratings