jastey

Is this true for SoD NPCs, too? I didn't see them in the BG:SoD GAM. But you are right for Jaheira, Minsc, K&D, of course. What do you mean by invalidated and why?

There is also stats etc. And: BGII considers imported items of which they could carry some. There is a way to make this so they are continuous NPCs - one of the advantages of EET - there is no need to take this away from players. Maybe it clears a little if you look into my SoD NPC Tutorial, and how they are handled at the end of SoD. And i was talking about bdcut61 I mentioned before. That is the cutscene that makes NPCs leave the party after the slayer dream scene, and it's also where mod NPCs patch their leaving to.

SoD does this itself, I think it's bdcut61 or something. Maybe you don't have to invent the weel anew. EDIT: the cutscene lets the NPCs leave per scriptnames, so mod NPCs that do not consider this will stay in group. The reason why I used the original cutscene from SoD for EndlessBG1 is that some NPCs need some cleanup if they leave, mod NPCs may have a "joinedparty" variable they need to adjust, some should take specific items with them (for plot reasons) etc. What I'm trying to say: just kicking Player2-6 will not be very mod friendly /compatible. Also: make sure you are not kicking Multiplayers.

You need to make them global before you stow them away. Then you can call them from anywhere by MoveGlobal[Object](), even if they "DestroySelf()"ed. EDIT: That is with using the death variable, at least. I never tried for "Playerx". CreateCreature will spawn the "untouched" cre. If you want players to come visit with pitchforks, go ahead. ^^ EDIT: depending on what you have in mind, you could also hide or make unselectable. Problem with a generic leaving script calling "Player2-6" is that you wouldn't know which NPCs were in party? EDIT 2: Ah, they never leave the party. Then I guess they can still be addressed by "PlayerX". I do believe that the game plays with deactivation of sorts. Or have a look at Weimer's Solaufein, the fight against the handmaiden (I think), where he has to fight alone.

The transition to BGII in EET is very sensitive. EndlessBG1 uses as much of EET's original transition as possible, because I ran into problems of all sorts, too. Meaning, even if SoD is skipped, the group is teleported to the last SoD area so the normal transition can trigger.

Only the ones that do not have direct EET compatibility, according to this list: https://k4thos.github.io/EET-Compatibility-List/EET-Compatibility-List.html (Same link that Jarno already posted.) Mods with direct EET compatibility you install to BGII folder after the EET transformation, even if they effect the BG1 content. The term is EET (Enhanced Edition Trilogy). I have no idea what you mean by that, Jarno.

Did you have a look at Infinity Animations whether it already covers the Drider priestess? If not, please make it compatible with it, whatever you do. My Solaufein mod's drider animations are from there and are compatible.

Hey, come on! This is the IE Engine! Just because it crashes if there is a wrongly formatted text or a "wrong" animation color it doesn't mean it would just crash here, right? Right? On a serious note: this should indeed be fine. It's actually content of bug reports: quest giver xyz didn't notice I already stole the item from his inventory etcpp. You could always test to make sure. I'm 99.95% sure it will not lead to a crash if the item is no longer in inventory. COPY_TRANS only works if you added a new dialogue state you can add it to. With a new state like you did for Solaufein, it's straight forward. Cheers! And, I really appreciate you asking this and collecting knowledge. I know I should write more tutorials about this, so the blame is on me / us older modders for not passing it on properly, but if I see newer mods using the incompatible methods it aches my heart.

It's usually not recommended, especially if you want to continue with your save game. Also, due to how the backup work, un-/reinstalling a mod means all mods installed later need to be uninstalled first, too. weidu handles this automatically, but chances are there could be a hickup along the way. You do not have that much mods installed from what you wrote, which mods do you want to uninstall or change?

OK, I'd do the first one differently so it doesn't scramble whatever the player already patched to their VAELASA 4 state. Since the item should only be handed if the dryad actually has it, i.e. there is an additonal condition and transaction, I do not see an easy way to do this via just patching VAELASA 4. Possibility 1: add a script block to the area script / dryad's script that gives the item "bdbrd01" to the player in case the dryad has it in its inventory as soon as the variable "Global("SummonDryads","AR1200",1)" from her original dialogue is set. Possibility 2: do it like you did for Solaufein, adding a new text line (+ dlg state) and COPY_TRANS. Possibilit 3: make the engine limitation your feature. Items will only be handed via GiveItem if the character talking has them in inventory. If the item is not there, the action will just be skipped. So, if the dryad doesn't have it then she will not give it, simply put. Then, in this case, you can use what I suggested above using ADD_TRANS_ACTION.

Ah, I see you have an additional trigger in the VAELASA transaction. Let me ponder about how I'd do this.

If you mean by moving that they will wait at the inn after being kicked out of teh party, you should not install both "Let NPCs wait somewhere" components of Tweaks Anthology and BG1NPC together but only one. Apart from that; Tweaks Anthology, BG1NPC + Ajantis Expansion should work well together.

Indeed, there are some basic, nonwritten rules that were established for dialogue patching in IE modding over the decades. In short: Make it as compatible and non-intrusive as possible. The reason is simple: another mod might have changed the transaction you are aiming at, meaning your mod would overwrite the other mod's changes. And - another mod might change the state your mod did changes to - overwriting yours. weidu was developped to make additions to dialogues as compatible as possible. This is done by: 1. Always patch your new transactions into the existing one. Do not add a new transition that includes "hard copied" transactions into your own mod. What I mean with hard copied is: copying the transactions that are in the original game and paste them into your mod package. Like I said, another mod might have already added to it, or a tweak mod might have changed the reward, etcpp. Inserting hard copied transactions would erase all changes the player already installed to their game. 2. If you make up a new branch from an existing dialogue state, always circle back to its transitions using COPY_TRANS. Otherwise, your branching off will erase any additions or changes other mods added - or yours might be overwritten by another mod installed later if it doesn't reflect this. There is more like "Never double a dialogue state just because you wanted to change the text line or change the transitions but patch the existing instead" etcpp. To your examples: The first one to VAELASA violates no. 1. In my unmodded game VAELASA 4 has the transactions: ~AddExperienceParty(32500) TakePartyItem("misc4n") SetGlobal("SummonDryads","AR1200",1)~ Apparently, your mod should add ~GiveItem("bdbrd01",LastTalkedToBy)~. So, instead of overwriting the existing transaction of VAELASA 4 by using EXTEND_BOTTOM like you did, you'll patch it simply by: Dang, I see now that you have a trigger there. What I suggest here would work, but it's a bit dirty. See below for comments. ADD_TRANS_ACTION VAELASA BEGIN 4 END BEGIN END ~GiveItem("bdbrd01",LastTalkedToBy)~ Big bonus: this will also work in case another mod added a whole new transition. The Solaufein addition violates no. 2 and 1: again it includes the existing game transcation, which is ~EscapeAreaObject("Tran2100")~, which could be changed by another mod. Also, what if another mod wants Solaufein to say another line here, too? If your mod is installed, the content of the other mod will be erased - or another mod doing it the same way would overwrite yours. So, branching with EXTEND_BOTTOM to a new state is fine, but you need to close the loop using COPY_TRANS, which will add the transactions of the original state like they are in the players' game the moment your mod is installed to your new state, letting the player experience all transactions that were there before. This needs a little restructure so you can put your new actions in: EXTEND_BOTTOM UDSOLA01 161 IF ~Global("BD_HAVE_SOD","GLOBAL",1) Global("K0_SOD_IMPORT_75","GLOBAL",1)~ THEN DO ~GiveItemCreate("bdbrd02",LastTalkedToBy,1,0,0) SetGlobal ("K0_SOD_IMPORT_75","GLOBAL",2)~ GOTO K0SODIMP END APPEND UDSOLA01 IF ~~ THEN BEGIN K0SODIMP SAY @80003 COPY_TRANS UDSOLA01 161 END END

Wellll, he is a bad boy. So sometimes, he likes the PC playing hard to get. Unfortunately, I didn't write Coran's romance and it's scripted really complicated, so I can't be of much help how to steer through it. But, as long as you are not accepting any gestures of more intimate nature, your PC should be fine. If you get both romances going long enough, you'll be one of the 0.01% of players who'll actually see the romance conflict contest between the two, which, biased as I am, I think is worth seeing.

Oh, no worries. His romance breaks easily because he gets bored easily. If your PC is more the Ajantis type, this might happen quickly. : p