The Imoen Bug

[Chronis]

So I got around to identifying the imoen bug and looking for anything similar in all the other NPCs like I said I would.

 

To refresh your memory the bug is that imoen automatically leaves at a reputation of 8 or lower when you initiate dialog with her.

 

Somewhere along the line this little bit of code got added to the Imoen2.dlg file

 

IF WEIGHT #27

~HappinessLT(Myself,0)

~ THEN BEGIN 4

SAY ~Well good! You've changed since we were friends anyway. Not nearly as much fun now. Should have stayed in Candlekeep, instead of wasting time with you gully pennies.~

IF ~~ THEN DO ~LeaveParty()

~ EXIT

END

 

These happiness checks belong in the P files and for every other joinable NPC they are only listed in P files. Having this code in the dialog file is what is causing imoen to leave when she should not.

 

Right now the behavior of all the other NPCs except imoen is as follows.

1) If there happiness drops to their breaking point they leave the group

2) If you kick them out of the group and they are even slightly unhappy they

will leave for good

 

Breaking Point and Slightly Unhappy levels are reached at different reputations depending on alignment

 

Alignment Breaking Point Reputation

Good 1 or 2

Neutral 1

Evil 19-20

 

Alignment Unhappy Reputations

Good 3-8

Neutral 2-5, and 19-20

Evil 13-17

 

If reputation drops to the breaking point, the Dplayer2.bcs script triggers causing the NPC to leave permanently.

 

If you kick an unhappy NPC out of the group, code in each specific NPC P file has a happiness check similar to the bad imoen code above. This will also trigger the NPC leave permanently.

 

The bad imoen code is causing any initialization of dialog to trigger the same reaction as if you kicked her out of the group.

 

The good news is the problem is limited to imoen and a very quick fix. If the bad code is axed, Imoen's behavior fall into line with all the other good NPCs in the game

 

-Chronis

[cmorgan]

Cool stuff, and comprehensive summation!

 

Quick follow up notes, and a requested discussion, plus final voting from active project members:

 

BGT adds this particular line as a separate entity to Imoen's J File, and Ascension64 has posted about this on his SHS forums, but I don't remember the specifics - basically, the argument has always revolved around whether the HappinessLT(0) was a bug left over from conversion to the BG2 engine (in BG2, these values are -255 or something) or Original Behavior and therefore to be left alone. Ascension64 so far has left this as "original behavior" on BGT, going so far as to correct and append the value to Imoen's file for her BG content.

 

There are a couple of ways folks can fix this behavior, if we want to fix it. Because of the bug reports on BGT and Megas, this is included as a "fix' to allow more BG1NPC content with parties which include the "evil NPCs". As of v15 (when it comes out), BG1NPC will seek for this state and disable it by setting a "non-attainable global", so that if someone feels that it must be re-enables in their game it can be done by CLUAConsole rather than editing the scripts with NI or DLTCEP.

 

REPLACE_STATE_TRIGGER IMOEN2J %BGTIMOENJState0% ~Global("X#JCleanImoen","GLOBAL",1)~

This patching may fail on BGT 1.05 if you have other mods installed before BGT (see the Floating State conversation on SHS). It will work fine on BGT 1.05 with no mods installed prior to BGT conversion, and on all BGT installs (Mega or vanilla, pre- or post BGT installation) when BGT v1.06 rolls out (thanks to Ascension64's special handling and work to provide us with those fluid state solutions).

 

 

ON TUTU/EASYTUTU:

 

I know this has come up a bunch of times on the BG1NPC front, and I think the answer has always been "it was original behavior, so leave it alone and let a Fixpack handle it".

 

I can definitely include a matching fix on the Tutu side, if I have a quorum (I am abstaining - I don't like the bug reports on Tutu, the difference in content BGT vs Tutu [but that is a functional difference as on BGT there are other mods at play cleaned out the non-conditional variable on BGT, and I agree with Pro5 that it is required on that platfiorm] but I don't see how low rep parties should keep Imoen around at all - under 8, I would expect her to leave at the very first opportunity!)

 

Arguments for:

• less bug reports from low rep players, and consistency.
  
• more possibility that Imoen will remain with Tiax, Edwin, Eldoth, SharTeel, et al.
  
• we already false out Minsc's and Kivan's timers and alter Coran's timers to support these NPCs staying around longer.
  

Arguments against:

• past project discussions have seemed to favor that Imoen leaving at low rep was expected behavior.
  
• This might be beyond our scope and belong in a fixpack.
  
• Technically, installing a Happy patch should allow a wider range of reputation before unhappiness kicks in, meaning that BG2 TweakPack could fix this using the components that alter unhappiness.
  

Discussion and votes? This is a one line fix. (anyone is welcome to discuss and help make up minds, but votes that count come from Domi, Andyr, Jastey, kulyok, and berelinde. 3 votes aye or nay settle the question.)

[Chronis]

Regarding the HappinessLT(0) check

 

This check is in the P file of every joinable NPC including imoen's..

The only actual effect of this is that NPCs will leave for good if you kick them

out of the party when they are unhappy.

 

It been a while since I played non Tutu BGI, but I am fairly confident this

is original behavior.

 

BGII NPCs have a check of HappinessLT(290) in their P files.

The only difference this makes is that they will be willing to come back into

the group if you kick them when they are unhappy, but not if your reputation drops so low that they reach their breaking point.

 

The problem with Imoen is that she has an extra and improper HappinessLT(0) check in her main dialog file imoen2.dlg

 

The effect of this check is that each time the PC speaks with her it triggers the same check it would if the PC kicked her out of the party. If she is even slightly unhappy, she takes off for good.

 

This is likely an error introduced either in the tutu conversion, or in an early version of the BG1NPC patch as she did not exhibit this behavior in the original BGI.

 

My recommendation is to ax the bad code in the Imoen2.dlg file and leave the

rest of the HappinessLT(0) checks alone as they are likely original BGI content.

 

-Chronis

[cmorgan]

As the crickets are chirping, I am assuming the lead and matching the behaviors on both sides of the aisle, so to speak.

 

Clean, unmodded _IMOEN2.DLG:

 

~HappinessLT(Myself,0)

~ THEN BEGIN 4 // from:

SAY ~Well good! You've changed since we were friends anyway. Not nearly as much fun now. Should have stayed in Candlekeep, instead of wasting time with you gully pennies.~ /* #87122 */

IF ~~ THEN DO ~LeaveParty()

~ EXIT

 

 

On Tutu only, instead of completely removing the state, we can preserve it by emulating the

ALTER_TRANS ~_IMOEN2~ // file name

BEGIN 4 END // state number (can be more than one)

BEGIN 0 END // transition number (can be more than one)

BEGIN // list of changes, see below for flags

~TRIGGER~ ~HappinessLT(290)~

~ACTION~ ~~LeaveParty() SetDialogue("_IMOENP")~

END

 

or we can just nix it entirely, leaving it never seen again under any circumstances other than setting the global specifically:

 

 

REPLACE_STATE_TRIGGER ~_IMOEN2~ 4

~Global("X#JCleanImoen","GLOBAL",1)~

 

I am coding in the second in the internal, and if there is no quorum or no vote before v15 is released, it will be a done deal.

[berelinde]

If you're asking if it's OK to nuke Imoen's refusal to rejoin at low reputations, I'm all for it. It's very strange that I can recruit Minsc with a reputation of 5, ditch him right away, and have him offer to meet me at the Belching Dragon, but Imoen, who has known me from childhood, does a runner.

[Chronis]

It should not make an in game difference either way.

If it is changed to ~TRIGGER~ ~HappinessLT(290)~ it will have the same effect as removing the state.

 

A trigger of <290 in the dialog file will never be triggered, because the Dplayer2.bcs file will automatically kick imoen out of the group at that happiness level.

 

I would do whatever is easier

 

If you're asking if it's OK to nuke Imoen's refusal to rejoin at low reputations, I'm all for it. It's very strange that I can recruit Minsc with a reputation of 5, ditch him right away, and have him offer to meet me at the Belching Dragon, but Imoen, who has known me from childhood, does a runner.

 

Imoen should not refuses to rejoin at low reputations with the current code.

 

Right now she acts in the following manner

 

Reputation > 8 she is happy, and will will be willing to rejoin the party if you kick her out

 

Reputation >2 but <8 she is unhappy and will stay in the group but if you kick her out she leaves for good.

 

Reputation > 2 but <8 if you initiate any dialog with her she automatically leaves the group. (this is the bug that will be fixed by the above change)

 

Reputation = 1 or 2, Imoen has had enough and will leave on her own

 

Currently, if you kick her out with a reputation of 9 or higher, you can come back with a lower reputation of say 5 and she will still be willing to rejoin. However, after she rejoins, you can't kick her out again unless your reputation is >8 or she leaves for good.

 

edit: edited for clarity

[cmorgan]

Cool - it's settled then - if the net result is a falsing of the state anyways, x#JClean it is.