Imoen's diamond line oddity

[Guest lauzi]

Well, I recently purshased BG1 + BG2 and their respective expansions. I installed BG1 + TotSC, patched it, installed BG2 + ToB, patched it. After that, I installed baldurdash fixes, as well as easyTuTu. Then, I installed the NPC Project mod.

 

I started a game of BG1, and when I went to gorion's body, Imoen responded just fine with the burying dialog. However, I picked up the diamond, and nothing happened. The line triggered when I got to friendly arm inn, after I killed the assassin. The exact time the line triggered is when I started looting it. What's up with that? Is my NPC Project installation messed up, or was it a one time error?

[Guest Guest]

Ok, I have another question. I tried talking to Imoen on my saved game (I saved immediately after I encountered the bug), and she said something about tarnesh' spellbook, instead of having the player-initiated barter. What is supposed to trigger that? Is that what she says when I kill the assassin, usually?

[Guest Guest]

Sorry to triple post, but I just read on the forums that the tarnesh banter is supposed to happen immediately after killing the assassin (I didn't know he was named tarnesh, I thought a random banter had triggered, because she talked about his spellbook before I even got the chance to loot the corpse). I guess what happened is "banter caching", something must've prevented the diamond line to trigger so it got cached for the next opportunity. I'll keep initiating interactions with the NPC's now to prevent this.

[Miloch]

You don't want to use Baldurdash with EasyTutu - see the installation order post for more info. Though I don't know if it would cause this problem - it sounds familiar from the previous version. You have the latest BG1 NPC (v12b3) installed, right? You don't have any other mods, just that one?

[berelinde]

If you are using EasyTutu, it incorporates Baldurdash fixes, so no further action is required. But the process of converting to Tutu renames everything that I can think of, so I don't know if it's actually going to hurt anything.

 

Because I'm constantly reinstalling mods as a result of frequent revisions in a mod I'm writing, I tend to reinstall Tutu a lot, too. All I do when I install Easy Tutu is show the installer where my BG1 installation is, where my patched BG2 SoA/ToB installation is, and let it do its thing. I use TutuFix v 17 because I like some of the tweaks, and then I proceed to install just about every mod compatible with Tutu.

 

It seems like Imoen is always one dialog behind.

 

Her diamond interjection hung, but the conditions for it were set, so the next time a call was made for an interjection (finding Tarnesh's spellbook), the diamond interjection fired. Initiating PID made another call to her interjection file (because that's where PID is stored). The way PID works is that it is placed at the absolute end of the file. If the conditions for anything else before it are true, that something else will fire instead of PID. Imoen's friendtalks are also stored in that file, so if a friendtalk hung, you might be able to start it by initiating PID.

 

Your plan will probably work. I haven't had it happen in a while, but one time, I had about 6 interjections stacked, all because one failed to fire. For me, they all fired at once, one right after the other. It was amusing.

 

@Miloch: I don't know if this problem is ever going to be completely solved. If the player does something like moving out of an area before the interjection fires or whatever, the interjection may hang. As PID clears the backup, it falls under the heading of harmless annoyance.

[Kulyok]

Might be a stupid question, but why do you need to reinstall (Easy)TUTU? Keeping a copy of override and dialog.tlk works for me.

[berelinde]

For some reason, it seems to take just as long to copy over those two files as it does to install the whole thing. Don't know why this would be, but it's been working out that way for month or so. Before that, I was just copying them over. But I've been seeing some general performance issues lately that I'm 99.99% sure are hardware related. So, I make frequent backups. It's the best I can do until I get around to replacing the HD, which is slated for mid-January.

[Miloch]

Oddity in Imoen's dialogue keeps coming up in different contexts. I don't know if it's even something introduced by BG1NPC since her dialog is corrupted in unmodded Tutu (but not BG1) - apparently bits of the file overlap and the offsets are off. And it's even more suspicious she's the *only* joinable NPC in Tutu this happens to. I've raised this sort of thing several times but it's fallen on blind eyes (particularly on PPG). I'm not a dialog expert but I'd be interested in knowing why it's not a problem.

Regarding Imoen dialogue... I'm sure others have noticed this, and it's probably nothing, but if you do a file corruption check in NI, you get some offset errors in _IMOEN.DLG. This is on a completely clean, unmodded EasyTutu install. You get the same thing in a few other .DLGs but none that affect BG1 NPC that I'm aware of. And a DLG check in DLTCEP has similar errors in _IMOEN.DLG and IMOEN2.DLG - something about titleless journal strings and transitions having action indexes but no flags. This comes up quite a bit so like I said, it's probably nothing (but if so it'd be good to filter out of the checks somehow...).

File: _IMOEN.DLG Offset: 3c0h Error message: Text(3c0h) overlaps Text(3c0h) by 42 bytes
File: _IMOEN.DLG Offset: 3c0h Error message: 42 unused bytes between Text(3c0h) and Text(3eah)
File: _IMOEN.DLG Offset: 3eah Error message: Text(3eah) overlaps Text(3eah) by 42 bytes
File: _IMOEN.DLG Offset: 3eah Error message: 42 unused bytes between Text(3eah) and Text(414h)
File: _IMOEN.DLG Offset: 414h Error message: Text(414h) overlaps Text(414h) by 43 bytes
File: _IMOEN.DLG Offset: 414h Error message: 43 unused bytes between Text(414h) and Text(43fh)

[berelinde]

Probably because the dialog file that is supposed to be corrupted is her pre-joining dialog. She uses the dialog file _IMOEN right up until she joins the party. Once she joins the party, she uses her joined dialog file, oftentimes referred to as her J file, but Tutu uses _IMOEN2 to name it. Her banters are pulled from her banter file, also called her B file, _BIMOEN. If you kick her out of the party, she uses her post(joined) file, or her P file, _IMOENP.

 

The problems people are reporting seem confined to her J file and possible her B file. If you were saying that _IMOEN2 and _BIMOEN were showing signs of corruption in an unmodified game, I am sure people would get more excited about it.

[Domi]

It seems like Imoen is always one dialog behind.

 

When that happens, the easiest way to go, is to initiate PIDs with her untill you clear her "cache". Basically what happened is that Global did get set, but Imoen did not have a chance to start a dialogue. The way I cope with that problem in IWD2NPC is by 'colsing' the Global once the character leaves the area where a scripted interjection was to occur.

[cmorgan]

The way I cope with that problem in IWD2NPC is by 'closing' the Global once the character leaves the area where a scripted interjection was to occur.

I would love to do that here, too; this would work for the one-time non-sequential things, anyways, especially all of the banters that we moved to J file. Basically, after every instance, a block that fires once the NPC leaves the area. If a person moves on too quickly, they would fire off a bug report, but at least we would reduce the chances of this cache buildup. Some materials, especially timered materials, could benefit from this.

 

So, in

IF
InParty(Myself)
CombatCounter(0)
!See([ENEMY])
AreaCheck("FW2700")
Global("X#IMDiamond","GLOBAL",0)
PartyHasItem("_MISC42")
THEN
RESPONSE #100
PlaySong(0)
PlaySound("imoen99")
SetGlobal("X#IMDiamond","GLOBAL",1)
StartDialogNoSet(Player1)
END

/* Cache Buildup Prevention */
IF 
Global("X#IMDiamond","GLOBAL",1)
!AreaCheck("FW2700")
THEN RESPONSE #100
SetGlobal("X#IMDiamond","GLOBAL",2)
END

 

The hard part is identifying which materials use just that one global, and which one starts a set of linked dialogues; if there was followup, where Global("X#IMDiamond","GLOBAL",2) sparks the next, etc. Obviously, friendship talks etc. cannot be fixed this way!

[Domi]

Yep, that's exactly what I do with the scripted interjections. Friedship talks can have the timer set the moment the global is set, and if after say 3 minutes or so the globals did not shut down, reset it to 0, reset the main timer.

 

But meanwhile I'd recommend to clean cache once in a while.

[berelinde]

I've been handling this by not including area checks for found items unless *absolutely* necessary. For my purposes, I don't care if Gavin remarks on finding a bounty notice on Nimbul in Nashkel or if he remarks on it once the party has already gone into the Inn. But the area check is necessary for Imoen, or else she'd give her speech the first time the party found any diamond, whether it was the one in the tree or not. This does seem to be a factor when interjections are supposed to happen close to transition areas: edges of maps, and in doorways.

 

The diamond is right on the edge of the map. Tarnesh is right on the stairs of the FAI. Rather inconvenient.

[cmorgan]

I am not officially putting this on the workllog yet, but I have added this particular block to Imoen and will take some time to think this through before tackling the job of parsing out where and when these babies go most appropriately. I am assuming that the "failed close" block should be put at the top of the BAF extension, so it is evaluated before the engine has a chance to trigger the skipped dialogue.

 

Is there a way to "deincrement" a variable? Perhaps

IncrementGlobal("myglobal","GLOBAL",-1)

? Otherwise, there couldd be huge numbers of blocks added by friendship talk rechecks...

[Domi]

IncrementGlobal("myglobal","GLOBAL",-1)

 

Yep, this is valid. I use it all the time in my "Interest" tracking globals