Happines and Breaking Points (How to in EET)

[Roxanne]

I can confirm that it is hardcoded. Replaced whole DPLAYER2.BCS with this code:

IF
  !InParty(Myself)
  OR(2)
    BreakingPoint()
    !HappinessGT(Myself,-299)
THEN
  RESPONSE #100
    DisplayStringHead(Myself,1)
    JoinParty()
END

Imoen, Jaheira and Khalid were automatically leaving the team and rejoining after I killed few people in Friendly Arms Inn. No problem with Xzar and Montaron (they don't mind due to Alignment) So it's the engine that kicked them from party in the first place, not what has been coded in DPLAYER2.BCS. I will post a bug report on Beamdog bug tracker.

 

 

 

 

That does not solve the issue of those like Vynd, according to race he is evil and will leave on HIGH reputation, but the guy does not care what surfacers think about reputation but takes PC as he/she acts. Same for Jen'lig, evil because Githyanki but does not care what some bigot citizens from the Prime think about her PC as long as he/she is efficient against the common foe.

So Drizzt evil too ?

This is the very definition of bigotry .. just set them to be neutral and it's all the same for what the world thinks about things.

 

We are in a game and those are the rules of that game. You can discuss a lot about that...

Someone Evil like Viconia or Edwin would never leave the party because PC earns reputation by good deeds - they would rejoice, it is profitable and it the best disguise they can ask for, they can act wonderfully out of the shelter of the Hero - in an evil party they will just attract all the unwanted attention of the authorities, etc...

 

That is a good first step, I think.

 

The way the game has advanced since its early days may require a different view on that good/evil classification.

There is the one aspect of how society may look at an NPC (and react, e.g. shopowners etc)

But it is different from how those NPCs chose to react - the PC gaining reputation may just serve their purpose well. So an option to let the NPC creator decide on this would be wonderful.

[Jarno Mikkola]

The way the game has advanced since its early days may require a different view on that good/evil classification.

There is the one aspect of how society may look at an NPC (and react, e.g. shopowners etc)

This idea is not a new one either... there's a mod, but because it is not really compatible with the BGT-weidu, it got pushed to sides ... and it has some odd concepts about the reputation.

But it's a computer game, so making the tally on the sides is as arbitrary as you make them.

[Roxanne]

 

The way the game has advanced since its early days may require a different view on that good/evil classification.

There is the one aspect of how society may look at an NPC (and react, e.g. shopowners etc)

This idea is not a new one either... there's a mod, but because it is not really compatible with the BGT-weidu, it got pushed to sides ... and it has some odd concepts about the reputation.

But it's a computer game, so making the tally on the sides is as arbitrary as you make them.

 

Sshhh - that mod is expert in BWS for a number of reasons. (And it whether ii works in EET if this engine works different fron BG2/BGT in this aspect??)

[agb1]

Virtue doesn't work in EE but K4thos suggested that he might reimplement it some day using a different method.

[K4thos]

Virtue doesn't work in EE but K4thos suggested that he might reimplement it some day using a different method.

to be more precise:

I could try to write it from scratch using the original mod as a reference for what to patch but only if EE engine will finally support Eval / Assign triggers and actions from TOBEX: http://www.shsforums.net/topic/54760-completed-script-variable-substitution-triggers-and-actions/

Let's see if patch 1.4 will add them. Without those the code to implement this feature would be too bloated. And porting the mod as it is, with the infamous 3500 lines added to baldur.bcs global script is not worth it, imo.

 

As for the problem at hand I've tested how it works in other engines/games:

1. vanilla BG1 - party members never leave you due to low reputation. I've killed everyone in Friendly Arms Inn and Imoen, Khalid, Jaheira complained but didn't leave me. DPLAYER2.BCS don't have anything that would kick party members out.

 

2. vanilla BG2 - party members initiate dialogue and leaves party due to block inside DPLAYER2.BCS that forces this behaviour:

IF
  BreakingPoint()
THEN
  RESPONSE #100
    SetGlobal("IHATEYOUALL","LOCALS",1)
    SetLeavePartyDialogFile()
    Wait(1)
    StartDialogueNoSet(Player1)
    ChangeAIScript("",DEFAULT)
    SetGlobal("IHATEYOUALL","LOCALS",0)
END

IF
  Global("IHATEYOUALL","LOCALS",1)
  InParty(Myself)
THEN
  RESPONSE #100
    SetLeavePartyDialogFile()
    Wait(1)
    StartDialogueNoSet(Player1)
    ChangeAIScript("",DEFAULT)
    LeaveParty()
    SetGlobal("IHATEYOUALL","LOCALS",0)
END

3. BGT - same as BG2, but the implementation is bugged because BG1 characters don't know how to react to IHATEYOUALL variable and don't have any dialogue for such occasion, so they end up being kicked out by script but initiate normal friendly POST dialogue, so you can keep them (only in BG1 portion of the game, BG2 dialogue files fits the way it is coded). If you remove above mentioned block from DPLAYER2.BCS than they will react exactly the same as in BG1 - won't leave, won't initiate dialogue.

 

4. BG:EE - Beamdog added new code to DPLAYER2.BCS to kick out characters:

IF
  !InParty(Myself)
  !HappinessGT(Myself,-299)
  !Name("neera",Myself)
  !Name("dorn",Myself)
  !Name("rasaad",Myself)
  !Name("baeloth",Myself)
THEN
  RESPONSE #100
    VerbalConstant(Myself,UNHAPPY_BREAKING_POINT)
    Wait(5)
    EscapeArea()
END

IF
  !CharName("Imoen",Myself)
  BreakingPoint()
THEN
  RESPONSE #100
    VerbalConstant(Myself,UNHAPPY_BREAKING_POINT)
    Wait(3)
    EscapeArea()
END

Kicking out party members due to low reputation is hardcoded in the exe file. The code doesn't even have LeaveParty() so I think it's intentional (which is awful change considering it migrated to BG2:EE too).

 

5. BG2:EE - again hardcoded kicking out, but characters will at least tell you their reputation dialogue thanks to the script (same as the one in vanilla BG2).

 

In other words major regression compared to how it worked in vanilla engine. What had been controlled entirely by DPLAYER2.BCS is now ignored and the engine kicks out characters on its own.

 

Reported the problem on Beamdog forums: https://forums.beamdog.com/discussion/46783/all-ee-engines-leaving-on-breaking-point-should-not-be-hardcoded

[Jarno Mikkola]

... 4 ...

There's an easy to tweak this, you just need to alter the happy.2da file a tiny bit. And it will never fire. Or it will fire when you wish it to, be it 85 or -555 if you associate the numbers and scripts etc. into a uniformatic functionality.

[argent77]

BG2EE added opcode 360 (Ignore reputation breaking point) for just this reason. Furthermore, there are a few comments from Avenger in this thread suggesting that the breaking point has not been hardcoded specifically in the Enhanced Editions.

[K4thos]

thanks, argent77. Although my tests shows that the effect doesn't work (unless it means something else than leaving the party on low reputation). Like I mentioned in vanilla BG:EE without any mods Imoen will still leave the party even though her CRE file has this effect applied. She is automatically kicked out by the engine. And nothing like this happens on fully patched BG1 and BG2:ToB where this is entirely controlled by DPLAYER2.BCS (no one leaves if you remove code from that script), so what Avenger said doesn't seem to be correct:

Which is fine, but I still think party member morale should be handled entirely via scripts.

 

I don't think Beamdog hardcoded anything over vanilla. The code they started from was the vanilla BG2/ToB source. If the breaking point code is hardcoded, then it was also in ToB.

[argent77]

This effect is not available in BG:EE v1.3.2053, but it's most likely added with the next patch. Did you test it in BG2:EE as well?

[K4thos]

I've tested it on EET too, but just noticed that only BG2:EE Imoen CRE files have this effect. So there is a working workaround for this issue. Thanks for information.

 

Roxanne, use this code to patch your CRE file:

LPF ADD_CRE_EFFECT
  INT_VAR
  opcode = 360 //Ignore reputation breaking point
  target = 1 //Self
  timing = 1 //Instant/Permanent until death
END

[Roxanne]

 

I've tested it on EET too, but just noticed that only BG2:EE Imoen CRE files have this effect. So there is a working workaround for this issue. Thanks for information.

 

Roxanne, use this code to patch your CRE file:

LPF ADD_CRE_EFFECT
  INT_VAR
  opcode = 360 //Ignore reputation breaking point
  target = 1 //Self
  timing = 1 //Instant/Permanent until death
END

1. With respect to timing - Instand /Permanent until death? Means it will end when NPC dies (for the first time), or not - should be Instand/Permanent

2. This may be directtly in the cre file, right? Also in the cre file of a save to test it.

 

I will do some tests on these assumptions.

[Roxanne]

 

 

I've tested it on EET too, but just noticed that only BG2:EE Imoen CRE files have this effect. So there is a working workaround for this issue. Thanks for information.

 

Roxanne, use this code to patch your CRE file:

LPF ADD_CRE_EFFECT
  INT_VAR
  opcode = 360 //Ignore reputation breaking point
  target = 1 //Self
  timing = 1 //Instant/Permanent until death
END

1. With respect to timing - Instand /Permanent until death? Means it will end when NPC dies (for the first time), or not - should be Instand/Permanent

2. This may be directtly in the cre file, right? Also in the cre file of a save to test it.

 

I will do some tests on these assumptions.

 

Tested it - works both for high and low rep on good/evil NPCs respectively. Those that have the opcode 360 stay, others leave.

I applied the code directly to the cre files with timing = 1 //Instant/Permanent and probability1 = 100

 

NB this time I had EE's own Dorn in the party who left on rep high.

 

Looks to me like another issue solved, thank you very much.

 

This may be helpful to others modders as well (e.g. Vynd, Tsujatha, Gavin, Edwin/Edwina is what I found in old dplayer2 code)

[Jarno Mikkola]

This may be helpful to others modders as well (e.g. Vynd, Tsujatha, Gavin, Edwin/Edwina is what I found in old dplayer2 code)

I am not so sure about that... cause; Would they be on the script file if they weren't meant to be made to leave if that were the case ? And like said, just edit the -300 to -299 in the happy.2da -file and you are fine with everyone, if that's what you want.

[Roxanne]

Conclusion from further testing is this:

Using opcode 360 with the settings described above makes the NPC immune to reputation changes and thus has the effect formerly (in BG2based ganmes) created by appending to dplayer2.bcs

 

code used by EE NPCs

IF
GlobalLT("ENDOFBG1","GLOBAL",2)
!InParty(Myself)
OR(5)
Name("neera",Myself)
Name("dorn",Myself)
Name("rasaad",Myself)
Name("baeloth",Myself)
HappinessGT(Myself,-299)
THEN
RESPONSE #100
Dialogue(Player1)
ChangeAIScript("",DEFAULT)
END

makes NPCs leave party on rep changes but having a talk with the PC prior to that (like Dorn you can pick him up when your rep has changed again to his liking)

 

Code used for Imoen used in dplayer2.bcs does nothing.

 

So, from this variants you can chose what you desire for your NPC or simply do your own tweak.

 

Fiddling with happy.2da is not what I would recommend for an NPC mod as it affects EVERYBODY in the game, not just your NPC.

This is for some Tweak mod to introduce again the *Happy feature* and this should (if at all) only done when clearly required by the player in his installation.

Otherwise a method that only affects a modder's own NPC(s) is the way to go.

[Roxanne]

Tested this successfully on all NPCs that should be immune to reputation changes and stay in the party even if reputation is very high or low.

In tp2 use this

 

COPY_EXISTING ~MyNPC.CRE~ ~override~
LAUNCH_PATCH_FUNCTION ADD_CRE_EFFECT
INT_VAR
opcode = 360 //Ignore reputation
timing = 9 //Permanent
target = 1 //Self
resist_dispel = 0 //Not dispellable + bypass resistance
END
BUT_ONLY