Lauriel Posted September 4, 2020 Author Share Posted September 4, 2020 (edited) 6 minutes ago, DavidW said: PI's syntax is not restricted as WEIDU's is to checking LABELs only of a particular mod, so LABELs can follow a component even as it migrates between mods (and should not be changed when a component migrates). That is not what was communicated to me at all. What was communicated to me was exactly as I had put in the OP. Edited September 4, 2020 by Lauriel Quote Link to comment
DavidW Posted September 4, 2020 Share Posted September 4, 2020 Well, in that case I'm confused again. If LABELs carry the tp2 name of their parent mod, and that tp2 name changes when the component is moved, then I can't at al see what the point is. @AL|EN? Quote Link to comment
Lauriel Posted September 4, 2020 Author Share Posted September 4, 2020 (edited) 3 minutes ago, DavidW said: Well, in that case I'm confused again. If LABELs carry the tp2 name of their parent mod, and that tp2 name changes when the component is moved, then I can't at al see what the point is. @AL|EN? Nope, you're right. I totally misunderstood. I'm so glad I started this topic. I'd have done this all wrong. I misread 1 sentence ... Edited September 4, 2020 by Lauriel Quote Link to comment
AL|EN Posted September 4, 2020 Share Posted September 4, 2020 18 minutes ago, DavidW said: OK: I think I'm being confused by Lauriel's original post, which suggests that the mod tp2 name ought to be part of the LABEL. That was the bit I didn't understand, given that the tp2 name is inferrable anyway. If the point is just that you want global uniqueness and so a modder prefix, that makes more sense. Is this correct: PI is using LABEL as metadata PI's syntax is not restricted as WEIDU's is to checking LABELs only of a particular mod, so LABELs can follow a component even as it migrates between mods (and should not be changed when a component migrates). For that reason, it's helpful for LABELs to be globally unique. (And use of modder prefix is the standard way to do it.) In fact, it would be helpful if people use globally unique LABELs (hence modder prefixes) even for components that have no prospect of being migrated (e.g., SCS's 'Smarter Mages') because otherwise they might trespass on some completely different mod's LABEL namespace and cause PI to get confused. For modders with more than one mod, it would be helpful if they can make sure that their own LABELs are globally unique, and that they don't use the same LABEL in two mods. Modder prefix alone won't do that; including the tp2 name is one way to do it. BUT if you include the tp2 name in a component LABEL you should absolutely leave it unchanged even if you then migrate the component into a different tp2. OK, I think that's a reasonable ask. (It's mostly moot for me for the moment because v246 slowdown means I can't use LABELs with SCS.) Yes! This is it. The last point ensure that player saved mod list/ mod compilations won't break. Now I see that using tp2 name might bring confusion. I'm using it because it also represents the name of the 'orgin mod' which contains code/component. Does anyone have suggestion how to better represent this part? Like 'display name of the mod without spaces/special characters' ? BTW: You can add labels into you mod and don't use them - it would still be a benefit for other mods(they can use ID_OF_LABEL) and PI. Quote Link to comment
AL|EN Posted September 4, 2020 Share Posted September 4, 2020 @LaurielYou label is fine as long as you understand that even if the label contains 'TRANSITIONS' which match tp2 name of you mod, it has to stay the same after theoretical transfer into different tp2 (you mod or someone else). You might also suggest for a better term. Quote Link to comment
Lauriel Posted September 4, 2020 Author Share Posted September 4, 2020 1 minute ago, AL|EN said: @LaurielYou label is fine as long as you understand that even if the label contains 'TRANSITIONS' which match tp2 name of you mod, it has to stay the same after theoretical transfer into different tp2 (you mod or someone else). You might also suggest for a better term. Yeah, I'll name mine more for what portion of the game it affects. Like my snark components, some are strictly for SoD and some for BG2 and some for in between. I think I'll break them out so they can be incorporated into other mods for just those campaigns and not require EET for those that are campaign specific. Quote Link to comment
DavidW Posted September 4, 2020 Share Posted September 4, 2020 15 minutes ago, AL|EN said: BTW: You can add labels into you mod and don't use them - it would still be a benefit for other mods(they can use ID_OF_LABEL) and PI. I realize this, but it's still live code, and it still makes WEIDU v246 sluggish on SCS. Quote Link to comment
jastey Posted September 5, 2020 Share Posted September 5, 2020 I still don't understand. What does PI do with LABELs, i.e. use them for? I thought they are for mods to be able to detect/forbid other components, either from its own or from different mods. But that's code that is coded into mods. Why would get PI confused if a mod component moves and gets a new LABEL if all mods using it would be updated, too? Quote Link to comment
jastey Posted September 5, 2020 Share Posted September 5, 2020 And: if I name my LABELs tp2name_componentname (without my prefix) it would still be unique, no? Because there are no two mods with the same tp2 name due to compatibility reasons. So, including the prefix to me is less of making the label unique, it's more of being able to spot quicker which other mod(der) the referenced LABEL belongs to (?). Quote Link to comment
AL|EN Posted September 5, 2020 Share Posted September 5, 2020 (edited) 4 hours ago, jastey said: I still don't understand. What does PI do with LABELs, i.e. use them for? I thought they are for mods to be able to detect/forbid other components, either from its own or from different mods. But that's code that is coded into mods. Why would get PI confused if a mod component moves and gets a new LABEL if all mods using it would be updated, too? PI doesn't yet use it yet, don't worry about updating the labels for now. I hope that if there won't be objections regarding making labels globally unique, I can use them for saving components/install order/etc. You are correct about the context usage by using weidu functions, but at the same time, PI can use them for much more. After you update labels across two or more involved mods, the only thing which would still work would be MOD_IS_INSTALLED/ID_OF_LABEL. Everything else will stops working: players private saved mod/component list players private sorting order lists public 'install order lists' public mod compilations It is exactly the same situation which would occur if you would change DESIGNATED and update the number across other mods. So if the modder is willing to use the labels in order to mitigate DESIGNATED problems, at the same time creating those labels as globally unique and unchangeable will protects all the rest. 4 hours ago, jastey said: And: if I name my LABELs tp2name_componentname (without my prefix) it would still be unique, no? Because there are no two mods with the same tp2 name due to compatibility reasons. So, including the prefix to me is less of making the label unique, it's more of being able to spot quicker which other mod(der) the referenced LABEL belongs to (?). Yes, even you simplified version will be unique. Also yes - if the original author of the component code will include the prefix, it can tell people who to thanks even if the component will be transferred/donated into other tp2's. Edited September 5, 2020 by AL|EN Quote Link to comment
jastey Posted September 5, 2020 Share Posted September 5, 2020 I see. That's a very powerful feature you are planning there for mod install order, awesome. Would you consider writing a best practice tutorial how to make a mod compatible and ready for PI? For example I had no idea the LABELs would be so important (and also not in this global range). I am absolutely willing to make my mods PI compatible but I need good instructions so I know what to add where without the feeling that I do extra rounds because I didn't know everything on time or - even worse - didn't know how to implement it so it would be useful. Quote Link to comment
AL|EN Posted March 8, 2021 Share Posted March 8, 2021 @jastey Missed you reply, sorry. I'm always in favor of up-to-date documentation but I have to find a way to have a centralized PI guide without fear that it will be read once and forgotten. Editing posts won't work. What's the best way of notifying modders about updates with new features? There is a point in time when there won't be any new PI modders feature but until it happens, there will always be an 'extra rounds' with PI because I'm still adding features to it. Quote Link to comment
jastey Posted March 8, 2021 Share Posted March 8, 2021 Hmm, first thing coming to my mind would be a pinned thread where you update the first post as well as posting into it if something changed or was added. 22 minutes ago, AL|EN said: There is a point in time when there won't be any new PI modders feature but until it happens, there will always be an 'extra rounds' with PI because I'm still adding features to it. That's understandable. I was referring to my feeling of poking in the mist because of not being aware what the current way of making mods PI compatible is. I also ask for understanding that implementing the changes requires time I do not always have. I'm aware I haven't given any feed back to the component-wise install order syntax yet, for example. Quote Link to comment
AL|EN Posted May 28, 2021 Share Posted May 28, 2021 @jastey The attempt was made: Also, don't worry about not implementing something. You already did more than most of us Quote Link to comment
Recommended Posts
Join the conversation
You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.