Post reply

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:
Subject:
Message icon:

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)?:

shortcuts: hit alt+s to submit/post or alt+p to preview


Topic Summary

Posted by: Wisp
« on: November 10, 2018, 02:27:05 PM »

There are other reasons for why you might want, or perhaps even should, use DESIGNATED, so I'd say no. Not using DESIGNATED means WeiDU will assign component numbers automatically.
Posted by: AL|EN
« on: November 03, 2018, 11:32:15 AM »

If all components use LABELS, it means that modder can skip "DESIGNATED int" keyword for all components, right? Does such situation is supported by weidu? What are possible consequences?
Posted by: Wisp
« on: August 28, 2018, 11:54:43 AM »

The syntax of REQUIRE_COMPONENT is
Code: [Select]
REQUIRE_COMPONENT  modToUninstall modComponent String
and modComponent isn't documented, so you could have been right that it can be a LABEL, but in fact the WEIDU parser seems to insist that it's an integer.
Yeah, the documentation for a lot of the old features just kind of assumes you know the "types" of the arguments. As you've surmised, REQUIRE_COMPONENT requires that modComponent is an integer, whereas, say, REQUIRE_PREDICATE, evalutes a patch expression, which may be a string, an integer, or something like ID_OF_LABEL.

So, unless majority of modders want's to change how LABEL works and in which context is used, and wisp will introduce those changes, I'm gonna assume that my GUID/UUID request can't be solved via LABEL, right?
LABEL is not changing, no. Are the salient points of your UUID proposal still that they'd live in the global scope (alongside TP2 names, rather than under them, like LABEL), are added to the log and maybe that a component can have at most one UUID? If not, would you care to summarise the current status?
Posted by: AL|EN
« on: August 26, 2018, 04:08:35 PM »

So, unless majority of modders want's to change how LABEL works and in which context is used, and wisp will introduce those changes, I'm gonna assume that my GUID/UUID request can't be solved via LABEL, right?
Posted by: AL|EN
« on: August 24, 2018, 01:53:02 PM »


As a matter of modding history that's not quite correct. Concerns about DESIGNATED go back (at least) a decade; it's just that marker files ended up being the preferred solution. If you're interested, there's a long discussion of it here: http://www.shsforums.net/topic/45953-brainstorming-for-the-bwp/
Man, that post is lovely, it's a please to read: http://www.shsforums.net/topic/45953-brainstorming-for-the-bwp/?p=496676
You were dealing the same problems as BWS, that was a magnitude smaller. The marker files was some sort of GUID and it was good stuff back then but now, when tools can use only things which --list-components-json will give them (marker files can't be received, same for READLN thing, lucky SCS don't have them ) it's very good idea to replace them with LABEL.


Posted by: DavidW
« on: August 24, 2018, 12:46:38 PM »

It wasn't used at all because nobody complain about component number /DESIGNATED until it causes BWS failures. Every single change of DESIGNATED in one mod was causing domino of wrong components logic including which components of single mod are required for other ones later and which components from one mod are mutually exclusive with another etc. It was fcking hell. And still is.

As a matter of modding history that's not quite correct. Concerns about DESIGNATED go back (at least) a decade; it's just that marker files ended up being the preferred solution. If you're interested, there's a long discussion of it here: http://www.shsforums.net/topic/45953-brainstorming-for-the-bwp/


Posted by: subtledoctor
« on: August 24, 2018, 12:17:59 PM »

Yeah in a nutshell AL|EN was requesting a new "UUID" function in Weidu and two things that came up in the conversation were "why not just use LABEL?" and "why not update how LABEL works?" This thread, in discussing 1) LABEL and 2) updating things for a next-generation Weidu, naturally called to mind those ideas.
Posted by: AL|EN
« on: August 24, 2018, 10:56:32 AM »

It wasn't used at all because nobody complain about component number /DESIGNATED until it causes BWS failures. Every single change of DESIGNATED in one mod was causing domino of wrong components logic including which components of single mod are required for other ones later and which components from one mod are mutually exclusive with another etc. It was fcking hell. And still is.

I wanted new weidu keyword for components: GUID/UUID. We are using "LABEL" because wisp tells everyone that LABEL can be used for all of this instead of new GUUID/UUID keyword for components. Sure it can, with addition of modder prefix. But if you are not convinced about the whole idea, and you want to use LABEL only in the context of internal mod components, then I'm not goona dictate you how you want to use weidu features for you mods. Others might use it differently, but I sense that they follow an "best practice" example. Anyway, I will just use what you will provide.

It's a pitty, thought. Even if wisp is goona add GUID/UUID, who is goona use it after dealing with DESIGNATED and LABEL?

@wisp What's you opinion about LABEL / GUID now?
Posted by: DavidW
« on: August 24, 2018, 09:41:09 AM »

I think the conversation is getting a bit tangled here. People are discussing some hypothetical new labeling system, where labels aren’t relativized to mod name and where different components can share labels. And maybe that’s a good idea (though I’m really unconvinced).

But confusingly, people are calling that hypothetical system LABEL. LABEL isn’t hypothetical: it has been implemented in WEIDU for years, albeit not much used, and it is, by design, mod-relativized and not shareable between components. Whatever the vices and virtues of using modder prefix with the new hypothesized system, there is no point doing it for LABEL.
Posted by: AL|EN
« on: August 24, 2018, 03:56:01 AM »

Quote
you could assign them all a shared label for the main thing they do and a unique label for their individual changes.
Agree, adding another label to component can be userful for component. And for some sophisticated logic (prevent LABEL1 unless contains LABEL2) also.

Quote
So the idea is a system that lets individual mod *components* be identified, without paying any attention to which mod they're in, and such that you can build an install structure that keeps working unedited even when components get swapped between mods?

I'm really skeptical that you can build a robust install structure on that basis: too many mods aren't modular in that way, and there's no guarantee that moving a component into a different mod won't affect compatibility and install-order issues. (Perhaps you'll say that the non-modular components don't get donated between mods? Widespread component donation is a new thing that I don't know much about.)
I agree that donating components can cause those. So far, donation wasn't some blindly code coping and it was only used for lite things like tweaks etc. But such problems won't matter for tools. One of the best example why it wont matter for conflict definitions is "Change XP" components: if it's based on LABELS, one single line of conflict definition for external tool (like "allow_only_single_label" = "ChangeGlobalXP" will make sure that player will always install only one mod, which has "Change XP" components. And even if new mod arrise, with the same component, I'm sure that community will guide modder to add such global LABEL so modders won't need to add yet another "FORBBIT_LABEL modname label"  and Tools with conflict definitions won't need to change it at all. A really wonderful perspective if you ask me.

Quote
Although at least for the SCS / SCSII merger, the amount of code structure change was large enough that it would have been a pretty bad idea just to assume that old and new parts worked the same way - I'd probably have changed the LABELs even if they did exist.
But not all of them, right? Things like "core", "NPCs components", "Skip the Candlekeep tutorial sections", "Move Boo into Minsc's pack", "Stackable ankheg shells, winterwolf pelts and wyvern heads" would keep their label. Avoiding even one modification of conflict definition after mod update is still huge improvement to current situation.

Quote
Maybe worth looking at from the other direction: what does a hypothetical REQUIRE_LABEL function gain from requiring mention of a .tp2 in its syntax?  The only benefit I can see is to avoid problems if two people use the same LABEL.  In which case, just use modder prefixes in LABELs as AL|EN suggests, and all is well.
Exactly. Defining labels which include modder prefix is the same amount of time and it gives extra benefits.
Posted by: subtledoctor
« on: August 23, 2018, 11:36:51 PM »

Maybe worth looking at from the other direction: what does a hypothetical REQUIRE_LABEL function gain from requiring mention of a .tp2 in its syntax?  The only benefit I can see is to avoid problems if two people use the same LABEL.  In which case, just use modder prefixes in LABELs as AL|EN suggests, and all is well. 

Realistically most mod components are mods unto themselves, loosely (to a greater or lesser extent) collected together under some common theme.  The .tp2 binds them together by whim of the author, more than for any important functional reason.  (And if there are important functional reasons like dependencies, well, just use REQUIRE_LABEL etc. to bind them in a more functional sense.)
Posted by: DavidW
« on: August 23, 2018, 07:41:39 PM »

As far as the proposed change for new label commands, making labels universal, I can see the component transferability benefit when I look at mods that are merged together, e.g. scs and scsii into stratagems or bg2tweaks etc. into cdtweaks.
Although at least for the SCS / SCSII merger, the amount of code structure change was large enough that it would have been a pretty bad idea just to assume that old and new parts worked the same way - I'd probably have changed the LABELs even if they did exist.
Posted by: Mike1072
« on: August 23, 2018, 07:21:30 PM »

One benefit of labels not mentioned here is that you can have multiple labels associated with a component.  If one component does 3 different things, you can have a label for each thing and if you decide later to separate them into different components, there won't be a problem if other mods use the labels for detection.

As far as the proposed change for new label commands, making labels universal, I can see the component transferability benefit when I look at mods that are merged together, e.g. scs and scsii into stratagems or bg2tweaks etc. into cdtweaks.

Another suggestion that relates to universal labels is allowing the same label on multiple components.  (Right now WeiDU warns about this, since ID_OF_LABEL has to return a single component number for a label.)  This could be useful if you had multiple subcomponents that all do the same thing slightly differently: you could assign them all a shared label for the main thing they do and a unique label for their individual changes.

These features replicate the benefits marker files offer over component numbers.
Posted by: DavidW
« on: August 23, 2018, 04:16:46 PM »

So the idea is a system that lets individual mod *components* be identified, without paying any attention to which mod they're in, and such that you can build an install structure that keeps working unedited even when components get swapped between mods?

I'm really skeptical that you can build a robust install structure on that basis: too many mods aren't modular in that way, and there's no guarantee that moving a component into a different mod won't affect compatibility and install-order issues. (Perhaps you'll say that the non-modular components don't get donated between mods? Widespread component donation is a new thing that I don't know much about.)

But in any case, there is no prospect of SCS components ever being donated in that way. SCS is built on a very large function library that no-one except me uses and uses a fairly big "initialize" component, and its components can't be lifted out. In the pretty unlikely scenario where I give the concepts/content of a component to another mod (I guess perhaps one of mine, for instance) then it will still end up having to be recoded enough that automatically assuming the same install order works is likely to be problematic.
Posted by: AL|EN
« on: August 23, 2018, 03:31:36 PM »

Quote
My proposal, and I think AL|EN's, is for any new LABEL-specific commands (e.g. REQUIRE_LABEL and LABEL_IS_INSTALLED or whatever) to work differently from REQUIRE_COMPONENT, by omitting reference to the modname.  Then if modders use their prefix with LABELs, every LABEL would be unique and - I think? - they could really work as a pseudo-UUID as AL|EN desires.
But what's wrong with how LABEL already works? The ordered pair (modname.tp2,LABEL) is guaranteed to be unique, with or without modder prefix; use that as your pseudo-UUID if you want one.

Just think from one level above mod perspective as I always do. If a tool or other mod define conflicts/dependence which are based on mod+lablel, it's improvement from the mod+designated. A modder can manipulate designated in any way, without affecting internal and external conflicts/dependence. But as soon as the component of one mod will be donated to other mod (witch happens often recently) it will destroy all logic which was based on mod+lablel and cause domino of errors. BWS/Zeitgeist/Other Tool/Other mods conflicts/dependence will be destroyed>they will need to be maintained endlesly>maintainer will be tired and leave>will have bad shape. Because of the consequences, using mod+lablel and relaying on them, will make components donation a very complex operation, require cooperation across various different mods, practically prevent such practice forever. No one will risk it. That is why I wanted UUID's and some rules for them, while still there is a chance for that since noone is using them.

I just want to have two functionality in one thing: a way for modder to define REQUIRE/FORBID "ID of component which has LABEL xxx#improvedSarevok" and a way for external tool to read this info and react (conflict/dependence/install order before/after) before installation begins.



Quote
My proposal, and I think AL|EN's, is for any new LABEL-specific commands (e.g. REQUIRE_LABEL and LABEL_IS_INSTALLED or whatever) to work differently from REQUIRE_COMPONENT, by omitting reference to the modname.  Then if modders use their prefix with LABELs, every LABEL would be unique and - I think? - they could really work as a pseudo-UUID as AL|EN desires.
Yes, that would also do. So if we remove mod reference, mods can define "allow_spelcasting_in_armor"/"khalid_as_ranger" and ANY component/mod/tool can react to it. But for mods, weidu needs to add them to weidu.log atleast. More advanced tools can extract this info from --list-components-json and react accordingly, because they know the whole set of mods/components which will be installed so filtering is possible.