Author Topic: Request for GUID feature  (Read 449 times)

Offline AL|EN

  • Planewalker
  • *****
  • Posts: 307
  • Gender: Male
Request for GUID feature
« on: August 29, 2018, 01:04:05 PM »
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:
Quote
// 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


Quote
// 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:
Quote
// choose one from those components, none of them are preferred for player
sd#SpellcastingInArmor <> cd#SpellcastingInArmor

Mod conflict definition:
Quote
// 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:
Quote
// 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:
Quote
// Change Khalid Class to Fighter/Ranger
BEGIN @11 DESIGNATED 11 LABEL "KhalidAsFighterRanger" // usage in the local mod scope/context
GUID "NPC:KHALID:CLASS"

Quote
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:
Quote
// 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 ...":
Quote
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.
« Last Edit: January 28, 2019, 05:45:47 PM by AL|EN »
You cannot have progress without committing changes...A Basic Modder's Guide to Git and Github

Offline subtledoctor

  • Planewalker
  • *****
  • Posts: 101
Re: Re: ID_OF_LABEL woes (solved)
« Reply #1 on: September 01, 2018, 12:19:52 PM »
You lost me at the end. Your example has multiple mods/components using the same GUID? Then it's not unique. Or, oh wait, I see, those components can have the non-unique "GUID" as well as others. That seems less like a GUID than a CONFLICT_CATEGORY or something like that.

My only concern is that this is getting cluttered. We'll need:
Code: [Select]
BEGIN ~component~
DESIGNATED ~int~
LABEL ~string~
GUID ~~
GUID ~~
GUID ~~
FORBID_COMPONENT ~yadda~
REQUIRE_PREDICATE ~yadda~

...etc. (Figuring out how to plug all that into SUBCOMPONENT is giving me the heebie-jeebies.

Can we maybe find a way to streamline that a bit?

Offline AL|EN

  • Planewalker
  • *****
  • Posts: 307
  • Gender: Male
Re: Re: ID_OF_LABEL woes (solved)
« Reply #2 on: September 02, 2018, 03:47:17 AM »
You lost me at the end. Your example has multiple mods/components using the same GUID? Then it's not unique. Or, oh wait, I see, those components can have the non-unique "GUID" as well as others. That seems less like a GUID than a CONFLICT_CATEGORY or something like that.
It may be, but its not bad thing in my opinion. The user case which I provide serve it's purpose. Think about GUID as LABEL in global mod swarm. The fact that they can be multiple components with one GUID only extends it's range of usage. I don't want to limit it. Modders can always make sure that all GUID's are unique across all their mods, even globally unique by using modder prefix which other modders won't use. What matter is the contexts of usage.


My only concern is that this is getting cluttered.
...etc. (Figuring out how to plug all that into SUBCOMPONENT is giving me the heebie-jeebies.
Can we maybe find a way to streamline that a bit?


How about:
Code: [Select]
BEGIN ~component~ DESIGNATED ~int~
LABEL ~label1~ ~label2~
GUID ~guid1~ ~guid2~
FORBID_LABEL ~yadda1~ ~yadda2~
REQUIRE_LABEL ~yadda3~ ~yadda4~
FORBID_GUID ~guid3~ ~guid4~
So modders can have multiple LABEL and GUID as one line? I'm sure that spiting arguments by "REGEX ~*~" won't be hard for weidu, right @wisp?


Example 3:
Quote
// Change Khalid Class to Ranger
BEGIN @0 DESIGNATED 0 LABEL "initialization" // local context: required for all components


BEGIN @1 DESIGNATED 1 LABEL "SomeOtherCompoenent" // local context: other component which require only "initialization" component
REQUIRE_LABEL ~initialization~


BEGIN @2 DESIGNATED 2 LABEL "ChangeKhalidClass" // local context: required for all class components
LABEL "ChangeKhalidClass"
REQUIRE_LABEL ~initialization~


BEGIN @10 DESIGNATED 10
LABEL "KhalidAsRanger"
REQUIRE_LABEL ~initialization~ ~ChangeKhalidClass~ // local context: require both "initialization" and "ChangeKhalidClass" components
FORBID_LABEL ~KhalidAsBard~ // local context: cannot be installed if "KhalidAsBard" is already installed


GUID "NPC:KHALID:CLASS" // global context: the same GUID because bunch of other mods can also change Khalid class and they can set the same GUID to exclude itself
FORBID_GUID ~NPC:KHALID:CLASS~ //global context: won't be installed if another mod already changed Khalid class and add "NPC:KHALID:CLASS" GUID to weidu log


BEGIN @20 DESIGNATED 20
LABEL "KhalidAsBard"
REQUIRE_LABEL ~initialization~ ~ChangeKhalidClass~ // require both "initialization" and "ChangeKhalidClass" components
FORBID_LABEL ~KhalidAsRanger~ // cannot be installed if "KhalidAsBard" is already installed


GUID "NPC:KHALID:CLASS" // global context: the same GUID because bunch of other mods can also change Khalid class and they can set the same GUID to exclude itself
FORBID_GUID ~NPC:KHALID:CLASS~ //global context: won't be installed if another mod already changed Khalid class and add "NPC:KHALID:CLASS" GUID to weidu log
It's very simple example but it's perfectly logical for me. Modder can deal with his own components locally, have all flexibility which he needs, and globally without worrying about other mods changes of DESIGNATED and LABEL's.


I don't know what else I can say, except for providing more examples based on BWS global conflicts/dependence rules which was created across all those years. And they work or I should say, the concept is working.
« Last Edit: January 28, 2019, 05:47:21 PM by AL|EN »
You cannot have progress without committing changes...A Basic Modder's Guide to Git and Github

Offline AL|EN

  • Planewalker
  • *****
  • Posts: 307
  • Gender: Male
Re: Re: ID_OF_LABEL woes (solved)
« Reply #3 on: September 04, 2018, 06:22:03 AM »
subtledoctor, just to make sure, scenario 1 is still valid for you? I choose SoB and TA because it's easy for me to post good examples for components which covers the same ground.

Also, I'm perfectly fine with only one, unique GUID for each component. We can start with such implementation, test it, see how it goes and give feedback.

@wisp, do you need any more info to add a basic implementation of GUID to weidu? I think that it would be pretty much coping most of the LABEL code with some extra stuff.
You cannot have progress without committing changes...A Basic Modder's Guide to Git and Github

Offline Wisp

  • Moderator
  • Planewalker
  • *****
  • Posts: 1037
Re: Re: ID_OF_LABEL woes (solved)
« Reply #4 on: September 08, 2018, 06:52:33 AM »
What happens when a duplicate GUID is encountered? With the original suggestion of alphabet soup, conflicts were perhaps unlikely, but free-form GUIDs that rely on modders using prefixes and good hygiene seems a lot more prone to conflicts arising.

Offline AL|EN

  • Planewalker
  • *****
  • Posts: 307
  • Gender: Male
Re: Re: ID_OF_LABEL woes (solved)
« Reply #5 on: September 08, 2018, 01:22:31 PM »
Do you mean GUID duplication across different mods? We can't exclude possibility, but the consequences are depends on the way how weidu/zeitgeist/other install tools interprets FORBID_GUID.

1. Intentional collision of the same GUID's from two or more different mods, It's explained at Scenario/Example 2:
If the one of the ModB component has "FORBID_GUID NPC_CLASS_KHALID" and ModA component having such a GUID was installed before ModB then:

- weidu could print info before installation of the component:
"Previously installed component have the same GUID as the current one. Are you sure that you want to install yet another component with GUID?"

- more advanced tools like zeitgeist/other install tools display a choice before installation of all chosen mods:
"You are going to install two mods/components which the same GUID" -> "choose A/B/ignore and continue"

2. Unwanted collision of the same GUID's from two or more different mods

Components witch change/cover the same NPC are good example when general GUID names can be useful and collisions are intentional. For unwanted collisions, there is an easy escape from such problems by using modder prefix:

ModD and ModE have the several exactly the same GUID for few of the components. They choose the same, general GUID name ( like 'initial' or 'main') to cover different things. There is a possibility for eg: ModE skipped required component because ModD had the same GUID's and it was installed as first.

As soon as such "GUID collision' is found to cause problems, one of the modder (or all of them) simply add their modded prefix to their GUID's and they became unique and in the future, there won't be chances for the next "GUID collision' (because no one can use other modder prefix) unless it will be intentional. More unique GUID's will be added to GUID swarm, new mods would have to simply include more of them if they want to interactions with different mods/components.

Even if external conflict definitions need to be updated, but it's a huge improvement over DESIGNATED/LABEL changes.

But as I mention before, I'm perfectly fine when all single mod GUID's would be forced to be unique. I'm fine even if you don't add FORBID/REQUIRE_GUID for weidu, only the "GUID" keyword for components. I could then rewrite all BWS conflicts to be GUID-based. It's still a huge gain for external conflict definitions because modders could change DESIGNATED/LABEL/structure of the components at any time, without affecting external conflict definitions (which covers cross-mods conflicts/dependence) like BWS already has. But if GUID is so useful for external tools, I'm sure that modders would also find them useful as well.
« Last Edit: September 08, 2018, 02:00:20 PM by AL|EN »
You cannot have progress without committing changes...A Basic Modder's Guide to Git and Github

 

With Quick-Reply you can write a post when viewing a topic without loading a new page. You can still use bulletin board code and smileys as you would in a normal post.

Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic.

Name: Email:
Verification:
Type the letters shown in the picture
Listen to the letters / Request another image
Type the letters shown in the picture:
What color is grass?:
What is the seventh word in this sentence?:
What is five minus two (use the full word)?: