K4thos

you didn't install the patch that replaces BP-BGT Worldmap BAM file, right? Download it from GitHub and reinstall worldmap. than it's a matter of adding additional trigger: !AreaType(BG1AREA) Will be ready for next RC, thanks for report. Finally that additional flag added to all imported areas is useful for something

what is the time limit for thieves guild? Is there similar functionality in other strongholds? Didn't think about that. btw. since you're already in SoA - do not go back to SoD areas. As mentioned in this post they are not ready yet for returning parties and I've just noticed that one of the links still connects them with rest of the world. Once you travel there you won't be able to go back. This will be fixed soon.

I think it must be considered for EET. @k4thos - suggest to add condition Global("OHRCUT01","AR2000",1) to the two blocks in ar2000.bcs that spawn Rasaad Thanks for report and investigation. The problem was with missing: !InMyArea("RASAAD") !InPartyAllowDead("RASAAD") in a block I've added to move the creature (original blocks that spawns new CRE file had this to prevent him from spawning to early). Didn't notice the problem myself since I've approached him from different direction when testing it and the proximity trigger is in sothern part of the map. Fixed for RC5.

there is: CopyGroundPilesTo("BD0120",[949.1686]) code in BDSODTRN.BCS that triggers SoD expansion. It moves what lays on the floor to that area, so it makes sense that his sword ends up in BD0120.ARE after transition. Is it possible to pick up item from the ground via script? If no than I think that "Put Sword of Chaos +2 in Sarevok's inventory" tweak can't be implemented properly (unless we add it to Charname inventory which is accessable by scripts). But it's usless anyway since we need to get it back a second later due to plot reasons. the same would happen in vanilla game if you install that tweak. It will be removed from EET_Tweaks.

this one will be greatly improved at some point to take into account DisplayStringWait action that is heavely used by Beamdog content (I will run each referenced WAV file with a tool that analyses the length of track and than add exactly as many SmallWait() ticks needed to not abort sounds triggered by this action). This is why the current tweak is not effective in SoD and other Beamdog's cutscenes. Although you can keep it installed for now since it will help with many vanilla BG2 cutscenes. as you can see this one doesn't work at all with patch 2.x GUI system. I've tried to port it into LUA but without success. needs updating with SoD added CRE files. Although no problem in keeping the current version usless considering the party is moved automatically to SoD after killing Sarevok. uninstall there were some changes in this implementation so not sure if this tweak still works. Did you try it? others from your list are probably ok.

I can check it out but where is the save that you've mentioned?

EET_Tweaks that currently hangs on GitHub is not fully compatible with EET 1.0 RC (I'm actually thinking about taking it down until update for that mod is ready). Those shaterring components uses entirely different system than the new implementation (made possible by patch 2.x), so it can cause problems if you installed it. I'd suggest uninstalling these components for now.

Iron Crisis has been removed from 1.0 releases for non-weapon items (it has been moved to unreleased new version of EET_Tweaks), so it's unliekly to be caused by EET. Maybe some other mod? The easiest way would be chcecking the item name in Near Infinity and than analyse that item. I will take a look if you send me that ITM file. mr2150, thanks for contribution. Both changes will be part of RC5.

Sounds like RNDTRES.2DA quirks, indeed. RC5 release (which is almost ready) shouldn't have this problem. thanks for report, will be fixed in next version. If it won't be fixed in the 2.4 patch than I will try to fix it locally.

fixed and fixed Thanks for both reports. I see that Roxanne already told you what to do in console and scripts (so no need to send your latest save) but you should still install the patch attached to this post because it will fix the same problems with other NPCs too. Before using it consider uninstalling patch attached to this post because new one fixes those problems too without disabling the feature for mods. hotFix.rar

that's expected, you need to wait for fix to make it work again. Send me latest save once you finish playing. When the fix is ready I will upload both save and hotfix. It will take few hours since I have work to do before I'm able to sit on it.

see post above yours

intersting, I've just tested it and unless I'm not mistaken it seems to work differently now compared to how it worked in patch 1.3. Now when you use MoveGlobal and start procedding additional actions at the same script block for some reason NPC Override script is able to kick in and run at least once before rest of the area script block proceeds. It's a major EET bug and regression compared to beta releases but easy to fix. A matter of changing: MoveGlobal("AR1000","Viconia",[1821.1081]) //some other actions ActionOverride("Viconia",ChangeAIScript("VICONIA",OVERRIDE)) to ActionOverride("Viconia",ChangeAIScript("VICONIA",OVERRIDE)) //NPC don't have to be in current area to make this work MoveGlobal("AR1000","Viconia",[1821.1081]) //some other actions Same happended for Dorn to you and will probably happen for other transition NPCs. I will write a hotfix for this problem later today and upload it here. Thanks for report. edit: don't play any further - your save needs to be cleaned for area spawn variables that already have been set for Viconia and Dorn.

thanks. Good that you've included the ARE script - I didn't even need to open your saves in NI. IF Global("RASAAD_SPAWN_STOP","GLOBAL",0) Global("RASAAD_1ST_SPAWN","BG4800",0) !Dead("RASAAD") // ~Rasaad~ !InPartyAllowDead("RASAAD") // ~Rasaad~ XPLT(Player1,1500) THEN RESPONSE #100 CreateCreature("RASAAD",[1100.782],SSE) // ~Rasaad~ ActionOverride("RASAAD",MakeGlobal()) ActionOverride("RASAAD",ChangeAIScript("RASAADX",DEFAULT)) SetGlobal("RASAAD_1ST_SPAWN","BG4800",1) END IF !Global("RASAADFIGHT","BG4800",1) Global("RASAAD_SPAWN_STOP","GLOBAL",0) Global("RASAAD_2ND_SPAWN","BG4800",0) !Dead("RASAAD") // ~Rasaad~ !InPartyAllowDead("RASAAD") // ~Rasaad~ XPGT(Player1,1499) XPLT(Player1,6050) THEN RESPONSE #100 ActionOverride("RASAAD",DestroySelf()) SmallWait(2) CreateCreature("RASAAD",[1100.782],SSE) // ~Rasaad~ ActionOverride("RASAAD",MakeGlobal()) ActionOverride("RASAAD",ChangeAIScript("RASAADX",DEFAULT)) SetGlobal("RasaadTalkedTo","BG4800",1) SetGlobal("RASAAD_2ND_SPAWN","BG4800",1) END IF !Global("RASAADFIGHT","BG4800",1) Global("RASAAD_SPAWN_STOP","GLOBAL",0) Global("RASAAD_3RD_SPAWN","BG4800",0) !Dead("RASAAD") // ~Rasaad~ !InPartyAllowDead("RASAAD") // ~Rasaad~ XPGT(Player1,6049) XPLT(Player1,27550) THEN RESPONSE #100 ActionOverride("RASAAD",DestroySelf()) SmallWait(2) CreateCreature("RASAAD",[1100.782],SSE) // ~Rasaad~ ActionOverride("RASAAD",MakeGlobal()) ActionOverride("RASAAD",ChangeAIScript("RASAADX",DEFAULT)) SetGlobal("RasaadTalkedTo","BG4800",1) SetGlobal("RASAAD_3RD_SPAWN","BG4800",1) END IF !Global("RASAADFIGHT","BG4800",1) Global("RASAAD_SPAWN_STOP","GLOBAL",0) Global("RASAAD_4TH_SPAWN","BG4800",0) !Dead("RASAAD") // ~Rasaad~ !InPartyAllowDead("RASAAD") // ~Rasaad~ XPGT(Player1,27549) THEN RESPONSE #100 ActionOverride("RASAAD",DestroySelf()) SmallWait(2) CreateCreature("RASAAD",[1100.782],SSE) // ~Rasaad~ ActionOverride("RASAAD",MakeGlobal()) ActionOverride("RASAAD",ChangeAIScript("RASAADX",DEFAULT)) SetGlobal("RasaadTalkedTo","BG4800",1) SetGlobal("RASAAD_4TH_SPAWN","BG4800",1) END It's the same problem as the one that caused bugs in vanilla BG:EE+SoD for Dorn and Neera but this time multiplied 4 times His cre file that is made GLOBAL at first spawn is respawned each time the party reaches higher XP (unless you got him into party which sets RASAAD_SPAWN_STOP to 1). And each time with another MakeGlobal() instead of MakeGlobalOverride() that would prevent GAM duplication. I get what they wanted to achieve here but all of this is usless in patch 2.x considering all vanilla NPCs now have Override script code that automatically adjusts the XP (looks like a leftover from earlier patches although someone from Beamdog already modified it after that considering all of these blocks reference one and the same CRE file which doesn't make sense). So yes, vanilla bug. This is another NPC that would also have problems with BeenInParty flags during SoD transition. (report mentioned in previous post). I will add fix for him to EET BG1 fixpack, thanks for report. edit: the reason why ActionOverride("RASAAD",DestroySelf()) doesn't work in this case is most likely caused by that first deleted Rasaad without area - the game runs DV actions on that GAM reference.

There are 2 vanilla bugs similar to this (duplicated GAM entries, 1 of them without map) caused by weird Beamdog code mentioned in my last post of this report: http://redmine.beamdog.com/issues/22244 When there is more than 1 GAM entry per NPC than the game confuses them when you reference NPC via DV. Both problems were fixed by EET fixpack, although there may be simillar problem for Rasaad. RC4 (and hotfix too unless I've made a mistake there) also fixed a problem with NPCLEVEL equivalent files referenced in CAMPAIGN.2DA that would respawn new CRE file based on 2da entry from different campaign if that NPC never joined the party. Although that problem simply replaced existing character rather than duplicating it. None of these explains your problem though. Please upload all your Chapter Start saves - I will try to discover at which point of the story duplication occured (or at least at which point that entry without area happended which may be responsible for further problems). Also your latest save if you have it before entering Nashkel. Thanks in advance.

This has nothing to do with the way SoD uses proximity triggers. In all EE and not EE games PIDs can be triggered by code like: ActionOverride("Viconia",StartDialogueNoSet(Player1)) from any script. And this shouldn't be the case if we are talking about "Player-Initiated Dialogues". use this code in command line to extract your dialogue file to d format: weidu.exe yourdialogue.dlg Now try to search for 'ObjectActionListEmpty(Myself)'. If I didn't make a mistake than the code should only change PID initial dialogues, nothing else. Dialogues with more triggers are skipped too. Your other IsGabber(Player1) instances should be unaltered by it. This fix will be included in RC5 finalise component to handle this automatically although I will limit the patching only to JOIN dialogue files mentioned in 2da files, so it will be impossible to patch a block that is not actually a PID.

that would explain it. Never played with PID (Player-Initiated Dialogues) installed, so never encountered it. There is also nothing like this in vanilla game. But it makes sense considering the only trigger check in PID dialogues in BG1NPC Project is: IsGabber(Player1) Same would happen in vanilla game if any mod installed after BG1NPC Project would append a new dialogue to VICONJ.DLG file because PID would be earlier and would trigger without our intention instead of that later dialogue. But there is a way to make PID dialogues compatible with mods installed later and EET that automatically merges join dialogue files. This additional trigger should do the job: ObjectActionListEmpty(Myself) Once it's there PID won't be initiated when dialogue is triggered by script for example via: ActionOverride("Viconia",StartDialogueNoSet(Player1)) And you will be still able to initiate dialogue manually with her, so nothing really is changed. Please install mod attached to this message and let me know if it fixes the problem. It should update every single PID dialogue in your game. fixPID.rar

Unless I am completely mistaken, this should be compatible with EET as it is. I installed it sucessfully. Sheena is not even compatible with BG2:EE: - it doesn't use HANDLE_CHARSETS but have French and Spanish language files encoded in ANSI - this means the mod will crush the game if you install those languages - it doesn't use ADD_JOURNAL (although not even weidu supports patch 2.x journal yet but still) - it overwrites mno1 animation instead of using EE new animation system, which means some creatures will use wrong animation (while BG2:EE probably doesn't use it in vanilla state, mno1 is used by SoD, so if you install it on EET some crusaders will have incorrect animation) As for the EET 'EET_modConverter' tool prints following changes needed to make it compatible: Patching Sheena/Dialogues/k#bsheen.D: GlobalLT("Chapter","GLOBAL",4) => GlobalLT("Chapter","GLOBAL",%bg2_chapter_4%) Patching Sheena/Dialogues/k#bsheen.D: GlobalLT("CHAPTER","GLOBAL",4) => GlobalLT("CHAPTER","GLOBAL",%bg2_chapter_4%) Patching Sheena/Dialogues/k#sheen.D: GlobalLT("CHAPTER","GLOBAL",4) => GlobalLT("CHAPTER","GLOBAL",%bg2_chapter_4%) Patching Sheena/Dialogues/K#sheenj.D: GlobalLT("CHAPTER","GLOBAL",4) => GlobalLT("CHAPTER","GLOBAL",%bg2_chapter_4%) Patching Sheena/Dialogues/K#sheenj.D: GlobalLT("CHAPTER","GLOBAL",4) => GlobalLT("CHAPTER","GLOBAL",%bg2_chapter_4%) Patching Sheena/Dialogues/K#sheenj.D: GlobalLT("CHAPTER","GLOBAL",4) => GlobalLT("CHAPTER","GLOBAL",%bg2_chapter_4%) Patching Sheena/Dialogues/K#sheenj.D: GlobalLT("CHAPTER","GLOBAL",4) => GlobalLT("CHAPTER","GLOBAL",%bg2_chapter_4%) Patching Sheena/Dialogues/K#sheenj.D: GlobalLT("CHAPTER","GLOBAL",4) => GlobalLT("CHAPTER","GLOBAL",%bg2_chapter_4%) Patching Sheena/Dialogues/K#sheenj.D: GlobalLT("CHAPTER","GLOBAL",4) => GlobalLT("CHAPTER","GLOBAL",%bg2_chapter_4%) Patching Sheena/Dialogues/K#sheenj.D: GlobalLT("CHAPTER","GLOBAL",4) => GlobalLT("CHAPTER","GLOBAL",%bg2_chapter_4%) Patching Sheena/Dialogues/K#sheenj.D: GlobalLT("CHAPTER","GLOBAL",4) => GlobalLT("CHAPTER","GLOBAL",%bg2_chapter_4%) Patching Sheena/Dialogues/K#sheenj.D: GlobalLT("CHAPTER","GLOBAL",4) => GlobalLT("CHAPTER","GLOBAL",%bg2_chapter_4%) Patching Sheena/Dialogues/K#sheenj.D: GlobalLT("CHAPTER","GLOBAL",4) => GlobalLT("CHAPTER","GLOBAL",%bg2_chapter_4%) Patching Sheena/Scripts/K#Sheena.baf: Global("CHAPTER","GLOBAL",6) => Global("CHAPTER","GLOBAL",%bg2_chapter_6%) Patching setup-Sheena.TP2: ALWAYS command expanded ALWAYS ACTION_IF (GAME_IS ~eet~) BEGIN OUTER_SET bg2_chapter = 12 END ELSE BEGIN OUTER_SET bg2_chapter = 0 END OUTER_FOR (i=1; i<=10; i=i+1) BEGIN OUTER_SET bg2_chapter = bg2_chapter + 1 OUTER_SPRINT name_source ~bg2_chapter_%i%~ OUTER_SET EVAL ~%name_source%~ = bg2_chapter END It would also need following changes to support EET continuity system (take a look at any of the available compatibility patches and you will see exactly the same steps for each BG2 NPC as below ones): 1. Add EVALUATE_BUFFER in tp2 file when COMPILE is used on k#bsheen.D, k#sheen.D, K#sheenj.D, K#Sheena.baf 2. Get rid of FATESP.DLG code when GAME_IS ~eet~ 3. Add EET_functions.tph to mod folder 4. Use EET_NPC_TRANSITION function from above mentioned file the same way as other BG2:EE NPC mods that have compatibility patches available. So no, it's not compatible as it is.

looks like the dialogue is initiated by Proximity Trigger attached to BD7300.ARE (Viconia Romance 1) using BDROM03.BCS. Can't reproduce it on my game. The expected conversation should start with: "Once again, our fates intertwine" but that's not what you see in your game, right? Post the first few words of the conversation she starts and I will be able to find which dialogue is triggered instead and why. If you don't want to wait you can continue your game by deleting BDROM03.BCS from Override but that won't be necessary if we find the problematic dialogue itself.

At this point only if author shows interest in adding EET 1.0+ compatibility natively. In such case I can create patches for all those above mentioned NPCs myself (if they already have BG2:EE version), ready to be internalized by authors. But the point is that the entire section "Mods that can be installed after EET on BG2:EE but MUST BE PATCHED FIRST" is meant to be temporary, not permanent solution. If there is no willingness to do so from authors than hosting unofficial patches may be actually against their will. It's also not practical considering patch becomes obsolete each time the mod is updated. Of course if the mod is not supported any more than creating and hosting compatibility patches for such mods is ok by me.

send me a save file, I will check what part of script initiates this dialogue. It may be vanilla bug though considering EET doesn't modify her script in any way that could cause it.

indeed, thanks!

http://gibberlings3.net/forums/index.php?showtopic=28161&page=5&do=findComment&comment=245621 should be fixed in RC4 already or for those who installed the patch distributed earlier with RC4. Is it not? I will check it out.

I already know where the problem lays. It's a chunk of code added by EET that automatically disables BG1 NPC after chapter > 7. It's used so you don't meet old NPCs without post BG1 content when going back to old areas. It will be fixed in next RC - thanks for report. Not yet sure how I will handle it but for now a fix that disables this system for mod added NPCS is attached to this post. Install it like any other mod (order doesn't matter). If you still have save before you started chapter 8 (so before you leave Baldur's Gate City for crusade) than Vynd will be available like in vanilla BG:EE+SoD. If you don't have it than you can kick that disabled NPC from your party and spawn new one via console: C:CreateCreature("GV#VYND") although keep in mind that he doesn't have SoD content and spawning new CRE will reset his local variables and progress. Alternatively I can fix your current save game if you don't have that older save and want to keep him for SoD. Upload it here. fixSoDTrans.rar

I can confirm this bug is caused by EET. No need to report it to author, it will be fixed here. Not yet sure what makes Vynd no able to be moved to that area.