Appends Options

[Sir_Carnifex]

I have been testing banters in the game by using CTRL + I to force the NPCs to talk. Every banter that my character begins works fine, but anything that starts with APPENDing another banter file does not.

The question here is, will APPENDS fail to activate using CTRL + I? If so, I guess I just need to let the game run for a bit. If not, I need to do some more research.

[jastey]

While typing the general remarks below, I understood what you were actually asking.. So you say that all banters you appended to bioWare NPC banter files do not fire? Did you check the correct spelling of the banter files (this question is not as stupid as it seems, although the WEiDU installer should complain if they are wrong, but sometimes several exist and only one is the right one, e.g. for Imoen)? Sometimes with using Cntr.+I you have to be patient and hit the keys several times for a banter to show up. If nothing helps, would you consider posting one of your appended banters that doesn't work?

Here some general blurb about banter files, I'll leave it standing although I guess you might know this already:

Cntr.+I only activates the banter in the B.dlg. That is why there go all unscriptd banters (i.e. the ones that are not called by a script using a specific variable).

For scripted dialogues, I recommend using the J.dlg. Scriptd banters are for a specific situation only (after a timer is run, if the party enters a specific area, after finishing a quest), so they are triggered by variables via the script file, and thus they cannot be called by Ctrl.+I.

Even if you'd put the scripted dialogues into the B.dlg (which would, in principle, work, but be cautious to use the right weighting), you wouldn't be able to call them via Ctrl.+I, since they need the trigger variables to be set.

This post has been edited by jastey: May 26 2008, 08:31 AM

[Sir_Carnifex]

Did you check the correct spelling of the banter files

Problem solved. It turned out I did make a mistake of that sort, but not in the Bioware character's file. I forgot to add the prefix on the death variable of my own character.

[Sir_Carnifex]

Even if you'd put the scripted dialogues into the B.dlg (which would, in principle, work, but be cautious to use the right weighting), you wouldn't be able to call them via Ctrl.+I, since they need the trigger variables to be set.

As long as you mentioned weights, would all the banters in the file have to have weights set for it to work? For an experiment, I included weights on three of the banters. So far after testing it several times, those three banters still come in a random order but always come before the non-weighted banters. That's not exactly the way I hoped it would work.

[jastey]

The weighted banters come before th unweighted ones, that is the way it should be. Per dialogue file, the blocks are processed from top to bottom. If you say you have the banters in a random order, could it be it wasn't the same NPC starting the dialogues?
If you want to have banters from different NPCs in a specific order, you will have to use variables to ensure it. (i.e. in the first banter by NPC 1, the variable XX-(your prefix)Banter1 is set to 1; in th second banter from NPC 2, the trigger block contains Global("XX_Banter1","GLOBAL",1).) Using variables to ensure the order is a good idea anyway, since weighting changes the top-to-bottom processing of a dialogue file.

[Sir_Carnifex]

The weighted banters come before th unweighted ones, that is the way it should be. Per dialogue file, the blocks are processed from top to bottom. If you say you have the banters in a random order, could it be it wasn't the same NPC starting the dialogues?

Correct. It was a different character who started the dialogue.

If you want to have banters from different NPCs in a specific order, you will have to use variables to ensure it. (i.e. in the first banter by NPC 1, the variable XX-(your prefix)Banter1 is set to 1; in th second banter from NPC 2, the trigger block contains Global("XX_Banter1","GLOBAL",1).) Using variables to ensure the order is a good idea anyway, since weighting changes the top-to-bottom processing of a dialogue file.

Thanks. I had the variables in as "LOCALS" when I tried this before. Go figure.

For scripted dialogues, I recommend using the J.dlg. Scriptd banters are for a specific situation only (after a timer is run, if the party enters a specific area, after finishing a quest), so they are triggered by variables via the script file, and thus they cannot be called by Ctrl.+I.

Well, I have a banter that requires a certain area that I put in the J.dlg. It won't trigger on its own but CTRL + I will bring it up when I am in the correct area. So That means that the variables, etc are all checking out but the dialogue just won't run without help for some reason. But that's only if I accidentally use the banter script as I did below. When I correct BCXHALBO to be CXHALBOJ, nothing happens.

CODE

BEGIN CXHALBOJ

CHAIN
IF ~InParty("BioChar")
See("BioChar")
!StateCheck("BioChar",STATE_SLEEPING)
Global("BioCharHalbo1","GLOBAL",3)
OR(11)
AreaCheck("AR0021")
AreaCheck("AR0313")
AreaCheck("AR0406")
AreaCheck("AR0509")
AreaCheck("AR0513")
AreaCheck("AR0522")
AreaCheck("AR0704")
AreaCheck("AR0709")
AreaCheck("AR1105")
AreaCheck("AR1602")
AreaCheck("AR2010")~
THEN BCXHALBO HalboBioChar1.3
~blah blah blah~
DO ~SetGlobal("BioCharHalbo1","GLOBAL",4)~
== BioChar
~blah blah blah~
EXIT

[jastey]

The CHAIN still appends to the B.dlg, in case you didn't notice.

But if you want to add the dialogue to your J.dlg, you need a script block that executes and triggers the dialogue. In case you haven't one already:
What you do is, in your modNPC.bcs, you put a script block that goes

CODE

IF //dialogue activation
~InParty(Myself) //for modNPC who starts the dialogue only if in the party
InParty("BioChar") //dialogue partner
See("BioChar")
!StateCheck("BioChar",STATE_SLEEPING) //you might want to cosider using CamDawg's "CD_STATE_NOTVALID" who includes other "unable to talk-checks", like dead, stunned, etc.
!Dead("BioNPC") //in case you use STATE_SLEEPING
Global("BioCharHalbo1","GLOBAL",2) //variable will be set that runs the dialogue, could be you have to adjust the value or create a new one
OR(11)
AreaCheck("AR0021")
AreaCheck("AR0313")
AreaCheck("AR0406")
AreaCheck("AR0509")
AreaCheck("AR0513")
AreaCheck("AR0522")
AreaCheck("AR0704")
AreaCheck("AR0709")
AreaCheck("AR1105")
AreaCheck("AR1602")
AreaCheck("AR2010")~
THEN
RESPONSE #100
SetGlobal("BioCharHalbo1","GLOBAL",3)
END

IF // daialogue triggering. repeat only the crucial triggers to prevent CTDs
InParty(Myself)
InParty("BioChar")
See("BioChar")
!StateCheck("BioChar",STATE_SLEEPING)
!Dead("BioNPC")
Global("BioCharHalbo1","GLOBAL",3)
THEN
RESPONSE #100
StartDialogNoSet("BioNPC") //calls the J of the modNPC
END

and in your J.d file, there goes the dialogue (do not include other triggers here than the trigger variable, as it might cause stutter bugs):

CODE

CHAIN
IF ~Global("BioCharHalbo1","GLOBAL",3)~
THEN CXHALBOJ HalboBioChar1.3 //appending to J.dlg
~blah blah blah~
DO ~SetGlobal("BioCharHalbo1","GLOBAL",4)~
== BioChar
~blah blah blah~
EXIT

[Sir_Carnifex]

Weidu doesn't like that script block. It has a parsing error and refuses to compile. According to the report, the final area check is wrong, but if I rearrange the order (put the area checks first) it will say whatever is at the bottom (right before the tilde) is wrong.

Usually when this happened before it was because I was missing a tilde, but I don't see anything wrong. Then again, I tend to miss a lot!

[Bearwere]

remove the tildes:

~InParty(Myself)

>

InParty(Myself)

,

AreaCheck("AR2010")~

>

AreaCheck("AR2010")

[Sir_Carnifex]

Ah, thanks! It's working now...until the next time. I'm afraid to ask why tildes are put around checks in a B or J DLG but not in a BCS. Maybe I should be satisfied knowing how and not why.

[Bearwere]

because...it their syntax, I think. BCS structure a much simplier than DLG, it's just IF..THEN, so why bother with tildes?

[jastey]

Yeah, sorry about that... no tildas around the triggers and actions in a baf.