With this new pocket system, Packmule seems to be doing nothing to alter storage capacity, is this an issue that people were aware of?
1 Like
2 Likes
Oh. Not actual size too? Because itās an actual thing. Some people are disorganised, some less so. Some (ahem, I wonder where I get this experience 
) will squeeze in stuff and make boxes/bags bulge. Downsides? Can damage storage containers. Upsides? If itās not sand, Iāll fit more it.
[Edit]
Had a think about it after reading the github on it.
When does the code check container size? As, can we just section off the two instances to avoid conflicts? As far as I can think of, the times when the game/npcs/etc check the containers, it can always be the default size, and when the player opens inventory, it can always be the bonus/decreased size?
Though, Iām guessing the game might check container size every tick? From experience, it only checks the container when the player interacts (the āfood frozen/falls out/liquid spills/etcā bugs only happen once the player picks up/interacts with the objects) and when it spawns, or when an NPC interacts with it.
As far as I can tell, spawning a container and an NPC interacting with it, could always reference the default container size. Then when a player interacts, if having a trait, references the trait size (or default + trait). I donāt see a problem with this logically. But it might have existing code that prevents this method?
I cannot think of an actual time/logical interaction in the game where the game would need to store or reference if a container is packed by the player. Can it not always assume any container the player is interacting with can have the bonus added (or debuff if disorganised trait), and any container not being interacted with to stay steady state, but if interacted with by the NPCs/game engine to be the default size?
This would cause the player to drop things if disorganised on opening a container normally packed, or a packmule organised container to drop things if an NPC without the trait interacts with it. Actually, that would then be a feature not a bug! (assuming it donāt cause segfaults ).
Thinking about it, having a size increase doesnāt make sense. Not that weāre saying that there is not the ability to pack things more efficiently or less efficiently, but rather that we rarely model the player deliberately doing things less efficiently in the first place. The way I see it, the turns spent rooting around in your inventory relate to the time your character takes to pack and unpack that bag āproperlyā to maximize the space. A poor packer can still perfectly fill a bag, theyāll just take longer. Same things reflected in making things take longer to take out, they didnāt pack the bag as well so its harder to slip out that quick item there, and harder to reorganize to make space to fill it in.
Speaking from the meta, I am also ok with the size change reduction if only because packmule was practically a must pick. Now with the pocket system, I imagine inventory granularity will allow us to generally increase carrying capacity overall, without creating scenarios like pants full of aluminium kegs. So carrying utility incidentals should be much easier without impacting your looting space. So the need to eke 40% extra capacity out to allow a combat load in an unencumbering setup should not be as needed. IRL thereās lots of exceptionally low encumberance items such as a utility/battle belt that we can accurately represent without being able to store a whole rifle in them.
We are not. See Tetris. See packing for aircraft luggage. You can pack efficiently or not. The game currently assume perfect packing in all instances. Packmule/disorganised assumes imperfect packing. And adjusts the possible volume for holding items accordingly. The game currently has the perfect volume as a baseline, and abstracting that, packmule is ābetter than perfectionā in effect. But only because we donāt apply a -5 or -10% packing restriction to normal characters.
Packmule can be closer to the ideal packing, normal could be slightly less, and disorganised less than that. Assuming it is workable in some part in code (it is, but at a risk of abstracting too much, or conflicting with other changes, unless all edge cases can be solved as I hope 
).
But I do agree, packmule and disorganised would also have different time penalties or benefits.
1 Like
I can agree with you, the game currently assumes perfect packing, and packmule trait assumes imperfect packing, and adds perfection.
So we can either conclude āwell packmule doesnāt make much sense thenā or we can rebuild the entire inventory alongside handling myriad edge cases to avoid weirdness like āThis drum can store 100L of water, or 110 1L bottles of waterā. You can shuffle the numbers to be 10% bonus or 10% malus but you still have to flag at some point āexcept this itemā, and the nested inventory nature is going to make that behave weird however you do it.
1 Like
AFAIK packmule never did liquids. Does the new system not allow definitions in the code to avoid putting a buff/debuff on containers only of sort ābox/bag/pocketā?
As said, there may be no edge cases. As the two systems might be seperate. In which case, it only requires the games with packmule traits in them, to then not assume perfect packing (apply a base % decrease or increase to box/bag/pocket size). It never even applied to furniture storage (cupboards or vehicles). Can we also only apply it to boxes, bags and pockets?
OR we assume the āthis bag is 10L storageā is the ideal storage/player assessed storage, not the actual size of the bag.
Abstractification works that way. Itās not an absolute or totality. It is ā10L bagā, but that phrase and coding is abstracted to āthe player reads this as a bag 10L bigā or āa player reads this as a bag able to contain up to 10Lā. While the code is very specific, our decisions on how to allow the player to interact with it are flexible. 
Iām more than well aware that code is very specific and our decisions are flexible, I am a programmer by trade and a gamedev by hobby. The latter part (about decisions are flexible) is my key focus here, your looking at making serious, potentially confusing, conflicting and edgecase-prone changes to a system to support a previous trait that didnāt really make a great deal of concrete sense, but could be argued strongly in one direction or another based on what assumptions we make about the game, IE perfect first or imperfect first.
Just as an example edgecase for a 10% malus, lets say we implement a āmagazine pouchā belt item. Just a spare canvas mag pouch, a perfect fit for a stanag, but you could make like a marine and fill it with crayons. With that 10% malus, the magazine pouch is now too small to fit a magazine. If you exclude this pouch from the malus, you now have items that you need to explain ābut not this guyā. If you exlude single-items from the malus then you have to explain that to people, and more edge cases. If you go the other direction with a 10% buff, you have people fitting the same containers inside of themselves, or packing extra items into storage containers describe as a fit for a given item, IE a single mag pouch. If you make all those items locked down and only accepting limited items, then you lose most of the strength of a dynamic nested inventory system, when your being told arbitrarily ācanāt put a flashlight in this magazine pouchā even when its just a fabric pouch.
Rather than go down that rabbit hole, this whole āmake it affect speed thenā steps away from the old system and looks to how to make it relevant to the new system. Maybe a rename is in order, thinking of āDexterousā from Project Zomboid, which is an inventory speed trait.
1 Like
How about rather than working with a fixed volume bonus/malus, you work with a stacking penalty based on the number of distinct items in the pack? This would straightforwardly exclude single-purpose pouches, magazines, liquid bottles, etcetera since is only a single item or bulk good inside. A 20L backpack might contain 9 2L bottles, but only 80 200ml ones. Single items donāt get packing penalty.
In this case uniform stacks get tricky though. Bullets in a magazine should probably be exempt, but loose bullets in your pack less so.
1 Like
Then donāt. Apply the bonus/deficit to ācardboard box and backpackā only. And yes. It may mean a NPC/player character with a ādisorganisedā trait cannot fit a magazine in the backpack pocket, because they cannot. As a game balance decision, we would be deciding they cannot fit that in there in that instance. That would be a feature, not a bug.
If applying only to cardboard boxes, backpacks and any other specific items to included, then I donāt see where that edge case would ever appear that would not actually be part of the debuff/deficit.
1 Like
Except now your āgame balanceā decision is doing things that are logically inconsistent, and violate the general CDDA design principle of āif it works in real life, it works in the gameā by special casing a specific category of inventory items for no other reason than to justify a trait that already exists on the back of a shaky, debatable premise.
All of that is a significant reach to make, compared to just changing the trait to make sense in the new inventory environment.
Regardless, the change to inventory speed has now been merged in as the function of the trait, so this debates fairly academic unless you want to pick up the reigns to develop and propose a merge of the change yourself.
Iām happy to discuss game mechanics and coding logic. I can just about edit a .json file, but can walk myself through logical operators.
So is it academic to discuss? Yes. Is it pointless? Iād think not.
All of that is a significant reach to make, compared to just changing the trait to make sense in the new inventory environment.
Yep. But the discussion was not to remove it entirely because it does not fit into the current code, but to modify it as a speed buff instead. IMO that also makes no sense. As thatās an awareness trait, not a packing size/organisation trait. (Though disorganised fits the description, packmule does not)
Except now your āgame balanceā decision is doing things that are logically inconsistent
IMO it is not. Pushing more into a backpack is not logically inconsistant. Into a bag or putting too much over and in a box. People do it all the time. Iāve not seen a game āsimulateā this other than a flat % increase or pure physics (2d, 3d or VR) based. It would be interesting to see it in other games and with other mechanics. Many many MMOs offer per bag/type/item buffs and debuffs depending on character ability/etc.
So Iām all for changing the description to āorganised/unorganisedā instead. And revisiting the option to over pack, risk dropping, or bulging containers at another time. I mean, this games got temperature mechanics and many others, so Iād not say never to the developers adding something else in the future (for example IIRC Kevin is working on LOS and raytracing lighting systems, that IMO Iād of never of guessed CDDA would get!).
Then by all means, go ahead and start developing the change. I have a feeling this conversation solely looping between you and I is not going to go anywhere, you seem to either be missing the point I am making or not understanding it, and I am clearly doing the same with your side of the argument.
Pushing more into a backpack is not logically inconsistant. Into a bag or putting too much over and in a box. People do it all the time
This is actually exactly why it doesnāt make sense to me. People do it all the time. Its not some special trait to be able to take advantage of all the space in a bag. Some people just take longer to do so than others. As you said, people do it all the time.
At a certain point with open source projects, nothing speaks more than seeing it in action, So go ahead and show us how this can be implement in a logically consistent, reliable way. Because despite your claims to the contrary, Iām still not seeing it as a trait based thing. Overpacking, bulging containers, etc is still a different beast than āI naturally fit more stuff into thingsā.
hahahaha. Yes, people also gorge on food all the time, or insist on eating at a table, but those are things we added as a trait.
As said, Iām happy to discuss the logic, or mechanical applications. But I see there are certainly preferences on if it should be added or not. If someone is honest with me and says they donāt want it in, then thatās fine. But donāt say itās because of logical inconsistencies, if itās not, or mechanical if itās possibly to apply to just one mechanism (I agree itās not my place to say how to program, but this is a forum, and thus open to discuss what may or may not be added or removed).
Iāll defend your right to remove a feature/item, or decide programming a system is too much time/resources for too little gain with a hard line! But I wonāt build the idea that trying or knowing is too hard or impossible. That teaches the wrong ideas, and breaks communication.
Oh boy, a discussion on high heat about to burst into flamesā¦ Letās add oil to it 
!
I guess @TechyBen talks about something like the āWinston Freerās Puzzleā, just translated into real situations. It not actually ājust takes longerā, it requires a different way to even start with.
For some anecdotal evidence (probably more a reference point):
Iām one of those who can pack stuff really tight. Others ask me a lot of times how I can do this and I honestly have no idea, it just happens.
I can pack a luggage, a shopping bag or a cars trunk just more efficiently than, for example, my mother. This is not a question of time, as I fit in the same stuff and amount nicely, that she was unable to while trying for half an hour, in bare minutes.
That said, Iām not sure if it should be actually in the game as it was for a while now, be it for the reason that it may cause confusion or just that itās to niche for it to actually have this trait in the game.
Also, āPackmuleā seems a weird name for it anyway, as I would associate this term with weight carrying capacity, not additional space.
1 Like
Yep. Other possible sensible (low coding effort for the returns in gameplay results) options people have suggested (similar to your carry weight one), is to just use it as a buff to lower/increase back pack or carry encumbrance.
It would have an āabstractedā similar result, allowing players to carry more or less with certain character builds. While still being reasonably realistic/balanced.
An encumbrance modifier for packmule does make sense to me. Specifically Iād think about reducing or eliminating the penalty for wearing two backpacks or belts, rather than reducing the encumbrance of the items themselves.
1 Like
Iām actually a big fan of the idea of packmule and disorganized effecting the time it takes to access your items from your pockets and bags.
It may not be the nearly 100% desired trait it used to be, but I feel like those extra couple of seconds Pulling ammo or explosives out of your jeans could occasionally be an unsung lifesaver.
Cash cards have been upgraded to the size of those oversized checks you see at awards and whatnot. Now just imagine the size of the new atms! 
2 Likes