weidu next generation - GUID/UUID keyword for every component

[AstroBryGuy]

If BWS wants to enforce some kind of GUID/UUID usage of LABEL for mods to be included in BWS, then go for it. That's the BWS team's prerogative as to how they run their project. But I disagree that a valid GUID/UUID tag should be required for all installs. If a modder wants to create a mod without a GUID/UUID and offer it outside of BWS, then WeiDU shouldn't block installation for lack of a tag that only benefits BWS. Similarly, WeiDU also shouldn't refuse to install Chimeric's mods for not using a modder prefix.

I also think it's a bad idea to bifurcate WeiDU support into "new mods" and "old mods", requiring different, incompatible versions of WeiDU to install each. Uninstalling or updating mods on a mixed selection will be a potential disaster (e.g., user tries to uninstall OldMod that ships with OldWeiDU. In the process, OldWeiDU attempts to uninstall and reinstall a bunch of  new mods that use NewWeiDU and some shiny new commands specific to NewWeiDU, so the process fails.)

Modders do not work for BWS. Adding required tags that only benefit BWS while breaking old mods is not a good idea.

Note - Of course, perfect backwards compatibility cannot be guaranteed for every new WeiDU release. Sometimes, it can be necessary to make a change that breaks the way some old mods do things. But this is a proposed change that breaks old mods for lack of a tag that doesn't affect actual mod functionality at all.

[subtledoctor]

Adding required tags that only benefit BWS while breaking old mods is not a good idea.

I think this is the core of any opposition to the idea.

BUT, while this thread might be combative at times, it's worth keeping the big picture in mind. The point here is a good one: how to create a system for conflict identification that will be robust. Obviously we different on the definition of "robust" - ALIEN thinks anything less than 100% uptime is a failure. I think 100% uptime is a pipe dream. There is a thriving community (four actually) which can be responsive to issues as they arise. So it's simply not necessary to reach perfection.

Anyway GUID/UUID is not perfect in this context.
- Weidu likely could not auto-generate it; how could it? What if it generates one, but something about the component (content, function, description text, intended install order) changes? How would Weidu know when to, or when not to, create a new GUID/UUID?
- What happens when my bard class overhaul gets split into four constituent parts? Which one keeps the ID? How do conflict rules get updated for the new components? We're right back at square one.
- What happens if a component's GUID/UUID stays the same, but its content changes? What if it used to be incompatible with some mod, and I make it compatible? What if it used to be compatible, but some new feature renders it incompatible?

So GUID/UUID is not perfect, it would be prone to many possible points of failure. I think it would be smarter to start with a system that we already have, and try to extend its utility.

The obvious one is component numbers. These are automatically applied... so that's a good start. They already work with stuff like FORBID_COMPONENT and REQUIRE_PREDICATE and would be easy to use with my hypothetical flag that is like those, but is install-order-agnostic. The problem, of course, is they this depends on the order of some text in a .tp2 file, and is thus unreliable.

Enter DESIGNATED. People tend to lump this in with component number but conceptually, it is really a different system. It is independent of .tp2 order but it works with FORBID and REQUIRE equally well. This is more stable than the first one, but still not totally reliable... people do change DESIGNATED numbers. They are still numbers and people like numbers to be ordered. I do silly OCD stuff like match up my DESIGNATED numbers to ranges of strings in my .tra files. I recently moved the last component of my mod to the beginning and naturally I changed its DESIGNATED number from 500 to 100.

Then we have LABEL. When you think about it this is really no different from DESIGNATED. The latter is simply a LABEL that happens to be in the form of an integer. But theoretically, FORBID and REQUIRE et al. could accept non-integer arguments and apply to LABELs and DESIGATEDs interchangeably. Why not? Modders might be more comfortable tagging components with a LABEL, and they might be less inclined to change it if they reorder their components.

Finally, GUID/UUID. A good idea, and perhaps you could call it best practice... but like most best practices, rather than making it a new requirement, why not make it an available feature, and people should tend to gravitate to it if they are smart. (And if they are not smart or don't care, that's their business and people don't have to use their mods!)

So here's my suggestion: make all these things work together. Let me do something like this in my .tp2:

Code: [Select]

BEGIN ~awesome win-button item pack~
LABEL ~awesome_items~
REQUIRE_PREDICATE MOD_IS_INSTALLED ~item_rev.tp2~ ~main_component~ // assuming Demi were to apply this LABEL
FORBID_COMPONENT ~iwdification.tp2~ ~30~
CONFLICT ~AL|ENS_mod.tp2~ ~CgACDAAKCwk~ // yes this is my new proposed component flag
Key thing being, allow modders to apply DESIGNATED and/or LABEL and/or GUID/UUID, and have the REQUIRE and FORBID stuff recognize any if those, or in their absence, simple component order. (And any plugin or other metadata-style tool like AL|EN uses and proposes could likewise recognize any and all of them.) This way we could more or less achieve blanket coverage. Would it be perfect? Still no. Would it be a damn sight better than the current situation? Surely. And it offers the path of least resistance to making it happen.

[subtledoctor]

Wait... thinking this through, why can't we already do this? Why does GUID/UUID have to be a new, separate thing? Can't a smart modder generate one, and simply use it as a LABEL?

So really, if the functions that check against DESIGNATED and component numbers could be extended to work equally well with LABELs, wouldn't we be 99% of the way there?

(Or get rid of LABEL and simply allow text strings to be used with DESIGNATED)

[Wisp]

Guys, it's not about generating GUID/UUID from the code. I'm requesting a simple and well-defined thing for the well defined purpose and I'm getting answers based on some false assumptions.

Let's go thought this again:
GUID/UUID simple definition:

Stands for "Globally Unique Identifier." A GUID is a 128-bit (16 byte) number used by software programs to uniquely identify the location of a data object.

I apologise. But in my defense, you talk about short UUIDs and link to base encoding and hashing functions, including a case where someone wants to use a short essentially-a-hash as an identifier.

I still don't see what the problem is if there are multiple LABELs. If you only wish to use one of them, what problem is a few, or even, hundred others?

- when the GUID/UUID is added to the component, it's a uniquely identifier of this component and this component only. If there are more than one GUID/UUID then both of them can be used to identify component. Looking at the context of the component, it can be identified by two different GUIDs/UUIDs so the identification is not unique. Not fulfilling this fundamental condition can't be ignored. You can't call it GUID/UUID and describe it like "och it's GUID/UUID but assign as many as you want because code allows to do it".

I think you are misunderstanding. My understanding is that the uniqueness is that there are no collisions (i.e., two independently generated UUIDs are virtually guaranteed to be different), not that the thing the UUID refers to must only have a single UUID. If nothing else, the random UUID (version 4) is going to be different every time you generate one, regardless of whether the thing is the same each time, and all UUIDs which include a timestamp are virtually guaranteed to be different each time, even if the MAC part, or whatever, is identical.

You don't really think literally made-up LABELs is a problem, do you? If a mod reports a LABEL as Foo, Foo is going to be valid.

Of course it's a problem. Labels like "MyFavoriteItems" are dangerous because two or more mod authors could use the same label. It would denies it's purpose. And arbitrary strings cannot be validated. Se below answer.

"MyFavoriteItems" is defined within the scope of fabulousitemmod.tp2, regardless of whether itempack.tp2 defines an identical label. There is no ambiguity.

I need a way to make it shorted

You could probably get away with just encoding a high-precision time-stamp, since it's highly unlikely two UUIDs are going to be generated at the same millisecond, or whatever. Whether this is short enough for you, I don't know. But you have to ask yourself how little information you want your UUID to contain and how likely collisions will be as a result.

- I have given the condition that GUID/UUID should be required for every component

And I have said that backward-incompatibilies are not happening in the foreseeable future.

EDIT: Now I'm also adding new requirement which I forgot to mention because It was oblivious for me: FORBID_COMPONENT, MOD_IS_INSTALLED and possible in the future INCOMPATIBLE_COMPONENT from this topic: http://forums.pocketplane.net/index.php/topic,29642.0.html should be able to use GUID/UUID

LABEL doesn't provide any of those features.

You resolve LABEL with ID_OF_LABEL, so yes, LABEL does, in fact, provide those features. This is done at install-time, which is why it does not matter if component numbers change, so long as the LABEL stays the same.

This feature is the foundation of effective BWS replacement, effective mod database and the effective solution for mod authors to write their own conflicts inside tp2 because component conflicts can't relay at the DESIGNATED as I proven via examples from first post of this topic.

Wisp, can you step into my boots and see my requests from external systems perspective?

The simple fact is that this feature cannot be mandatory. Other things considered, it's a reasonable request, but mods can't suddenly not work just because they were not updated to make use of it. Moreover, this may be a necessary thing for mod databases, BWS replacements and more, but it is not a necessary thing for WeiDU, which installs mods, manages the mod stack and uninstalls mods. UUIDs do not feature in these things and WeiDU cannot make spurious requirements like that, for the simple fact that it is not required by WeiDU. If this is a necessary feature for mod databases and BWS replacements, they are the ones who need to require that mods use it, not WeiDU, because WeiDU functions in a wider variety of use cases. I get that maybe modders have not been rallying to the BWP cause, all agreeable and eager to facilitate the work, but you can't use WeiDU to force them to cooperate.

[AstroBryGuy]

Wait... thinking this through, why can't we already do this? Why does GUID/UUID have to be a new, separate thing? Can't a smart modder generate one, and simply use it as a LABEL?

That's what I suggested. 

If BWS wants to enforce some kind of GUID/UUID usage of LABEL for mods to be included in BWS, then go for it.

[GeN1e]

Wait... thinking this through, why can't we already do this? Why does GUID/UUID have to be a new, separate thing? Can't a smart modder generate one, and simply use it as a LABEL?

So really, if the functions that check against DESIGNATED and component numbers could be extended to work equally well with LABELs, wouldn't we be 99% of the way there?

(Or get rid of LABEL and simply allow text strings to be used with DESIGNATED)

My understanding is that both DESIGNATED and LABEL are limited to their tp2, while his concern is about component migration between tp2's. In that case GUID-like marker can indeed be useful, although one can already place mymod_mycomponent.mrk file into override for cross-tp2 detection (this is how Detectable Spells operate, for example - it is used by multiple mods, but the included fixpack for older versions only runs once).

[subtledoctor]

Wait... thinking this through, why can't we already do this? Why does GUID/UUID have to be a new, separate thing? Can't a smart modder generate one, and simply use it as a LABEL?

So really, if the functions that check against DESIGNATED and component numbers could be extended to work equally well with LABELs, wouldn't we be 99% of the way there?

(Or get rid of LABEL and simply allow text strings to be used with DESIGNATED)

My understanding is that both DESIGNATED and LABEL are limited to their tp2, while his concern is about component migration between tp2's. In that case GUID-like marker can indeed be useful, although one can already place mymod_mycomponent.mrk file into override for cross-tp2 detection (this is how Detectable Spells operate, for example - it is used by multiple mods, but the included fixpack for older versions only runs once).

Was that (component migration) the whole point of this? I thought it was the one example of a point of failure that might be addressed by GUID/UUID better than LABEL/DESIGNATED. One among many possible points of failure, and one so rare and remote that it honestly doesn't concern me. Certainly not sure much that it's worth such a drastic change in what we demand of modders.

If that's the whole conversation, then I'm not sure the conversation is worth all this drama. Maybe be this is finally proof positive that marker files really are superior.

[AL|EN]

I can't quote everyone's post, yet I try to do my best:

@AstroBryGuy You are seeing this completely wrong: BWS don't want to enforce anything. Otherwise we would do it 3 years ago. My request come to support modder and give them new features which can be benefit for mods players and external systems. So they are not beneficial only to BWS. Are you really think that I'm so selfish?

I disagree also about you weidu statement: it's the current design which created problems because auto-overwrite feature. I've posted solution for this problem as well.

@subtledoctor Thanks for the great feedback. That's what I've counted for. It shows advantages (already exists) and disadvantages of different solutions.

Let me elaborate about GUID concerns:
1. Weidu likely could not auto-generate it; how could it?  What if it generates one, but something about the component (content, function, description text, intended install order) changes? How would Weidu know when to, or when not to, create a new GUID/UUID?

I'ts mod author who generate GUID ( same as makingup LABEL) using new weidu comandline option --generate-guid (won't mention about external solutions again) and put generated string into component, using GUID keyword. Similar as LABEL but without tp2 dependency.

2. What happens when my bard class overhaul gets split into four constituent parts? Which one keeps the ID? How do conflict rules get updated for the new components? We're right back at square one.
a) If any of the new components don't conflicting with other mods anymore you generate 4 new GUID's for you new for components, it's like sending message "Hey, no more conflicts" other mods doesn't need to be updated
if there is
B) If you split component 1 to 10,11,12,13 AND some part of the component 10 code are still conflicting with the same mods as component 1 did, you copy and old component 1 GUID to component 10 and generate 3 new, since they are new code/component. This way, conflict data is untouched for other mods.

3. What happens if a component's GUID/UUID stays the same, but its content changes? hat if it used to be incompatible with some mod, and I make it compatible? What if it used to be compatible, but some new feature renders it incompatible?
- it depends how big changes was. If there are cosmetic changes and the purpose is not changed, GUID stays the same. If there are compatibility improvements, related to other mods which use you GUID, then by generating new GUID you make you new component compatible without need an action from other modder It there are drastic changes, it's new component so new GUID is needed.

All you concerns are applied to DESIGNATED/LABEL also.

CONFLICT ~AL|ENS_mod.tp2~ ~CgACDAAKCwk~ // yes this is my new proposed component flag

Nope, GUID don't relay/is not bound to tp2: CONFLICT ~CgACDAAKCwk~ is all what you need to have.

Was that (component migration) the whole point of this? I thought it was the one example of a point of failure that might be addressed by GUID/UUID better than LABEL/DESIGNATED. One among many possible points of failure, and one so rare and remote that it honestly doesn't concern me. Certainly not sure much that it's worth such a drastic change in what we demand of modders.

LABEL/DESIGNATED also affect exported mod compilations/exported mod install order. GUID also but less, less often. They might not concern you but they might concern other modders who might want to set (conceptual)conflicts with you mod. You said that "The point here is a good one: how to create a system for conflict identification that will be robust." If someone is wiling to use LABEL, he needs to write them inside component code. The same action is required for GUID, the only addition is to run weidu + give_me_10_GUID's and the effect of it is removing tp2 dependency. Using you example:

Code: [Select]

BEGIN ~awesome win-button item pack~
LABEL ~awesome_items~
REQUIRE_PREDICATE MOD_IS_INSTALLED ~item_rev.tp2~ ~main_component~ // assuming Demi were to apply this LABEL
FORBID_COMPONENT ~iwdification.tp2~ ~30~
CONFLICT ~CgACDAAKCwk~ // yes this is my new proposed component flag, assuming AL|EN were to apply this GUIDthe only difference is that you makeup LABEL and GUID is provided for you. That's very low effort for ensure much easier component migration which won't require changes from other mods.

[AL|EN]

If nothing else, the random UUID (version 4) is going to be different every time you generate one, regardless of whether the thing is the same each time, and all UUIDs which include a timestamp are virtually guaranteed to be different each time, even if the MAC part, or whatever, is identical.

I know that it will be different at the time of the generation but it is not bad thing. After it would be pasted to tp2, it won't change (there are drastic exceptions but also apply to LABEL).

"MyFavoriteItems" is defined within the scope of fabulousitemmod.tp2, regardless of whether itempack.tp2 defines an identical label. There is no ambiguity.

You resolve LABEL with ID_OF_LABEL, so yes, LABEL does, in fact, provide those features. This is done at install-time, which is why it does not matter if component numbers change, so long as the LABEL stays the same.

It should not relay/be bound to tp2. If you write any code to support new usage of LABEL, you might also write it for GUID.
Well, it seems that LABEL doesn't relay/isn't bound to tp2. Let me dig deeper.

The simple fact is that this feature cannot be mandatory. Other things considered, it's a reasonable request, but mods can't suddenly not work just because they were not updated to make use of it. Moreover, this may be a necessary thing for mod databases, BWS replacements and more, but it is not a necessary thing for WeiDU, which installs mods, manages the mod stack and uninstalls mods. UUIDs do not feature in these things and WeiDU cannot make spurious requirements like that, for the simple fact that it is not required by WeiDU. If this is a necessary feature for mod databases and BWS replacements, they are the ones who need to require that mods use it, not WeiDU, because WeiDU functions in a wider variety of use cases. I get that maybe modders have not been rallying to the BWP cause, all agreeable and eager to facilitate the work, but you can't use WeiDU to force them to cooperate.

I'm not that selfish.  That is why I started by pointing weidu design flaws ( by no means, I don't blame you for it ) and the solutions for them will be beneficial to modders, players and external systems.
If I would do otherwise, I would just write statement like: "BWS needs this, this and that" without showing benefits for others. I would not read other people requests and point out the flaws with them.
Finally, I would come here and only do complain about how bad things are looking from my needs and post some demands.  I'm not forcing anyone to do anything. I hope that it doesn't look like that.


And I'm not requesting to be mandatory in a way that will break old mods or mods that won't adapt to use it. That is why I combine this request with abandoning auto-overwrite functionality because it already shows it's flaws and cause problems for mods. So mod which won't use it, will be fine (old weidu) and mods who will use it will be also fine(new weidu).

[GeN1e]

2. What happens when my bard class overhaul gets split into four constituent parts? Which one keeps the ID? How do conflict rules get updated for the new components? We're right back at square one.
...
B) If you split component 1 to 10,11,12,13 AND some part of the component 10 code are still conflicting with the same mods as component 1 did, you copy and old component 1 GUID to component 10 and generate 3 new, since they are new code/component. This way, conflict data is untouched for other mods.

It's not necessarily that simple. In fact, you posted a good example of this yourself:

Code: [Select]

item_rev(6|7|8|1040|1041|1042|1043)>fullplate(1)Originally there only used to be 6, 7 and 8 components that were in conflict. And then four more have been added, which contained the same exact incompatibility with FP&PS. I.e. either the ID had to be shared by multiple components; or FP&PS would need to check for additional GIUDs, which is not so different from re-checking the status of IR's DESIGNATED numeration; or IR couldn't split its components, which, well, is as ridiculous as it sounds.

a) If any of the new components don't conflicting with other mods anymore you generate 4 new GUID's for you new for components, it's like sending message "Hey, no more conflicts" other mods doesn't need to be updated
if there is
...
3. What happens if a component's GUID/UUID stays the same, but its content changes? hat if it used to be incompatible with some mod, and I make it compatible? What if it used to be compatible, but some new feature renders it incompatible?
- it depends how big changes was. If there are cosmetic changes and the purpose is not changed, GUID stays the same. If there are compatibility improvements, related to other mods which use you GUID, then by generating new GUID you make you new component compatible without need an action from other modder It there are drastic changes, it's new component so new GUID is needed.

The problem is that mod author first needs to know what makes compatibility concerns for other mods. Maybe they check to avoid combining two conceptually different armor system revisions. Or maybe they want AI to make special use of IR's potion revisions which used to be a minor part of its main component uhm, I lied here, it was the other way around, potions got merged into the main component instead - but you get the idea.
And the bigger yet problem is that the author may be completely in the dark about someone checking for his components.

[AL|EN]

It's not necessarily that simple. In fact, you posted a good example of this yourself:
Code: [Select]
item_rev(6|7|8|1040|1041|1042|1043)>fullplate(1)
Originally there only used to be 6, 7 and 8 components that were in conflict. And then four more have been added, which contained the same exact incompatibility with FP&PS. I.e. either the ID had to be shared by multiple components; or FP&PS would need to check for additional GIUDs, which is not so different from re-checking the status of IR's DESIGNATED numeration; or IR couldn't split its components, which, well, is as ridiculous as it sounds.

The case of DESIGNATED:
item_rev(6|7|8|1040|1041|1042|1043)>fullplate(1)

- item_rev and fullplate can't change DESIGNATED numbers/can't split components without making this conflict invalid or even producing nonsense results
- it's true that if the 1040|1041|1042|1043 were added later, conflict definitions need to be updated

The case of GUID:
//old item_rev(6|7|8|1040|1041|1042|1043)>fullplate(1)
DgoOAQoHBwI|CgsLCwMLBAI|Bw0HCgMFCAo|AQENBQ0NDgo|CAMPDAoGAgc|AgUADAcJDQQ|DgsDCgoGBgk > DwcHAQEJAAk

- item_rev and fullplate can change DESIGNATED numbers/can split components preserving at least some of the conflict data
- if the GUID is changed there is no danger of showing nonsensical conflict from my first post example, conflict will be disabled
- it's true that if the AQENBQ0NDgo|CAMPDAoGAgc|AgUADAcJDQQ|DgsDCgoGBgk GUIDs were added later, conflict definitions need to be updated

That's only for two mods. When you use five or more, every single change of DESIGNATED numbers creates hell. GUID can save us from applying nonsensical conflict.

The problem is that mod author first needs to know what makes compatibility concerns for other mods. ... And the bigger yet problem is that the author may be completely in the dark about someone checking for his components.

There are some mod authors that are not aware about other mods which use DESIGNATED to setup conflicts between mods. That is how it works/looks today. One smal change with the DESIGNATED number for the mod of unaware author and ... boom! That's where GUID can help.

[AL|EN]

Wait... thinking this through, why can't we already do this? Why does GUID/UUID have to be a new, separate thing? Can't a smart modder generate one, and simply use it as a LABEL?
So really, if the functions that check against DESIGNATED and component numbers could be extended to work equally well with LABELs, wouldn't we be 99% of the way there?
(Or get rid of LABEL and simply allow text strings to be used with DESIGNATED)

That's very good point! It doesn't have to relay/be bound to tp2 if it's accepting generated GUID. But what are consequences of touching DESIGNATED from the context of weidu internal component functionality which use DESIGNATED to installing/reinstalling/weidu.log ?

I'm tired, will think about it later.

[subtledoctor]

Yeah using text in DESIGNATED is probably more trouble than it's worth.  The easier route would likely be to allow REQUIRE and FORBID et al. to work with LABELs as well as component numbers.

CONFLICT ~AL|ENS_mod.tp2~ ~CgACDAAKCwk~ // yes this is my new proposed component flag

Nope, GUID don't relay/is not bound to tp2: CONFLICT ~CgACDAAKCwk~ is all what you need to have.

Ah - the point you raise about .tp2 independence is a good one.  But perhaps there is a simpler way to get there.  Maybe Weidu could allow .tp2 independence, like so:

Code: [Select]

BEGIN ~awesome win-button item pack~
LABEL ~awesome_items~
FORBID_COMPONENT ~*.tp2~ ~CgACDAAKCwk~
So, if you see that another mod sensibly uses a GUID, you could say "forbid install together with that component, no mater where it goes in the future." Obviously you would not want to do it with, say "~*.tp2~ ~main_component~" but that's just a question of, again, encouraging modders to use best practices.

It's not necessarily that simple. In fact, you posted a good example of this yourself:

Code: [Select]

item_rev(6|7|8|1040|1041|1042|1043)>fullplate(1)Originally there only used to be 6, 7 and 8 components that were in conflict. And then four more have been added, which contained the same exact incompatibility with FP&PS. I.e. either the ID had to be shared by multiple components; or FP&PS would need to check for additional GIUDs, which is not so different from re-checking the status of IR's DESIGNATED numeration; or IR couldn't split its components, which, well, is as ridiculous as it sounds.

As I think about this, there's no reason multiple components couldn't share a GUID or a LABEL, right?  And CONFLICT/FORBID/REQUIRE could work on all of them.  And by the same token, there's no particular reason a single component couldn't have multiple LABELs or GUIDs.  So maybe this problem I presented is solvable.  But, again, as I think about ways to solve it, it looks a LOT like it's just replicating what I already do with marker files.

Still and all, I see some concrete ways to move toward AL|EN's vision (albeit with baby steps that don't break backward compatibility):
- Allow REQUIRE and FORBID and similar flags to recognize and work with LABELs in addition to integer component numbers (maybe you can already get there with ID_OF_LABEL but that looks clunky to use in this way)
- Allow .tp2 wildcards when specifying the mod in REQUIRE, FORBID, et al.
- Create a CONFLICT flag that doesn't actually forbid anything but only records a conflict and displays a text string explaining it (okay, I've been harping on this, I'll stop now)

[AL|EN]

If weidu allow for "*.tp2" it might also don't require it:

Code: [Select]

FORBID_COMPONENT ~CgACDAAKCwk~

Obviously you would not want to do it with, say "~*.tp2~ ~main_component~" but that's just a question of, again, encouraging modders to use best practices.

Generating GUID eliminate such possibility. It also avoid tension/fight between two modders who will setup LABEL as "awesome_items"/"cursedItems" for their mods which alters cursed items because "it's my label!"

But, again, as I think about ways to solve it, it looks a LOT like it's just replicating what I already do with marker files.

Are you talking about files such as override\EET.flag? They are some sort of solution but can't be included to --list-components-JSON because it's arbitrary code.

As I think about this, there's no reason multiple components couldn't share a GUID or a LABEL, right?  And CONFLICT/FORBID/REQUIRE could work on all of them.  And by the same token, there's no particular reason a single component couldn't have multiple LABELs or GUIDs.

Are you talking about something like this:

Code: [Select]

BACKUP ~item_rev\backup~
AUTHOR ~item_rev~
//only those components are enabled in item_rev v4
BEGIN ~1040~
DESIGNATED 1040
GUID/LABEL ~CwEHCw0IBQk~ ~AQENBQ0NDgo~

BEGIN ~1042~
DESIGNATED 1042
GUID/LABEL ~CwEHCw0IBQk~ ~AgUADAcJDQQ~

Alternative syntax using GUID/LABEL_GROUP:

Code: [Select]

BACKUP ~item_rev\backup~
AUTHOR ~item_rev~
//only those components are enabled in item_rev v4
BEGIN ~1040~
DESIGNATED 1040
GUID/LABEL ~AQENBQ0NDgo~
GUID/LABEL_GROUP ~CwEHCw0IBQk~

BEGIN ~1042~
DESIGNATED 1042
GUID/LABEL ~AgUADAcJDQQ~
GUID/LABEL_GROUP ~CwEHCw0IBQk~

For this case, mods/external system are able to:
1. Setup conflict for all components which related to "Revised Armor" by using single GUID/LABEL

Code: [Select]

// item_rev 1040 and 1042 (and all future components which will have the same  GUID/LABEL ) vs fullplate 1
CwEHCw0IBQk > DwcHAQEJAAk
if there will be a future components which will still related to "Revised Armor", using the same GUID/LABEL can include those components for already existing external conflicts/dependency eliminating the need to edit mods/external systems.

2. Setup conflict/dependency only for single component,

Code: [Select]

// only item_rev 1040 vs fullplate 1
AQENBQ0NDgo > DwcHAQEJAAk
So maybe allowing the same GUID/LABEL for single component is not a bad thing. Without it, we eliminate a possibility to split components and keep FULL conflict data for mods/external systems. The GUID/LABEL which is used many times for multiple components act as "GUID/LABEL_GROUP" same as "GROUP" for components. Does "GUID/LABEL_GROUP" is reasonable addition because it follows  same logic as "GROUP" for components?

This would require some understanding of the conflict/dependency concept for mods/external systems but I'm sure that we can document it pretty well.

Even if we can get everything from LABEL, i'm still not convinced that it should be called "LABEL" because it doesn't define purpose/context of what it will be used for. An alias would be a good addition.

[AL|EN]

I'm trying to test ID_OF_LABEL (let's forget now about tp2 dependency) but it doesn't work:

Code: [Select]

BEGIN ~6~
DESIGNATED 6
LABEL ~CwEHCw0IBQk~
PRINT ID_OF_LABEL ~setup-GUIDExample.tp2~ ~CwEHCw0IBQk~
Anyone can post working code?

[Wisp]

You need to use an intermediate variable.

[GeN1e]

As I think about this, there's no reason multiple components couldn't share a GUID or a LABEL, right?  And CONFLICT/FORBID/REQUIRE could work on all of them.  And by the same token, there's no particular reason a single component couldn't have multiple LABELs or GUIDs.  So maybe this problem I presented is solvable.  But, again, as I think about ways to solve it, it looks a LOT like it's just replicating what I already do with marker files.

Yes, markers are so far the most flexible. The ideal solution, as I see it, would be content type register as a component flag, and also as an action to append the list manually - so that if you comment out a section of code or uninclude a tph, you'll also automatically disable the marker/register associated with that section. Basically, the exactly same thing as markers, but somewhat more robust if we assume the component flag to be mandatory (while the tp2 action remains optional).
I also don't think it would need a real GUID, just using author's nickname as prefix should be enough, even if it migrates across tp2s, from mod to mod. While there's already some other "Ardanis" registered here on PPG, and we have two Avengers, I'm rather confident such things will resolve themselves before it comes to mod publishing.

[AL|EN]

You need to use an intermediate variable.

That's not really helpful for someone who never write tp2 mod except playing with weidu commandline/components etc

I also don't think it would need a real GUID, just using author's nickname as prefix should be enough, even if it migrates across tp2s, from mod to mod. While there's already some other "Ardanis" registered here on PPG, and we have two Avengers, I'm rather confident such things will resolve themselves before it comes to mod publishing.

And then we will see "Ardanis" flag inside "Avenger" mod. Misleading and complete mess.

[Wisp]

The amount of work involved in loading and parsing all TP2 files in order to find some particular UUID would be stupidly large. This would especially be an issue in BWP contexts, where you can have a large number of TP2 files in the same game. On the whole, I think the number of times where it's useful to be free of the TP2 file (so far, pretty much only when a component migrates from one TP2 to another) is by far outweighed by the number of times it would be useful to limit the scope of the search (pretty much every time).

DESIGNATED assigns component numbers. These must be numbers.

Similarly, UUIDs would need to be resolved into component numbers before they could be used by predicates.

[Wisp]

You need to use an intermediate variable.

That's not really helpful for someone who never write tp2 mod except playing with weidu commandline/components etc

Code: [Select]

BEGIN ~6~
DESIGNATED 6
LABEL ~CwEHCw0IBQk~
OUTER_SET num = ID_OF_LABEL ~setup-GUIDExample.tp2~ ~CwEHCw0IBQk~
PRINT "%num%"


[GeN1e]

I also don't think it would need a real GUID, just using author's nickname as prefix should be enough, even if it migrates across tp2s, from mod to mod. While there's already some other "Ardanis" registered here on PPG, and we have two Avengers, I'm rather confident such things will resolve themselves before it comes to mod publishing.

And then we will see "Ardanis" flag inside "Avenger" mod. Misleading and complete mess.

There's already some "Ardanis"-labeled content inside SCS, plus it helps with tracking original coder and is human-readable. Much like variables, you can generate unique names or you can use self-descriptive ones whose function is immediately recognizable, and is easier to maintain.
I predict there'd be higher rate of human error with randomly generated IDs you'd have to look up every time you need to work with compatibility, than with descriptive labels that may on a rare occasion jump between mods. Even ctrl-c/v is not a salvation here. Might as well switch to machine code.
If you get a dupe label, it can be easily checked by simply reading the code and fixed. If you accidentally mess up with GUID in some way, it'll take effort to figure out just where the error came from in the first place.

[AL|EN]

First experiments with LABEL:

- in the current state, it is keyword/feature which nobody uses. Proof: I've checked more than 600 mods https://pastebin.com/raw/TKBBsRw0 and noone is using LABEL component keyword.

Can we at lest agree that in order to make it useful, something need s to be changed/improved and there is no problem of "breaking old mods" ?

[Wisp]

First experiments with LABEL:

- in the current state, it is keyword/feature which nobody uses. Proof: I've checked more than 600 mods https://pastebin.com/raw/TKBBsRw0 and noone is using LABEL component keyword.

Can we at lest agree that in order to make it useful, something need s to be changed/improved and there is no problem of "breaking old mods" ?

I'm open to suggestions. I think it's already been suggested you could probably add a set of predicates that take a label directly and transparently resolve it into a component number. Maybe you could even adapt some or all of the existing predicates.

But I would be entirely unsurprised if the low to non-existent usage of LABEL was less due to its properties and more due to one or more of the following:
1. The usage of marker files is too ingrained.
2. The majority of mods predate LABEL.
3. Low awareness of LABEL and "new" features in general. Many modders probably do not code their mods ab initio, drawing upon all available features (or the subset best suited for the task). Instead they do like they did in the past and/or draw more or less heavily upon example code. So in effect, established patterns stay established and new features are underutilised.

But we have a few people participating here. Everyone, why are you not using LABEL and is there anything that could be changed about it that would make you start using it?

[subtledoctor]

Yes, markers are so far the most flexible. The ideal solution, as I see it, would be content type register as a component flag, and also as an action to append the list manually - so that if you comment out a section of code or uninclude a tph, you'll also automatically disable the marker/register associated with that section. Basically, the exactly same thing as markers, but somewhat more robust if we assume the component flag to be mandatory (while the tp2 action remains optional).
I also don't think it would need a real GUID, just using author's nickname as prefix should be enough, even if it migrates across tp2s, from mod to mod. While there's already some other "Ardanis" registered here on PPG, and we have two Avengers, I'm rather confident such things will resolve themselves before it comes to mod publishing.

The downside to marker files - and, I think, what we are considering here - is that I don't think a GUI Weidu app could read marker file dependencies and forbiddances and translate them into visual conflicts in the GUI.  Whereas, it's seems straightforward (kind of? maybe?) to read component numbers and labels and utilize or display such stuff.

[subtledoctor]

I'm open to suggestions. I think it's already been suggested you could probably add a set of predicates that take a label directly and transparently resolve it into a component number. Maybe you could even adapt some or all of the existing predicates.

But I would be entirely unsurprised if the low to non-existent usage of LABEL was less due to its properties and more due to one or more of the following:
1. The usage of marker files is too ingrained.
2. The majority of mods predate LABEL.
3. Low awareness of LABEL and "new" features in general. Many modders probably do not code their mods ab initio, drawing upon all available features (or the subset best suited for the task). Instead they do like they did in the past and/or draw more or less heavily upon example code. So in effect, established patterns stay established and new features are underutilised.

But we have a few people participating here. Everyone, why are you not using LABEL and is there anything that could be changed about it that would make you start using it?

I'm not using LABEL because I didn't know it existed.     Also I don't know what it gets me.  DESIGNATED is important because it can be used as predicates.  If LABEL could be used with the same usage, interchangeably I would probably switch to LABEL.

But, of course, there are many mods that won't switch, because they are not being updated.  That's why I suggest labels and component numbers be used interchangeably - so there is a fallback that doesn't require the use of two different systems.