EET interferes with familiar mods...?

[subtledoctor]

From a report, it appears that EET does something that has an effect on how/when familiars are summoned.

For reference, the mod in question allows the player to pick a familiar and then casts a subspell which does the actual summoning:

Spoiler

 

The opcode 192 effect in the subspell is basically the same as the one in the unmodded SPWI123.spl.  Any idea why the mod would work in BG2EE, but not in EET?

 

[Jarno Mikkola]

It could be any of the 628 effects. Not just the one.

[subtledoctor]

Thank you for being entirely unhelpful as usual.  That particular version of the spell has a bunch of opcode 146 effects that cast subspells with opcode 171 effects, for unrelated reasons.  Neither opcode 146 nor opcode 171 will result in a error message that "Only the protagonist may cast Find Familiar."  Only the opcode 192 'Find Familiar' effect causes that. 

So, given that the the spell mimics the opcode 192 effect from the unmodded Find Familiar spell, and it works just fine in the absence of EET, I conclude that either 1] there's something I don't understand about opcode 192, or 2] there's something I'm unaware of that EET does relating to familiars.  (I don't know how the game checks for whether the caster is the protagonist in the first place... I suspect this process is being modified by EET somehow.)

[Jarno Mikkola]

Well, that might be important to eliminate.

Why is the power 0, in spwi123.spl it's 1... and the dispel/resist is in the original spell zero, not 2.

If I remember, this bug might have been fixed already and now it's broken again.

Edited January 27, 2020 by Jarno Mikkola

[subtledoctor]

2 hours ago, Jarno Mikkola said:

Why is the power 0, in spwi123.spl it's 1... and the dispel/resist is in the original spell zero, not 2.

I did notice those differences... but if they prevent the opcode from working, why does it work fine in BG2EE?  EET is BG2EE, but modified; so the evidence seems to suggest that the difference lies somewhere in EET's modifications.

2 hours ago, Jarno Mikkola said:

If I remember, this bug might have been fixed already and now it's broken again.

...what bug?

[Bubb]

EET uses this block in K#FAMSUM.BCS to detect if the summoner was the protagonist:

IF
    TriggerOverride(Player1,Summoned(Myself))
THEN
    RESPONSE #100
        SetGlobal("K#FAMPRO","GLOBAL",0)
END

 

Looks like you are changing the alignment of the protagonist for a split second before you invoke the summon. The problem lies in Summoned(), and how the engine processes "reactionary" triggers.

The engine saves a snapshot of the summoner's object selector values (plus a few other things) when it summons the familiar, and since you change the character's alignment right before the summon, it saves the altered value. The Summoned trigger runs late enough that the protagonist's alignment has already reverted. It's basically asking the trigger, "Does Player1 match the snapshot I saved earlier?" - and that fails, since the alignment is different.

I don't know how to fix the mechanism, that's just what I've found from inspecting the engine.

[subtledoctor]

Huh. Any idea why EET does that? What is the K#FAMPRO global variable used for?

EDIT - and I guess, the ultimate question is whether that gets installed in EET_Core or EET_End.  If the former, then I can do something about it.

Edited January 28, 2020 by subtledoctor

[K4thos]

unswered here: 

all it does is unhardcoding find familliar spell to no longer use opcode 192 but scripts instead, so that different CRE files can be summoned in different parts of the game. And since summoning and removing familiar scripts are meant to work exactly like opcode 192 by default, hence the K#FAMPRO global variable usage.

 

[subtledoctor]

23 minutes ago, K4thos said:

unswered here: 

all it does is unhardcoding find familliar spell to no longer use opcode 192 but scripts instead, so that different CRE files can be summoned in different parts of the game. And since summoning and removing familiar scripts are meant to work exactly like opcode 192 by default, hence the K#FAMPRO global variable usage.

Thanks for the response... but that didn't quite answer it for me!     If I understand you correctly, does that mean I cannot use the basic Find Familiar spell in EET games?  Opcode 192 cannot be used?  I have to manually script the summon?  If so... how does one do that??

I guess the short version of my question is, can EET implement that in a way that doesn't disable mods that use the 192 effect?  I don't know how the k#famsum script works, but it seems like it leads to to overly restrictive results - as noted, it prevents the familiar from being summoned if the caster's alignment has changed.  It affects my mod in particular, because it uses alignment changes to determine which familiar should be summoned; but it seems like it would cause problems in the base game as well, since there are several ways the player's alignment can change (the Helm of Opposite Alignment, the Hell Trials, etc.)

Edited February 7, 2020 by subtledoctor

[Jarno Mikkola]

15 minutes ago, subtledoctor said:

Thanks for the response... but that didn't quite answer it for me!     If I understand you correctly, does that mean I cannot use the basic Find Familiar spell in EET games?  Opcode 192 cannot be used?  I have to manually script the summon?  If so... how does one do that?

Seems to me that you are not asking the question correctly, as I saw k4thos answer, and read it like so: The spell is changed so that it doesn't use the Find Familiar opcode, but instead uses a script mechanism included in EET to produce the same effect via a scripted action that is included, in the said script. So the EET edit the spell to summon a creature, than then runs the said script(K#FAMSUM.BCS) and a correct creature is produced.

The PC's alignment change might need to be taken into account at some point. It just might lenghten the script a bit... but you could open the said script and see if you worry is even required.

Edited February 7, 2020 by Jarno Mikkola

[K4thos]

Quote

Thanks for the response... but that didn't quite answer it for me!     I understand you correctly, does that mean I cannot use the basic Find Familiar spell in EET games?  Opcode 192 cannot be used?  I have to manually script the summon?  If so... how does one do that?

you can but in such case you will remove the EET feature that allows summoning different CRE files in different parts of the game. If you prefer it like this you can use this code to get rid of EET implementation:

ACTION_FOR_EACH file IN FAMCAT_ FAMDUST_ FAMFAIR_ FAMFER_ FAMIMP_ FAMPSD_ FAMQUAS_ FAMRAB_ FAMCAT FAMDUST FAMFAIR FAMFER FAMIMP FAMPSD FAMQUAS FAMRAB FAMCAT25 FAMDUS25 FAMFAI25 FAMFER25 FAMIMP25 FAMPSD25 FAMQUA25 FAMRAB25 BEGIN
    COPY_EXISTING ~%file%.CRE~ ~override~
        LPF DELETE_CRE_EFFECT INT_VAR opcode = 232 END
    BUT_ONLY
END

You will also need to restore vanilla SPCL342.SPL and SPWI123.SPL since EET removes opcode 192 from them and adds script execution instead.

Alternatively, if you want to keep EET implementation, you can edit:

- K#FAMSUM.BCS - controls which familiar will be spawned and initial bonuses

- K#FAMKIL.BCS - controls what happens when your familiar dies

- K#FAMREM.BCS - used to manually remove the familiar without negative consequences (for example after importing character that has familiar to new game or at the end of SoD, so that player can summon new one after leaving the cage)

 

Edited February 7, 2020 by K4thos

[subtledoctor]

7 minutes ago, Jarno Mikkola said:

The PC's alignment change might need to be taken into account at some point. It just might lenghten the script a bit... but you could open the said script and see if you worry is even required.

You're not caught up Jarno.  My worry is required, because it has already been reported that the script breaks my mod:

On 1/27/2020 at 2:42 PM, Bubb said:

EET uses this block in K#FAMSUM.BCS to detect if the summoner was the protagonist:

IF
    TriggerOverride(Player1,Summoned(Myself))
THEN
    RESPONSE #100
        SetGlobal("K#FAMPRO","GLOBAL",0)
END

Looks like you are changing the alignment of the protagonist for a split second before you invoke the summon. The problem lies in Summoned(), and how the engine processes "reactionary" triggers.  The engine saves a snapshot of the summoner's object selector values (plus a few other things) when it summons the familiar, and since you change the character's alignment right before the summon, it saves the altered value. The Summoned trigger runs late enough that the protagonist's alignment has already reverted. It's basically asking the trigger, "Does Player1 match the snapshot I saved earlier?" - and that fails, since the alignment is different.