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.
The syntax of REQUIRE_COMPONENT isYeah, 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.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.
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?
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
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.
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.
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 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.
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.)
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.
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.
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.
QuoteMy 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.
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.