[ABANDONED] Inventory slots per armor

[gix]

Abandon reason: a solution was implemented, but it was too difficult to use

Hi, Solarius
Just posted a PR into OXC (https://github.com/SupSuper/OpenXcom/pull/1210) which allows to link specific inventory rules to armors.
So no more hidden builtin weapons and so on => you just define as many overlapped inventory rules as you want, and then in the armor.rul you say for your armors (I think self-explanatory):

Code: [Select]

    inventorySlots:
      - STR_GROUND
      - STR_RIGHT_HAND
      - STR_LEFT_HAND
      - STR_SMALL_BELT
      - STR_SMALL_RIGHT_LEG
      - STR_SMALL_LEFT_LEG
      - STR_RIGHT_SHOULDER
      - STR_LEFT_SHOULDER
      - STR_SMALL_BACK_PACK
    defaultInventoriesMap:
      STR_BELT: STR_SMALL_BELT
      STR_RIGHT_LEG: STR_SMALL_RIGHT_LEG
      STR_LEFT_LEG: STR_SMALL_LEFT_LEG
      STR_BACK_PACK: STR_SMALL_BACK_PACK
And (well, along with the corresponding language strings) done - you have a small belt and so on...
You can even define inventories with no slots and empty (" ") text  ...

[Solarius Scorch]

OK, thanks. We'll see what Meridian says.
If I understood correctly, this modifies the inventory per armour, with no fixed "blank" objects involved? If it's true, then it sounds pretty awesome.

[gix]

OK, thanks. We'll see what Meridian says.
If I understood correctly, this modifies the inventory per armour, with no fixed "blank" objects involved? If it's true, then it sounds pretty awesome.

Yep, that's correct - see attached changed standard armors (left on pupose the "deleted" backpack label, the others are just changed in case)
And the armor modification ruleset:

Code: [Select]

armors:
  - type: STR_NONE_UC
    inventorySlots:
      - STR_GROUND
      - STR_RIGHT_HAND
      - STR_LEFT_HAND
      - STR_SMALL_BELT
      - STR_SMALL_RIGHT_LEG
      - STR_SMALL_LEFT_LEG
      - STR_RIGHT_SHOULDER
      - STR_LEFT_SHOULDER
      - STR_SMALL_BACK_PACK
    defaultInventoriesMap:
      STR_BELT: STR_SMALL_BELT
      STR_RIGHT_LEG: STR_SMALL_RIGHT_LEG
      STR_LEFT_LEG: STR_SMALL_LEFT_LEG
      STR_BACK_PACK: STR_SMALL_BACK_PACK
  - type: STR_PERSONAL_ARMOR_UC
    inventorySlots:
      - STR_GROUND
      - STR_RIGHT_HAND
      - STR_LEFT_HAND
      - STR_BELT
      - STR_SMALL_RIGHT_LEG
      - STR_SMALL_LEFT_LEG
      - STR_RIGHT_SHOULDER
      - STR_LEFT_SHOULDER
      - STR_SMALL_BACK_PACK
    defaultInventoriesMap:
      STR_RIGHT_LEG: STR_SMALL_RIGHT_LEG
      STR_LEFT_LEG: STR_SMALL_LEFT_LEG
      STR_BACK_PACK: STR_SMALL_BACK_PACK
  - type: STR_POWER_SUIT_UC
    inventorySlots:
      - STR_GROUND
      - STR_RIGHT_HAND
      - STR_LEFT_HAND
      - STR_BELT
      - STR_RIGHT_LEG
      - STR_LEFT_LEG
      - STR_RIGHT_SHOULDER
      - STR_LEFT_SHOULDER
      - STR_SMALL_BACK_PACK
    defaultInventoriesMap:
      STR_BACK_PACK: STR_SMALL_BACK_PACK
Oooh - and just by thinking - we could by a further small change mod also the hand inventory size by armor, so particular units can pick only small objects... Need to think further if maybe make even possible to have a non-rectangular shape (allowing to pick either a 1*3 or a 2*2 object, but not a 3*2)...

[Meridian]

So, I have reworked gix's proposal, because it was not backwards-compatible.

All in all, I am not happy with my solution either, it feels quite unnecessary and I don't see much improvement over the existing approach (which is a misuse of another feature I admit, but that was also not my idea).

To summarize the advantages:
 - you can must define for each armor, which slots it contains
 - the unwanted slots will actually disappear... not just be covered by black foreground
 - the descriptions (and TU cost) of unwanted slots will disappear too
 - you will be able to move slots easily just on selected armors, give them different description and different TU costs

But there are also disadvantages:
 - additional slots are still defined globally... so if you add any new ones, they will by default go to all armors (backwards-compatibility)
 - thus you will need to change the ruleset for ALL your armors, and enumerate the slots that belong to each armor...
 - ... which is basically the same amount of modding work and same amount of extra ruleset as today (for defining those black blank slot covers)
 - you can't change ground slot
 - you can't change hand slots (this could theoretically be added, but it is a serious pain in the ass)
 - you can remove belt and backpack... but you will need to name some other slots, which will fulfill the role of belt and backpack, for example for autoequip algorithm and for AI (could be any slot except ground, even hands)
 - if you decide to use STR_BELT_1 and STR_BELT_2 for two different armors... they will also be saved differently in the inventory templates... so sharing equipment layout between different armors will also be a PITA...
 - ... therefore, there will be a possibility to define a "matching ID" for all inventory slots... so you can define that STR_BELT_1 and STR_BELT_2 should both be saved as STR_BELT_COMMON and then loaded back by reverse search... which is also dangerous if you define two different slots in the same armor to save under same ID (e.g. if you say that "right leg" and "belt" should both save as "xyz")

OK, enough complaining, here's how it could look like:

Code: [Select]

invs:
  - id: STR_MY_CUSTOM_BELT_ONLY_FOR_POWER_ARMOR # a new inv. slot
    x: 192
    y: 104
    slots:
      - [0, 0]
      - [1, 0]
    costs:
      STR_BACK_PACK: 16
      STR_GROUND: 6
<snip>

Since you added a global slot, now we need to redefine ALL armors (this can be a hundred for bigger mods), so that they know they should not use this new slot.

You can omit STR_GROUND, STR_RIGHT_HAND and STR_LEFT_HAND, because the game adds ground and hands automatically if they are missing.
Backpack and belt (e.g. STR_BACK_PACK and STR_BELT) would also be added automatically... we get to that later.

Code: [Select]

armors:
  - type: STR_NONE_UC
    inventorySlots: [ STR_LEFT_SHOULDER, STR_RIGHT_SHOULDER, STR_LEFT_LEG, STR_RIGHT_LEG ]
  - type: STR_PERSONAL_ARMOR_UC
    inventorySlots: [ STR_LEFT_SHOULDER, STR_RIGHT_SHOULDER, STR_LEFT_LEG, STR_RIGHT_LEG ]
  - type: STR_POWER_SUIT_UC
    inventorySlots: [ STR_LEFT_SHOULDER, STR_RIGHT_SHOULDER, STR_LEFT_LEG, STR_RIGHT_LEG, STR_MY_CUSTOM_BELT_ONLY_FOR_POWER_ARMOR ]
  - type: STR_FLYING_SUIT_UC
    inventorySlots: [ STR_LEFT_SHOULDER, STR_RIGHT_SHOULDER, STR_LEFT_LEG, STR_RIGHT_LEG ]

You also need to specify, which slots are belt and backpack... if they are different than vanilla slots.
So in this case, you would need to define belt slot for power armor:

Code: [Select]

armors:
  - type: STR_POWER_SUIT_UC
    inventorySlots: [ STR_LEFT_SHOULDER, STR_RIGHT_SHOULDER, STR_LEFT_LEG, STR_RIGHT_LEG ]
    slotBelt: STR_MY_CUSTOM_BELT_ONLY_FOR_POWER_ARMOR
#    slotBackpack: STR_BACK_PACK # no need to define this if it's not changed

Both "slotBelt" and "slotBackpack" would be added automatically to "inventorySlots", besides the ground and hand slots.

Lastly, so that we can use equipment templates between different armors, we need to define that STR_MY_CUSTOM_BELT_ONLY_FOR_POWER_ARMOR and STR_BELT should be treated the same way.

Code: [Select]

invs:
  - id: STR_MY_CUSTOM_BELT_ONLY_FOR_POWER_ARMOR
    x: 192
    y: 104
    layoutMatchId: STR_BELT    # treat this slot same way as STR_BELT slot for equipment layout templates handling
#
# slots and costs definition
#

So, now the question after all the explanations: is someone interested in this feature or is it not worth the (modding) effort?

[Solarius Scorch]

While I really like the idea, the implementation problems you described are rather scary (work-intensive), so I'd rather stick with the old method of blocking slots with black boxes.

[Meridian]

One thing I forgot to mention: also the "defaultInventorySlot" attribute (in the item ruleset) would change semantics and you would need to write the slot's "layoutMatchId" there instead of its "id".

The newest rebased version is available here, if someone wanted to try it: https://github.com/MeridianOXC/OpenXcom/commits/slots-per-armor

For now, it's not going to be merged into the main branch... for lack of interest.

[Nord]

Maybe you will not do it? It will ruin a lot of things.
Or it can use a switch. Between old and new mechanic.

[Ethereal]

For now, it's not going to be merged into the main branch... for lack of interest.

No matter how it was implemented - i support such innovations. Moreover... Since the script is, what prevents the introduction of this option in OXCE? Additional features for modding - it's always good.

[Meridian]

No matter how it was implemented - i support such innovations.

So you support everything no matter how bad it is? Because that's how it sounds. I don't.

Moreover... Since the script is, what prevents the introduction of this option in OXCE?

All the disadvantages I have mentioned?
Did you read them?

Additional features for modding - it's always good.

Only if they work.

[robin]

IMO the current current "black patch" method already enables every inventory customization I can think of; it's certainly a hack but it works.
But I use few armors and few slots customizations, so I might not fully appreciate the potential/improvement that this new method bring to the table.

[Yankes]

No matter how it was implemented - i support such innovations. Moreover... Since the script is, what prevents the introduction of this option in OXCE? Additional features for modding - it's always good.

No, every change made to code base create new bugs. Every new feature have "cost" in code base. With this two things in mind and fact that some features are not usefully for most of modders this could made whole code base worsen.
And what will be result? New features will be harder to implement.
At some point code base could be so rotted that only same solution would be "do not touch it".

[Ethereal]

You know better. And then "for lack of interest.", and how does he emerge - at once in refusal. Do not want to enter - do not enter. Implement can a separate mod that can be installed and removed at will without touching the rest. It will not be superfluous.

[Yankes]

Implement can a separate mod that can be installed and removed at will without touching the rest

How? Right now only way to implement it is as change in source code, this mean you need have a separate exe to "install", and who will maintain this exe?