Issue 2067: Inventory not paging

Topics: Developer Forum
Aug 24, 2006 at 4:02 AM
I've created an inventory task for this and attached it to the issue. Basically what I've done is created a list of 52 items using a-z and A-Z as invientory ids, and initalized there values to nothing. When an item is added, it takes up the first slot that is nothing. When an item is dropped, is sets that slot to nothing. When you display the inventory, it prints out every item that is not nothing. If there are more than 26 items, it prompts you to continue.
Aug 25, 2006 at 6:03 AM
I haven't seen this code, since it hasn't been integrated yet, but why are we initializing and allocating 52 items if the character only has 1 item? Why aren't we just using a List(Of InventoryItem)? What's the benefit of pre-initializing and allocating the memory for 52 items?
Aug 25, 2006 at 12:47 PM
Currently the inventory displays in two ways.

The first way is the "kitchen sink" way that displays everything, page after page (at least that's the intent.)

The other way is to display only the item types requested. For example, when the character selects "right hand" then only items that are equippable to a hand slot would be displayed, just like only footwear would be displayed if the player selected "feet."

Semi-unrelated note: Identical items "stack" whenever they are added to the inventory. Not all items that appear identical actually are though, and these items should be listed separately.
Aug 25, 2006 at 2:16 PM

I find initallizing it 52 items with the letters as keys a little easier to deal with, rather then assigning the keys dynmically each time. The advantage to this as well is it limits the amount a hero can carry. Until items are giving weights, and the amount carried is limited by weight, I am just limiting it by number of items.

The other reason I did it this way is this: If the character presses the letter G, which list item is that? By using a kye,value pair, and having all keys alreadys set with values set to nothing when empty, I don't have to do any math or extraneous programming to figure out what item G may be referrening to.

Another reason: With a plain list(item) list, when an item is removed it's position in the list would change, meaning it's access letter would change as well. While this isn't bad per say, it could confuse users. By keeping the letters the same even after dropping an item, I get inventory behaviour that resembles NetHack much more closely.

My next steps are to modify the heros "back pack" to really just be a this class. I will then expand the class to allow for listing items only by item type (ie Weapons, Armor, Potions, etc). This is another spot where fixed keys for items will help.
For example, lets say my inventory looks like this:
a - Potion of Healing
b - Long Sword +1
c - Potion of Invisibilty
d - Leather Armor
e - Dagger

Now, without fixed keys, if I ask for a list of Weapons I may get:
a - Long Sword +1
b - Dagger
So, as a player, I quickly exit inventory, press d for drop, and then b to drop my dagger. But the system would compute b to be the second item in the list (with out lots of extra code), and actually drop my Long Sword +1

Now with fixed keys, my list of Weapons would display:
b - Long Sword +1
e - Dagger

So, if the player drops item e, they will really drop the dagger.

So now, the way the class is set up, it will take very little extra work to item filter by Item Type to the inventory. I can also handle all filter keypress events within the class as well, so it won't interfere with the main input.

Aug 25, 2006 at 3:57 PM
Actually, most (if not all) items already have weights assigned. I just don't have an encumbrance system in place to take advantage of them yet.

(Note to self... add encumbrance work ticket.)
Aug 25, 2006 at 3:59 PM
This discussion has been copied to Work Item 2583. You may wish to continue further discussion there.
Aug 27, 2006 at 4:36 AM

that all makes sense, and the dictionary of key-value pairs is definitely a good idea.