EET support?

[agnes]

Is this planned to be added?

[jmaeq]

It's in my plans to include EET support. It will happen...eventually.

[jastey]

If you have BGII:EE compatibility, adding EET is not very complicated (if you know how). Let me know if you want help!

[jmaeq]

6 hours ago, jastey said:

If you have BGII:EE compatibility, adding EET is not very complicated (if you know how). Let me know if you want help!

That would be fantastic, thank you very much! I'll try to fiddle around with it first before I start bombarding you with questions. Who knows, maybe I'll be able to fumble my way around. 

[jastey]

The basics is really easy if you've already done it, so don't spend too much time searching. This is what I wrote somewhere else with regard to making a BGII:EE NPC mod EET compatible:

Quote

The basic way to make a BGII:EE NPC EET compatible is the following:

The EET Contiuous Chapter System you'll need always. Changes for this: the addition to the tp2 ALWAYS block, changing the chapter numbers to the according OUTER_SPRINTs %bg2_chapter_x% and adding the EVALUATE_BUFFER to the compilation commands of the relevant files in the tp2.

Then there are two ways to proceed from here for the ToB transition (for a BGII-only NPC).

1. Using the EET_NPC_TRANSITION function AND disabling the following for EET:
   1. summoning via fate spirit dialogue (FATESP.dlg)
   2. the disabling of the possibility to summon via fate spirit if NPC is in party upon soA-ToB transition (usually done by setting the variable in AR4000.bcs)
   3. creation of NPC if called via fate spirit (AR4500.bcs)
2. Not using the EET_NPC_TRANSITION function. In this case, the summoning of the NPC has to be added to FATESP.dlg, the possibility to do so has to be disabled if the NPC is in party upon SoA->ToB transition, and the creation of the NPC in AR4500.are has to be provided by patching AR4500.bcs. In addition to this (and this is new), the change of the override script from the SoA to the ToB one has to be done by hand in AR4000.bcs if the NPC is in party, as it will not be done automatically.

Apart from that, for a BGII NPC you should be fine. Care has to be taken if the mod was developped on BGT with all the BG1 ressources, as EET uses own filenames for the BG1 files that share names with BGII files, but that shouldn't be an issue for most BGII mods.

Theoretically, EET provides much more possibilities for the continuous NPC summoning in ToB etc. It does, for example, distinguish between "NPC was in party", "NPC was never in party" (-> will not be available for summoning in a continuous game), and "is dead" (-> summoning is available but NPC will not spawn, obviously).

For the "old" BGII NPC, the continuous system is a bit dangerous, though, as it will move the BGII NPC to ToB as (s)he was left in SoA - in case that was in chapter two, the NPC will be level 7/8/9 and the player might be a bit piqued if there is no script added to boost the XP a little.

If you look at e.g. Amber v5 and search for ~eet~ in the tp2 you'll see the according script blocks that need to be added to the tp2.

[jmaeq]

Oh! If it really is a couple minutes like the tutorial said and if it's just that chunk in Amber's tp2, then TBL is now EET compatible (I will release this new version tomorrow). Thank you, jastey!

Edited February 8, 2019 by jmaeq

[cmorgan]

Check on one big thing too, just in case -  amellg, on an EET install, reported my SoA PiDs fire in ToB as well. Screening the always-true condition with a chapter check solved the problem. That leads me to believe that the safest way on an EET install is to add chapter conditions to dialogues you want to trigger in the correct game (or to use the other identifiers). Most content is specific enough as it is to avoid this, but if you have a PiD for SoA and a different one for ToB, it might be worth an extra variable check!

[jmaeq]

1 hour ago, cmorgan said:

Check on one big thing too, just in case -  amellg, on an EET install, reported my SoA PiDs fire in ToB as well. Screening the always-true condition with a chapter check solved the problem. That leads me to believe that the safest way on an EET install is to add chapter conditions to dialogues you want to trigger in the correct game (or to use the other identifiers). Most content is specific enough as it is to avoid this, but if you have a PiD for SoA and a different one for ToB, it might be worth an extra variable check!

That would have been a huge mess, if you didn't catch that. Thank you!

Also, just to clarify on addressing the chapters across EE and EET, instead of using this:

Global("Chapter","GLOBAL",6)

I should be doing something like this:

Global("Chapter","GLOBAL",%bg2_chapter_6%)

^ This version would be fine for both EET and non-EET?

[jastey]

Oh, yes, that's a good note indeed. All joined dialogue is combined to one so any case of "I don't need to close the dialogue's variable because it ends in SoA" will lead the player stuck with the same dialogue in ToB - SoA PID being the most favorite candidate.

18 minutes ago, jmaeq said:

^ This version would be fine for both EET and non-EET?

You compile it using EVALUATE_BUFFER and it will give the correct chapter number for all games (with the according tp2 block).

[K4thos]

Quote

Most content is specific enough as it is to avoid this, but if you have a PiD for SoA and a different one for ToB, it might be worth an extra variable check!

I've just checked the files and it looks like The Beaurin Legacy uses IsGabber(Player1) trigger for Player-Initiated Dialogues, so no additional filtering is needed here.

EET has built in PID dialogue detection via IsGabber trigger and adds Chapter checks in such places automatically - unless Chapter trigger already exist, in such case the additional PID filtering is skipped.

[jastey]

3 minutes ago, K4thos said:

I've just checked the files and it looks like The Beaurin Legacy uses IsGabber(Player1) trigger for Player-Initiated Dialogues, so no additional filtering is needed here.

EET has built in PID dialogue detection via IsGabber trigger and adds Chapter checks in such places automatically - unless Chapter trigger already exist, in such case the additional PID filtering is skipped.

Man, I don't know how many times I'll use this smiley on you but you really deserve it. Awesome.

[cmorgan]

Niiiice!! 

[jmaeq]

Would it be safe to only use EVALUATE_BUFFER on the scripts and dialogue affected by the chapters and leave all others using the good 'ole COMPILE only?

And I'll just say this one final time, so it doesn't get too repetitive - thanks for the never-ending help everyone!

[jastey]

27 minutes ago, jmaeq said:

Would it be safe to only use EVALUATE_BUFFER on the scripts and dialogue affected by the chapters and leave all others using the good 'ole COMPILE only?

Yes. EVALUATE_BUFFER just makes sure the %xxxx% OUTER_SPRINT variables are replaced with whatever they were supposed to mean. It doesn't hurt to use it if there is no variable, but you don't need it then, either.

[jmaeq]

So, for one last check:

1. ALWAYS block of code in tp2
2. Change chapter globals to %bg2_chapter_x% (I won't need to do anything for PIDs because of IsGabber)
3. Use COMPILE EVALUATE_BUFFER on files that are affected by the chapters