Version 5 Bug Reports

[CamDawg]

Quick update... some of these are untested since a buddy has borrowed my ToB disc (should have it back tomorrow to confirm these fixes):

 

• Generated all m***.2da files for the imported IWD animations from sounds.ini. Should fix the yeti soundset and unmute/correct sounds for other imported animations. This was something I avoided since v1, and it was every bit as tedious as I feared.
  
• Wylfdene now has the fancy Icasaracht fleeing animation upon death.
  
• Three Doves appears to be working and is now available
  
• Summoners in the jackal caves stay put
  
• All area transitions now flagged as impassable by NPCs to restore IWD behavior as well as avoid script blowups
  
• About 30 area animations now properly layered and no longer covering PCs and NPCs
  
• Weapon descriptions now properly reflect proficiencies
  
• Added bigg's weapon proficiency tweak as a separate component to allow players six different weapon proficiency systems: BG2 (default), BG2 rebalanced (from Tweaks), BG w/ weapon styles, BG w/o weapon styles, IWD w/ weapon styles, IWD w/o weapon styles
  
• Fixed rogue doors in Lonelywood and Whistling Gallows
  

 

I also have a beta version of Item Upgrade for anyone feeling adventurous.

 

Next up is grogerson's latest TotL bug reports.

[CamDawg]

@ CamDawg: Sorry for the delay. I checked my savegame for the Fallen Temple and ALL_KEYS=6 is set, yet the stairs remain closed.

Humor me with one last test--the door is flagged as secret; could you stand around with a thief and try to detect it?

 

If it's not that then I'll just move the door & transition activation to the area script and be done with it.

[grogerson]

Humor me with one last test--the door is flagged as secret; could you stand around with a thief and try to detect it?

Tomorrow. I'm getting ready to hit the sack now, but one more update.

 

My party (second install) finished the Temple of the Forgotten God. The only thing I noticed was that verbeegs move too fast, and when they fall I have a dead leopard in front of me.

 

These animation glitches are becoming frustrating. I'm wondering if, when I install the game, those "failed to convert" messages are what I'm seeing. Unfortunately I see nothing in the debug file.

[DavidW]

These animation glitches are becoming frustrating. I'm wondering if, when I install the game, those "failed to convert" messages are what I'm seeing.

 

Tell me about these messages.

 

Unfortunately I see nothing in the debug file.

 

You wouldn't. The animation-conversion routine in setup-iwd_in_bg2 is a shell, it calls lots of other weidu routines via external calls.

[Jarno Mikkola]

These animation glitches are becoming frustrating. I'm wondering if, when I install the game, those "failed to convert" messages are what I'm seeing. Unfortunately I see nothing in the debug file.

There could be issues that have not as much to do with the IwDinBGII, but with your original games you use to make it.

As for me, the Verbeegs were Verbeegs even after they were dead.

So, you did a clean install of the BGII & IwD before you used them to make the conversion. And should you know, the Clean install means in these games an install totally without any mods, just the add-on_pack & latest patch and that it. The add-ons are of course the ToB & HoW. So no (G3)BGII fixpacks or any other 'fix packs', also the 'Data' -folder in the Icewind Dale game should have exactly 145 files, while the 'data' -folder in the BGII game should have exactly 68 files.

 

And when you make that clean install, you have to make sure that there is no related files on the install folder... because the games uninstallation doesn't remove the 'override' -folder that can effect a lot of those things if not removed.

[CamDawg]

TotTL spawns

Nail down what the CheckPartyAverageLevel trigger actually checks (used in the TotL castle interior spawns).

Alright, the diffmode in this trigger is a complete red herring. The second parameter is actually to make this a GT/LT trigger.

 

CheckPartyAverageLevel(5,1) will return true if the average party level is exactly five.

 

CheckPartyAverageLevel(5,2) will return true if the party level is less than five.

 

CheckPartyAverageLevel(5,3) will return true if the party level is greater than five.

 

So the "CheckPartyAVerageLevel(14,2)" trigger in efxdell.bcs should be converted as LevelPartyLT(14). The CheckPartyAVerageLevel(16,3) check in efxkeeph.bcs should be converted as LevelPartyGT(16). (You may see EASY and NORMAL in those triggers in NearInfinity, as it will look to diffmode.ids if present.)

[CamDawg]

...and this affects Difficulty() triggers as well, so we're mapping those incorrectly to boot. New mappings should be

 

Difficulty(foo,1) -> Difficulty(foo)

Difficulty(foo,2) -> DifficultyLT(foo)

Difficulty(foo,3) -> DifficultyGT(foo)

 

CheckPartyAverageLevel(foo,1) -> LevelParty(foo)

CheckPartyAverageLevel(foo,2) -> LevelPartyLT(foo)

CheckPartyAverageLevel(foo,3) -> LevelPartyGT(foo)

[DavidW]

I take it these are all best fixed in the core installer?

[CamDawg]

I take it these are all best fixed in the core installer?

Yeah, but it shouldn't be too hard to have a fix in the mean time. They are, I believe, introduced by HoW and only used in the expansion areas--I saw maybe 10-15 difficulty triggers in the whole game.

[grogerson]

Humor me with one last test--the door is flagged as secret; could you stand around with a thief and try to detect it?

 

If it's not that then I'll just move the door & transition activation to the area script and be done with it.

Halfling thief with 100 in both detect and remove could not find the door. I even redid Lower Dorn's to check it. Are there any other variables that trigger the door other than ALL_KEYS?

[CamDawg]

Humor me with one last test--the door is flagged as secret; could you stand around with a thief and try to detect it?

 

If it's not that then I'll just move the door & transition activation to the area script and be done with it.

Halfling thief with 100 in both detect and remove could not find the door. I even redid Lower Dorn's to check it. Are there any other variables that trigger the door other than ALL_KEYS?

No, ALL_KEYS = 6 is the only trigger; the door has a script to open itself. I think I'm just going to move the whole sequence to the area script and be done with it.

[CamDawg]

Humor me with one last test--the door is flagged as secret; could you stand around with a thief and try to detect it?

 

If it's not that then I'll just move the door & transition activation to the area script and be done with it.

Halfling thief with 100 in both detect and remove could not find the door. I even redid Lower Dorn's to check it. Are there any other variables that trigger the door other than ALL_KEYS?

No, ALL_KEYS = 6 is the only trigger; the door has a script to open itself. I think I'm just going to move the whole sequence to the area script and be done with it.

Eureka! I see the problem now, and I understand why it wasn't turning up in testing. A handful of scripts have an always-true block to cut off the remainder of their script after a certain event has happened. This is the script for the stairway to open in ar8012:

 

IF
Global("I#_void_script","GLOBAL",1)
THEN
RESPONSE #100
	NoAction()
END

IF
Global("ALL_KEYS","GLOBAL",6)
THEN
RESPONSE #100
	OpenDoor(Myself)
	TriggerActivation("To8013",TRUE)
	SetGlobal("I#_void_script","GLOBAL",1)
END

The idea's pretty simple--once the party has all the keys it sets the I#_void_script variable. Once set the first block always returns true, blocking the second block from ever firing again. I should have noticed the problem much sooner--i#_void_script is 1) global in scope and 2) used by other scripts. So the first time you encounter a script that voids itself, it also voids all scripts with a similar setup. Notably, the first such place is in level four of Dragon's Eye--since my test party never got there and had this variable set my test showed everything worked dandy. This same variable also cuts off the Announcer in the initial Wylfdene encounter, which is also why I couldn't replicate the bug in my testing.

 

I've identified the seven scripts where this happens, and changed the variable to be unique in each case (can't change scope, since these are generally area or trap scripts). If you manually set i#void_script back to 0, I'm sure the staircase will work.

[CamDawg]

• Generated all m***.2da files for the imported IWD animations from sounds.ini. Should fix the yeti soundset and unmute/correct sounds for other imported animations. This was something I avoided since v1, and it was every bit as tedious as I feared.
  
• Wylfdene now has the fancy Icasaracht fleeing animation upon death.
  
• Three Doves appears to be working and is now available
  
• Summoners in the jackal caves stay put
  
• All area transitions now flagged as impassable by NPCs to restore IWD behavior as well as avoid script blowups
  
• About 30 area animations now properly layered and no longer covering PCs and NPCs
  
• Weapon descriptions now properly reflect proficiencies
  
• Added bigg's weapon proficiency tweak as a separate component to allow players six different weapon proficiency systems: BG2 (default), BG2 rebalanced (from Tweaks), BG w/ weapon styles, BG w/o weapon styles, IWD w/ weapon styles, IWD w/o weapon styles
  
• Fixed rogue doors in Lonelywood and Whistling Gallows
  

Jackal summoners continue to piss me off. Rest of the fixes are confirmed as working, with a huge caveat for Three White Doves: replicating the weapon is pretty straightforward, the problem is that the only way to kill a target based on hit dice is to use the slay opcode... to which virtually all undead are immune. So, we either have a severely nerfed Doves or remove an immunity from undead, neither of which is an optimal solution (the former more palatable than the latter, at least).

 

Difficulty and CheckPartyAverageLevel have been re-mapped. The issue with ar8012 and opening the staircase (six keys, evil idol, post right above this, etc. ) has also been resolved.

[DavidW]

Eureka! I see the problem now, and I understand why it wasn't turning up in testing. A handful of scripts have an always-true block to cut off the remainder of their script after a certain event has happened.

 

This is an idiot mistake on my party, sorry.

 

That "I#_void_script" block is part of the unholy tangle of methods I used to handle the ChangeCurrentScript command. (cf line 3367 et seq in setup-iwd_in_bg2.tp2). IIRC, areas can't use the BG2 version of ChangeCurrentScript. Using a global rather than a local variable is obviously stupid, I can only assume I was half asleep or something.

 

I think this happens in seven places: ~ar9201~ ~d4doorg~ ~d4doort~ ~d4geldor~

~d5door~ ~d5yxudor~ ~ldbdgopn~.

[CamDawg]

Good, I've got all seven then. I think they have to be global in scope (areas can't have locals, and myarea is out as well since some of these are in the same area) so I've simple done a simple replace with I#_void_script_%SOURCE_RES% to make each variable unique.