BG issues in scripts

[morpheus562]

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.

[jastey]

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

 

[Guest Graion@Work]

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.

[jastey]

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.

[jastey]

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?

[marchitek]

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

[jastey]

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.

[Guest Graion@Work]

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.

[jastey]

Yes, thanks!

[CamDawg]

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.

[jastey]

Cool! And thanks.

[CamDawg]

Fixed.

[The_Baffled_King]

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".

[jastey]

Ah, that also makes sense.