Guest morpheus562 Posted April 12, 2022 Share Posted April 12, 2022 1 minute ago, jastey said: That could be a remnant since she automatically joins the group at the beginning. In my last many playthroughs, I quickly head south before talking with her and proceed to gain 12k exp before picking her up in Chapter 2. I suspect I could clear the mines and proceed to Chapter 3 and she would still be there. Curiosity only, not suggesting anything gets changed. I wonder under what condition it is meant to remove Imoen and how it is supposed to trigger. Quote Link to comment
jastey Posted April 12, 2022 Author Share Posted April 12, 2022 First I thought this script block is completely useless, but I think it removes Imoen's body in case she was killed in this area. That's the only sense I can read into this. EDIT: It still only works if the player manages to prevent her from joining. IF Dead("Imoen") // Imoen Exists("Imoen") // Imoen !InParty("Imoen") // Imoen !BeenInParty("Imoen") // Imoen THEN RESPONSE #100 ActionOverride("Imoen",DestroySelf()) Continue() END Quote Link to comment
Guest Graion@Work Posted April 12, 2022 Share Posted April 12, 2022 I meant that there are a lot of mods which needs to check against this particular Xzar block and patch it just for their code to work and this looks silly enough to me that if this gets fixed in a followup patch, leaving this compat code could be another source of an easy-to-overlook bug. I suspect that this might be a regression from Beamdog's ToB-styled NPC recoding, because the mods affecting the area have classic compatibility and I don't remember them including workarounds for this, which is another reason for me to treat it as a bug (but I intend to check this at home). I am not really a fan of mods trying to constantly fix the basegame, because this can lead to situations like BG1NPC, where half the mod is basically just various fixes set up just for mod code prerequisite. Quote Link to comment
jastey Posted April 12, 2022 Author Share Posted April 12, 2022 5 minutes ago, Guest Graion@Work said: the mods affecting the area have classic compatibility and I don't remember them including workarounds for this Yes, in BGT this loop is really, really rare. I think it could happen, though. I didn't check Tutu. But I had a look at BG:TotSC as well and the BG:EE code is more like it was there, so it's not necessarily something BG:EE introduced, it just shows because it gets modded more. 6 minutes ago, Guest Graion@Work said: I meant that there are a lot of mods which needs to check against this particular Xzar block and patch it just for their code to work and this looks silly enough to me that if this gets fixed in a followup patch, leaving this compat code could be another source of an easy-to-overlook bug. So you are against including this in the EEFP? 7 minutes ago, Guest Graion@Work said: which is another reason for me to treat it as a bug So you are for including it? I don't understand what your opinion is. Quote Link to comment
jastey Posted April 12, 2022 Author Share Posted April 12, 2022 I checked BG1NPC: this is not considered yet. This means BG1NPC bugs out with regard to Gorion's burial and Dyna's romance quest in case people do not take Xzar into the group at all. Was this script changed in BG:EE recently, or do a lot of people take Xzar (and Montaron) in the party, or is noone really playing mods? Quote Link to comment
marchitek Posted April 12, 2022 Share Posted April 12, 2022 (edited) IMHO This is exactly kind of fix that should be provided by EEFP. Probably it wan't make to official patch since it not cause any bug in unmodded game but at the same time its clearly original script flaw. Unless this is part of modding best practice to avoid EXTEND_BOTTOM and always EXTEND_TOP + Continue(). Edited April 12, 2022 by marchitek Quote Link to comment
jastey Posted April 12, 2022 Author Share Posted April 12, 2022 4 minutes ago, marchitek said: Unless this is part of modding best practice to avoid EXTEND_BOTTOM and always EXTEND_TOP + Continue(). I have a gut feeling that if every mod would do that it could lead to other problems. It would mean all mod added script blocks would be executed in one go in case there is several that would give true at some point which just feels like it could lead to hickups. But I know at least one modder who switched to doing exactly that because of looping scripts added to area scipts by other mods... EDIT because once you hunted such a bug down to be the reason your mod didn't work you really do not want to experience that again. Quote Link to comment
Guest Graion@Work Posted April 12, 2022 Share Posted April 12, 2022 My opinion is for fix inclusion in FP. My point was that mods should really just assume that the base games are alright and shouldn't try to patchwork basegame issues outside of their scope. Really not fond of looking at things like this (or the wyvern cave area file not having it's BCS script value initialized in the games). I managed to typo that variable in a release when I wanted to init it, and that could even break SotSC, depending on install order (although it wasn't reported I believe, or maybe only in Discord). Not fond of these fixes scattered/duplicated in multiple mods instead of being centrailzed into one common mod/official patch. Hope I'm enough clear this time. Quote Link to comment
CamDawg Posted April 12, 2022 Share Posted April 12, 2022 This is EEFP material, full stop. We fix bugs like this in BG2FP already--the last block in the Spellhold exterior area script gets caught in a loop opening the door. A similar issue existed with Narlen Darkwalk's spawn in the city of Baldur's Gate. Every mod that wanted to do something in the NE section of the city had to fix his scripting and, as a result, you had a lot of mods interacting poorly. Quote Link to comment
jastey Posted April 12, 2022 Author Share Posted April 12, 2022 Cool! And thanks. Quote Link to comment
The_Baffled_King Posted April 28, 2022 Share Posted April 28, 2022 On 4/12/2022 at 7:10 AM, jastey said: First I thought this script block is completely useless, but I think it removes Imoen's body in case she was killed in this area. That's the only sense I can read into this. EDIT: It still only works if the player manages to prevent her from joining. IF Dead("Imoen") // Imoen Exists("Imoen") // Imoen !InParty("Imoen") // Imoen !BeenInParty("Imoen") // Imoen THEN RESPONSE #100 ActionOverride("Imoen",DestroySelf()) Continue() END I thought this was intended to get rid of party NPC Imoen (IMOEN1.CRE) who appears via the GAM file when non-party NPC Imoen (IMOEN.CRE) was killed in Candlekeep? Both versions share the script name "Imoen". Quote Link to comment
jastey Posted April 28, 2022 Author Share Posted April 28, 2022 Ah, that also makes sense. Quote Link to comment
Recommended Posts
Join the conversation
You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.