Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nested containers and fast pickup via volume assignment #34678

Closed
FeepingCreature opened this issue Oct 12, 2019 · 3 comments
Closed

Nested containers and fast pickup via volume assignment #34678

FeepingCreature opened this issue Oct 12, 2019 · 3 comments
Labels
<Enhancement / Feature> New features, or enhancements on existing Game: Mechanics Change Code that changes how major features work (S3 - Duplicate) Bug that is duplicate of another one

Comments

@FeepingCreature
Copy link
Contributor

FeepingCreature commented Oct 12, 2019

Problem description

Containers such as duffel bags increase the available volume of your character, but also add encumbrance. As such, it would be useful to be able to quickly drop them and pick them back up before and after combat. However, treating bags as containers that can be opened and have items removed and inserted, such as the Kevlar vest, would make inventory management too awkward.

Proposed solution

Items gain a new internal field indicating the parent container that contains them. When the parent container is moved, all nested items are also moved with it, for free, without losing their parent. (Their encumbrance is accounted for by the parent container's encumbrance.) When picking up an item that has child items in the same inventory, the child items are likewise moved for free.

Additional notes

I'm calling this "volume assignment" because items are assigned to the item which provides the volume that contains them.

It would be logically cleaner to represent contained items as a list of children in the surrounding container. However, this would require all code that handles inventories to be changed. Using a parent field allows for a gradual introduction.

The ability to assign items to containers would be handy, but will not be necessary for the usecase of divesting yourself of encumbrance before combat.

There is no need to represent this in the inventory UI, though it could be done by a gray right-aligned text in the inventory stating the container. Indentation is less useful in the player inventory, because the containing inventories will usually be [W]orn.

When picking up items, the default sort mode should show contained items indented under their parent container, similar to Dwarf Fortress.

Proposed implementation tasks

Each of those tasks could be handled in a separate PR.

  • add a parent container reference to items
  • assign items to a parent container on pickup, respecting that container's volume limitation
  • when item is dropped, drop child items as well, keeping parent assignment
  • when item is picked up, pick up child items as well
  • when item is destroyed, spill contained items into the surrounding inventory or the ground
  • show volume assignment in the player inventory
  • show volume assignment in the pickup inventory
  • add menu entries to [take out]/[put into] items.

Don't forget to assert that parent items are in the same inventory as the child item!

@ghost
Copy link

ghost commented Oct 12, 2019

Please refer to #3671

@FeepingCreature
Copy link
Contributor Author

FeepingCreature commented Oct 12, 2019

This issue is as far as I can see a different approach that is explicitly not based on logical nesting, ie. sub-invlets.

(Though the practical gameplay functionality is the same.)

edit: Basically I think my requirements for a solution to this are lesser (see the proposed implementation sequence), and allow for a gradual introduction instead of a monster PR. Not sure how that interacts with the bounty on #3671.

@Night-Pryanik Night-Pryanik added (P5 - Long-term) Long-term WIP, may stay on the list for a while. <Enhancement / Feature> New features, or enhancements on existing <Suggestion / Discussion> Talk it out before implementing Game: Mechanics Change Code that changes how major features work labels Oct 12, 2019
@kevingranade kevingranade added (S3 - Duplicate) Bug that is duplicate of another one and removed (P5 - Long-term) Long-term WIP, may stay on the list for a while. <Suggestion / Discussion> Talk it out before implementing labels Oct 12, 2019
@kevingranade
Copy link
Member

The difference you are proposing is an implementation detail, not a new feature, hence this is a duplicate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
<Enhancement / Feature> New features, or enhancements on existing Game: Mechanics Change Code that changes how major features work (S3 - Duplicate) Bug that is duplicate of another one
Projects
None yet
Development

No branches or pull requests

3 participants