Split from
this topic.
LABEL is not changing, no. Are the salient points of your UUID proposal still that they'd live in the global scope (alongside TP2 names, rather than under them, like LABEL), are added to the log and maybe that a component can have at most one UUID? If not, would you care to summarise the current status?
All but one: components can have multiple GUID's
I'm sure that modders will find a creative way how to use them and I don't want to limit their creativity. The power of GUID leads in the way how its used and interpreted via external mods/tools.
So this is summary of the current status:
A. LABEL
- will be used in the local mod scope/context, for better organization of the internal mod components dependence
- can also be used to defining special dependence/requirements in terms of selecting components via GUI interface
so nonsensical component combinations can be prevented from installing at all (workaround for current weidu limitation)
- modders can change them at will, others won't complain
- external mods/tools conflict definition won't be based on them as they can be changed frequently
- maybe it's good thing to remove warring when multiple LABELS occur or move them to debug only
B. GUID ( Globally Unique Identifier, let's have 'globally' in the name of it )
- will be added to weidu.log (and --list-components-json)
- will not be bound to the mod tp2
- weidu commands syntax will have only one parameter, GUID itself
- will be used in the global scope/context, for defining global mods components dependence
- can be used to prevent installing overlapping/conflicting components from many mods
- once set, should not be changed, unless component purpose of it was changed completely so there is no more conflict
- components can have multiple GUID's, the more you have, the more interactions with different components will occur
My goal are those scenarios which are now possible:
1. Cooperation between two modders:// Scales of Balance: Item & Weapon Overhaul (IWO): Yet Another Revised Armor System
BEGIN @100 DESIGNATED 100 LABEL "YARAS" // usage in the local mod scope/context
GUID "sd#SpellcastingInArmor" // even with modder prefix, it's still beneficial when LABEL "YARAS" will be renamed and GUID will not
// Tweaks Anthology: Allow Arcane Spellcasting in Armor
BEGIN @212000 DESIGNATED 2120 LABEL "SpellcastingInArmor" // usage in the local mod scope/context
GUID "cd#SpellcastingInArmor" // even with modder prefix, it's still beneficial when LABEL "SpellcastingInArmor" will be renamed and GUID will not
External tool conflict definition:
// choose one from those components, none of them are preferred for player
sd#SpellcastingInArmor <> cd#SpellcastingInArmor
Mod conflict definition:
// forbid component from installing if there is a GUID of ...
sob.tp2: FORBID_GUID cd#SpellcastingInArmor ~Spellcasting in armor allready installed by other mod~
cdtweaks.tp2: FORBID_GUID sd#SpellcastingInArmor ~Spellcasting in armor allready installed by other mod~
Benefits from defining conflicts via GUID for mods and external tools:
- modders can modify DESIGNATED and LABEL without touching external conflicts definition
- no matter which mod will have those example components, global conflicts definition won't change
2. Global exclusion of the components:Component from any mod: Change Khalid Class to x
ModA.tp2 - two components, different LABEL but the same GUID:
// Change Khalid Class to Ranger
BEGIN @1 DESIGNATED 1 LABEL "KhalidAsRanger" // usage in the local mod scope/context
GUID "NPC:KHALID:CLASS"
BEGIN @2 DESIGNATED 2 LABEL "KhalidAsBard" // usage in the local mod scope/context
GUID "NPC:KHALID:CLASS"
ModB.tp2:
// Change Khalid Class to Fighter/Ranger
BEGIN @11 DESIGNATED 11 LABEL "KhalidAsFighterRanger" // usage in the local mod scope/context
GUID "NPC:KHALID:CLASS"
ModC.tp2:
// Change Khalid Class to Cleric
BEGIN @111 DESIGNATED 111 LABEL "KhalidAsCleric" // usage in the local mod scope/context
GUID "NPC:KHALID:CLASS"
External conflict definition:
// choose one from those components, none of them are preferred for player
ALLOW_SINGLE_GUID "NPC:KHALID:CLASS"
Mod conflict definition, "forbid component from installing if there is a GUID of ...":
ModA.tp2: FORBID_GUID NPC:KHALID:CLASS ~Khalid class was already set via different mod~ // wisp, possible to identify it?
ModB.tp2: FORBID_GUID NPC:KHALID:CLASS ~Khalid class was already set via different mod~
ModC.tp2: FORBID_GUID NPC:KHALID:CLASS ~Khalid class was already set via different mod~
Additional benefits for above case:
- any modder who will create "Change Khalid Class to x" component can add GUID "NPC:KHALID:CLASS" to it so only one of those components will be allowed to install
- existing mods can add new components and hookup to the conflict definitions easily
- in such case, there is no need to modify previous mods or tools conflict definitions
- components can literally fly across various mods tp2 without destroying mods or tools conflict definitions
That's how I see it. I'm sure that there might be future discussion about how we define such global GUID's but let's talk about it later.
@CamDawg, Subtledoctor, DavidW and others
Does those scenarios looks valid and useful for you? I can work with such thing with ease. Let's give such system a try.