Posted by: AL|EN
« 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.
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.