[CR] Implement item type slots for items to be of multiple types.

[BevapDin]

Item slots replace (partially) the specific item subtypes: instead of an item type being it_armor, it is now of the base itype plus an armor slot. The armor slot contains the properties that have previously been stored in the it_armor.

This allows all items types to have armor properties, as all item types can have an armor slot. Access to the armor slot is wrapped in the item class (as was access to members of it_armor).

The same is done for containers.

I added the armor slot to all bows in archery.json, so they can be worn without modifications, but I'm not a bow person, so this is very much open for discussion. I also added the armor slot the wearable containers.

See #4189

---

TODO: document the stuff

Some things to consider:

• I'd like to move the flags SEALS, WATERTIGHT, PRESERVES, RIGID into boolean properties of the container slot. They are of no use and no meaning outside of it (on non-container items).
• Similar for armor flags (especially the layer).
• Further separation into different slots: it_spoils (contains spoilage, so that non-food can spoil as well, may even contain a item type. hat it spoils into). it_spawns_in for the container the item spawns in (applies to ammo and food, but could be used for anything else as well).
• Splitting bionic difficulty into install difficulty (property of the CBM item), and removal difficulty (property of the installed bionic). This would allow different CBM items (with different size/rarity/spawn location) that also differ by the install difficulty but grant the very same bionic. For example a CBM item commonly found in doctors office with high install difficulty (intended to be installed by experienced doctors) and another item (same bionic) very rarely found (in outposts?) that is easier to install but might be heavy and bulky.
• Several item types use item::charges for the very same thing (chapters for books, amount of loaded ammo for guns and tools, number of items for ammo and food). This limits the the compatibility: an item can not be a book and a tool (with charges).

[narc0tiq]

This looks like the first step to item composition, likely a very good and useful thing. I don't really find the dynamic_cast<it_armor> very nice to look at, and it can be confusing as you end up with two names for the same memory, either of which might get deleted at any time.

I have one minor quibble: I'd drop the "_slot" from the name. They're armor properties, you may as well be accessing them as it->armor->whatnot.

P.S.: Fix yo' compile errors. ;)

[BevapDin]

Compiler errors? What compiler errors. There are now compile errors. (fixed and rebased)

I also renamed the itype members as requested.

This looks like the first step to item composition

That's the goal.

[KA101]

This ready to go?

[kevingranade]

Awesome, just what I was hoping for.
I like all your ideas in your TODO.
Regarding charges, the only thing that tomes to mind is to stick those values in item_vars. i.e. gun "charges" becomes item_vars["ammo_count"], battery charges for tools becomes item_vars["battery_charge"]. That refactoring can happen as each itype that uses charges is migrated to using a slot.

[BevapDin]

I added documentation and moved the container flags into boolean members. Those container flags are now shown in the item description, along with the content size of the container (this already included in some item descriptions but not in all and getting the content size from the item type directly makes sure it's always correct).

And I declare this ready.