Jump to content

moveto spoils startconversation?


davidlallen

Recommended Posts

The interaction of different NPC commands seems very fragile, and it's making me frustrated. At one point in my mod, some bad guys appear, and the security guard NPC is supposed to force-greet me to ask for help. In version 1.0 of my mod, the security guard is always nearby and "guardREF.startconversation player helptopic" works fine. In version 1.1, I added a sleep package to the guard so he would sleep in a certain bed at night, which is in another cell. The sleep package works fine, he travels back and forth. But, if the bad guys come at night, the guard wakes up, but it takes a long time for him to walk from his bed, to where he is supposed to warn me.

 

So I added a "guardREF.moveto" a nearby location just before the startconversation, and this is where the problem comes. Now he correctly teleports to the location but never does the startconversation. It doesn't matter where I stand, I can see him teleport in and then just stand there. I take out the moveto and he forcegreets correctly.

 

Why should adding a moveto before a startconversation cause the startconversation to be ignored?

Link to comment
Share on other sites

I would try adding a delay after the moveto. A moveto causes an actor to evp. It also takes a little time. If the moveto and the startconversation are given in the same script iteration (frame), the evp could be canceling the dialog.

 

 

Link to comment
Share on other sites

I have a trigger script like this:

begin OnTriggerEnter player
if (bMarkTriggered == 0) && (getstagedone DWRDonDialog 14)
	DWRMarkNPCRef.moveto DWRMarkEndMarker
	DWRMarkNPCRef.StartConversation player DWRMarkDialogHA
	setstage DWRMarkDialog 9
	set bMarkTriggered to 1
endif
end

In order to add a delay, I have to add a fake quest with a timer, right? There is no way to put a delay into a trigger. I would think that if the lines follow each other in the code, one should finish, before the other starts. We cannot write any useful programs if all lines in a block must be assumed to execute in parallel. Is there any way to predict which combinations will not work?

Link to comment
Share on other sites

I had not thought of putting a gamemode block into the trigger script, but that makes sense. Of course it will run every frame when the player is in the cell, waiting for the *one single frame all game* when it is needed. But this tiny overhead should be ok. I'll try it, seems like it should work.
Link to comment
Share on other sites

That is working. Thanks for the suggestion. If I can be sure which commands take "zero time" and which don't, it will be easier to get this type of thing working faster. I expected moveto to take "zero time" but this shows it does not. Any thoughts on which other commands will need to be separated by timers?
Link to comment
Share on other sites

That is working. Thanks for the suggestion. If I can be sure which commands take "zero time" and which don't, it will be easier to get this type of thing working faster. I expected moveto to take "zero time" but this shows it does not. Any thoughts on which other commands will need to be separated by timers?

 

Commands that cause something to be loaded into the current cell, I would say - PlaceAtMe and MoveTo need multiple frames to complete, are the ones that I can think of that i've had issues with. Probably other functions that cause graphic effects - though I haven't done much with those. If I enable 0 an object that is already in the current cell, I usually wait till the next frame to do anything with it.

 

And generally, when i've scripted my companion to perform a task like hacking a terminal, delay is my friend ;)

Link to comment
Share on other sites

I had not thought of putting a gamemode block into the trigger script, but that makes sense. Of course it will run every frame when the player is in the cell, waiting for the *one single frame all game* when it is needed. But this tiny overhead should be ok. I'll try it, seems like it should work.

 

From what I have read, posted by people that know these things, the performance impact of these types of scripts is almost nil.

 

A performance hit will come from a script that is poorly written such that it involves some graphics action every frame - will probably CTD eventually.

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...