10 réponses à ce sujet

[ColorsFade]

I'm trying to understand some behavior here, and to figure out the best way to implement some conversations. 

 

As an example, in an OnClientEnter script I have some conditional code that creates an NPC and fires a conversation. It looks like this: 

iLoc = GetLocation(oPC);
iPSpeaker = CreateIPSpeaker("triel_guard_runner", "triel_guard_runner", iLoc, 1.0f);
//DelayCommand(1.0f, AssignCommand(oPC, ActionStartConversation(oRunner, "triel_guard_runner", FALSE, FALSE, TRUE, FALSE)))

Initially, I had the DelayCommand() call uncommented. When it is uncommented, it fires the conversation immediately upon entering the area (which is what I want). 

 

However, according to what I've read, it seems that CreateIPSpeaker is supposed to handle everything for me automatically, without the need for the AssignCommand/ActionStartConversation call. 

 

But here's the issue I noticed: if I comment out the DelayCommand line, it can take several seconds for the conversation to fire, at which point in time the PC and party may have already run off several yards away from the NPC (triel_guard_runner) who they are supposed to converse with. The conversation happens, but by now they are beyond shouting distance and it look silly. 

 

Also, if I exit the previous area and enter this area using one of the companions, it can take even longer for the CreateIPSpeaker to fire the conversation. 

 

So what is the correct way to set all this up to ensure the conversation fires and fires quickly upon entering the area? Am I using CreateIPSpeaker wrong? Do I even need to use it at all in this instance? When is the appropriate time to use CreateIPSpeaker()?

 

 

 

 

 

[Tchos]

The delay (beyond the 1 second delay you put into it) is caused by the script firing before either the NPC or the PC (likely the latter) is present and/or not busy.  When the dialogue fails initially, the Ipoint Speaker switches to its backup plan of trying again, twice on each heartbeat, so every 3 seconds until both are present and have clear action queues.  Controlling a companion will indeed cause a delay using the speaker as written.  I have a small rewrite of the speaker's method planned to prevent that.

 

If the dialogue fails initially when you're not using the Ipoint Speaker method, there is no backup, which is the reason to use an ipoint speaker in the first place.  You should remove the 1.0f delay in the CreateIPSpeaker line.  Since it will try again in any case, there's no reason to delay it.  However, you might want to use the location of the NPC to spawn it instead of the PC, who's transitioning between areas, even though it should have finished by the time On Client Enter fires.  It's also not necessary to specify the NPC's conversation if the NPC already owns a conversation.

 

You should not have two separate methods of firing the conversation.  Use one method or the other, not both.

[kamal_]

I've had issues with using an area's onenter script to launch a conversation with an ipspeaker. In fact I was troubleshooting that this past weekend. I went with the brute force method of just putting a trigger in the area itself where the player spawns in, and putting an onenter to speak on the trigger. Not "elegant", but has been reliable. You can also place the speaker instead of spawning one if there's only one place to enter into the area.

[Tchos]

Never place an IP Speaker object.

[kamal_]

What is the reason not to place one? It seems to work very reliably.

[ColorsFade]

I went with the brute force method of just putting a trigger in the area itself where the player spawns in, and putting an onenter to speak on the trigger. Not "elegant", but has been reliable. 

 

That's the method I used almost exclusively in my prologue and it worked. I only went that route because I opened up some OC areas to see how they did it. 

 

I was under the impression that the CreateIPSpeaker() was more reliable, so I was trying to change a few to this method and see how it worked. That's when I noticed the delays. 

[andysks]

The delays, I was talking with Tchos about this recently. In simple words, he told me that the ip-speaker will try to find an object to assign a convo to, and this one is by default the first PC. So if you are controlling a companion at the time you enter the trigger then it will keep looking. I had the same problem and it's quite annoying, currently working on a solution. The ip-speaker IS really reliable. And when Tchos says you shouldn't place them he means the ip-speaker, because it will run unnecessary hb if it just placed as a speaker and not in order to do what it's supposed to do. The way you did it until now, you could have just placed a simple ipoint. It would be the same .

[Tchos]

What is the reason not to place one? It seems to work very reliably.

 

As Andy explained, and which I've explained in this forum many times before, placing an ipoint speaker, which is to say the object in the blueprints called "Ipoint Speaker" and not just any old ipoint that you're using as a reference object for a conversation, is placing an object which was designed to be used in a system and never meant to be placed, leaving it without necessary variables for it to do its job.  It should never have been left as a blueprint at all, because you should never place it. 

 

It's designed to be spawned solely through its creation script, with variables attached that will automatically fire the conversation.  If you place it, it will cycle twice per heartbeat forever uselessly trying to fire a conversation that was never specified through its creation script on a creature that was also never specified on its creation script.  Yes, you can put a conversation on it manually, at which point you're using it exactly like a standard ipoint (or any other non-static object) with no heartbeat script attached, and bypassing all of the checks, contingencies, and retries of the ipoint speaker system.  Except that this one runs a heartbeat.

 

Additionally, when I've seen people placing ipoints for use in conversations, they usually have the ipoint be the one that actually speaks or owns the conversation.  The ipoint speaker does not speak.  After all its checks and contingencies, it assigns a command to the PC to speak to an NPC, and then destroys itself after the conversation has successfully fired.

 

Again, if you are going to place something for a conversation, and don't care about checks and backup measures or plan to implement your own, place or spawn a normal ipoint.  If you want to use the object called "ipoint speaker" for its conditional benefits, spawn it through its script.

 

As an aside, I made a simple test where using an object would spawn an ipoint speaker that started a conversation with an NPC to judge its speed and effectiveness when I was moving, and/or in combat, and/or controlling a companion instead of the main PC, and each time it was instantaneous.

[PJ156]

Could you give me an example of the script that would operate off a trigger that spawns the ipoint speaker. I'm still a little confused by this. If the ipoint has no convo assigned directly to it how do i tell it by script which one to fire. Or do I create a blueprint and spawn that?

 

I want to do this by spawning as placing is against the philosophy of my current project. That said, what options do I have for spawning the ipoint,

 

 

 

PJ

[andysks]

Hi Peter. I used to use a script, which I don't anymore for various reasons. I won't post the whole of it because it's a bit obsolete and it might lead to further confussion, but the basic functions looked like that, and worked.

void SpawnSpeaker()
{
     
     object oPC = GetEnteringObject();
     if (!GetIsPC(oPC))
         return;	

	string sSpeakerTag = GetLocalString(OBJECT_SELF, "SpeakerTag");
	string sConvo      = GetLocalString(OBJECT_SELF, "Convo");
	location lLocation = GetLocation(oPC);
	float fDelay       = GetLocalFloat(OBJECT_SELF, "Delay");
	int iDestroySelf   = GetLocalInt (OBJECT_SELF, "DestroySelf");
	int iCondition     = GetLocalInt (OBJECT_SELF, "Condition");

	CreateIPSpeaker(sSpeakerTag,sConvo,lLocation,fDelay);
	

}

If you feel like it pm me to explain further why I don't use it anymore, and also I could provide you a script for triggers that basically does the same as an ip-speaker minus the heartbeat .

[Tchos]

Could you give me an example of the script that would operate off a trigger that spawns the ipoint speaker. I'm still a little confused by this. If the ipoint has no convo assigned directly to it how do i tell it by script which one to fire. Or do I create a blueprint and spawn that?

 

You don't assign a conversation to an ipoint if you're using the ipoint speaker, and you don't create new blueprints.  You spawn the speaker with the function CreateIPSpeaker(), which has a parameter to specify the actual NPC who speaks, and the conversation they will use (if it's different from the one the NPC already owns -- otherwise you don't need to specify it).  The ipoint speaker destroys itself automatically after the conversation is done.  You don't have to think about the ipoint at all.  Just use the function.

 

If you feel like it pm me to explain further why I don't use it anymore, and also I could provide you a script for triggers that basically does the same as an ip-speaker minus the heartbeat .

 

I know I haven't provided the failsafes yet for the custom trigger script, but when they're done, it will have a heartbeat on the trigger script, because that's a necessary part of the failsafes.  As with the normal ipoint speaker, it runs a heartbeat only when it exists, which is upon being spawned immediately before the conversation, until just afterward.