Integration with Dialogue System

PixelCrushers

I think my documentation was just a bit lacking. I tried to clarify it a bit in the next version. "If Player Involved" will only be true if:

1. In the dialogue database, the conversation's actor is a player character (i.e., the actor's IsPlayer field is true), and

2. The player is the actor in the conversation trigger/action. The Third Party: Dialogue System Conversation action does this by default. But if you're using the Dialogue System's Conversation Trigger instead, you may need to assign the player to the Actor field.

Eastman

"1. In the dialogue database, the conversation's actor is a player character (i.e., the actor's IsPlayer field is true), and"

Ah yes, this was the issue. In the database under Actors I had named my player character Player instead of the actual AC character's name (which was MainChar). Sorted now, many thanks!

PixelCrushers

Happy to help. In the future, if you want to use Player in the database, you can add an Override Actor Name component to MainChar and specify "Player".

wrongtarget

Here's an idea.
What about an option in the third party action to specify which node a conversation should start from?

I suppose that this should always be handled through variables...but may be handy? What do you think? 

PixelCrushers

Hi wrongtarget, thanks for the idea. I'd like to keep the Dialogue System as streamlined as possible by sticking with the variable method. Do you have any suggestions for making it easier to handle through variables? The third party action could include an option to set a variable, but that would be redundant with the built-in Variable:Set action.

wrongtarget

I'll think about it, but you're right. It's not a great idea.

I just felt frustrated for a minute because our writer set up this conversation in Articy for a cutscene and in the middle of the conversation, control returns to the player and he must do something before the conversation progresses. 
So I had to split the conversation inside Dialogue System to be able to run from the second point when I wanted. It was only mildly irritating, so I suppose it doesn't really require an overhaul.

Here's a real issue that's not solved though, I always dock my Dialogue System tab in the Unity Editor layout. Even though I always use the same database, sometimes the DS window will ask me to open a database again (I have not been able to determine when is exactly that it unloads the database). 
Now if at this point I double click the database in the Project tab, the DS window will not refresh with the database. It will still show a message asking me to select a database. 
So I have to close the DS tab, open the database, and dock the tab again. 

I don't know if I'm explaining the problem well and if there's any way around it. 
Thanks for your awesome support

wrongtarget

Another thought. What about being able to specify in the AC sequencer command what step from the ActionList to run from?
Is a similar problem, but when you have a cutscene where there's a lot of going back and forth between Dialogue System and AC's actions, there doesn't seem to currently be a way to run everything from the same actionlist continuously, so we need to split it in lots of actionlists. 

wrongtarget

Sorry Tony, feel I've been spamming this thread lately. 
Here's another issue, when setting an Third Party action to change a Dialogue System variable, I set as an Integer variable type and assign the new value, but as soon as I press play, it changes to boolean, breaking the flow.

PixelCrushers

Hi wrongtarget, 

This updated package adds an optional third parameter to the AC() sequencer command. The syntax is:

    AC(actionList, wait|nowait, stepIndex)

• "wait"/"nowait" specifies whether the sequencer should wait for the ActionList to finish.
• stepIndex is the step to run from.

It also fixes a bug in the Third Party: Lua action. When the Sync checkbox was ticked, it would sync from AC to Lua beforehand but it wouldn't sync back from Lua to AC afterward. It now syncs in the proper directions before and after running the Lua code.

I don't know if the bug fix will address the Dialogue System variable issue you described. If it doesn't, can you please explain how to reproduce it?

You can also download the updated support package from the Pixel Crushers customer download site. If you need access, please email me at tony (at) pixelcrushers.com.

The issue with the Dialogue Editor tab will be fixed in an upcoming release of the full Dialogue System package. It's a known issue that occurs in certain situations when switching into and out of play mode.

wrongtarget

Hi @PixelCrushers,

Having a little issue that I haven't noticed before. Not sure if it's a DS problem or something related to our Spine integration, but thought that you may point us in the right direction.
If I have an action to move the character to a point, and then a voice sequencer command, the talk animation will start before the camera has finished catching up with the player.

As a result, when the player character finishes saying its line, the camera will have a sudden "jump". 

It's as if the game was paused by the speaking animation, instead of running in the background. 

Any ideas?

Thanks!

PixelCrushers

Hi,

The Dialogue System's "Voice()" sequencer command just calls Unity's audio.Play() and animation.CrossFade(). The dialogue entry will wait until the audio and animation are done before moving to the next dialogue entry or response menu, but it waits in a coroutine so it won't pause anything.

I don't quite understand what's going on in your scene, so I'm afraid instead of offering an answer I'm going to bombard you with questions:

What's controlling the camera? Are you using a Camera() or LiveCamera() sequencer command? By Spine, do you mean the 2D skeletal animation system? If so, is this controlling the camera?

Is the "action to move the character" an Adventure Creator ActionList? If so, and if you're starting it with the Dialogue System's "AC()" sequencer command, have you tried the "nowait" argument to tell it to run in the background?

Also, just as an aside, you can use the ->Message() and @Message() syntax in sequences to tell sequencer commands to wait for other sequencer commands. For example, if you want to wait for an ActionList to finish before playing the lipsync, set the sequence to something like this:

AC(MoveToPoint)->Message(Moved); Voice(hello,hello)@Message(Moved)

wrongtarget

Hey Tony,

Thanks again for the help. 

1. At least in this particular instance, we're not using any camera sequencer commands. 
Yes, by Spine I mean the 2D skeletal animation system, it has no involvement in camera though.

2. The ActionList is the OnStart ActionList in this case, so it happens when the scene begins and it's not being called with the AC() sequencer command.

From what our programmer gathered "the camera issue is because AC is being paused by DS while the camera is still moving, then when the conversation ends it kicks back in where the camera would be otherwise" and  " it's happening for any sequence input"

He doesn't think it's the sequencer action that's causing it, but rather DS kicking in?

Edit: As I was typing this, we stumbled with the solution. Changing the Take Camera Control to Never in the Dialogue Manager seems to fix the issue. 
The way it is right now may be a bit abrupt? Maybe if AC Bridge started a coroutine to check if the camera movement has come to a stop before turning of AC camera control?

PixelCrushers

> As I was typing this, we stumbled with the solution. Changing the Take Camera Control to Never in the Dialogue Manager seems to fix the issue.

The option exists for this very reason, so you found the right solution.

> The way it is right now may be a bit abrupt? Maybe if AC Bridge started a coroutine to check if the camera movement has come to a stop before turning of AC camera control?

That might cause issues. For example, what if the camera never stopped moving for some reason? If a dialogue entry had a sequence that waited for a completion message from a Camera() command, it could hang the game.

If you don't mind giving control of the camera to the Dialogue System during the conversation, you can make the START node's Sequence position the camera over a duration, such as:

Camera(Closeup, speaker, 2)

It will smoothly move the camera from its current position to a closeup of the speaker over 2 seconds.

Or, if you don't want to give control to the Dialogue System, you could write a small script that implements OnConversationStart and OnConversationEnd. In OnConversationStart, it could run a coroutine that waits until the camera stops, then calls AdventureCreatorBridge.DisableACCameraControl(). And OnConversationEnd could call EnableACCameraControl(). If you need a hand with this, just let me know.

wrongtarget

I'm most likely missing something here because it's already early hours of the day, but what if like in our case we only want to make use of Camera commands in a few stages of conversations and leave AC control camera for the rest of the time?
Why isn't it possible to give control to DS only when there is a Camera command in the dialogue? 

PixelCrushers

Would it work to have a sequencer command ACCam(on/off) that lets you disable and enable AC control? ACCam(off) could also wait for the camera to stop moving before disabling control.

I'll think about other ways to handle this, too. There are some side effects to what you described, and I don't want to break anyone's current projects.

shredingskin

Apparently AC 1.40 breaks the bridge.

PixelCrushers

Working on it today. :-) I'll release a patch on the Pixel Crushers download site when it's ready. If you need access, please email your Asset Store invoice number (for the Dialogue System) to tony (at) pixelcrushers.com

PixelCrushers

You can download the patch right here: AdventureCreator_Support_2014-11-12.unitypackage

It requires v1.40, and also adds a sequencer command ACCam(mode), where mode can be:

• on: Enables AC camera control immediately.
• off: Disables AC camera control immediately.
• idle: Waits until the camera stops, then disables AC camera control.

There's also a new option for the bridge's Take Camera Control property: "After Stop If Player Control", which automatically works like idle mode above at the start of the conversation.

wrongtarget

Sorry @PixelCrushers that I didn't reply to your question before. 
I'm glad that you went ahead with your idea and added that sequencer command. I think it was an elegant solution, thank you very much for this.

We're working right now in a camera sequencer command that can zoom and pain in our 2D game without messing the perspective. Since our game is a 2D game where sprites move in the x/y/z planes, and some background layers are laid out in different Z positions, none of the current camera command options work for us right now. 

Would you be interested  that we send you over the script when it's done? 
Cheers

PixelCrushers

Hi @wrongtarget - yes, that would be great. Thanks! Is the existing Zoom2D() sequencer command useful in your situation?