ID_OF_LABEL returns the component number if found, or min_int (-2^30 on the standard win32 build of WeiDU) if the tp2 doesn't exist or no such LABEL exists; it fails if two components share a LABEL, or a component has two LABELs defined.

Also, this will parse the tp2 each time it is called - 100 calls on scsii's tp2 cost about 7 seconds on my machine. I could speed this up by adding caching if there's a need (or you can speed it up yourself by cutting your tp2's size by putting each component's code in INCLUDEd files).

From a conceptual point of view, I can't think of any reason why it would matter if a component has two LABELs defined, and I can think of some cases where it would be helpful. Is that a coding limitation, or a deliberate feature?

I think we can live with a 0.07 second slowdown per component (and most of SCSII's code is INCLUDEd anyway).

Presumably LABELs need to live in the main TP2 file - putting them in INCLUDEd code wouldn't work.

From a conceptual point of view, I can't think of any reason why it would matter if a component has two LABELs defined, and I can think of some cases where it would be helpful. Is that a coding limitation, or a deliberate feature?

It was easier to code that way (not that it'd be hard to allow multiple LABELs per component); however, I can't allow two components (in the same tp2) to share a LABEL (ID_OF_LABEL must return a single component number), so I can't see how a component with two LABELs would be helpful.

From a conceptual point of view, I can't think of any reason why it would matter if a component has two LABELs defined, and I can think of some cases where it would be helpful. Is that a coding limitation, or a deliberate feature?

It was easier to code that way (not that it'd be hard to allow multiple LABELs per component); however, I can't allow two components (in the same tp2) to share a LABEL (ID_OF_LABEL must return a single component number), so I can't see how a component with two LABELs would be helpful.

Can the label check default to its BEGIN string (in the first .tra file, if it's traed) if there's no LABEL defined? I'm sure someone will think of some arcane reason not to do that, but otherwise the feature would be rather useless for detecting older mods unless they're all recoded.

No. If the older mod is updated to use LABEL (or to reword the component name), future ID_OF_LABEL will stop working. Besides, an older, unsupported mod called Karea (or something like that) would block the install if used with ID_OF_LABEL because of the "components can't share a LABEL" rule - it has three or four components (in different SUBCOMPONENT groups) all named "Reduce to 50%".

I don't propose using this for older mods (which, if they're not being maintained, have static component numbers in any case)- it's more that it's useful going forward for complex mods like SCS.

The older mod I was talking about is Miloch's Aurora, actually. Besides, other mods wouldn't work if LABEL_OF_ID was called on them and the component name was a valid LABEL (for ex. bg2tweaks and 'PnP table').

What's the rationale for failing instead of returning the first component to match LABEL?

I don't know what the actual motivation is, but it seems a good idea to me, simply because if you're repeating a LABEL, something has gone wrong, and this ought to be signposted rather than occurring silently. (I suppose putting up an INSTALLED_WITH_WARNINGS flag would also achieve that; conversely, I can't see any particular downside to just FAILing.)

LABEL will print a warning if there's another such LABEL in the TP2; ID_OF_LABEL will return min_int print a warning if there is no such LABEL in the tp2 or it is repeated (returns min_int without a warning if the tp2 is not found).

Is there a good reason for folks to stop flagging the components and start using an internally defined label? The only one I can think of is if R_P and R_F only check override, and someone has biff'd the install. (I'm not criticising adding the functionality, only asking what makes it more powerful/interesting/useful than simply dropping a flag file for each component and checking for it like UB/BG1NPC used to do).

It's probably a "less intricate" or at any rate less crufty way of doing it. See here for a background discussion, if you really want some bedtime reading material .

It is equivalent to using MOD_IS_INSTALLED [component#] but DavidW's issue was that mod component numbers (of active mods anyhow) can be subject to change, whereas labels might be less so. It isn't really necessary unless you're in that position. For example, bigg's comment about Aurora doesn't worry me much, because I don't really plan on rearranging the existing component numbers (any more). If I did, I would probably introduce LABELs. Likewise, Level 1 NPCs has about 100 components now, but I don't see the real value of LABELs for it for the same reason, unless someone wants to make a case for that.

[Edit: on the other hand, L1NPCs relies on a !(MOD_IS_INSTALLED ~setup-scs.tp2~ 3020) to make sure it doesn't mess with BG1 NPCs affected by SCS's analogous component. So I guess I would need to know the LABEL for that if DavidW intends on changing the component number (again). If not, I don't see the need to replace a bunch of existing syntax.]

[Edit: on the other hand, L1NPCs relies on a !(MOD_IS_INSTALLED ~setup-scs.tp2~ 3020) to make sure it doesn't mess with BG1 NPCs affected by SCS's analogous component. So I guess I would need to know the LABEL for that if DavidW intends on changing the component number (again). If not, I don't see the need to replace a bunch of existing syntax.]

Good case-study, actually. I'm not intending to change the component number, but I can't promise not to, and I can't really keep track of all the mods that might be relying on my fixed component numbers.

@Cmorgan: I don't strongly feel that it is better than component flag dropping (it's a bit more elegant and aesthetically pleasing). The idea came out of a discussion of why MOD_IS_INSTALLED couldn't substitute for marker files, and consideration of what would so substitute. I'm not especially planning to retrofit SCS to this just yet, though I'll certainly use it going forward.

I am going to continue dropping marker files in the override, BTW - the only people who dislike them are Miloch (and WeiDU 221 removes his objections) and Jarno (but he's a colossal moron, so nobody should consider anything he says).

Is the point of LABEL to obliterate the need of markers, or only to allow for flexible MII substitute? Because if that's the former, then I'm unsure if you are fixing anything (I may be reading this thread wrong, though), since markers in reality serve a very definite purpose, completely different from MII.That purpose being nothing else than to act as a global over-tp2 WeiDU variable, because you can't ~SET mod_x_is_here = 1~ and expect it to be read by the next WeiDU launch.Detectable Spells is a good example, because it now is put into separate tph and dumps a marker to prevent the repeated clean-up of previous versions (Ascension, Kelsey). And obviously it can't check for MII, since it doesn't know which mod will use in future - for example, I'm incorporating it into RtW, and SCS/RR can't know that without an update.

What really would be helpful, is to have a way to store variables between mods, perhaps by extending WeiDU.log or dumping a new WeiDU.arg into the game directory, callable with every setup launch.

Is the point of LABEL to obliterate the need of markers, or only to allow for flexible MII substitute? Because if that's the former, then I'm unsure if you are fixing anything (I may be reading this thread wrong, though), since markers in reality serve a very definite purpose, completely different from MII.

Marker files still remain the most effective way to track this sort of thing (you can use FILE_EXISTS ~override/banter-accelerator.mrk~ rather than keeping track of all mods that contain a banter accelerator). LABEL and MOD_IS_INSTALLED are like a Toyota Prius: it's ugly, slow and less cost-effective than oil-operated cars, but snotty intellectuals feel superior by using it because it doesn't pollute the air override.

Would it be possible to get rid of the warning when two or more components use the same LABEL?

I am using them for Infinity Animations to specify which IA_content is installed to run each component. That way, modders won't have to check for existing bam files (with weird names) to know if their are installed or not, but rather use this kind of code:

I wanted to use them to check if IA_contents were installed. As many components share the same content, it would have been a good way to identify them and avoid checking for all the components of using the IF_FILE_EXIST command.

It works fine but unfortunately displays warnings that may confuse players.