Author Topic: weidu next generation - GUID/UUID keyword for every component  (Read 7358 times)

Offline AL|EN

  • Planewalker
  • *****
  • Posts: 391
  • Gender: Male
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
http://hashids.org/

Why we need them? Let's look at one of the conceptual conflicts between mods:

1. Simple "Armor encumbrance":
Quote
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:
Quote
ModA(10) = "Main component"
ModA(100) = "Portrait component"

ModB(1) = "Main component
ModB(2) = "Portrait component"

Conflict:
Code: [Select]
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
« Last Edit: August 03, 2017, 12:18:17 PM by AL|EN »
Project Infinity public BETA - mod manager for Infinity Engine games
Modder's Guide to Github - you cannot have progress without committing changes

Offline GeN1e

  • Planewalker
  • *****
  • Posts: 267
  • Gender: Male
Re: weidu next generation - GUID/UUID keyword for every component
« Reply #1 on: July 24, 2017, 12:56:35 AM »
Playing devil's advocate again, what will become the very purpose of DESIGNATED if you can change it at will?
Quote
1. Simple "Armor encumbrance":
Quote
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
« Last Edit: July 24, 2017, 01:06:44 AM by GeN1e »

Offline AL|EN

  • Planewalker
  • *****
  • Posts: 391
  • Gender: Male
Re: weidu next generation - GUID/UUID keyword for every component
« Reply #2 on: July 24, 2017, 03:40:57 AM »
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.
« Last Edit: July 24, 2017, 03:42:08 AM by AL|EN »
Project Infinity public BETA - mod manager for Infinity Engine games
Modder's Guide to Github - you cannot have progress without committing changes

Offline GeN1e

  • Planewalker
  • *****
  • Posts: 267
  • Gender: Male
Re: weidu next generation - GUID/UUID keyword for every component
« Reply #3 on: July 24, 2017, 03:54:06 AM »
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.
« Last Edit: July 24, 2017, 03:58:47 AM by GeN1e »

Offline AL|EN

  • Planewalker
  • *****
  • Posts: 391
  • Gender: Male
Re: weidu next generation - GUID/UUID keyword for every component
« Reply #4 on: July 24, 2017, 04:19:37 AM »
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.
« Last Edit: July 24, 2017, 04:20:56 AM by AL|EN »
Project Infinity public BETA - mod manager for Infinity Engine games
Modder's Guide to Github - you cannot have progress without committing changes

Offline Wisp

  • Moderator
  • Planewalker
  • *****
  • Posts: 1176
Re: weidu next generation - GUID/UUID keyword for every component
« Reply #5 on: July 25, 2017, 04:06:10 PM »
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?

Offline AL|EN

  • Planewalker
  • *****
  • Posts: 391
  • Gender: Male
Re: weidu next generation - GUID/UUID keyword for every component
« Reply #6 on: July 26, 2017, 04:14:21 AM »
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.
Project Infinity public BETA - mod manager for Infinity Engine games
Modder's Guide to Github - you cannot have progress without committing changes

Offline Wisp

  • Moderator
  • Planewalker
  • *****
  • Posts: 1176
Re: weidu next generation - GUID/UUID keyword for every component
« Reply #7 on: July 27, 2017, 04:13:40 PM »
- 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.

Quote
- any component can have zero or more LABELs instead of one unique
What's wrong with more than one LABEL?

Quote
- 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.

Quote
- it can be anything like 'mycat12$' instead of generated value
So alphabet soup is better than something meaningful and/or memorable?

Offline AL|EN

  • Planewalker
  • *****
  • Posts: 391
  • Gender: Male
Re: weidu next generation - GUID/UUID keyword for every component
« Reply #8 on: July 27, 2017, 04:47:21 PM »
Quote
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.

Quote
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.

Quote
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.
« Last Edit: July 27, 2017, 05:00:14 PM by AL|EN »
Project Infinity public BETA - mod manager for Infinity Engine games
Modder's Guide to Github - you cannot have progress without committing changes

Offline AstroBryGuy

  • Planewalker
  • *****
  • Posts: 154
  • Gender: Male
Re: weidu next generation - GUID/UUID keyword for every component
« Reply #9 on: July 27, 2017, 10:08:38 PM »
Quote
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".

Offline AL|EN

  • Planewalker
  • *****
  • Posts: 391
  • Gender: Male
Re: weidu next generation - GUID/UUID keyword for every component
« Reply #10 on: July 28, 2017, 03:19:54 AM »
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.
Project Infinity public BETA - mod manager for Infinity Engine games
Modder's Guide to Github - you cannot have progress without committing changes

Offline Wisp

  • Moderator
  • Planewalker
  • *****
  • Posts: 1176
Re: weidu next generation - GUID/UUID keyword for every component
« Reply #11 on: August 01, 2017, 03:42:07 PM »
Quote
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.

Quote
Quote
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?

Quote
Quote
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.

Quote
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.

Offline Sam.

  • The moose man
  • Planewalker
  • *****
  • Posts: 86
  • Gender: Male
    • Classic Adventures Homepage
Re: weidu next generation - GUID/UUID keyword for every component
« Reply #12 on: August 01, 2017, 10:32:41 PM »
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.
"Ok, I've just about had my FILL of riddle asking, quest assigning, insult throwing, pun hurling, hostage taking, iron mongering, smart-arsed fools, freaks, and felons that continually test my will, mettle, strength, intelligence, and most of all, patience! If you've got a straight answer ANYWHERE in that bent little head of yours, I want to hear it pretty damn quick or I'm going to take a large blunt object roughly the size of Elminster AND his hat, and stuff it lengthwise into a crevice of your being so seldom seen that even the denizens of the nine hells themselves wouldn't touch it with a twenty-foot rusty halberd! Have I MADE myself perfectly CLEAR?!"
-- <CHARNAME> to Portalbendarwinden

Offline AL|EN

  • Planewalker
  • *****
  • Posts: 391
  • Gender: Male
Re: weidu next generation - GUID/UUID keyword for every component
« Reply #13 on: August 03, 2017, 10:17:11 AM »
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:
Quote
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.

Quote
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.


Quote
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.

Quote
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 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/ 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)
Code: [Select]
Here is your new GUID:8b97a0a3-048b-45db-8c4a-97f040448244
2. open http://guid.us/Test/GUID paste GUID and click validate - you will have a properly validated GUID
Code: [Select]
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.

Quote
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?

« Last Edit: August 03, 2017, 12:17:56 PM by AL|EN »
Project Infinity public BETA - mod manager for Infinity Engine games
Modder's Guide to Github - you cannot have progress without committing changes

Offline subtledoctor

  • Planewalker
  • *****
  • Posts: 131
Re: weidu next generation - GUID/UUID keyword for every component
« Reply #14 on: August 03, 2017, 02:03:20 PM »
If LABEL is used the same way as DESIGNATED/COMPONENT, then there should never be a collision:
Code: [Select]
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)

Offline AL|EN

  • Planewalker
  • *****
  • Posts: 391
  • Gender: Male
Re: weidu next generation - GUID/UUID keyword for every component
« Reply #15 on: August 03, 2017, 03:02:38 PM »
If LABEL is used the same way as DESIGNATED/COMPONENT, then there should never be a collision:
Code: [Select]
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
Code: [Select]
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?
« Last Edit: August 03, 2017, 03:12:01 PM by AL|EN »
Project Infinity public BETA - mod manager for Infinity Engine games
Modder's Guide to Github - you cannot have progress without committing changes

Offline subtledoctor

  • Planewalker
  • *****
  • Posts: 131
Re: weidu next generation - GUID/UUID keyword for every component
« Reply #16 on: August 03, 2017, 03:32:00 PM »
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.

Offline GeN1e

  • Planewalker
  • *****
  • Posts: 267
  • Gender: Male
Re: weidu next generation - GUID/UUID keyword for every component
« Reply #17 on: August 03, 2017, 04:40:21 PM »
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?

Offline AL|EN

  • Planewalker
  • *****
  • Posts: 391
  • Gender: Male
Re: weidu next generation - GUID/UUID keyword for every component
« Reply #18 on: August 03, 2017, 04:55:56 PM »
Quote
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?

Quote
... 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.


Quote
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.

Quote
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:
Code: [Select]
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.

Code: [Select]
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.
« Last Edit: August 03, 2017, 05:22:10 PM by AL|EN »
Project Infinity public BETA - mod manager for Infinity Engine games
Modder's Guide to Github - you cannot have progress without committing changes

Offline AL|EN

  • Planewalker
  • *****
  • Posts: 391
  • Gender: Male
Re: weidu next generation - GUID/UUID keyword for every component
« Reply #19 on: August 03, 2017, 05:16:50 PM »
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.
« Last Edit: August 03, 2017, 05:26:26 PM by AL|EN »
Project Infinity public BETA - mod manager for Infinity Engine games
Modder's Guide to Github - you cannot have progress without committing changes

Offline subtledoctor

  • Planewalker
  • *****
  • Posts: 131
Re: weidu next generation - GUID/UUID keyword for every component
« Reply #20 on: August 03, 2017, 05:19:10 PM »
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.
« Last Edit: August 03, 2017, 05:24:27 PM by subtledoctor »

Offline AL|EN

  • Planewalker
  • *****
  • Posts: 391
  • Gender: Male
Re: weidu next generation - GUID/UUID keyword for every component
« Reply #21 on: August 03, 2017, 06:10:34 PM »
Quote
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?

Quote
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.

Quote
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"

Quote
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.

Quote
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?

« Last Edit: August 03, 2017, 06:17:13 PM by AL|EN »
Project Infinity public BETA - mod manager for Infinity Engine games
Modder's Guide to Github - you cannot have progress without committing changes

Offline GeN1e

  • Planewalker
  • *****
  • Posts: 267
  • Gender: Male
Re: weidu next generation - GUID/UUID keyword for every component
« Reply #22 on: August 03, 2017, 06:37:14 PM »
Quote
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".

Quote
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.
« Last Edit: August 03, 2017, 06:39:27 PM by GeN1e »

Offline subtledoctor

  • Planewalker
  • *****
  • Posts: 131
Re: weidu next generation - GUID/UUID keyword for every component
« Reply #23 on: August 03, 2017, 08:25:29 PM »
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.

Offline AL|EN

  • Planewalker
  • *****
  • Posts: 391
  • Gender: Male
Re: weidu next generation - GUID/UUID keyword for every component
« Reply #24 on: August 04, 2017, 03:52:06 AM »
Quote
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".

Quote
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?


Quote
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.

Quote
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.

Quote
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.



Quote
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.
« Last Edit: August 04, 2017, 04:05:35 AM by AL|EN »
Project Infinity public BETA - mod manager for Infinity Engine games
Modder's Guide to Github - you cannot have progress without committing changes

 

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

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

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