Portrait Flashing on Conversation Start

[Tony Li]

Understood. I'll let you know what I find in a repro setup by tomorrow.

[Tony Li]

Hi,

I wasn't able to reproduce the issue. Here's the test scene I'm using:

DS_AnimatedPortraitTestScene_2024-01-06.unitypackage

Perhaps you can change it to produce the issue.

[lcn_mc]

Hey, all. Apologies for necroing the thread, but I did some more experiments on this issue (in my particular use case, that is) and narrowed it down to a likely culprit. In addition, I found what looks to be a functional workaround.

So, to refresh, here's the bug I observed:

• On a seemingly random basis, there would be a one to two frame flash of the wrong Dialogue Portrait at the start of a conversation.
• This bug occurs in situations where the Subtitle Panel game objects used for the Player and NPCs are overlapping in the scene.
• This bug may somehow be exclusive to importing Articy files, but I can't say so with confidence one way or the other. (I've only ever used Articy in my workflows.)

After further experimentation, I determined the following:

• The portrait showing up incorrectly would be that of whatever Dialogue Actor is currently set as the Conversant in the Dialogue System's list of variables.
• The bug does not occur until there is a conversation with a conversant that isn't the Player. (In other words, if you had a series of monologue conversations that was just the player's Actor, the bug would not manifest. However, once you had your first 'player talks to NPC' conversation where that NPC was a Dialogue Actor, the bug would occur, and then continue occurring.)
• It didn't seem to matter whether the conversant was using animated dialogue portraits, but it did matter if the conversant had a Dialogue Portrait set. (e.g.: The Game Object with the Dialogue Actor component could be missing an Animator Controller component as well as having no attached Animator, so long as it had an image linked for the Dialogue Portrait part of the Dialogue Actor Component.)
• This bug will only occur in use cases like mine, where all of the Dialogue Portrait image objects are stacked on top of each other in the scene. If they were not overlapped, this issue would not be observable.

Then, after even more experimentation, I found the following workaround:

• For each conversation, and at the per-Conversation level (e.g.: Beginning at the Start node), set the Actor and Conversant to a 'dummy' Actor that is flagged as a NPC.
  (If the 'dummy' Actor is set as a Player, I observed a separate bug where the entire Dialogue Portrait would flash the flat gray 'faded out' color for one frame.)
• In Articy (which I use in my workflow as opposed to editing any conversations in the Dialogue System in Unity), this involves creating two dummy Actors as Entities, making sure they're flagged as 'Is NPC,' and dragging them into the Entities field for each Dialogue.

I need to do further testing on the workaround, but my provisional testing was completely successful.

So, while not a true fix for this odd issue, it does remove the immediate visual bug of seeing a one to two frame flash of the wrong dialogue portrait at the start of a conversation. Hope it helps anyone else who ran into it!

[Tony Li]

Hi,

Thanks for sharing your workaround! I may have mentioned this earlier in the thread, but are your subtitle panels' Visibility dropdowns set to Always From Start? That might cause this issue, since it will open all panels marked Always From Start as soon as the conversation starts.

[lcn_mc]

Tony,

I believe they are indeed set to Always Visible from Start. I did some initial experiments a while back wherein I change those options around, but that ended up fixing this 'wrong portrait flickers' issue, but replaced it with some other issue that (I think) was related to dialogue portraits not appearing until the speaker's first line of dialogue had finished appearing. Something odd like that.

This workaround I've described above still has a minor bug in that the speaker's portrait, even though it's the correct one, is in the 'darkened / inactive' state for one to two frames, but I think most players will not notice it.

I'm planning to implement this workaround tonight and (hopefully) do some initial testing on it, so hopefully it behaves as my preliminary testing indicated last night.