Viewing Issue Simple Details Jump to Notes ] Wiki ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0009322 [DCSS] Bug Report minor always 2014-12-12 23:46 2014-12-16 22:36
Reporter Sandman25 View Status public  
Assigned To wheals
Priority normal Resolution done  
Status closed   Product Branch 0.16 ancient branch
Summary 0009322: item_slot displays "!bad item"
Description I have
item_slot ^= ring of flight:F
in my init.txt.
When I equipped an unknown ring I got
F - a ring of flight (right hand)
a !bad item (cl:100,ty:0,pl:0,pl2:0,sp:0,qu:0)

I tried to reproduce the error (this time using item_slot ^= ring of poison resistance:p), it happened for ring of poison resistance too. The error does not happen if I don't have item_slot for the item.
Additional Information
Tags No tags attached.
Attached Files ? file icon fix-itemslot.patch [^] (22,809 bytes) 2014-12-13 20:54 [Show Content]

- Relationships

-  Notes
Sandman25 (reporter)
2014-12-13 04:02
edited on: 2014-12-13 04:07

The bug is caused by code which calls set_ident_type, the code does not expect inventory index to change after the call.
For example, for reading a scroll lines 3145+ in are:

    set_ident_type(scroll, ID_KNOWN_TYPE);
        mprf("It %s a %s.",
             you.inv[item_slot].quantity < prev_quantity ? "was" : "is",

As you can see item_slot still references old inventory slot.
That's why I was forced to change read/quaff/equip logic in my patch.
The bug can probably be fixed by removing optimization and using instead of item_slot.

Sandman25 (reporter)
2014-12-13 20:54
edited on: 2014-12-13 20:59

Please see fix_itemslot patch. Tested quaffing potions, reading scrolls, equipping jewelry, identifying potions, identifying scrolls, identifying jewelry, Ashenzari with jewelry, death (inventory items stay in old positions after death).
Remaining problems:
1) scroll of remove curse is not moved to required letter after joining Ashenzari (it looks like you.type_ids[basetype][subtype] = setting is what triggers the identification, it would require a new loop over the whole inventory, probably I am wrong here)
2) Scrolls and potions have different behavior, one of them is removed from the inventory before ID/swap, another after ID/swap. My first patch was taking care of the difference but here we have a generic approach and I am not sure we want to add a new parameter for swapping, it is a minor issue anyway)

PS. Forgot to mention. I read in Wikipedia that C++ references cannot be reseated so I had to use pointers, hopefully it is correct approach.

wheals (administrator)
2014-12-14 02:59;a=commitdiff;h=5701f100ccae [^] should fix the problems; tested it with identifying with scroll and with use of several item types.

I went with a solution of having auto_assign_item_slot() be an obligation of the caller of set_item_flags() since it just seemed easier to do it this way, since it allowed postponing the reassignment until the end of the function calling it. It also fixes the problem of 0000002, since both should swap slots as the very last thing.
Sandman25 (reporter)
2014-12-14 03:45

Sandman25 (reporter)
2014-12-15 02:07

The item is not assigned if corresponding slot is already busy. Is it expected behavior? That kind of removes the whole point since it is very likely that both "f" and "c" will be busy when player finds first ring of protection from fire/cold. Is it possible to remove second condition in
if (isaalpha(i) && !you.inv[letter_to_index(i)].defined())
in auto_assign_item_slot?
wheals (administrator)
2014-12-15 02:24

I wasn't sure; this behavior is like spell_slot. Admittedly, spells /are/ different because they can't be unidentified. However, you can still list a bunch of potential letters (like cC or fF) for item_slot. Additionally, someone might want this behaviour; for example, item_slot ^= scroll:ABCEDFGHIJKLMNO if they want scrolls to be all be on the early capital letters.

In general, I'd rather err on the side of adjusting too little rather than too much, since using =i is easier than going to the rcfile to change your options. I do see your point, so I won't resolve yet.
Sandman25 (reporter)
2014-12-15 02:44
edited on: 2014-12-15 02:48

Is it possible to introduce a new setting like auto_swap_items (false by default) which would control presence of the second condition? I would set it to true and be happy while everyone else can use the default. I can create a patch if needed (though I learned that unsurprisingly my patches are bad usually)

wheals (administrator)
2014-12-15 02:50

That could be good, I'll work on coding it up.
wheals (administrator)
2014-12-16 17:54

I decided to not go with another option after all; instead, items don't displace another item if the latter also matches the regex. This should allow using item_slot for the example of scrolls that I gave, and also not spam messages about swapping if e.g. you pick up and then drop two wands of hasting if they are mapped.
wheals (administrator)
2014-12-16 17:54

Specificially, I did so in;a=commitdiff;h=24051f7046d3. [^]
Sandman25 (reporter)
2014-12-16 22:35


- Issue History
Date Modified Username Field Change
2014-12-12 23:46 Sandman25 New Issue
2014-12-13 04:02 Sandman25 Note Added: 0028062
2014-12-13 04:03 Sandman25 Note Edited: 0028062
2014-12-13 04:04 Sandman25 Note Edited: 0028062
2014-12-13 04:07 Sandman25 Note Edited: 0028062
2014-12-13 20:54 Sandman25 File Added: fix-itemslot.patch
2014-12-13 20:54 Sandman25 Note Added: 0028064
2014-12-13 20:56 Sandman25 Note Edited: 0028064
2014-12-13 20:57 Sandman25 Note Edited: 0028064
2014-12-13 20:59 Sandman25 Note Edited: 0028064
2014-12-14 02:59 wheals Note Added: 0028065
2014-12-14 02:59 wheals Status new => resolved
2014-12-14 02:59 wheals Fixed in Branch => 0.16 development branch
2014-12-14 02:59 wheals Resolution open => done
2014-12-14 02:59 wheals Assigned To => wheals
2014-12-14 03:45 Sandman25 Note Added: 0028069
2014-12-14 03:45 Sandman25 Status resolved => closed
2014-12-15 02:07 Sandman25 Note Added: 0028071
2014-12-15 02:07 Sandman25 Status closed => new
2014-12-15 02:07 Sandman25 Resolution done => reopened
2014-12-15 02:24 wheals Note Added: 0028072
2014-12-15 02:44 Sandman25 Note Added: 0028073
2014-12-15 02:45 Sandman25 Note Edited: 0028073
2014-12-15 02:45 Sandman25 Note Edited: 0028073
2014-12-15 02:46 Sandman25 Note Edited: 0028073
2014-12-15 02:48 Sandman25 Note Edited: 0028073
2014-12-15 02:50 wheals Note Added: 0028074
2014-12-16 17:54 wheals Note Added: 0028083
2014-12-16 17:54 wheals Status new => resolved
2014-12-16 17:54 wheals Resolution reopened => done
2014-12-16 17:54 wheals Note Added: 0028084
2014-12-16 22:35 Sandman25 Note Added: 0028089
2014-12-16 22:35 Sandman25 Status resolved => closed

Mantis 1.1.8[^]
Copyright © 2000 - 2009 Mantis Group
Powered by Mantis Bugtracker