How do I check for an installed component in the middle of the tp2?

[jastey]

I know "REQUIRE_COMPONENT", which I think can only be used to check whether a mod (component)'s requirements of another mod being installed is met (if not, the whole component / mod is skipped).

 

What I need is a check for a mod component being installed, but in combination with other checks, something like

 

REQUIRE_PREDICATE ((GAME_IS ~bg2 tob bgt~) AND (COMPONENT_IS_INSTALLED ~somemod.tp2~ "0") AND (FILE_EXISTS ~override/somefile.xx~))

 

Does something like this exist?

[Mike1072]

So close. It's called MOD_IS_INSTALLED.

[jastey]

I checked the readme, I swear! But I missed it. Thank you!

[subtledoctor]

Don't you worry that the mod structure might change and the check will then point to the wrong component? Aren't marker files better suited for this purpose?

[Jarno Mikkola]

Don't you worry that the mod structure might change and the check will then point to the wrong component? Aren't marker files better suited for this purpose?

And WHERE WOULD YOU PUT THOSE ?

Yes, the question is legitimate, but also accusatory for a reason, and that reason is that any other than the actual game file can break things in a larger install. There was a culture of making marker files in the past and we moved from it as... well, they can demolish good intentions. Try to install the LStest mod to a game that has a .bcs "marker file" in the override -folder made from an .itm file. And you'll fail. This can be applied to every marker file approach you could think could be good.

[CamDawg]

The fun part is that MOD_IS_INSTALLED can be used at a patch level, too.

 

Don't you worry that the mod structure might change and the check will then point to the wrong component? Aren't marker files better suited for this purpose?

Yes and no. Marker files are more likely to change than mod structures, but really neither are 100%.

 

And WHERE WOULD YOU PUT THOSE ?

Yes, the question is legitimate, but also accusatory for a reason, and that reason is that any other than the actual game file can break things in a larger install. There was a culture of making marker files in the past and we moved from it as... well, they can demolish good intentions. Try to install the LStest mod to a game that has a .bcs "marker file" in the override -folder made from an .itm file. And you'll fail. This can be applied to every marker file approach you could think could be good.

Just because a mod did something incredibly, incredibly dumb once (bcs, really?) with a concept doesn't invalidate the concept itself. Copying something to a non-game extension is safe, for example.

 

That being said, the Tweaks consolidation will likely dump all of its marker files.

[subtledoctor]

I dunno, I made a little teeny-tiny .txt file that says

hello!

...and just re-copied it as D5_taspl.2da and D5_skspl.2da and D5_apr.2da and D5_profs.2da (and I realized later that I could simply use a .txt extension and it would work just fine)... so I have a bunch of extra little .2da files when I look in NI, but can they really do any harm?

 

Related on-topic question: could the concern about changing structure be alleviated by using the "designated" flag? Because, the Weidu docs say not to use that flag, but it would make this kind of stuff easier...

[Mike1072]

Related on-topic question: could the concern about changing structure be alleviated by using the "designated" flag? Because, the Weidu docs say not to use that flag, but it would make this kind of stuff easier...

 

Where does it say not to use it? You absolutely should use it.

[CamDawg]

Related on-topic question: could the concern about changing structure be alleviated by using the "designated" flag? Because, the Weidu docs say not to use that flag, but it would make this kind of stuff easier...

DESIGNATED is great; I use it to add a little flexibility for future expansion, like for Tweaks. 'Reveal Area Maps' is DESIGNATED 1100 and 'Add Map Notes' is 1110, which allowed me to slot the new 'Do Not Reveal Area Maps' at 1101.

[Jarno Mikkola]

Related on-topic question: could the concern about changing structure be alleviated by using the "designated" flag? Because, the Weidu docs say not to use that flag, but it would make this kind of stuff easier...

The very latest weidu readme says just:

 

DESIGNATED forcedNumber

Normally module components are numbered based on their order in the TP2 file (starting from 0). This flag sets the current component number to forcedNumber. The next component (if it lacks a DESIGNATED flag) will be forcedNumber+1. You can easily shoot yourself in the foot by setting forcedNumber too low (e.g., so that multiple components have the same number).

Stop using the read me that google gives you, it's ancient v185...

[subtledoctor]

Ah I see. Well I guess I'll start using DESIGNATED in my next version. I would have already, if I had not read the wrong Weidu readme... I think it pays to be anal about such things: I traified my 20,000 line tp2 by hand, just so that I could categorize each group of strings with groups of components... now those tra references can match DESIGNATED component numbers!

 

OCD joy! And it will simplify internal component checking like that described in the OP, of which my mod does a lot.

[jastey]

subtledoctor: I am checking for IA main component installed, chances this will change from "0" are 0, I think, but thank you for the concern.

 

Where and when would I use DESIGNATED - in my own mod, if I want a component to have a number different from the automatic counted one?

[Jarno Mikkola]

Where and when would I use DESIGNATED - in my own mod, if I want a component to have a number different from the automatic counted one?

Well you kinda answered yourself this already... but, if you have more that 10 component it makes it easier to separate things in sections ... while you use ASK_EVERY_COMPONENT and stuff like that. And you can sneak in additional components afterwards.

 

Just because a mod did something incredibly, incredibly dumb once (bcs, really?) with a concept doesn't invalidate the concept itself. Copying something to a non-game extension is safe, for example.

The .bcs file is just an example, one that was easy to make as I knew the system cause I used the COPY_EXISTING_REGEXP GLOB ~.*\.bcs$~ -command and knew it's weakness. An there's not much that I can fix at my end. Or is there ?

K, you say that copying to non-game extension is safe, there too some things that need to be remembered, not to use .baf .bcs, .d, .dlg etc. -files as there's a good chance that one of the COMPILE -commands will get stuck at it, yes there's still a few mods that compile the override -folder . Same thing goes for nearly all the in game files for different reasons...

 

I dunno, I made a little teeny-tiny .txt file that says

hello!

...and just re-copied it as D5_taspl.2da and D5_skspl.2da and D5_apr.2da and D5_profs.2da... so I have a bunch of extra little .2da files when I look in NI, but can they really do any harm?

 

These files are in game files, now normally it's mostly fine, but then someone installs a mod that makes a .bif from the override folder, which makes your flags disappear and then you mod looks like it was not installed. This happens even in in_mod_markers. Level 1 NPCs a mod that comes to mind, it was originally made with a marker file, component zero's marker disappeared and NPC components couldn't be installed after the game was started as the megamod was unplayable without the End_Biff(yep, it's been a while).

[CamDawg]

 

Just because a mod did something incredibly, incredibly dumb once (bcs, really?) with a concept doesn't invalidate the concept itself. Copying something to a non-game extension is safe, for example.

The .bcs file is just an example, one that was easy to make as I knew the system cause I used the COPY_EXISTING_REGEXP GLOB ~.*\.bcs$~ -command and knew it's weakness. An there's not much that I can fix at my end. Or is there ?

K, you say that copying to non-game extension is safe, there too some things that need to be remembered, not to use .baf .bcs, .d, .dlg etc. -files as there's a good chance that one of the COMPILE -commands will get stuck at it, yes there's still a few mods that compile the override -folder . Same thing goes for nearly all the in game files for different reasons...

 

Tweaks has used .g3 marker files for about a decade now. I'm pretty sure we can say those are safe at this point.

 

I dunno, I made a little teeny-tiny .txt file that says

hello!

...and just re-copied it as D5_taspl.2da and D5_skspl.2da and D5_apr.2da and D5_profs.2da... so I have a bunch of extra little .2da files when I look in NI, but can they really do any harm?

 

These files are in game files, now normally it's mostly fine, but then someone installs a mod that makes a .bif from the override folder, which makes your flags disappear and then you mod looks like it was not installed. This happens even in in_mod_markers. Level 1 NPCs a mod that comes to mind, it was originally made with a marker file, component zero's marker disappeared and NPC components couldn't be installed after the game was started as the megamod was unplayable without the End_Biff(yep, it's been a while).

 

...which is why you always use FILE_EXISTS_IN_GAME for anything copied to the override.

[DavidW]

Don't you worry that the mod structure might change and the check will then point to the wrong component? Aren't marker files better suited for this purpose?

Yes, at least for mods with complicated structure. (I have changed the component structure of SCS(II) at least three times. DESIGNATED helps, but only to a degree.)

 

And WHERE WOULD YOU PUT THOSE ?

The override directory is completely harmless provided you aren't unwise enough to use a file with an in-game extension. (TweakPack's .g3 or SCS's .mrk, for instance, are fine.)

 

There was a culture of making marker files in the past and we moved from it

Speak for yourself; I have no intention to stop using marker files.

 

This can be applied to every marker file approach you could think could be good.

I wait with interest to hear how a .g3 or .mrk marker file can break the game.

 

yes there's still a few mods that compile the override -folder

This won't be a problem for a .g3 or .mrk file - but in any case, if you're installing a mod that is issuing a global COMPILE command to a space over which it has no control, marker files are the least of your worries.

 

To comment briefly on the computer science here: the problem with MOD_IS_INSTALLED is that a component number is only contingently associated with the component itself. The fact that the "make Irenicus into a talking donkey" component is numbered 1000, or that it installs donkey.bcs, is only a contingent feature of the component and isn't guaranteed stable. (You also can't tell directly from the code whether the component-check is actually linking to the component, which creates potential for bugs.) WEIDU's LABEL feature helps, because it does point directly to the component rather than to some contingent feature of it. I don't use it in SCS because (a) the syntax is a little cumbersome, (b) I want a slightly finer-grained ability to detect subcomponents than LABEL makes convenient, and ( c ) there's nothing actually wrong with the marker file approach.