-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Conversation
"count" : 100, | ||
"reliability" : 8, | ||
"reload_time" : 80, | ||
"flags": [ "NO_RELOAD", "NO_UNLOAD" ] |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
I don't like the idea of changing the drop leg pouches purely to ammo pouches. |
I'm going to second this. |
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, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"to_hit" is optional
The current values look good for such an application. |
Better name than drop leg ammo pouch? |
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. |
Rebased against master as there was a merge conflict with #14949 |
"material" : ["cotton", "null"], | ||
"volume" : 1, | ||
"warmth" : 0, | ||
"phase" : "solid", |
There was a problem hiding this comment.
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" ] |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
* INVENTORY_HANDLING_FACTOR * MAP_HANDLING_FACTOR * VEHICLE_HANDLING_FACTOR
Ah, interesting. |
// @todo handle unpacking costs | ||
// @todo account for distance | ||
|
||
mv += dynamic_cast<player *>( &ch )->item_handling_cost( *what ); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
Found problem during testing, working on fix |
Oh? o.o |
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 |
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 toitem_location
and*::visit_items
sufficient to implement this: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 viaitem_location::obtain
.The above screenshot demonstrates this functionality:
STANAG magazine (30)
is contained bydrop leg ammo pouch
and worn byCharacter
item_location::describe
usesCharacter::find_parent
to help determine the container namegame::reload
usesitem_location::obtain
to unpack the item to the base of the inventoryplayer::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 containeritem_location::describe
can optionally return the location relative to the playeritem_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 movestl;dr
Demonstrates a wearable ammo pouch from which you can reload