Jump to content


Photo

Trouble with Player Initiated Dialogue

PID NPC Dialogues

  • Please log in to reply
18 replies to this topic

#1 tibicina

tibicina
  • Member
  • 9 posts

Posted 26 November 2014 - 06:31 PM

Is Player-Initiated-Dialogue the same thing as "force-talking"?

 

I'm working on a new NPC and am having difficulty getting the right written content to display when I click on the character. Right now, when I click on the player character, the face icon, and the npc, the game displays one of my friend-talks instead of the "flirts" content.

 

Now, I understand (sorta) why it's pulling up that content. My .baf file lists that particular talk as 1:

 

Spoiler

 

But I'd like to find out how to get it to display the right content. Do I have to renumber all the blocks? 

 



#2 --jastey-

--jastey-
  • Guest

Posted 27 November 2014 - 01:52 AM

Force-talking is PID, yes. You need a variable trigger for all other dialogues that cannot be true unless they are set, i.e. a variable that is not "0" but has to have a value.

 

The only "dialogue" state that has to be true always (~True()~) is the PID which has to be at the very bottom of the dlg-file (compiled last in the install).

 

The call of a dialogue is done teh way that: If a dialogue is to be called, the engine searches the dlg from top to bottom for a true dialogue. The first one it finds will be triggered. Thus, all other dialogues have to be secured by a trigger variable that has not the value "0".

 

-jastey



#3 --jastey-

--jastey-
  • Guest

Posted 27 November 2014 - 01:57 AM

OK, now I finally read your post properly, ahem.

 

What you need is a dialogue call via script (for your other dialogues) that sets the true trigger varaible the moment the dialogue is called. If the love talk with "Global("TIMaethLoveTalks","GLOBAL",1)" can be triggered via PID, then this means that Global("TIMaethLoveTalks","GLOBAL",1) is already true although the dialogue is not to be called yet.

You should change the calling of the love talk to something like

IF

[timer expired]

[match conditions true]

Global("TIMaethLoveTalks","GLOBAL",1)

THEN RESPONSE #100

SetGlobal("TIMaethLoveTalks","GLOBAL",2)

[start dialogue]

END

 

And in the dlg-file, the trigger for teh dialogue would be Global("TIMaethLoveTalks","GLOBAL",2).



#4 --jastey-

--jastey-
  • Guest

Posted 27 November 2014 - 02:06 AM

... And of course I meant something like this, to prevent the stutter bug:

 

IF

[timer expired]

[match conditions true]

[PC can talk, NPC can talk, no enemy nearby, no fight etcpp]

Global("TIMaethLoveTalks","GLOBAL",1)

THEN RESPONSE #100

SetGlobal("TIMaethLoveTalks","GLOBAL",2)

END

 

IF

[PC can talk, NPC can talk, no enemy nearby, no fight etcpp]

Global("TIMaethLoveTalks","GLOBAL",2)

THEN RESPONSE #100

[start dialogue]

END



#5 tibicina

tibicina
  • Member
  • 9 posts

Posted 27 November 2014 - 09:58 AM

Here's the whole .baf for reference and the love-talk in question:

 


Spoiler

Spoiler

 

Ok. I've used Kulyok's method, setting two blocks for the love-talks. I have the variable set when I set the timer earlier in the .baf and increment it in the first block. Then, in the second block, it should call the .dlg file (which identifies the global).

 

I think the problem may be that I have the LoveTalks grouped with the FriendTalks.  I've been modifying Branwen to do this NPC, but I'm afraid that I'll have to separate LoveTalks (romance only) from FriendTalks (friends and romance). Do you think my issue is that the first LoveTalk is with the FriendTalks?

 

I hope I've been able to make the problem make sense, Jastey... Thanks to your earlier advice, the Talks are firing properly. My issue now is the PID.  


Edited by tibicina, 27 November 2014 - 10:19 AM.


#6 jastey

jastey
  • Administrator
  • 3218 posts

Posted 27 November 2014 - 12:23 PM

Your increment script block does not check for Global("TIMaethFriendActive","GLOBAL",1), so theoretically, the friendship and LT variables could be incremented although this condition is not valid (possible PID triggering later)?

 

-The night dialogue is triggered for PID because you set the trigger variable true in the script block above without triggering it before the party rests. But in the time between, the trigger is true so that is what the player gets when he force-talks your NPC.

 

For the rest dialogues, the incrementing of the trigger variables has to be in the xxxxD.baf - (and here, not in two script blocks but only one.) Solution is to remove the "Global("TIMaethLoveTalks","GLOBAL",1)" from the script block above, and take it into the xxxxD.baf directly with something like:

 

IF
    InParty(Myself)
    RealGlobalTimerExpired("TIMaethTalksTimer","GLOBAL")
    Global("TIMaethShutUp","GLOBAL",0)
    See(Player1)
    !StateCheck(Myself,CD_STATE_NOTVALID)
    !StateCheck(Player1,CD_STATE_NOTVALID)
    CombatCounter(0)
    !See([ENEMY])
    !AreaType(DUNGEON)
    Global("TIMaethLoveTalks","GLOBAL",1)  //4 - LT 1: Reverie uses dream script TIMaethD.BAF  <--This displays in PID
THEN
  RESPONSE #100
  IncrementGlobal("TIMaethLoveTalks","GLOBAL",1)
    StartDialogueNoSet(Player1)
  END

 



#7 tibicina

tibicina
  • Member
  • 9 posts

Posted 27 November 2014 - 07:41 PM

This is what I have in TIMaethD.baf for that LoveTalk:

 

Spoiler

 

As you mentioned above, it is in two blocks, imitating Branwen's method.



#8 jastey

jastey
  • Administrator
  • 3218 posts

Posted 27 November 2014 - 09:11 PM

I didn't check Kulyok's Branwen, but I would assume the D does not deparate in two blocks.

 

-Simply because the engine checks the xxxD.bcs only once before the rest. If you make the dialogue call two blocks, only the first one will be executed before the (first) rest. So, the variable is set but the dialogue does not trigger (it would, theoretically, before the next rest, but chances are high the player has unintentionally triggered the dialogue via PID until then).

 

For the rest dialogues, the "set the trigger variable and then make a looping script block until the dialogue is really executed" is not necessary, anyway, as the player cannot interrupt the script block in this case (as (s)he can during normal play).

 

EDIT: So, solution would be to make the dialogue triggering in the xxxD.bcs only one script block, and remove the incrementing of the variable from the overall incrementing script block.


Edited by jastey, 27 November 2014 - 09:12 PM.


#9 tibicina

tibicina
  • Member
  • 9 posts

Posted 27 November 2014 - 09:22 PM

Makes a lot of sense. I've made the necessary changes. So now the PID doesn't call LoveTalk 1. NOW it calls a random piece from TIMaethJ:

 

Spoiler
 
Any ideas on why this got called instead of my PID scripting? The check for the player character's gender does come up as true, but I use that same check elsewhere without it showing up during force-talking...:
 
Spoiler
The PID script does come last in the TIMaethJ file.

Edited by tibicina, 27 November 2014 - 09:26 PM.


#10 jastey

jastey
  • Administrator
  • 3218 posts

Posted 28 November 2014 - 12:02 AM

I wrote it above but it might not have been as clear as I wanted it to: The call for a dialogue means the first true dialogue in the dlg file (read from top to bottom) will be triggered. "Gender(Player1, FEMALE)" is always true if the PC is female, so that is what the player gets if force-talking the NPC (while being female). The reason why you do not see the other instances where you use this trigger is because they are further down the dlg file (in compiled state). If you deactivate the one you will start to see the other, still instead of the PID. (It also means you won#t be able to call the other dialogues that uses this trigger via script, btw - always the first will pop up if no other trigger variable will be used.)

Every dialogue that is not PID needs an own, unique trigger variable that will be only true if the dialogue is meant to be called.
See it like a unique key for unique doors. You do not want the dialogues use the first exit door they see - you want them to use the unique doors that leads them to the one right exit - so every dialogue needs a unique clue where this would be. If that makes sense.

-I am not a real fan of using CHAIN all along, btw, as it messes with the install order (using CHAIN it is not clear that a script block in your .d will really be below another in the compiled dlg). (Also, it is considered bad style by the older modders but that shouldn't prevent you from using it. :) )

#11 jastey

jastey
  • Administrator
  • 3218 posts

Posted 28 November 2014 - 12:07 AM

A question: Why does the dialogue state have this trigger, anyway? It is not a real dialogue beginning, if I see it correctly. You only need trigger variables at the dialogue states if you want the dialogue to start with this state, not if it's "in the middle" of a dialogue.

-One thing to the PID: If you add the ~!ActuallyInCombat()~ to the PID, this means he would "Has Nothing To Say" in case of combat - this could lead to player "bug" reports about the PID not working. You could add a one-liner for ~ActuallyInCombat()~ to prevent this - if you want to.

Edited by jastey, 28 November 2014 - 12:08 AM.


#12 tibicina

tibicina
  • Member
  • 9 posts

Posted 28 November 2014 - 11:10 AM

Bless you for being so patient with me!! I'm a noobie scripter, so I'm struggling a bit with the words to describe the problems and understand.

 

I have the gender dialogue trigger in the middle state purely for style reasons; Maethor acts differently depending on gender. Maethor as a male punches a male player character. He wouldn't punch a female player. I *can* just edit it to a single response, but I'm trying to figure out how I can make the trigger unique so that I can keep the variable responses without, say, having two completely separate dialogues for male or female players. :-) 

 

Concerning the ~!ActuallyInCombat()~... I'll try that, although it hadn't occurred to me that someone would try force-talking while in combat... as a player, I've been more concerned in combat about not getting the stuffing knocked out of me! :-)


Edited by tibicina, 28 November 2014 - 11:14 AM.


#13 tibicina

tibicina
  • Member
  • 9 posts

Posted 28 November 2014 - 11:34 AM

"I am not a real fan of using CHAIN all along, btw, as it messes with the install order (using CHAIN it is not clear that a script block in your .d will really be below another in the compiled dlg). (Also, it is considered bad style by the older modders but that shouldn't prevent you from using it.  :) )"

 

I usually don't use CHAIN... TIMaethJ is mostly traditional scripting. CHAIN appears only during dialogues that have extended descriptive sequences or have other characters talking in them--situations where the player character has no responses... 


Edited by tibicina, 28 November 2014 - 11:34 AM.


#14 jastey

jastey
  • Administrator
  • 3218 posts

Posted 28 November 2014 - 11:53 AM

Oh yes, in these cases I also use CHAIN and I love it! EDIT: Although if it's only a series of dialogue lines for the NPC, it can also be done easy in a normal dialogue state. But different NPCs talking or different reactions of the same NPC, CHAIN is great.
 
I still don't see why you'd have to put the trigger (PC female / male) in the state trigger, though. What I think you mean is the following, or am I wrong?

 

IF ~Global("[VariableThatStartsDialogue]","GLOBAL",1)~ THEN greeting
SAY ~Oh, hello, there!~

IF ~Gender(Player1, FEMALE)~ THEN + female

IF ~Gender(Player1, MALE)~ THEN + male

END

 

IF ~~ THEN female    <---------------------------------- no state trigger needed here inside the dialogue

SAY ~It's great to travel with a heroine!~

IF ~~ THEN DO ~SetGlobal("[VariableThatStartsDialogue]","GLOBAL",2)~ EXIT

END

IF ~~ THEN male <---------------------------------- no state trigger needed here inside the dialogue

SAY ~It's great to travel with a hero!~

IF ~~ THEN DO ~SetGlobal("[VariableThatStartsDialogue]","GLOBAL",2)~ EXIT

END


Edited by jastey, 28 November 2014 - 12:03 PM.


#15 jastey

jastey
  • Administrator
  • 3218 posts

Posted 28 November 2014 - 12:02 PM

And of course you could write my above example using CHAIN, too:

 

CHAIN

IF ~Global("[VariableThatStartsDialogue]","GLOBAL",1)~ THEN TIMaethJ greeting

~Oh, hello, there!~ DO ~SetGlobal("[VariableThatStartsDialogue]","GLOBAL",2)~

== TIMaethJ IF ~Gender(Player1, FEMALE)~ THEN ~It's great to travel with a heroine!~

== TIMaethJ IF ~Gender(Player1, MALE)~ THEN ~It's great to travel with a hero!~

EXIT


Edited by jastey, 28 November 2014 - 12:03 PM.


#16 tibicina

tibicina
  • Member
  • 9 posts

Posted 28 November 2014 - 05:29 PM

After some tweaking, PID now working! Yay!

 

I have the trigger variable set where it is primarily because it's a long distance (29 states) from the opening of the dialogue. I did add a global checking to see whether the globalGT was equal to that talk (making it a more "unique key" as you suggested...). 

 

Your examples are really cool... I'll have to consider how to tweak my dialogue to similarly take the trigger out of the internal dialogues...

 

Spoiler

 

There's an amusing sidenote to this, though... The dialogue I quote above is one of two. One is scripted for a female Maethor and one for a male Maethor (Maethor starts off female, but using the belt of gender on her makes her use alternative friend and love talks.)


Edited by tibicina, 28 November 2014 - 05:46 PM.


#17 jastey

jastey
  • Administrator
  • 3218 posts

Posted 28 November 2014 - 11:38 PM

If the dialogue state is specified, it doesn't matter where in the .d file it is. State triggers are only for triggering the dialogue state via a script or PID. They are completely ignored insde a dialogue path, and only lead to errors as you have encountered.

 

And from your code, I have the feeling I have to repeat myself: If you want the dialogue to go two different paths depending on your NPC's gender (EDIT: or, in this case, the PC's), the state trigger is the wrong place to put it - the separation has to be in the transaction of your reply option. Currently, in your dialogue, the state "A62.5A" is not called anywhere. I do think that you expect it to being called after the reply option

 

"++ ~In a house with two women, I'm sure he was well compensated for his trouble...in one way or another.~ + A62.5"

 

if the PC is female? Or is the dialogue state A62.5A called from somewhere you didn't post above?

 

If it is as I think it is, what you have to do is the following.

 

This:

Spoiler

 

 

would have to be this:

Spoiler

 

One comment to this: I am not sure an evil aligned (CN aligned etc.) PC would actually regret his / her words - in general, it is risky to tell the player what his/her PC is feeling, because players tend to have an own opinion on that. General standard for mods that are considered good is to describe what the NPC is doing (recoiling as if physically struck, then hitting the PC - or at least trying to) and leave the reactions and feelings to the player by giving different choices. This includes giving different choices at every instance, also (the common would be "friendly reply", "indifferent", and "unfriendly reply")

 

 

Another syntax correction:

IF ~~ THEN BEGIN A63.1OB
SAY ~I wish I could accept that... Maybe someday. *Maethor reaches over and takes your hand, giving it a quick squeeze.* But you've been a patient listener. Thank you, <CHARNAME>. It's nice to know you have faith in me.~
IF ~~ THEN EXIT <---- needs to be put here.
END

 

I can only advise to make a running install as soon as possible and debug your dialogues one after the other. Firstly it is really cool to see your own content in the game, and secondly you won't be faced with 50+ syntax errors on your first test install (I am talking out of experience)..


Edited by jastey, 29 November 2014 - 12:02 AM.


#18 tibicina

tibicina
  • Member
  • 9 posts

Posted 29 November 2014 - 11:05 AM

Maethor, fortunately, is scripted to only romance good-aligned npcs, so I don't have to worry about what evil-aligned player characters might think. She's a paladin, so all she would be doing in an evil-aligned party is front-line melee fighting... But I  understand the point. I'll try to cut back on describing the player's emotions.  My background as a writer actually makes this a little harder... :-)

 

I'm really sorry that you're having to repeat yourself. I'm not trying to be resistant. It takes me awhile to understand exactly what you're getting at. But I am slowly making the needed corrections. I'll move the triggers as you recommend.

 

"I can only advise to make a running install as soon as possible and debug your dialogues one after the other. Firstly it is really cool to see your own content in the game, and secondly you won't be faced with 50+ syntax errors on your first test install (I am talking out of experience).."

 

My first test install had dozens...literally dozens...of syntax and parsing errors. I've been doing running tests for a couple of weeks now to correct various problems. 



#19 jastey

jastey
  • Administrator
  • 3218 posts

Posted 30 November 2014 - 12:12 AM

Sorry if I sounded patronizing. I wish you success with your mod! The snippets of the love talks look very intriguing (but I guess the romance is for elven-PCs, only?)







Also tagged with one or more of these keywords: PID, NPC, Dialogues