10 replies to this topic

[Kulyok]

Thank you for the report. It was quite a while ago, and I don't remember what it may have been(though I have a suspicion that I had a script inside the white doe .cre file and extra patching in .tp2 introduced a bug, but never mind). In any case, to fix this, you need to add this to /phase2/baf/x#xqxan.baf:

/* Initiate */
IF %BGT_VAR%
Global("X#XQWhiteDoeAppeared","GLOBAL",2)
InParty(Myself)
!StateCheck(Myself,CD_STATE_NOTVALID)
InMyArea(Player1)
!StateCheck(Player1,CD_STATE_NOTVALID)
CombatCounter(0)
!See([ENEMY])
THEN
RESPONSE #100
StartDialogueNoSet(Player1)
END

Again, thank you for the report. I believe that editing mods via a third party mod, or unauthorized crossmod content is a bad idea that might lead to bugs or other unfortunate consequences. Reporting on the mod's forum, on the other hand, is great.

[berelinde]

On the other hand, there are times where a modder patch fixes an issue one way and the BWP fixpack fixes the same issue a different way, and at that creates bigger problems. Because players invariably use both fixes and then grumble when they have to spend 36 hours rebuilding their installations.

Some mods are no longer maintained, but all G3 mods are. If the author is unable to make the fixes personally due to RL obligations, leaving the communty, or what have you, the designated maintainer will do it. IF folks report the problem rather than just posting in the BWP fixpack thread. Nobody has time to read every post there on the off-chance one of the mods they maintain might be mentioned.

[berelinde]

i30817, on Oct 20 2011, 08:29 AM, said:

berelinde, on Oct 20 2011, 04:19 AM, said:

On the other hand, there are times where a modder patch fixes an issue one way and the BWP fixpack fixes the same issue a different way, and at that creates bigger problems. Because players invariably use both fixes and then grumble when they have to spend 36 hours rebuilding their installations.

Sure. This is why the BWP fixpack should be pruned on each release, checking new mod patches against the mod changelog to see if they are still needed.

It's a two way street.

The problem is that the BWP doesn't even track the current version of the mods, let alone the patch status. I have lost track of the number of "Hideous bugs!" posts I've seen where the WeiDU logs list outdated versions of the mod.

Edit: Anyway, this is derailing the topic. As penance for allowing myself to get distracted with a favorite rant, I will link this thread in the workroom "to do" list.

Edited by berelinde, 20 October 2011 - 06:25 AM.

[cmorgan]

i30817, thanks for reporting it over here - I won't wait for v20, as that is tied to the French translation (almost done, but still in proofreading). I'll "silently" update this in the v19 and upload the changes this weekend, so that when the site update happens it is in place.

As for preserving in the engine, I think there actually is a way of doing that within a cutscene. That suggestion I can table for v20, pending further research.

Edited by cmorgan, 25 November 2011 - 08:49 AM.

[cmorgan]

Kulyok is right, something is messing with your game, probably via script patching in another mod in your Mega-install.

A vanilla install of BG1NPC on EasyTutu or BGT creates x#wdoe.cre, using script X#WDOE, DV X#WDOE, and diloag file X#WDOE. Confirmed on both installs that everything works as planned - creature created, and scripts correctly assigned.

The script has

IF
	See("xan")
	Global("X#XQWDoeApproaches","GLOBAL",0)
THEN
	RESPONSE #100
		SetGlobal("X#XQWDoeApproaches","GLOBAL",1)
		MoveToObject("xan")
		ActionOverride("xan",StartDialogueNoSet("xan"))
END

It looks like something in your install is messing with the X#WDOE.BCS. Can you confirm this, please? I have seen some reports that indicate that using neutral .cres running scripts might be flaky under certain conditions, like ToBEX, but I can't pin them down.


I am logging this as "hold off for confirmation and replication", as the current code is tested and stable - if it turns out we absolutely need to change this in order for it to work in a BWP install, we can switch to the new detection through (unless Kulyok returns and says "dump the old .bcs and move the behavior to Xan's script regardless.")

From the original post:

Quote

Xan bg1npc quest with the slavers can apparently get hosed by a dialog bark (one of the random ones) that xan emits between talking to the slavers and the doe appearing. The doe no longer initiates "dialog" to xan (though she still points to him).

Edited by cmorgan, 25 November 2011 - 09:04 AM.

[Kulyok]

I think that, yes, it's better to delete ActionOverride("xan",StartDialogueNoSet("xan")) from the white doe's script and edit Xan's script instead. I believe that ActionOverride indeed might've been interrupted, and StartDialogueNoSet works better in such situations for the next update. I might even browse my other mods to check if I overuse ActionOverride's there - it's no good to "lose" a banter if it can be avoided.

[cmorgan]

Got it - I will remove the script X#WDOE from the package (there is no other block in that script), and add in

/phase2/baf/x#xqxan.baf:

/* Initiate */
IF %BGT_VAR%
   Global("X#XQWhiteDoeAppeared","GLOBAL",2)
   InParty(Myself)
   !StateCheck(Myself,CD_STATE_NOTVALID)
   InMyArea(Player1)
   !StateCheck(Player1,CD_STATE_NOTVALID)
   CombatCounter(0)
   !See([ENEMY])
THEN
   RESPONSE #100
		 StartDialogueNoSet(Player1)
END

The repair should be reflected on GitHub and in v20 docs as of tomorrow morning (packaging and uploading tomorrow).

Edited by cmorgan, 26 November 2011 - 07:12 PM.