Every time I want to implement something item related, I see two solutions:
[ul][li]Use item IDs to make it work[/li]
[li]Invent a horrible workaround that would take way too much work to be worth it and would require significantly more maintenance[/li][/ul]
This happens a lot, so I see a lot of need for item IDs.
Crafting reworks, crafting UI reworks, “continuous” crafting (including constructions, like chainsawing trees), remember reload option, “eat again from the same stack” option, throwing UI rework that doesn’t require selecting the item every time and doesn’t break constantly due to picked up items having a “preferred” tag, zombies “picking up” their worn clothes on rez, container assignment, NPCs caching seen items, player getting a pseudo-safe-mode trigger on seeing a wanted item, and few more I forgot right now.
Item IDs are the right thing - elegant and usable. Every option I listed above requires a workaround for lack of IDs (if it is at all possible without them). Why work around the problem instead of fixing it?
Even if you do need a gun that is also a container (???), you can just have the gunmods system only integrate contents that are marked as installed gunmods, it's trivial to do.
That was mostly just an example of how is “contents” vector used.
If you want more serious problems:
[ul][li]Many display/interact functions assume container has only 0 or 1 contents or has limited content types. Allowing arbitrary containers would results in containers randomly becoming “edible” (first item is food), colored as rotten/filthy and so on.[/li]
[li]Active item processing assumes only 0 or 1 contents[/li][/ul]
$ grep "contents\.front" -r src | wc -l
107 lines that assume contents are 0 or 1 elements.
Not all of those are problems, but all of those need to be handled in some way.
And that’s just scratching the surface. Many inventory handling functions would need to be rewritten from scratch to handle recursive items without getting “too recursive”. For example, everything that uses the “inventory” class, which would most likely become implicit.
Third is a non-issue, Items would be assigned to containers at all times, that's the whole point of the system.
A system like that would most likely require tedious adjustments pretty often. Because sooner or later (most likely way too soon), someone would want to add different move costs for drawing items from pockets and backpack, but not want to add a sane UI or automatic system to make sure knife and pistol go into pockets and not duffel bags, while scrap goes into duffel and not pockets.
It is probably doable well, but I’ve seen enough realism to warrant being more skeptical than just “sure, but I won’t be the one implementing it”. Double negativity points and warranted skepticism when said realism is called “sense” or “logic”.
I really do want to be proven wrong here, I honestly do.
Not interested, it doesn't make any real progress toward a complete solution.
Starting with sane UI would be a great sign that the whole thing won’t become an inventory shuffling simulation that only exists to make the author feel good about his PR being merged but a usable addition to the game.
If written without terrible hacks, changing the UI to use a different container system would be just 20 lines or so.