[Repaired v20] Xan quest slight bug

[Guest i30817]

Here:

http://www.shsforums.net/topic/42220-fixes...post__p__525133

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

[Guest i30817]

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.

 

Since i like living on the bleeding edge in software (and the collection of mods is so huge), there is no way to get a stable install. Since i don't like bugs either, i report on both places.

 

The patching BGT does (via diff i think), should minimize the errors that might happen due to misplaced version=/=patch (better yet would be to refuse to apply the patch - even if it applies with fuzz) if the mod version is not the expected one.

 

By reporting on both places i hope to help the authors and eat my pie at the same time (before new version patch bugs).

 

 

Besides, there are mods that are abandoned, but have fixes still.

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

[Guest i30817]

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.

[Guest i30817]

If i could make a suggestion for the subsequent battle (excellent btw - only been able to win it with luck, color spray, spook, and charm person) - if it is possible in the engine, could you preserve the party formation? They could start the battle/conversation just as near the guards (to be just as intense), but after dying once i placed my spellcasters on the front of the T formation to cast a wall of color spray to deal with those annoying archers, and couldn't because the party starts the scene in a as if a zig-zag line regardless.

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

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.

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

[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:

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

[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).