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

Item length #40186

Merged
merged 13 commits into from
May 11, 2020
Merged

Item length #40186

merged 13 commits into from
May 11, 2020

Conversation

KorGgenT
Copy link
Member

@KorGgenT KorGgenT commented May 5, 2020

Summary

SUMMARY: Features "Implement item length"

Purpose of change

For item pockets, it's weird you can store a longsword in a tin can. So, the first of 2 ways to stop this is to implement a 'longest side' trait for items.

Describe the solution

  • implemented a "length" unit and appropriate conversion functions for mm, cm, meter, and km. additionally added one for converting volume to a "length" assuming the volume is for a cube.
  • added length attribute to itype and updated readers for units to properly read it in. additionally automatically calculate length if none is assigned, assuming the item is a cube. this should be pretty good for most use cases. liquids always return 0 length, so defining something in json for a liquid will not do anything. similarly for soft items. it shows on the iteminfo and uses the option for imperial vs. metric that was implemented in an earlier pr for character heigh display.
  • added a max length attribute to pocket_data so when you try to put a long item (example item is the pool cue) into a pocket that does not have sufficient length, you cannot. additionally calculates max length of item if not assigned to be cbrt(volume) * sqrt(2). i did not add a json example for pockets as of the time of writing this summary. maybe golf bags would be a good starting example. shows in the general pocket info screen in iteminfo.

Describe alternatives you've considered

putting swords in tin cans is pretty humorous, so probably that

Testing

spawned a plastic tub
image
and tried to place a pool cue in it
image
it did not fit.

Additional context

this pr is mostly all infrastructure work, so most items won't change, but some might. it will also be worth eyeballing the calculated lengths in game to sanity check the formula i used, and/or use that to denote items that need some hard quinting-at. also pinging @laveyanfiend because he's been asking about this feature

@KorGgenT KorGgenT added [JSON] Changes (can be) made in JSON [C++] Changes (can be) made in C++. Previously named `Code` Items: Containers Things that hold other things labels May 5, 2020
@ymber
Copy link
Member

ymber commented May 5, 2020

Items made entirely from soft materials should be handled differently here. The obvious option would be to ignore dimensions and assume you can fold them however you need but we might want a better model than that.

src/item_pocket.cpp Outdated Show resolved Hide resolved
@jbytheway
Copy link
Contributor

Items made entirely from soft materials should be handled differently here. The obvious option would be to ignore dimensions and assume you can fold them however you need but we might want a better model than that.

Presumably such items just won't get a length value? So long as length is not used for anything else, that shouldn't be a problem.

@mlangsdorf
Copy link
Contributor

At some point I will probably borrow "length" so that we can determine which melee weapons are "long" and incur penalties in tight spaces, and then it will matter that a bullwhip is 15' long but can be easily stored in a backpack. Probably the easiest solution at that point would be to add an explicit "weapon_length parameter" which defaults to "length". Even if that doesn't work, and in the meantime, I don't see an issue with soft items having no explicit length.

@KorGgenT
Copy link
Member Author

KorGgenT commented May 5, 2020

i didn't think of soft items. I can except them for now, but i do think we should have some kind of idea for limitation for them.

@KorGgenT
Copy link
Member Author

KorGgenT commented May 5, 2020

probably the green line makes more sense, as the member is called "longest_side" after all and is mostly used for being able to fit things into pockets.

@ghost
Copy link

ghost commented May 5, 2020

image
I shall update my tutorial on #37374 to reflect the longest_side math

@nexusmrsep
Copy link
Contributor

Question to think about regarding length: "Can I carry a gun sticking out of a backpack?" Technically it'd be possible to some extent IRL with some containers.
image

src/item_pocket.cpp Outdated Show resolved Hide resolved
@Mecares
Copy link
Contributor

Mecares commented May 7, 2020

Question to think about regarding length: "Can I carry a gun sticking out of a backpack?" Technically it'd be possible to some extent IRL with some containers.

Maybe allowing to stick out by less than a third or a quarter of the total length should be possible.

@kevingranade
Copy link
Member

This is segfaulting with this stack in the archery damage test:

test_archery_balance( "selfbow", "arrow_metal", "", "mon_turkey" );
\-> test_projectile.critical_multiplier = weapon.ammo_data()->ammo->critical_multiplier;

@KorGgenT
Copy link
Member Author

KorGgenT commented May 9, 2020

turns out the test was seg faulting because arrows were too long for the bows. woops.

"pocket_data": [ { "pocket_type": "CONTAINER", "max_contains_volume": "18 L", "max_contains_weight": "30 kg", "moves": 300 } ],
"longest_side": "900 cm",
"//": "The main section of the golf bag actually assumes things will stick out of it, but specifically contains them, so some extra wiggle room was added.",
"pocket_data": [
Copy link
Member

Choose a reason for hiding this comment

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

So new melee meta is going to be golf bag of weapons? :D

@kevingranade kevingranade merged commit 519e6bf into CleverRaven:master May 11, 2020
@KorGgenT KorGgenT deleted the item-length branch May 11, 2020 03:43
@kevingranade kevingranade mentioned this pull request May 11, 2020
if( value_ % 1'000'000 ) {
jsout.write( string_format( "%d km", value_ / 1'000'000 ) );
} else if( value_ % 1'000 ) {
jsout.write( string_format( "%d meter", value_ / 1'000'000 ) );
Copy link
Contributor

@olanti-p olanti-p May 19, 2020

Choose a reason for hiding this comment

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

Shouldn't this be 1000?
And all value_ % 1xxx checks be value_ % 1xxx == 0 to avoid e.g. formatting 1 as 0 km and 1000000 as 1000000 mm

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[C++] Changes (can be) made in C++. Previously named `Code` Items: Containers Things that hold other things [JSON] Changes (can be) made in JSON
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants