Overloaded quiver issue fixed in r1827

[bron]

> Allowing people to put objects back into chests.
> It would be useful for ironman characters

I've thought about this as well. It would be very useful in an ironman to be able to stash things like !*Heal* or ?Banish into a "strongbox" where they are not accessible (can't be used like items in the backpack), but can't be destroyed either (not vulnerable to fire, frost, etc.). To avoid giving people extra inventory, the strongbox would occupy an inventory slot, and could only hold one stack of item(s). This would give you the same inventory space as now, except you'd have the option of keeping something safe but unavailable. [In a non-ironman game, you'd just put the item(s) into your home.]

[zaimoni]

I only have one exception. Allowing people to put objects back into chests. Chests should never stack and the weight is the chest weight plus the objects inside. The only way to get stuff out of the chest is to drop it and open it. It would be useful for ironman characters. However, I think this is pretty difficult to implement based on the way chests are handled.

Actually, the problem for all of this is the object representation in *bands.

[buzzkill]

> Allowing people to put objects back into chests.
> It would be useful for ironman characters

I've thought about this as well. It would be very useful in an ironman to be able to stash things like !*Heal* or ?Banish into a "strongbox" where they are not accessible (can't be used like items in the backpack), but can't be destroyed either (not vulnerable to fire, frost, etc.). To avoid giving people extra inventory, the strongbox would occupy an inventory slot, and could only hold one stack of item(s). This would give you the same inventory space as now, except you'd have the option of keeping something safe but unavailable. [In a non-ironman game, you'd just put the item(s) into your home.]

This is a good idea. The sheer weight of larger chests makes it prohibitive for many characters without a speed decrease. Furthermore, requiring the chest to be dropped to access it's contents, make it so cumbersome to use, that it would not suffer widespread use/abuse. I'd add, that the while content's of the chest would be safe from damage and theft, there should be some (really small) possibility of the chest itself (depending on type), and it's contents being destroyed (by very powerful attacks).

[PowerDiver]

Actually, the problem for all of this is the object representation in *bands.

It would be fairly easy to implement a scheme where you put the chest in your pack, then load it, and when you want something you have to empty the chest entirely. That wouldn't require messing with the object structure or creating any linked lists. It would just be mucking with variable sized inventories, which while a little painful would be a lot more feasible.

I have no opinion whether it is a good idea, but I think that's how a first draft should be implemented.

[zaimoni]

It would be fairly easy to implement a scheme where you put the chest in your pack, then load it, and when you want something you have to empty the chest entirely. That wouldn't require messing with the object structure or creating any linked lists.

I don't have a visual for what this pseudocode would be. To put thing mildly, slot suppression (e.g., how Zaiband makes savescumming enchanting armor for money boring) took five tries to get right for stores; I don't want to think about how unmaintainable the corresponding code for inventory would be.

It would just be mucking with variable sized inventories, which while a little painful would be a lot more feasible.

I have no opinion whether it is a good idea, but I think that's how a first draft should be implemented.

Variable-size inventories aren't that bad technically (moving the equipment slots before the pack is a rote change), but it throws off game balance impressively and gives me pause in how to manage the display.

[PowerDiver]

I'm using 1847 and am having occasional poor behavior wielding into a used slot when the pack is full, even using only a couple of quiver slots. Do you have a guess what the problem is, or do I need to track it down myself?

My only macro these days is "w-aw-a" so presumably I do this a lot more than anyone else.

[d_m]

I'm using 1847 and am having occasional poor behavior wielding into a used slot when the pack is full, even using only a couple of quiver slots. Do you have a guess what the problem is, or do I need to track it down myself?

My only macro these days is "w-aw-a" so presumably I do this a lot more than anyone else.

I think this is a bug I'm working on. I'll explain the known one and you can see if it matches what's happening.

If you wield an item from the floor with a full pack, the item you were wielding should be dropped (which is what used to happen). Instead, it is getting added to the pack and the "last" item in the list is being dropped.

The reason this happens is that I am using the "pack sorting" code to also figure out how many pack slots are lost to the quiver, which (I think) means that I am sorting the pack earlier than it used to be sorted. Previously, I think the unwielded weapon went into the last slot (the INVEN_PACK slot) which would then cause it to be dropped when the pack size was enforced.

Does this seem plausible?

[PowerDiver]

I think this is a bug I'm working on. I'll explain the known one and you can see if it matches what's happening.

If you wield an item from the floor with a full pack, the item you were wielding should be dropped (which is what used to happen). Instead, it is getting added to the pack and the "last" item in the list is being dropped.

The reason this happens is that I am using the "pack sorting" code to also figure out how many pack slots are lost to the quiver, which (I think) means that I am sorting the pack earlier than it used to be sorted. Previously, I think the unwielded weapon went into the last slot (the INVEN_PACK slot) which would then cause it to be dropped when the pack size was enforced.

Does this seem plausible?

I suppose so. I thought it was something else because of its frequency, but maybe that was just a function of what was in my pack at the time.

[d_m]

The issue with wielding from the floor while your pack is full has been fixed in HEAD.

At this point all issues with the quiver code that I know of have been fixed.

[Psi]

The issue with wielding from the floor while your pack is full has been fixed in HEAD.

At this point all issues with the quiver code that I know of have been fixed.

Teeny, tiny little bug. Unid'd stuff in the quiver does not get id'd on death (ie when checking your inventory after you die).

[PowerDiver]

Another bug. I autopickuped a small stack of just-fired bolts, expanding the quiver to use an extra slot, dropping the last item from my pack.

[d_m]

Another bug. I autopickuped a small stack of just-fired bolts, expanding the quiver to use an extra slot, dropping the last item from my pack.

I guess the correct behavior here is a message that you can't auto-pickup the ammo because your pack is full?

[PowerDiver]

I guess the correct behavior here is a message that you can't auto-pickup the ammo because your pack is full?

That seems right.

I want to pickup the part of a stack that would fit into the quiver, but that is inconsistent with the way stacks are treated outside the quiver. I guess this is a separate issue.

I also had some buggy behavior picking up ammo inscribed f0 that did not move to slot 0. Maybe I wielded it from the ground? If I see it again and detect a pattern I will let you know.

[d_m]

Teeny, tiny little bug. Unid'd stuff in the quiver does not get id'd on death (ie when checking your inventory after you die).

Fixed in r1852.

[PowerDiver]

Another related issue. In 1851 if I take off equipment with a full pack, the item is placed in the pack and then the last item in the pack is dropped. Instead, the item removed should be dropped.

This behavior is different from wielding off the ground.