Coran acting up

[berelinde]

In the Nashkel mines area, Coran seems to want to say something. He starts dialog that does PID after PID after PID after PID. The only thing I could do was drop him from the party.

 

Reporting it for the sake of completeness, since this might not be a BG1 NPC problem. Gavin was in the party, so it's always possible that could have been it, but they had no scheduled dialog.

[cmorgan]

any replication?

[berelinde]

Didn't get that far again yesterday. I had consoled him in before we should have legitimately had access to him, though, so I have no idea if that was causing a problem. Could be.

 

I'll try it again later.

[Domi]

It indicates that Coran has script asking him to initiate a dialogue from J-file, and no dialogue on dialogue file has a corresponding Global. Those are usually very difficult to track, and usually you need a saved game, to see which dialogue tries to trigger and finds no purchase.

[berelinde]

Rats. I will try it again later.

 

At least I can now breathe easier, though. I know it wasn't Gavin breaking Coran's dialog: it only calls on the banter file for Coran, and uses Interact() as opposed to StartDialogNoSet().

[Domi]

Hmm, I would suggest avoiding Interact() like a plague, to be honest, it tends to mess things up with the 'original' NPCs, if you don't luck out to get the WEIGHTs just right. Probably won't though in this case, because I moved everything scripted away from B files.

 

Also, if the error does not replicates, try a quick check on your order of install. The PIDs always have to be the last file, because they use True() condition. It could get messed up because of installs-reinstalls. Though in this case, I think, it will show the flirts not indefinetly, but following the sequence of scripts, just shows the wrong text over and over when timer expires.

[Domi]

I have a hunch that it could be Coran's native script that makes him quit the party if a wyvern is not slain in due time (his quest). I remember fixing it w-a-a-ay back, but it could be that your set of conditions does not correspon exactly, or something. At any rate, that would be the first suspect, seeing how it's a 'new' bug.

[berelinde]

Probably the wyvern script. He had been in the party for a while.

 

If Interact() is not terribly reliable, I can switch to StartDialogNoSet() and change the references easily enough. There are less than a dozen scripted banters, all told.

[pro5]

The wyvern script is supposed to be disabled by this TP2 block:

COPY_EXISTING ~_CORAN.BCS~ ~override~
 DECOMPILE_BCS_TO_BAF
 REPLACE_TEXTUALLY
~GlobalTimerExpired("Coran","GLOBAL") InParty(Myself) !Dead("wyvern")~
~GlobalTimerExpired("Coran","GLOBAL") InParty(Myself) !Dead("wyvern") Global("X#CoranWyvernDisable","GLOBAL",1)~
 COMPILE_BAF_TO_BCS
 BUT_ONLY_IF_IT_CHANGES

but I'm almost certain it doesn't replace anything, because WeiDU decompiles each condition in new line.

 

It should be changed to:

COPY_EXISTING ~_CORAN.BCS~ ~override~
 DECOMPILE_BCS_TO_BAF
 REPLACE_TEXTUALLY
~GlobalTimerExpired("Coran","GLOBAL")~ ~False()~
 COMPILE_BAF_TO_BCS
 BUT_ONLY_IF_IT_CHANGES

 

P.S. Also, I wouldn't really know, but don't all deathvars in Tutu start with lowercase letters? In that case, "Coran" above should be replaced with "coran". Or you could use CASE_INSENSITIVE predicate.

[cmorgan]

Do we replace this with another dialogue? I am trying to remember why we disable this, and if another dialogue uses the Disable global (or is this like X#JFIX where we disable by adding an impossible to achieve variable instead of just falsing it out -- and why don't we just false it out? Which reminds me, when we rebuild the BGT side with Pro5's materials, we eed to false the JFix materials out and deal with Kivan's timer, which is manually disabled on the BGT side until we rebuild it with a condition instead of a non-conditioned PID conflicting code). Sorry, full of questions today.

 

The dv's are supposedly case-insensitive, but I have been making all BG1 NPC Project materials standardize on "lowercasedv", to match decompiled WeiDU materials. Plus, it helps identify code I have somehow missed reviewing if I see the capital starting dv!

[berelinde]

Did I accidentally stumble on something useful? Cool.

[pro5]

The dv's are supposedly case-insensitive, but I have been making all BG1 NPC Project materials standardize on "lowercasedv", to match decompiled WeiDU materials. Plus, it helps identify code I have somehow missed reviewing if I see the capital starting dv!

The dv's are case insensitive, but REPLACE_TEXTUALLY by default isn't.

 

If WeiDU decompiles the script with "coran", then REPLACE_TEXTUALLY ~Coran~ ~Something~ won't change anything.

 

Do we replace this with another dialogue?

No, two new script blocks are added which do the same thing, just with stricter conditions (ensuring we don't break possible romance):

EXTEND_TOP ~_CORAN.bcs~ ~BG1NPC/Core/BAF/X#CORWYV.BAF~

 

By the way, both script blocks in X#CORWYV.BAF could use

GlobalLT("ENDOFBG1","GLOBAL",2)

for BGT compatibility, and the second one could use extra check that the first warning has actually happened:

Global("X#CoranWyvernWarning1","LOCALS",1)

[cmorgan]

The dv's are case insensitive, but REPLACE_TEXTUALLY by default isn't.

If WeiDU decompiles the script with "coran", then REPLACE_TEXTUALLY ~Coran~ ~Something~ won't change anything.

Wicked cool - good to know! I will double check the decompilation, and make sure either to include the CASE_INSENSITIVE or make sure the code has the same case as decompiled. I like learning new stuff!

 

By the way, both script blocks in X#CORWYV.BAF could use

GlobalLT("ENDOFBG1","GLOBAL",2)

for BGT compatibility, and the second one could use extra check that the first warning has actually happened:

Global("X#CoranWyvernWarning1","LOCALS",1)

Thanks - will put on the list tonight (or just do) the LOCALS. As for the EOBG, this may be a tp2 error - the BAF should have a BGT version in the BGT files; if not, this is my error on the conversion. Any Tutu D or BAF extension should have a corresponding BGT version with both area checks and dvs moved over to BGT, and most of all the

GlobalLT("ENDOFBG1","GLOBAL",2)

set up. I made a decision up front to keep things clear but mirrored; if we look at a file and see the EOBG variable up front, we know we are looking at BGT code. Silly, as it could be put on both sides, but helpful when putting Tutu vs BGT versions up against eachother and making sure both sides of the code get tweaked.

 

 

Edit: hey, just for the record, then, does BGT use "EndofBG1", "ENDOFBG1","endofbg1", or something else? I have been unsing "EndofBG1"

[pro5]

Edit: hey, just for the record, then, does BGT use "EndofBG1", "ENDOFBG1","endofbg1", or something else? I have been unsing "EndofBG1"

BGT uses GlobalLT("ENDOFBG1","GLOBAL",2) as in above example, though it shouldn't matter. Good luck if you're going to change that everywhere, I didn't bother.

[cmorgan]

Well, since I was the idiot who volunteered to put all of it in in the first place, I probably should do it the way the target vehicle is coded, instead of my fancy iNterPretaTioN pulled from my head Serves me right for not doing the research beforehand.