Practically all mods have already implemented a solution using NULL items.
The DEV effort is big.
The migration effort for modders is also big.
What benefit(s) does your solution bring to justify the efforts?
Meridian, thank you for taking the time to hear me out, I really appreciate it. Sorry to be lengthy below, trying to be concise but also clear on the issue and request.
Justification - I believe this suggestion is:
[Backwards Compatible]
1.) Implementation doesn't impact current mod structure (completely backwards compatible)
2.) Current mods do not need modified (migration can be ignored)
3.) Fairly simple migration effort for modders
--> search for builtInWeapons:
--> replace with customInventory: *newCustomInventoryDefintion
4.) Armors with default inventory need not to be changed
[Future Mods]
1.)
Greatly simplifies new armor definitions with 'custom' inventories as opposed to NULL blanks.
2.)
Quickly allows for many more custom inventories including unique locations, names, and sizes of inventories for any armor definitions.
3.)
Massively simplifies submods that modify the inventories of other mods. (This is my current situation - explained below)
4.)
Any changes to parent mods inventory or armor configurations, i.e. X-Com Files would not affect nor require a submod to be changed and compatibility wold be maintained.
[My Goal]
1.)
Extend or modify the inventory, currently only with global invs: but
without having to
break ALL parent mod armor inventories.
2.) I want to
create new custom armors that have
more inventory slots than the globally defined invs: in X-Com Files.
-- backpack with 2x4 shape
-- backpack with 4x4 shape
-- additional 1x1 pocket slot
[Problem]
- I've created a unique inventory that unfortunately changes
ALL inventories globally for ALL parent mods under current format.
- I have to
fix / override ALL inventories across ALL armor definitions for ALL other mods.
[Example]
1.) I'm creating a sub mod for X-Com Files that adds new armors and
changes the global inventory configuration. This would affect other mods that add additional armors too.
2.) I replace 3x3 backpack with 4x4 backpack and add a 1x1 pocket slot.
invs:
...
...
- id: STR_BACK_PACK
x: 180
y: 31
slots:
- [0, 0]
- [0, 1]
- [0, 2]
- [0, 3]
- [1, 0]
- [1, 1]
- [1, 2]
- [1, 3]
- [2, 0]
- [2, 1]
- [2, 2]
- [2, 3]
- [3, 0]
- [3, 1]
- [3, 2]
- [3, 3]
...
...
...
- id: STR_POCKET
x: 0
y: 86
slots:
- [0, 0]
...
armors:
- new: STR_SUIT_RUCKSACK_UC # Suit with 2x4 backpack & Pocket
...
builtInWeapons:
- INV_NULL_2X4_BACK_PACK
...
- new: STR_POWERARMOR_LARGEPACK_UC # Power Armor with 4x4 bacpack
builtInWeapons:
- INV_NULL_1X1_POCKET
3.) Now
ALL parent mods, i.e. X-Com Files have a 4x4 backpack and a 1x1 pocket.
4.)
All X-Com Files armors with defined INV_NULL_3X3_BACK_PACK have to be fixed with INV_NULL_4X4_BACK_PACK and INV_NULL_1X1_POCKET
5.)
All X-Com Files armors have to be fixed with INV_NULL_1X1_POCKET if you don't want the pocket
added to all armors.
6.)
A lot more additional fixes have to me made to armors with other types of
buildtinWeapons such as ones that block off the backpack for a buildtinWeapon: jetpack, etc.
Hundreds of entries need updated / fixed with overrides:
armors:
...
...
...
- override: STR_SUIT_UC
builtInWeapons:
- INV_NULL_4X4_BACK_PACK
- INV_NULL_1X1_POCKET
- override: STR_SUIT_INFERNAL_UC
builtInWeapons:
- INV_NULL_4X4_BACK_PACK
- INV_NULL_1X1_POCKET
- override: STR_SUIT_SPARTAN_UC
builtInWeapons:
- INV_NULL_4X4_BACK_PACK
- INV_NULL_1X1_POCKET
- override: STR_SUIT_KYBEROS_UC
builtInWeapons:
- INV_NULL_4X4_BACK_PACK
- INV_NULL_1X1_POCKET
- override: STR_SUIT_OLYMPIAN_UC
builtInWeapons:
- INV_NULL_4X4_BACK_PACK
- INV_NULL_1X1_POCKET
- override: STR_SUIT_PROTEAN_UC
builtInWeapons:
- INV_NULL_4X4_BACK_PACK
- INV_NULL_1X1_POCKET
- override: STR_SUIT_H_UC
builtInWeapons:
- INV_NULL_4X4_BACK_PACK
- INV_NULL_1X1_POCKET
...
...
...
7.)
Any updates / changes / additions / to X-Com Files armors or inventory definition could potentially breaks this submod
and X-COM FIles... ,
hundreds of 'overrides' potentially have to be redone again to fix compatibility.
8.)
New code format request as follows would
not require any changes to X-COM Files defintions via overrides and
wouldn't break parent mods even when they are updated / changed.
Example:
extraInvs: &SuitWithRucksack
...
...
- id: STR_BACK_PACK
x: 180
y: 31
slots:
- [0, 0]
- [0, 1]
- [0, 2]
- [0, 3]
- [1, 0]
- [1, 1]
- [1, 2]
- [1, 3]
...
...
...
- id: STR_POCKET
x: 0
y: 86
slots:
- [0, 0]
...
extraInvs: &PowerarmroLargeBackpack
...
...
- id: STR_BACK_PACK
x: 180
y: 31
slots:
- [0, 0]
- [0, 1]
- [0, 2]
- [0, 3]
- [1, 0]
- [1, 1]
- [1, 2]
- [1, 3]
- [2, 0]
- [2, 1]
- [2, 2]
- [2, 3]
- [3, 0]
- [3, 1]
- [3, 2]
- [3, 3]
...
...
...
armors:
- new: STR_SUIT_RUCKSACK_UC # Suit with 2x4 backpack & Pocket
...
customInventory: *SuitWithRucksack
...
- new: STR_POWERARMOR_LARGEPACK_UC # Power Armor with 4x4 bacpack
....
customInventory: *PowerarmroLargeBackpack
....
... These definitions don't change X-Com Files armors or inventory in anyway
... No overrides needed to X-Com Files
... Changes to X-Com Files doesn't affect these definitions in any way
- This would
maximize compatibility across mods and submods that desire to have custom armor inventory definitions.
- This would
eliminate any dependent changes to mods when other codependent mods make changes to their inventory or armor definitions.
