Pocket Plane Group
Friends and Neighbors => Weimer Republic (WeiDU.org) => WeiDU => Topic started by: AL|EN on July 23, 2017, 09:59:23 AM
-
I decide to split this from "add keywords for components" topic because there might be a longer discussion related to how it should be implemented.
Weidu should provide a way to generate unique identifier across world of weidu mods. Such GUID/UUID should be require for every single components to have them.
Requirements for GUID/UUID:
- unique
- short
- doesn't relay on DESIGNATED because mod authors should be free to change it and reorder mod components
Requirements for weidu:
- ability to generate such GUID/UUID( weidu.exe --new-GUID/UUID <amount>?)
- include GUID/UUID for --list-components-JSON data
- add GUID/UUID to weidu.log in order for other mods to check installation for specific components
- 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
Requirements for mod authors:
- one-time generation of GUID/UUID for every component and add it for every mod component
- it should never change for the components which has the same functionality so you can change DESIGNATED number and reorder as much as you want
- it should be changed only in specific situations like complete code rewrite ( so component no longer has technical conflict with others )
Those are good examples which I found:
https://stackoverflow.com/questions/9543715/generating-human-readable-usable-short-but-unique-ids (https://stackoverflow.com/questions/9543715/generating-human-readable-usable-short-but-unique-ids)
http://hashids.org/ (http://hashids.org/)
Why we need them? Let's look at one of the conceptual conflicts between mods:
1. Simple "Armor encumbrance":
item_rev(6|7|8|1040|1041|1042|1043)>fullplate(1)
This conflict is external so it fully relay at the DESIGNATED component numbers. Every ... single ... change and this conflict not only is not correct but it prevents installing wrong components.
2. It might also produce nonsense, example:
Components:
ModA(10) = "Main component"
ModA(100) = "Portrait component"
ModB(1) = "Main component
ModB(2) = "Portrait component"
Conflict:
ModA(100) > ModB(2)
Conflict before DESIGNATED change:
ModA "Portrait component" is preferred to ModB "Portrait component"
DESIGNATED change:
ModA(100) = Main component
ModA(200) = Portrait
Conflict after DESIGNATED change:
ModA "Main component" is preferred to ModB "Portrait component" - nonsense!
This is not something uncommon because there are over 1200 of such conflict in BWS conflict database, I've encounter such situation many, many times. It must be prevented in order to have any sane solution for mod external conflicts database. It might also eliminate the same problem for Weidu/Zeitgeist: compatibility reporting - http://forums.pocketplane.net/index.php/topic,29642.0.html (http://forums.pocketplane.net/index.php/topic,29642.0.html)
-
Playing devil's advocate again, what will become the very purpose of DESIGNATED if you can change it at will?
1. Simple "Armor encumbrance":
item_rev(6|7|8|1040|1041|1042|1043)>fullplate(1)
This conflict is external so it fully relay at the DESIGNATED component numbers. Every ... single ... change and this conflict not only is not correct but it prevents installing wrong components.
Why would there be a change, though? As you may have noticed, the numbering is a little odd here, from 6,7,8 and straight into 1040s. The mod was expanding, but existing component designation was already crammed with no room left for insertions. And I couldn't just go and remap them, because that would likely throw sticks into BWS' wheels, so instead I kept existing designation and numerated new components with some space between them.
Then, later on, we made most of the choices mandatory, and only allowed to choose between having or not movement speed encumbrance, leaving just 1040 and 1042. Yes, it doesn't seem very pretty it you look inside tp2, but I believe it still does the job it was designed for, no?
What would change if we used unique IDs instead? Remap the designation, for once, but what would be the point of still having it at all then?
PS If there're modders who change designating with each new version, then they're not using DESIGNATED the way it was intended for. In other words, the problem is with mod authors, not with WeiDU.
PPS I guess this qualifies as material for your "wrong ways to do things" thread at G3, huh? :D
-
GeN1e, good feedback but...It's not the question why there ba a change, it only matter that it can be changed and they will. You are trying to relay on people to follow best practices. It was never the case for most of the weidu mods. Partially because lack of weidu standards, proper documentation with examples. I've seen to many DESIGNATED changes like this:
"1 2 3" > "10 11 20 21 22 30 31 32 33"
to have faith that they would not change in the future. The DESIGNATED numbers are used to directly interact with mod installation procedure so mod authors who want's to have an nice setup of the components can change them and they will change them. On the other side, mod own GUID/UUID's aren't user internal by mod code - they are used by external systems (BWS/Mod Database/Other Mods) so once generated and putted inside tp2, mod author won't take look at them anymore.
And finally, we see great cooperation between mod authors. They started to donate the components from their own mods to other mods because "A.I." mod is no place for "Changingg NPC stating location". Recent examples are SoB/M&G/T&B/F&F and Tweaks Anthology mods. In case when such donation occurs, DESIGNATED numbers are 90% likely to change. But GUID/UUID's won't so they can travel across various mods without affecting them and other external systems! :)
I hope that this shows how badly we need GUID/UUID's.
-
Thing is, if they can change DESIGNATED at will, what's stopping them from accidentally the ID as well. You'd still be relying on people to not mess it up. The only advantage I see is ID being a new thing with specific set of instructions to accompany, so it has a greater chance of people paying closer attention rather than telling everyone to use DESIGNATED the way it was meant to be. I.e. it's more like a way to address the existing human issue than to fix what wasn't really broken in code. If that was the idea, then I guess you have a point.
-
They won't change GUID/UUID's because there is no purpose of doing that. There are few cases when the DESIGNATED needs to be changed because mod evolution and you cannot shout at mod authors because they care about details. The advantage of the GUID/UUID's is the fact that won't change when mod components will be donated/transferred into other mods. DESIGNATED numbers for modA can be the same as DESIGNATED numbers for modB. For such case, they DESIGNATED numbers needs to be changed and it shouldn't affect external systems. GUID/UUID's can't have conflicts so they won't be changed.
-
Why is this better than LABEL and why would it see greater adoption?
Yes, LABELs are within the scope of the TP2 and do not allow straightforward migration of components between TP2s, but how often does that happen?
-
Because:
- is not required
- any component can have zero or more LABELs instead of one unique
- if two components in the same tp2 share a LABEL it will print only warning instead of blocking error
- it can be anything like 'mycat12$' instead of generated value
It doesn't matter how often components migration/donation happen - if they do, without GUID/UUID the consequences for other mods/external systems are so bad, that it prevent's doing such migration in the first place.
-
- is not required
This can't be required either, because WeiDU can't start failing mods for not using features that did not exist when the mod was written.
- any component can have zero or more LABELs instead of one unique
What's wrong with more than one LABEL?
- if two components in the same tp2 share a LABEL it will print only warning instead of blocking error
There's arguably no good time to fail a mod for incorrect LABELling (no, I don't think running a bunch of validation at install-time is a good idea). But fair enough, it's a shortcoming.
- it can be anything like 'mycat12$' instead of generated value
So alphabet soup is better than something meaningful and/or memorable?
-
This can't be required either, because WeiDU can't start failing mods for not using features that did not exist when the mod was written.
Old mods won't be affected after you disable auto-overwrite scheme and GUID/UUID should be required because otherwise it's useless and there is no point of implementing it if nobody will use it.
What's wrong with more than one LABEL?
Well, the purpose/definition of GUID/UUID in any system is to have one GUID/UUID per something. Not ten or one hundred.
So alphabet soup is better than something meaningful and/or memorable?
Yes, because it can be validated/verified if this is a valid GUID/UUID and not something madeup. With something memorable there is always a temptation to change it.
I have the impression that you trying to show that everything is already done and everyone can use it since beginning of weidu. Obviously is not the case. When I take closer look at LABEL, it turned out to be completely useless. Nice idea but bad implementation. It can't even serve as "TAG" replacement. Thus I'm requesting not only a new keyword but also have in mid how it should be used, for what purpose. This feature is really necessary for mod database/mod installer/component conflicts.
-
This can't be required either, because WeiDU can't start failing mods for not using features that did not exist when the mod was written.
Old mods won't be affected after you disable auto-overwrite scheme and GUID/UUID should be required because otherwise it's useless and there is no point of implementing it if nobody will use it.
Only on Windows will you always have profligate copies of the WeiDU executable in the game directory.
Some Mac packages will have a copy of WeiDU, but if the Mac package was made by a Windows-based modder, the weidu binary will often not have the executable bit set. So, many Mac users (who may be unfamiliar with Unix commands like chmod) dump the un-executable binary and use subtledoctor's Mac WeiDU Launcher instead. It places a single copy of the weidu executable in the game directory and then creates symlinks to it for each mod. In fact, subtledoctor's own mods come packaged with it instead of a Mac version of WeiDU named setup-[modname].
Linux versions of mod packages generally do not contain a WeiDU executable at all. The standard install method is to download WeiDU separately, and place a copy of the weidu and weinstall binaries in a directory in the user's $PATH (e.g., /opt/bin) and then install mods using the command "weinstall [modname].tp2".
-
If you have single weidu binary which is used to install mods for MAC/OSX and even Windows users, it's still the old weidu, without new requirements so the old mods are perfectly fine. I really don't see a problem which you trying to show.
-
This can't be required either, because WeiDU can't start failing mods for not using features that did not exist when the mod was written.
Old mods won't be affected after you disable auto-overwrite scheme and GUID/UUID should be required because otherwise it's useless and there is no point of implementing it if nobody will use it.
Mods will continue to run with the latest WeiDU in the foreseeable future. If (and this is a very big if) that changes, it'd probably be even further away than the long term.
What's wrong with more than one LABEL?
Well, the purpose/definition of GUID/UUID in any system is to have one GUID/UUID per something. Not ten or one hundred.
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?
So alphabet soup is better than something meaningful and/or memorable?
Yes, because it can be validated/verified if this is a valid GUID/UUID and not something madeup. With something memorable there is always a temptation to change it.
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.
I have the impression that you trying to show that everything is already done and everyone can use it since beginning of weidu. Obviously is not the case. When I take closer look at LABEL, it turned out to be completely useless. Nice idea but bad implementation. It can't even serve as "TAG" replacement. Thus I'm requesting not only a new keyword but also have in mid how it should be used, for what purpose. This feature is really necessary for mod database/mod installer/component conflicts.
You want something that can be used to refer to components that is not component numbers, because over a sufficiently large data set, components change over time. That's LABEL. I can't do different implementations for everyone simply because the current implementation is not to someone's liking. Sure, if there are technical shortcomings that prevent the feature from fulfilling its purpose, that's different, but so far I don't think you've raised any? (That would not apply equally to GUIDs.) Feel free to correct me if you have.
But to discuss you idea: you are essentially proposing a hash function that generates short hash values. But you don't specify what should be hashed in order to generate this value. How should different authors be prevented from hashing the same thing and getting the same hash values? The uniqueness metrics only deal with the probability of different things resulting in the same hash value. Identical things are always going to give the same value.
-
My thoughts:
Supposedly what will be hashed to generate a corresponding GUID/UUID will be a block of code (which will functionally be a string of bytes). For now, let's assume this block of code will be an entire component (so that it matches the 'scope' of what LABEL currently identifies). The hash is generated from this particular string of bytes to produce a unique identifier. Now let's suppose a second modder borrows this component from the first modder and adds it to his mod. The second modder uses spaces to indent his code while the first modder used tabs, and the second modder modifies the code to use spaces so it flows with the rest of the code in his TP2. Or if you don't like that, say one modder notices a typo in the comments and corrects it. Hell, one modder is on Windows and the other is on Mac, and the line endings get changed from CRLF to LF. In any of these cases, what the component actually does stays the same, but since the 'string' has changed, the hash has changed. My point is hashing changeable code (especially since changes can be made without modifying the code's output) and verification by re-hashing are not practical or useful things. It would be much more meaningful to generate a GUID/UUID, use that as the LABEL, and add code comments and a note in your copyright section to NOT ever change the LABEL unless there is a significant change in what the code block does.
Suppose you generate a GUID/UUID of a component titled "Add Spells", and all that component does is call a function titled "copy_spells". A second modder hashes his component which happens to have identical code, but his "copy_spells" function copies completely different spells into the game. GUID/UUID hashes to the same value, but the in-game results are completely different. Again, you'd be better off doing something like hashing your function and using that GUID/UUID as your component's LABEL.
-
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 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".
Practical implication are going even further: if a component can have more than GUID/UUID, then people will be confused about it's purpose. How I could write a component dependency if one component will have 5 GUID/UUID! Which one I should place my beat? There are no guaranties that the mod author won't remove the one I've chosen "because I can!" But if there is ONE GUID/UUID for ONE component it won't be a problem because the purpose of it is clear and there is no point of even looking at the GUID/UUID after adding it to the component code.
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.
But to discuss you idea: you are essentially proposing a hash function that generates short hash values. But you don't specify what should be hashed in order to generate this value. How should different authors be prevented from hashing the same thing and getting the same hash values? The uniqueness metrics only deal with the probability of different things resulting in the same hash value. Identical things are always going to give the same value.
No, that is not something I've requested. I requested new KEYWORD called GUID or UUID, define it's requirements and purpose. I've posted examples about implementation but I think that looking at the http://hashids.org (http://hashids.org) might be the reason why you assume that I'm requesting hash function. I'm not, it was just a link to code examples for code/decode examples.
So let me use example (for this example, forget about my requirements that it should be much shorter):
1. open http://guid.us/ (http://guid.us/) and copy GUID - you will have a properly generated GUID ( I need a way to make it shorted, let's skip this requirements for now)
Here is your new GUID:8b97a0a3-048b-45db-8c4a-97f040448244
2. open http://guid.us/Test/GUID (http://guid.us/Test/GUID) paste GUID and click validate - you will have a properly validated GUID
GUID Test results:
Yes, that is GUID!
Here it is right back at you: 8b97a0a3-048b-45db-8c4a-97f040448244
Viola! We have a way to generate GUID and a way to validate it. Validation of the GUID will ensure that it was properly generated and eliminate the chance of the same GUID/UUID for multiple components.
You want something that can be used to refer to components that is not component numbers, because over a sufficiently large data set, components change over time. That's LABEL. I can't do different implementations for everyone simply because the current implementation is not to someone's liking. Sure, if there are technical shortcomings that prevent the feature from fulfilling its purpose, that's different, but so far I don't think you've raised any? (That would not apply equally to GUIDs.) Feel free to correct me if you have.
It's not about liking, it's about that LABEL doesn't work as I want. I've posted many technical shortcomings that prevent the feature from fulfilling its purpose:
- I have given the condition that it must be one, unique GUID/UUID
- I have given the condition that GUID/UUID can't be some arbitrary strings because they must be validated in order to check if it's a real GUID/UUID
- I have given the condition that GUID/UUID should be required for every component
- I have given the condition that GUID/UUID should be added to weidu.log
- also, LABEL was used by mod authors before for completely different purpose and context that GUID/UUID will be used
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. If those aren't "technical shortcomings that prevent the feature from fulfilling its purpose" that I don't know what else I could say. 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?
-
If LABEL is used the same way as DESIGNATED/COMPONENT, then there should never be a collision:
FORBID_LABEL ~mymod.tp2~ ~generic_item_pack_label~
I get the benefit of GUID/UUID, but my concerns are
1) How much are the benefits, compared to a well-handled LABEL
2) What are the burdens required to make it happen? Specifically,
- What, precisely, will Weidu have to do to create these?
- What, precisely, will modders have to to to implement it?
-- Corollary: what happens to old mods and/or modders who do nothing?
(Yes, I'm aware that the corollary concern applies equally to LABEL)
-
If LABEL is used the same way as DESIGNATED/COMPONENT, then there should never be a collision:
FORBID_LABEL ~mymod.tp2~ ~generic_item_pack_label~
That won't work because in this case, label is combined with tp2 name and it will fail after donation/component move to another mod and then domino of the dependence across various external systems (mods/BWS) will also fail. If it would be used that way, it would completely prevent component donation because of the repercussion. Also, when it comes to writing conflicts, I want to achieve simplicity:
# Data for describing conflicts between ModA with ModB: CgACDAAKCwk>AQEPCQYLBQg
or for tp2
BEGIN 0
GUID/UUID "CgACDAAKCwk"
// My component has conflict with ModB copmponent
FORBID_GUID/UUID "AQEPCQYLBQg"
That's it, nothing more.
I get the benefit of GUID/UUID, but my concerns are
1) How much are the benefits, compared to a well-handled LABEL
2) What are the burdens required to make it happen? Specifically,
- What, precisely, will Weidu have to do to create these?
- What, precisely, will modders have to to to implement it?
-- Corollary: what happens to old mods and/or modders who do nothing?
(Yes, I'm aware that the corollary concern applies equally to LABEL)
1. Since LABEL doesn't provide any of the GUID/UUID functionality, and the LABEL was used for the different pupse before, I would say thet the benefits are infinite.
2a. Litte to nothing. After agreement about what function should be used, we can relay on external online generators / third pary multi platform solutions.The only weidu change which is required is to fail when there is no GUID/UUID. Next, weidu can implement standard validation function. And finally it's own function to generate such GUID/UUID but it would provide the same results as other solutions. But we need to have foundations for modders / external systems to work.
2b. Generate GUID/UUID by using accepted solution and then put the:
GUID/UUID <generatedGUID/UUID>
for each mod component, that's it. As soon as two mod will implement those, mod authors can implement reliable conflict definitions, which will be used by next BWS and waiting for weidu/Zeitgeist code to handle them internally.
2c: For old mod and unmaintained mods (yep, those 100 BG2 kit mods), nothing will change because weidu should stop auto-update functionality anyway. Weidu can even have "experimental" code branch with all those new features, without affecting old mods at all. For old mods which recently got support, they will be updated because such update require no coding skill.
As for the modders who won't do a thing: are we really want to abandon all solutions to problems because of the people who won't do something? This type of thinking will lead to nowhere.
Now, do me a favor and ask the opposite question: what happens if GUID/UUID won't be implemented?
-
You described what you believe the EXTENT ("infinite") of the benefit over a non-colliding LABEL, but you did not describe WHAT the benefit is. That is still not clear to me.
2) What are the burdens required to make it happen? Specifically,
- What, precisely, will Weidu have to do to create these?
- What, precisely, will modders have to to to implement it?
-- Corollary: what happens to old mods and/or modders who do nothing?
2a. Litte to nothing. After agreement about what function should be used, we can relay on external online generators / third pary multi platform solutions.The only weidu change which is required is to fail when there is no GUID/UUID. Next, weidu can implement standard validation function. And finally it's own function to generate such GUID/UUID but it would provide the same results as other solutions. But we need to have foundations for modders / external systems to work.
2b. Generate GUID/UUID by using accepted solution and then put the:
GUID/UUID <generatedGUID/UUID>
for each mod component,
See, you lost me right there. Modders should not have to (and will not, even if they should have to) go get on a 3rd-party website and generate a meaningless string of characters (which will be lost forever if ever mistakenly deleted or edited) and add this to their .tp2 files. It just won't happen. And what do you do to the modders who don't do it? How do you enforce this? Chuck a parse error at them?
At least, with something like DESIGNATED or LABEL, you could theoretically throw a parse error at them at say "every component must have a unique label." And modders will not freak out because they can simply call one component "items" and another component "kits" etc. That is noob-friendly. If you demand a GUID/UUID they will just go "WTF is a GUID/UUID???"
- If you make LABEL semi-mandatory, people will not freak out, and if you are slick you could pretty easily convince them that it is a good thing.
- If you use DESIGNATED/component # as a backup value for mods with missing LABELs, you won't have any issue with old unmaintained mods, because every mod automatically has component #s, and if a mod is not maintained then by definition the component #s aren't changing anymore.
Does that get us 100% of the way to conflict-identification Nirvana? Nope. But it gets us about 97% of the way there, and realistically that is close enough.
To recap: I understand what you are saying about the benefits of GUIDs/UUIDs for mod components. But it is a pipe dream that will never happen. It is Utopia - "no-place." I'll take 97% of Nirvana over 100% of Utopia.
-
I don't closely follow BWS/BWP development and its forums, so I may be slightly out of touch with reality here. However, is there any particular reason why BWS can't be limited to a small selection of mods with a stamp of quality on them? If we take a step back and think what caused this all, I believe it began with BWS running out of power to maintain expert installations, that seem to include pretty much everything under the sun.
I understand your predicament quite perfectly, because I'm aware what it means to try keeping in order the environment that changes constantly and out of your control. The series of your recent proposals clearly indicates you'd rather pass the burden of maintenance over to mod authors themselves - which is how it should be anyway.
My problem is that the way ideas are currently going, people will end up having to bear responsibility for mistakes made by less competent modders. Let's imagine someone, e.g. Chimeric who not so long ago boasted he gave no damn about existing rules and ethics, makes a mod that jeopardizes stability and compatibility of the entire game installation. Would you ask the community to adapt to new standards so that such mod can be included into BWS, or would you rather skip it?
-
See, you lost me right there. Modders should not have to (and will not, even if they should have to) ... It just won't happen.
It's you assumption, nothing more! I already have confirmation from K4thos that he will do it without blink of an eye. How about that? The only question is: will you do it? Will you accept Pull Request "Added GUID/UUID"? As soon as the weidu will support it's own GUID/UUID function, this "problem" will gone. Hey, I can pay someone to implement this code tomorrow. Will you be happy?
... string of characters which will be lost forever if ever mistakenly deleted or edited) and add this to their .tp2 files.
They won't be lost because as soon as there will be a new version of the mod with GUID/UUID, other mods/external systems will use them to describe component dependency. So in case of code loos, components can be have the same GUID/UUID as before. And there is old version of the mod uploaded somewhere. And there are local copies of the mod. You are showing something which is not a problem at all. Next time, try to think it through.
And what do you do to the modders who don't do it? How do you enforce this? Chuck a parse error at them?
Nothing. They can still use old weidu and ignore new requirements. But the new weidu will require this as it brings great overall benefit for other mods/external systems/features.
At least, with something like DESIGNATED or LABEL, you could theoretically throw a parse error at them at say "every component must have a unique label." And modders will not freak out because they can simply call one component "items" and another component "kits" etc. That is noob-friendly. If you demand a GUID/UUID they will just go "WTF is a GUID/UUID???"
[size=78%]- If you make LABEL semi-mandatory, people will not freak out, and if you are slick you could pretty easily convince them that it is a good thing.[/size]
- If you use DESIGNATED/component # as a backup value for mods with missing LABELs, you won't have any issue with old unmaintained mods, because every mod automatically has component #s, and if a mod is not maintained then by definition the component #s aren't changing anymore.
GUID/UUID can be semi-mandatory until they became mandatory - no problem. Since next weidu, it can print a warning with this simple message:
WARRING:
Starting at weidu 250, GUID/UUID will be mandatory for every component. Put this line after BEGIN:
GUID/UUID "dynamicallyGeneratedGUID/UUID
How about that? Are you gonna tell me that a noob cannot put this into their tp2? Or read documentation? Or ask someone to help him?
And the combination of tp2 + DESIGNATED is already serving as backup solution.
Does that get us 100% of the way to conflict-identification Nirvana? Nope. But it gets us about 97% of the way there, and realistically that is close enough.
To recap: I understand what you are saying about the benefits of GUIDs/UUIDs for mod components. But it is a pipe dream that will never happen. It is Utopia - "no-place." I'll take 97% of Nirvana over 100% of Utopia.You ignored the fact that you "97% of Nirvana" is a solution which fails after donation/component move to another mod. It's "0% of Nirvana and 100% Hell" because in the long run, it makes impossible to donate/move component to another mod.
-
I don't closely follow BWS/BWP development and its forums, so I may be slightly out of touch with reality here. However, is there any particular reason why BWS can't be limited to a small selection of mods with a stamp of quality on them? If we take a step back and think what caused this all, I believe it began with BWS running out of power to maintain expert installations, that seem to include pretty much everything under the sun.
The problem is not in the number of mods because even if we would have only two mods: Tweaks Anthology and SCS, all maintenance/features problems would still be there. Believe me, I've made step back. That's why I've limited my BWS maintenance to absolutely minimum. Then, I take look at the reasons why 3 persons left the project. And I don't have good news for you. But instead of starting from whining, I've request solutions to solve global problems.
I understand your predicament quite perfectly, because I'm aware what it means to try keeping in order the environment that changes constantly and out of your control. The series of your recent proposals clearly indicates you'd rather pass the burden of maintenance over to mod authors themselves - which is how it should be anyway.
Yep, that's how it should be from the start, I'm glad that someone else finally see this. But the author of the BWS make it "I will take care about everything for you including:
- mod description, categorization, wiki and download link file size, file name och and workaround for shitty hosing sites and hacking of the NISI installers also
- mod component description (BWS renamed some components to indicate received feedback)
- components internal dependency from GUI perspective (they won't applied to commandline installation because of the "one by one" steps)
- components external mod/components dependency
- install order
- providing patches via BWFixpack
Now, it has to be "giving and receiving" approach.
My problem is that the way ideas are currently going, people will end up having to bear responsibility for mistakes made by less competent modders. Let's imagine someone, e.g. Chimeric who not so long ago boasted he gave no damn about existing rules and ethics, makes a mod that jeopardizes stability and compatibility of the entire game installation. Would you ask the community to adapt to new standards so that such mod can be included into BWS, or would you rather skip it?
Not only skip it but I would even remove such mod as I did with "38 Subraces" because it breaks every NPC romance.
Now, I'm gonna sleep for at least 12 hours.
-
A suggestion, if you want to win people to thinking your way, you should be a bit more respectful.
How often do components move from one mod to another?? I mean, people can deal with it on those rare occasions. Update stuff to account for it. (~mymod.tp2~ ~label~) becomes (~youmod.tp2~ ~label~). Doesn't sound so horrible to me. But what do I know, I don't think things through.
Not only skip it but I would even remove such mod as I did with "38 Subraces" because it breaks every NPC romance.
See honestly I think that's just wrong. What if a player understands those conflicts, and isn't interested in any NPC romances, but IS interested in adding subraces? You take away the ability of that player to use what is, in their install with no NPC romances, a perfectly fine and compatible mod. I've seen other such biased and misguided attempts at "curation" in BWS too, mods being moved to the inaccessible "expert" category because some maintainer didn't like the mod.
Maybe that's all well and good for BWS because hey, that's your business if it's your software. But should Weidu itself be making such subjective decisions? Just no.
-
A suggestion, if you want to win people to thinking your way, you should be a bit more respectful.
Suggestion taken. My questions still remains: assuming that weidu will give you the GUID/UUID generator at the flick of your fingers, will you add implement it? Or accept PR which do the work for you? You would have to do something anyway if you would want to use LABEL so how about putting the work and effort into something without LABEL flaws?
How often do components move from one mod to another?? I mean, people can deal with it on those rare occasions. Update stuff to account for it. (~mymod.tp2~ ~label~) becomes (~youmod.tp2~ ~label~). Doesn't sound so horrible to me. But what do I know, I don't think things through.
It doesn't matter how often components migration/donation happen - if they do, without GUID/UUID the consequences for other mods/external systems are so bad, that it prevent's doing such migration in the first place. In a year after first usage of the LABES, we could have 3 or more dependency, after two years, 5 or more. And if one single component would be moved, it needs four or more mods to adopt. I simply cannot advocate a half-backed solution because spending 1 minute to use solution which works can avoid all of this.
See honestly I think that's just wrong. What if a player understands those conflicts, and isn't interested in any NPC romances, but IS interested in adding subraces? You take away the ability of that player to use what is, in their install with no NPC romances, a perfectly fine and compatible mod.
I'm not taking away anything. If anyone wants to install it, he can. Not only using weidu but even with the combination of the BWS (pause and install). But I'm not gonna risk that some new player will be lurked by fancy mod name for his first modded game experience. It was the only mod which was removed from BWS and I place any bet that it was great decision. If someone thinks it's bad, fell free to fork BWS, restore it, publish the application using different name and provide support for it when players come and ask "why romances aren't working"
I've seen other such biased and misguided attempts at "curation" in BWS too, mods being moved to the inaccessible "expert" category because some maintainer didn't like the mod.
And why It's the first time when I hear about it? Can you post recent example of it? Anyway, I have already a solution to avoid similar situation for the future.
Maybe that's all well and good for BWS because hey, that's your business if it's your software. But should Weidu itself be making such subjective decisions? Just no.
Things which I request will be also a valid and reliable foundation for the features which you requested. But weidu doesn't exclude any mod from installing, can you please elaborate?
-
Yep, that's how it should be from the start, I'm glad that someone else finally see this.
I am and always was of the opinion that e.g. people shouldn't shuffle their DESIGNATED values. So it's not exactly "finally", rather "nothing new here".
But the author of the BWS make it "I will take care about everything for you including:
- mod description, categorization, wiki and download link file size, file name och and workaround for shitty hosing sites and hacking of the NISI installers also
- mod component description (BWS renamed some components to indicate received feedback)
- components internal dependency from GUI perspective (they won't applied to commandline installation because of the "one by one" steps)
- components external mod/components dependency
- install order
- providing patches via BWFixpack
This is exactly where my skepticism kicks in - BWS appeared out of nowhere, incorporated most of the mods out there regardless of what their authors may think, then something broke, and now BWS goes to dictate its own rules to the entire scene.
Don't get me wrong, I know there're players out there who'd rather use BWS than sit through readmes and manual installs, so it's very nice of someone to take it upon themselves to help those players out with installation process. But the key words are still "take it upon themselves". I can completely understand if there was some kind of application process for inclusion into BWS framework, like developers getting their games into Steam, but in this case Steam is trying to outlaw all developers who for whatever reason haven't yet sent their application form.
My opinion - you're just approaching it from the wrong end. BWS compatibility should be initiated by modders who made a conscious decision to be part of the project. Without it you'll be stuck chasing the train where each car goes its own rails, no matter what. With that in mind, a lot of your requests - e.g. invalid path names, lack of component descriptions, backup location etc. - wouldn't affect uninterested parties in any way, as they can be resolved through proper use of WeiDU. Even auto-update feature should be possible to circumvent with external installer calling setups renamed to back to weidu.exe and moved into appropriate mod folder (well, I think so, at least).
From my perspective it's less problems for everyone involved, from players to modders to WeiDU, if the latter retains its traditional behavior and requirements. I already said I may be in the dark, especially in recent years, but my impression of BWS has always been as "those crazy guys at SHS subforum", not as some kind of community manager everyone answers to. Mod authors wishing to step further can additionally integrate themselves into BWS (or, as case may be, BWS v2.0). I haven't seen Zeitgeist yet, so I can't say much about it atm.
-
We're talking about Weidu here, and you said "I would remove such a mod."
As for the rest, I just don't see what the consequences that would be "so bad" for a once-in-a-blue-moon occurrence. Components moving is literally no different from the creation of new mod components, and that's not going to stop. So what's the problem?
Plus if we had a deferential message-only INCOMPATIBLE flag like I suggested, then the component that moved could carry its conflict notifications with it!
[Modname + label] is basically the same as [prefix + 6-letter filename]... it works well file mod files, why not for labels? And I think modders will more likely willingly adopt a system like that - and realistically you need modders to adopt this system because, as I think about it, I don't see Weidu doing it automatically.
-
I am and always was of the opinion that e.g. people shouldn't shuffle their DESIGNATED values.
They should and they sometimes have to. We need solution for this, not calling them "bad weidu developers".
This is exactly where my skepticism kicks in - BWS appeared out of nowhere, incorporated most of the mods out there regardless of what their authors may think, then something broke, and now BWS goes to dictate its own rules to the entire scene.
It's not that something was broke only for BWS. I was always broken even for weidu. You blame BWS for problems caused by "not-optimal" weidu design. BWS was the place where those problems arise and has been noticed. Almost all BWS problems are also applied to weidu and Ziegsiet in future. I posted ideas how to solve them and pointed fals inside half-backed solutions/alternatives. It the already existing thing has not been used for the past 10 years it means that they are useless and we need something which will work. You call this "dictate its own rules to the entire scene." Really?
With that in mind, a lot of your requests - e.g. invalid path names, lack of component descriptions, backup location etc. - wouldn't affect uninterested parties in any way, as they can be resolved through proper use of WeiDU. Even auto-update feature should be possible to circumvent with external installer calling setups renamed to back to weidu.exe and moved into appropriate mod folder (well, I think so, at least).
And guess what? No one was resolving those issues through proper use of WeiDU. Those request wich you mention are not so important or already marked as "won't fix" because of other things involved. Some of them might be incorporated some may not but things like GUID/UUID must be created.
My opinion - you're just approaching it from the wrong end. BWS compatibility should be initiated by modders who made a conscious decision to be part of the project. Without it you'll be stuck chasing the train where each car goes its own rails, no matter what.
From my perspective it's less problems for everyone involved, from players to modders to WeiDU, if the latter retains its traditional behavior and requirements. I already said I may be in the dark, especially in recent years, but my impression of BWS has always been as "those crazy guys at SHS subforum", not as some kind of community manager everyone answers to. Mod authors wishing to step further can additionally integrate themselves into BWS (or, as case may be, BWS v2.0). I haven't seen Zeitgeist yet, so I can't say much about it atm.
That's exactly what I'm doing. The thing is, using current state of the community tools, mod authors cannot effectively support any external system, not limiting to BWS ! You want to argue about that? I'm approaching from the the best end: fixing those problems at the root foundation, where they will bring benefits for all, not only for BWS. Otherwise, you won't be seen all of my feedback. Because I didn't posted all my ideas, you are fail to see that my requests will give the control of the mods back yo the mod authors, instead of maintainers. And eliminate "BWS removed my mod!" problem. But it all depends from the amount of meaningful support form weidu side.
We're talking about Weidu here, and you said "I would remove such a mod."
That's not what I've said, read it again. Nobody is removing mod from weidu because it's impossible.
As for the rest, I just don't see what the consequences that would be "so bad" for a once-in-a-blue-moon occurrence. Components moving is literally no different from the creation of new mod components, and that's not going to stop. So what's the problem?
Plus if we had a deferential message-only INCOMPATIBLE flag like I suggested, then the component that moved could carry its conflict notifications with it!
I've posted problems several times, I'm not gonna repeat myself. If you are willing to support a system which will fail, go for it. I can't and I'm sure that writing a special, new code for the flawed system is not a wise decision.
-
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.
-
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:
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.
-
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)
-
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.
-
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.
-
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).
-
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. ;)
-
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:
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.
-
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. :o :o :o 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).
-
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:
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.
-
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.
-
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.
-
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:
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:
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)
-
If weidu allow for "*.tp2" it might also don't require it:
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:
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:
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
// 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,
// 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.
-
I'm trying to test ID_OF_LABEL (let's forget now about tp2 dependency) but it doesn't work:
BEGIN ~6~
DESIGNATED 6
LABEL ~CwEHCw0IBQk~
PRINT ID_OF_LABEL ~setup-GUIDExample.tp2~ ~CwEHCw0IBQk~
Anyone can post working code?
-
You need to use an intermediate variable.
-
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.
-
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.
-
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.
-
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
BEGIN ~6~
DESIGNATED 6
LABEL ~CwEHCw0IBQk~
OUTER_SET num = ID_OF_LABEL ~setup-GUIDExample.tp2~ ~CwEHCw0IBQk~
PRINT "%num%"
-
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.
-
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" ?
-
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?
-
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.
-
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. :P 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.
-
Question: Can someone explain to me why DawidW prefer to use:
REQUIRE_PREDICATE FILE_EXISTS ~override/dw#setup.mrk~ @8 // ~This component requires the core "initialise" component to be installed~instead of
REQUIRE_PREDICATE MOD_IS_INSTALLED "STRATAGEMS" "1000" @8 // ~This component requires the core "initialise" component to be installed~Does using file to check if component is installed have any advantages over checking weidu.log?
Maybe LABEL must be added to weidu.log so MOD_IS_INSTALLED can check LABEL instead of DESIGNATED?
-
Marker files have all of the benefits of GUID/UUID that you talked about. Among other things, they are portable, moving with a component no matter what mod installs it. And multiple components can install the same marker file, allowing detection of whatever quality you want to represent by it.
For example, the first install option for Faiths & Powers, which lets you choose a deity through a dialogue, adds d5_deity.d5. The second install method puts all of the kit choices in menus, but it also installs the deity dialogue as a backup option for NPCs and dual-classing. So this component installs both d5_menus.d5 and d5_deity.d5. So another mod can check whether a particular component is installed, but it can also broadly check whether that particular part of the mod is present, regardless of which component did it.
-
Yep, that is a nice feature set of marker files. The worst thing is that many mods are using them and weidu cannot present/use them as a component logic dependence ( they serve such purpose) I won't even ask about it. The depper we dig, the worse it look :'(
Maybe, in order to give GUID/UUID same sort of portability as marker files, i think that they need to be placed into weidu.log when the component is installed. So other functions like MOD_IS_INSTALLED/other can check for it. And the warring about multiple components using the same LABELS should be removed. GUID/UUID_GROUP seems to be unnecessary.
-
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?
DESIGNATED and markers seemed to suffice just fine...
Question: Can someone explain to me why DawidW prefer to use:
REQUIRE_PREDICATE FILE_EXISTS ~override/dw#setup.mrk~ @8 // ~This component requires the core "initialise" component to be installed~instead of
REQUIRE_PREDICATE MOD_IS_INSTALLED "STRATAGEMS" "1000" @8 // ~This component requires the core "initialise" component to be installed~Does using file to check if component is installed have any advantages over checking weidu.log?
The best answer I can think of atm is that log check doesn't have any particular advantage over the marker either.
Captain Obvious, duh :D
Looking at IR's compatibility setup (https://github.com/Gibberlings3/ItemRevisions/blob/master/item_rev/lib/compatibility.tpa), it also favors markers a few times, for some reason. One specific case is SR v3, which serves as a version check as well. I could swear I heard about it being possible to retrieve installed mods' versions, but I can't seem to find it in the readme?
Regarding the difficulty of getting markers outside of FILE_EXISTS_IN_GAME, yes, I most definitely agree it is their biggest (and only?) downside.
As I mentioned, the best solution imo would be to have CONTENT_MARKER tp2 component flag, which can include one or more strings that are stored in log or somewhere, and ADD_CONTENT_MARKER tp2 action to append the list manually, e.g. if specific ACTION_IF conditions are met or something. MARKER_EXISTS ~string~ value would return 0 or 1 if such marker exists.
Both the unique string generation and mandatory part can be applied to it as well, though I continue to question the necessity of both specifications - it's more likely that only a handful of mods with complex structure really need a careful assessment of compatibility, and that can realistically be resolved by hand and a bit of nagging. Heck, you can even print a warning (without failing the install process otherwise) that a recommended bit of component information is missing - e.g. if tp2 contains ASK_EVERY_COMPONENT amount of them.
PS Do note that I don't consider myself an active modder any longer, though, more like old geezer dwelling on past accomplishments and sharing wisdom with the young, so take whatever I say with a grain of salt.
-
Guys, I'm going on vacation. To summarize, let the GUID/LABEL serve the same role as marker files ( added to weidu.log ) and a new role for mod to search GUID/LABEL inside a tp2 which is present(extracted) inside game directory, so it could be possible to check a components which might be installed in the future. Let the same GUID/LABEL be allowed for more than one component and be called <ModderPrefix>something for now, to not making this more complicated.
EDIT: Removed requirements for GUID, conversation continue here: http://forums.pocketplane.net/index.php/topic,29787.0.html