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

Further container logic [RDY] #14972

Merged
merged 19 commits into from
Jan 28, 2016
Merged

Conversation

mugling
Copy link
Contributor

@mugling mugling commented Jan 23, 2016

EDIT: rebased against master

This PR continues directly from #14949 which is not yet merged. There are 11 new commits starting with 09ff0fd. It contains extensions to item_location and *::visit_items sufficient to implement this:

ccda

This PR does not implement a UI for nested containers but does however provide some of the key functionality that would be required. Character::find_parent can be used to determine whether an item has a parent container from which it can then be recursively unpacked via item_location::obtain.

The above screenshot demonstrates this functionality:

  • STANAG magazine (30) is contained by drop leg ammo pouch and worn by Character
  • item_location::describe uses Character::find_parent to help determine the container name
  • game::reload uses item_location::obtain to unpack the item to the base of the inventory
  • Reloading then proceeds as normal via player::assign_activity

Implementation details:

  • *::visit_items is extended to also provide a pointer to the parent node
  • *::find_parent uses the above to find any parent container
  • item_location::describe can optionally return the location relative to the player
  • item_location::obtain fetches the item to the root of the character inventor and in doing so it triggers events, eg. item::on_takeoff and deducts the appropriate number of moves

tl;dr
Demonstrates a wearable ammo pouch from which you can reload

"count" : 100,
"reliability" : 8,
"reload_time" : 80,
"flags": [ "NO_RELOAD", "NO_UNLOAD" ]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why no unload? Can't you get rid of the belt and just use the ammo without it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Too easy to accidentally destroy your ammo belt. I was going to allow disassembly though.

@Coolthulhu
Copy link
Contributor

I don't like the idea of changing the drop leg pouches purely to ammo pouches.
It is an useful storage item that doesn't have an alternative. Ammo pouches should be a different item.

@Rivet-the-Zombie
Copy link
Member

Ammo pouches should be a different item.

I'm going to second this.

@mugling
Copy link
Contributor Author

mugling commented Jan 23, 2016

I don't like the idea of changing the drop leg pouches purely to ammo pouches.

I'll create a new type but before I do so are the JSON values about right?

"color" : "dark_gray",
"covers" : ["LEGS"],
"covers" : ["LEG_EITHER"],
"to_hit" : 0,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"to_hit" is optional

@Rivet-the-Zombie
Copy link
Member

I'll create a new type but before I do so are the JSON values about right?

The current values look good for such an application.

@mugling
Copy link
Contributor Author

mugling commented Jan 23, 2016

Better name than drop leg ammo pouch?

@Rivet-the-Zombie
Copy link
Member

How about 'leg ammo pouch' so we could then add other variants like 'chest ammo carrier'?

Or just call them 'ammo pouch' and 'ammo carrier' or whatever.

@mugling mugling changed the title Further container logic Further container logic [RDY] Jan 24, 2016
@mugling
Copy link
Contributor Author

mugling commented Jan 24, 2016

Rebased against master as there was a merge conflict with #14949

"material" : ["cotton", "null"],
"volume" : 1,
"warmth" : 0,
"phase" : "solid",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"phase" : "solid", is default value for optional entry

"holster_msg": "You stash your %s",
"max_volume": 2,
"draw_cost": 5,
"flags": [ "COMPACT_MAG" ]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why this flag is here? Do we need to have the same flag on a container and on a magazine we want to store? If so, it's better to announce it in docs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to have the same flag on a container and on a magazine we want to store?

Yes

If so, it's better to announce it in docs.

See 4842355. Is there anywhere else?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I saw the referenced note but I misunderstood it. Anyway, thanks for clarification.

Is there anywhere else?

No, I'm talking about exactly this place.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No worries, it's all a bit jumbled after rebasing

@chaosvolt
Copy link
Contributor

Ah, interesting.

// @todo handle unpacking costs
// @todo account for distance

mv += dynamic_cast<player *>( &ch )->item_handling_cost( *what );
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Btw. you can dynamic cast reference, no need to convert the value to a pointer first.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you sure this works on all compilers?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know, but The C++ Standard says so. That said, do you know any compilers that don't support it?

@mugling mugling changed the title Further container logic [RDY] Further container logic [WIP] Jan 25, 2016
@mugling
Copy link
Contributor Author

mugling commented Jan 25, 2016

Found problem during testing, working on fix

@chaosvolt
Copy link
Contributor

Oh? o.o

@mugling mugling changed the title Further container logic [WIP] Further container logic [RDY] Jan 25, 2016
@mugling
Copy link
Contributor Author

mugling commented Jan 25, 2016

Fixed in 3504233.

Previously reloading using the first item of an inventory stack and without a parent container could trigger the debugmsg "Tried to find item parent using character who doesn't have the item". The fix stops the loop iterating if the first call to Character::find_parent returns nullptr (signifying no parent).

@kevingranade kevingranade merged commit 3504233 into CleverRaven:master Jan 28, 2016
@mugling mugling mentioned this pull request Jan 29, 2016
@mugling mugling deleted the containers1 branch January 31, 2016 11:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants