jastey

I don't see a new version?

@Jarno Mikkola Did you look at what I posted? The EET chapter syntax gets transformed into a strref entry somehow. This was for BGII:EE.

Oh, this is interesting:

Same here:

That was not the question. The question was whether your inofficial EET version also includes the Viconia component.

What is the problem with Lure of Sirine's Calling? I am lost as to what should be changed in the mod package.

Thanks for the update!

Let me know how it works. Have the same problem.

Yay to crawling! Crawling comes after laying and leads into walking, so that's a good thing!

@Mike1072 Thank you! @Luke I'd be interested, but I am not sure I'd work my way through the book.

@AL|EN Thank you, I thought you are referring to some tool or somesuch... A site with explanations is great.

@CamDawg Thank you very much! @AL|EN No. I am just using code snippets I have from elsewhere, I do not know regex coding.

I need enlightment with regard to REPLACE_TEXTUALLY. I thought I know how to use it but it appears I really don't. With @K4thos' permission I am using the following code adapted from EET in my SoD Tweakpack which works fine, i.e. it gets patched accordingly: COPY_EXISTING ~BD6100.BCS~ ~override~ DECOMPILE_AND_PATCH BEGIN SPRINT textToReplace ~IncrementGlobal("bd_finale","bd6100",10)~ COUNT_REGEXP_INSTANCES ~%textToReplace%~ num_matches PATCH_IF (num_matches > 0) BEGIN REPLACE_TEXTUALLY ~%textToReplace%~ ~IncrementGlobal("bd_finale","bd6100",1)~ PATCH_PRINT ~Patching: %num_matches% matches found in %SOURCE_FILESPEC% for REPLACE_TEXTUALLY: %textToReplace%~ END ELSE BEGIN PATCH_WARN ~WARNING: could not find %textToReplace% in %SOURCE_FILESPEC%~ END END BUT_ONLY So, I'm a smart girl so I wanted to use this for another purpose. So I'm using this: COPY_EXISTING ~bd0120.BCS~ ~override~ DECOMPILE_AND_PATCH BEGIN SPRINT textToReplace ~InPartyAllowDead("imoen")~ COUNT_REGEXP_INSTANCES ~%textToReplace%~ num_matches PATCH_IF (num_matches > 0) BEGIN REPLACE_TEXTUALLY CASE_INSENSITIVE ~%textToReplace%~ ~\1 Global("C#st_ImoenInGroupKD","GLOBAL",0)~ PATCH_PRINT ~Patching: %num_matches% matches found in %SOURCE_FILESPEC% for REPLACE_TEXTUALLY: %textToReplace%~ END ELSE BEGIN PATCH_WARN ~WARNING: could not find %textToReplace% in %SOURCE_FILESPEC%~ END END BUT_ONLY and the install fails with the error message: Looking at what I did with REPLACE_TEXTUALLY elsewhere, I put the text into brackets and backslashs, and then it installs and patches fine: COPY_EXISTING ~BD6100.BCS~ ~override~ DECOMPILE_AND_PATCH BEGIN SPRINT textToReplace ~\(InPartyAllowDead("imoen")\)~ COUNT_REGEXP_INSTANCES ~%textToReplace%~ num_matches PATCH_IF (num_matches > 0) BEGIN REPLACE_TEXTUALLY CASE_INSENSITIVE ~%textToReplace%~ ~\1 Global("C#st_ImoenInGroupKD","GLOBAL",0)~ PATCH_PRINT ~Patching: %num_matches% matches found in %SOURCE_FILESPEC% for REPLACE_TEXTUALLY: %textToReplace%~ END ELSE BEGIN PATCH_WARN ~WARNING: could not find %textToReplace% in %SOURCE_FILESPEC%~ END END BUT_ONLY This leads to the following questions: 1. Why is k4thos' code working for bd6100.bcs (without bracktes and backslashes) but not in my case? 2. Why is the install failing at all and not just printing the ~WARNING: could not find %textToReplace% in %SOURCE_FILESPEC%~ line in my first case? My second question is relatedt to 1.2. Because, I want this to work on EET as well as SoD. So, I need the REPLACE_TEXTUALLY to consider both "imoen" and "imoen2" (case insensitive). I thought this is done by using "imoen[2]", but then I get the happy warning upon install: So, here the warning actually works. Which leads me to my final, all defining question: How would the working, multiplatform code look like? If anyone could be of assistance, I'd be grateful.

EET needs other area codes and some cre files have different namens, so depending on what you did, compatibility might not be present (even if the mod installs fine, it might well be that BGII areas were patched instead.)

Did you also try cheating into the area? Where does your install order come from, did you use an automated installer or did you do it by hand? I am surprised to see Ascension before the BG2Fixpack. One note: All four mods were updated recently with bugfixes.

@Arthas Tales of Anegh is from Kerzenburgforum. I just got the same bug report at SHS. I'm sorry for the mess, I'll look into it but it could take a while.

As long as it is clear not to put the SoD script into the BG 1 parameter the function works perfectly. Knowing what I do now it is totally clear that's a bad idea considering it adds the DestroySelf after BG:EE, but I needed a moment to get there, so maybe a small note would be nice.

Unfortunately no, since the structure changed, too. Also, you need the deinstall info from the installed version, so it's basically no difference whether you deinstall the old version fist and then install the new or whether you'd have the possibility to do it in one go.

I can't answer the reason why the transitions and states are created as they are, but the most important thing is: the way it is, it will work, since the INTERJECT only fires for the condition ~IsGabber("MyNPC")~ this means the correct transaction will follow, as well. If you are really interested in why WeiDU is creating the states in such way, Wisp would be the best to explain. The second question: I don't know whether INTERJECT supports it (and I never tried), but you could try INTERJECT SHOAL 1 2 3 InterjectShoal == MYNPCJ IF ~IsGabber("MyNPC")~ THEN @1 DO ~Something()~ = @2 DO ~SomethingElse()~ EXIT and see what happens if you compile it.

I finally got it: -If the NPC has SoD content and uses the same script for BG1 and SoD, do not specify the BG1 script ( STR_VAR override_BG1 = ""). This will prevent the DestroySelf() in Chapter 7. -If the NPC has no SoD content, specify the BG1 script to make sure the NPC will be gone from chapter 7. -If your NPC has different scripts for BG1 and SoD, specify the BG1 script IF you want your NPC to be gone in SoD in case they were not recruited in BG1. I hope this makes sense. Maybe adding a short description to the Modder's Notes would be helpful, unless I'm the only one who was too dense to see this clearly right away.

Oh. That "modmerge is needed" warning is something I took from a very experienced modder so I'd assume it does what it is supposed to. You are not on a Windows OS? This is in the bg1re.tp2: Question: Did you mod the game earlier (including modmerge), then let it update ("revert to a clean install"), and then modded anew, starting with Modmerge? Because in that scenario there were problems with Modmerge pretending to have run but it somehow didn't. Have a look here about what you can do.

I am pretty sure the problem lies with my using the function, as the script block in question looks very much like a "for BG:EE NPC without SoD content" feature. I did not see how to set the function's parameters for an SoD-only (or "SoD also") NPC, though, in the Modder's Notes. EDIT: Wait, I think I get now what it is for: The NPC that was spawned in BG:EE should be no longer present if the SoD campaign started. But since he should not self destruct if he was carried over from BG:EE, this script block gets deactivated if they are present in Korlaz's crypt. I still miss how this would not interfere with a pure SoD NPC or a BG:EE+SoD NPC that is allowed to be present in SoD albeit not in party during the transition.

Fluke13, just to make sure: you deinstalled old version first, then deleted the old folder, before installing the new version?

Both good catches, thank you! Download link is fixed, the mixed reply options will be fixed in the next mod update.

Hello @K4thos, if I want to use the EET_NPC_TRANSITION for an SoD-only NPC, how would I do it correctly? The NPC is only available after the PC left the Ducal Palace, and should not be available in BGII. What I use so far: ACTION_IF GAME_IS ~eet~ BEGIN INCLUDE ~EET/other/EET_functions.tph~ LAF ~EET_NPC_TRANSITION~ INT_VAR type = 1 //Biff is only available in BG:EE/SoD STR_VAR dv = "xxBiff" override_BG1 = "xxBiffs" //OVERRIDE script in BG:EE (actually a BG:EE script doesn't exist, so we just put in the SoD one) override_SoD = "xxBiffs" //OVERRIDE script in SoD traFile = "%MOD_FOLDER%/tra/%LANGUAGE%/dialog.tra" //path to the text line for the ToB Fate Spirit summoning string = "@0" /* ~Bring me Biff the Understudy.~ */ stringPosDV = "Baeloth" //Name after which Biff's should be put into the order of reply options at the fate spirit summoning dialogue. /* From the "Modder's Notes for Baldur's Gate: Enhanced Edition Trilogy (EET)": stringPosDV = "" //set the DV of NPC right below your response (used for sorting FATESP responses alphabetically) //Aerie, Ajantis, Alora, Anomen, Baeloth, Branwen, Cernd, Coran, Corwin, Dorn, Dynaheir, Edwin, Eldoth, Faldorn, Garrick, //Glint, HaerDalis, Hexxat, Imoen2, Jaheira, Jan, Kagain, Keldorn, Khalid, Kivan, Korgan, MKhiin, Mazzy, Minsc, Montaron, //Nalia, Neera, Quayle, Rasaad, Safana, SharTeel, Skie, Tiax, Valygar, Viconia, Voghiln, Wilson, Xan, Xzar, Yeslick, Yoshimo //variable not set (default) = NPC name appended at the end of summoning list */ END END This leads me to a second, related question. Because the function places the following scriptblock into the NPC's override script: IF !InPartyAllowDead(Myself) GlobalGT("CHAPTER","GLOBAL",7) Global("K#PartySoD","LOCALS",0) THEN RESPONSE #100 DestroySelf() END As far as I can see, the NPC would have to be in the group in bd0103 (Ducal Palace at beginning of SoD) so this local variable would be set to 1: Doesn't this mean that any SoD-only NPC would DestroySelf() instantly in SoD, as well as any NPC that wasn't in the party after the first SoD dungeon? What about NPCs that might be left standing at the end of BG1 (or in Korlasz's crypt) but should still be present at the beginning of SoD (in BG city or later) per NPC design? With the experience from my last questions concerning this function (ahem) I am sure the mistake is on my side and I'm missing something.