Mod Compatibility List for EET

[Guest Henanigan]

Quote

Yeah, that's what I'm asking.

And to be clear, since no answer was provided, beyond referring me to an install tool that (magically?) would know what to do: In the odd case that a BG1 mod has native EET support; and so can be installed post-EET; but it needs to go before a mod that must be installed before EET; and our particular 'native EET support' mod is not listed as compatible with that procedure (i.e. to be installed before EET): what to do then? Is it taken for granted that any BG1 mod with 'native EET support' can go before EET, too? (If so, what's the purpose of the compat folder?) I'm beginning to suspect that my question does not come across at all, provided that it's actually being read, so I'm trying to clarify once again. Apologies to those who got it the first time!

[Fouinto]

Your Question seems clear to me.

I don't know the answer but I can tell you how I (personnaly) do :

1. I install Pre-EET mods in BWP order,
2. then EET,
3. at least I install Post-EET mods in BWP order.

And then, I don't know if I have already met your kind of problem

All in all, I don't think there can be a "one fit all" rule for this kind of problem : it probably highly depends on why the post-EET mod should go before a pre-EET mod.

[Guest Henanigan]

Merci, monsieur!

Here's one example. Someone at the Beamdog forums asked a week ago about his PI install order for an EET install. He had BGQE go after EET as per the official compatibility list. However, he was told that BGQE must go before BG1NPC: https://forums.beamdog.com/discussion/comment/1110682/#Comment_1110682

To be clear, I think that this advice was correct (and there is a bgqe folder in EET's compat folder). What I would like to know is what mods may, or should, be installed this way with EET, and preferrably clear documentation on what mods are pre-EET vs. post-EET (more clear than a reference to BWP or BWS).

(I doubt that the consequences would be major in this case; a few dialog options missing? But still, it would be good to get it right, I think. :) )

[jastey]

22 hours ago, Guest JustInstalledEET said:

Some mods and references in k4thos' list are not reflecting this.

Would you care to tell us which ones you are referrint to here?

[Guest Henanigan]

Quote

why are you treating EET as a different beast than BGT?

Because it is? :) Seriously, for my part, because BGT is for pre-EE versions of the game, and I no longer play them.

Quote

weren't these problems already sorted with BGT when it got out? 

Not sure what you mean here. I think that EET was written from scratch ('both mods share little to no common code and took different design decisions in many aspects'), which means different issues. And of course, neither BGT nor EET sorts intercompatibility issues between the mods themselves.

Actually, I've seen some posts where EET compatibility (according to the list we're talking about here) was confused with intercompatibility between mods.

[jastey]

BG1NPC Project is EET compatible as of v24.2 .

(It needs some more testing before I'd recommend integrating it into a Megainstall.)

[Jarno Mikkola]

On 12/31/2019 at 8:00 PM, Guest Henanigan said:

Because it is? Seriously, for my part, because BGT is for pre-EE versions of the game, and I no longer play them.

Not sure what you mean here. I think that EET was written from scratch ('both mods share little to no common code and took different design decisions in many aspects'), which means different issues. And of course, neither BGT nor EET sorts intercompatibility issues between the mods themselves.

Actually, I've seen some posts where EET compatibility (according to the list we're talking about here) was confused with intercompatibility between mods.

Well, thing is, both use a common file association file for each, it's generally in the /lib/ folder... so if a mod uses ar0200.bcs in the BG1/BG1EE game, it's reflected in the mods library code, it's compatible with games by retreaving the "ar0200" portion of that for BG1/BG1EE, while the BGT(-weidu) will read is as ar7300.bcs ... just for compatibility's sake from it's own library file. This is why many mods have compatibility updates, and that update also need to abide the commonly arranged library of things.

It's a sign of majority of the moding community, that these things have been thoroughly established.

This was established a long time ago, BEFORE the EE games were a thing, because there was also BG1 / Tutu and BGT compatibility to consider.

[Guest Henanigan]

Hi Jarno, thanks for your comment! As I am sure you are well aware (but others may not be), cpmvars do not solve all compatibility issues; for example, a mod that I updated is supposed to be compatible with standalone BG:EE, standalone BG2:EE, Tutu, BGT, and EET. But the standard libs only contain variables for the BG1 part, or so it seems. So, having accounted for BGT, Tutu, and EET, what area does AR1800 refer to? (In my case, parallel scripts sufficed to address this, and other issues.) Another mod that I updated had area codes hardcoded into binary files. And of course, there may be smaller issues to consider, like facing values in a script. (There may be libs for these as well? OTOH, including a dozen or so libraries may be overkill just to fix one local issue.) If it were true that all these problems were sorted when BGT (BW?) got out, one wonders why there are still mod incompatibilities around... Lazy modders? :)

[jastey]

6 minutes ago, Guest Henanigan said:

But the standard libs only contain variables for the BG1 part, or so it seems.

That is because except for the chapter numbering in EET, all other ressources of BGII and SoD are unchanged in BGII:EE / EET?

What do you mean by parallel scripts, it is not necessary to double the mod files to account for the usual BGII ressources. The only place where EET and BGT needs to be treated differently is the transition to BGII (and the BG1 part, of course), but for BGII, ressource names are the same. Do you have an example?

[Jarno Mikkola]

52 minutes ago, Guest Henanigan said:

So, having accounted for BGT, Tutu, and EET, what area does AR1800 refer to? (In my case, parallel scripts sufficed to address this, and other issues.) Another mod that I updated had area codes hardcoded into binary files.

If the files are in binary format, you neeed to uncompile them using the original game they were compiled in, copy the raw code(so if the file was a .bcs, the source file is a .baf) as is to the mod folder and recompile it DURING the install process using the library files you need to include into the mod folders. Easy.

If you fail to do so, you have not maintained the compatibility, but failed at it.

Say the ar1800.are / ar1800.bcs etc are not in Tutu at all... the files in Tutu start with bg1800... which in the case you ask is the Cloakwoods Exterior.

In BGT(-weidu), they are the very same as the ones all the others in BG2's, the North Forest... the Cloakwoods Exterior in BGT(-weidu) is the other column file from here, aka they start with ar8600... so no incompatibility anywhere, and all the files that need to use those file names, can do so with the inserts from the libraries as long as the GAME_IS variable is identified.

These are community created, and maintained, and thus seen as a guideline, for all modmakers.

42 minutes ago, jastey said:

all other ressources of BGII and SoD are unchanged in BGII:EE / EET?

And in BG2:SoA, BG2:ToB, BGT, BGT-weidu.

PS, wth is "BGII:EE", you Roman or something ? Yes, you should be a Latin, girl.

Edited January 22, 2020 by Jarno Mikkola

[Guest Henanigan]

48 minutes ago, jastey said:

What do you mean by parallel scripts

Like I said, the mod is supposed to be compatible with standalone BG1 as well as standalone BG2 (happy, Jarno?). A script that works for BG2, EET, and BGT, would not work for BG1: there, AR1800 means something else.

As for examples, you may have seen the files.

[Guest Henanigan]

27 minutes ago, Jarno Mikkola said:

If the files are in binary format, you neeed to uncompile them using the original game they were compiled in, copy the raw code(so if the file was a .bcs, the source file is a .baf) as is to the mod folder and recompile it DURING the install process

These are not BCS or DLG files though, but vertex and info files. Yes I could update them during install; there are thousands of occurrences though, in varying positions. Quite a long tp2 file there. Somehow it seemed easier to use two sets of files.

27 minutes ago, Jarno Mikkola said:

If you fail to do so, you have not maintained the compatibility, but failed at it.

If you say so. The mod in question is perfectly compatible with BGT and EET now though (original mod was BGT only).

27 minutes ago, Jarno Mikkola said:

Say the ar1800.are / ar1800.bcs etc are not in Tutu at all...

I think you missed my point See my reply to Jastey above.

[jastey]

7 minutes ago, Guest Henanigan said:

Like I said, the mod is supposed to be compatible with standalone BG1 as well as standalone BG2 (happy, Jarno?). A script that works for BG2, EET, and BGT, would not work for BG1: there, AR1800 means something else.

As for examples, you may have seen the files.

Ah gotcha. Thanks for the explanation.

[Guest Henanigan]

You're welcome. I didn't go into details at first since it seemed a bit off-topic. Sorry if it confused things.

[Jarno Mikkola]

1 hour ago, Guest Henanigan said:

These are not BCS or DLG files though, but vertex and info files. Yes I could update them during install; there are thousands of occurrences though, in varying positions. Quite a long tp2 file there. Somehow it seemed easier to use two sets of files.

Well, 2 sets with BG1 and suppose BG2... but add in Tutu; that's 3rd, BGT-weidu; that's 4th, add in EET that's already a 5th, while you can uncomple the files and then use the library files to compile the files depending on the GAME_IS value and you got yourself 1/5th of the job to update, once it works.

@jastey, you have the ability to separate parts of the thread, if you feel the need to do so, I'll go ahead and say that maybe you might, if you want.

Edited January 22, 2020 by Jarno Mikkola