Page 2 of 4

Re: DS behavior with SimStatus 'Untouched' in non-existent tables

Posted: Mon Oct 15, 2018 11:51 am
by Abelius
Ahh, okay.

I wondered how each entry was identified if not by the ID, so I have now my answer. :P

Thank you, Tony.

Re: DS behavior with SimStatus 'Untouched' in non-existent tables

Posted: Thu Feb 07, 2019 2:50 pm
by Abelius
Hi Tony,

Sorry for unearthing this thread, but I'm having the original issue again, in version 2.1.1.1:

Image

Did you, for some reason, undo the change in 2.x versions, maybe? I've recently upgraded DS to the latest version and I don't think this was happening before in version 1.8.6.

As I said before, I'd need DS not throwing exceptions when a node is not found in the table, and assume that node is untouched for conditional scenarios, so I can add new dialogue trees and use SimStatus = untouched conditionals.

Could you clarify the intended status of this behavior for me, please?

Re: DS behavior with SimStatus 'Untouched' in non-existent tables

Posted: Thu Feb 07, 2019 3:15 pm
by Tony Li
The SimStatus reload code was rewritten for versions 1.8.8 and 2.1.0. It used to be an O(n^2) operation. Now it's O(n). In other words, the time used to grow exponentially with the number of nodes -- which wasn't acceptable for very large databases -- but now it just grows linearly.

Can you identify whether entirely new conversations are the issue, or new nodes that were added to existing conversations after the save?

Either way, it's still supposed to backfill SimStatus for new nodes and new conversations. It sounds like there might be a bug then.

Re: DS behavior with SimStatus 'Untouched' in non-existent tables

Posted: Thu Feb 07, 2019 4:55 pm
by Abelius
In this case in particular is a new node inside an existing conversation.

I can't tell at this moment if new conversations would have this problem as well, but I could arrange a test if you want.

Re: DS behavior with SimStatus 'Untouched' in non-existent tables

Posted: Thu Feb 07, 2019 4:59 pm
by Tony Li
Please test that case, too, if you don't mind. In the meantime, I'll look into the code that backfills new dialogue entry nodes.

Re: DS behavior with SimStatus 'Untouched' in non-existent tables

Posted: Thu Feb 07, 2019 6:15 pm
by Abelius
Hi there,

I'm having difficulties in testing the issue with a new conversation.

What I've done is the following:

1. I start a new game
2. I go through the entire Intro and the needed quests to reach the point where I got the mentioned exception.
3. I save the game at that point.
4. I initiate the conversation with the character. It works fine this time because (I assume) it's a new game from scratch.
5. I duplicate the conversation and assign it to the 'Talk To' AC action for that character, so it uses the new convo instead of the old.
6. I load the previous save and I get an error when clicking on the character, and the conversation doesn't start:

Image

Then I've tried to use the old convo, linking to the new duplicated conversation with the same result. I've also tried to create (instead of duplicating) a new convo, copying+pasting the nodes from the old convo. It happens the same. As long as I try to start a new convo, I get that error.

Scary. :roll:

Re: DS behavior with SimStatus 'Untouched' in non-existent tables

Posted: Thu Feb 07, 2019 6:28 pm
by Abelius
Uh... I've just found something weird, in addition to the previous.

Image

Each character Hotspot has that Dialogue Actor script (I don't think that was there before 2.x), pointing to a stream of Hex characters.

I thought that could be the problem, but the error persists after changing that nonsense to the appropriate character name from the dropdown list.

Now I'm wondering if I can delete those 'Dialogue Actor' scripts safely. Because I don't really know why they're even there, in the AC Hotspot object. :?

Edit: this is what I've had in 1.8.6, instead of the Dialogue Actor script:

Image

And I don't even know why I had those 'Override Actor Name' components there, lol. If there was a reason, I forgot long time ago. But the thing is, they've turned into a different script with 2.x upgrade.

I guess this is not related to my original problem, right?

Re: DS behavior with SimStatus 'Untouched' in non-existent tables

Posted: Thu Feb 07, 2019 7:15 pm
by Tony Li
The DialogueActor / OverrideActorName thing is unrelated. In 1.x, the script was named OverrideActorName. In 2.x, it's renamed to DialogueActor but it has the same GUID. It carries over all the values from 1.x and adds new functionality. The strange hex is the same issue as the SequencerShortcuts. Unity was unable to convert it properly from Binary/Mixed serialization to Force Text serialization. Selecting the right actor from the dropdown will fix it, although it's admittedly an annoying manual process.

Thanks for the SimStatus info. It's all the same thing. When loading a saved game, the Dialogue System isn't setting up SimStatus info for conversations that weren't in the saved game.

I'll dig into the code. I may need to send you a script that provides extra log info.

In the meantime, is the Dialogue Manager's Other Settings > Include SimStatus checkbox ticked?

Re: DS behavior with SimStatus 'Untouched' in non-existent tables

Posted: Thu Feb 07, 2019 7:27 pm
by Abelius
Yup, it is.

This is my config, in case it helps:

Image

Re: DS behavior with SimStatus 'Untouched' in non-existent tables

Posted: Fri Feb 08, 2019 4:13 am
by Abelius
Hi Tony,

I've installed the patch you sent me and it's working well in both cases (new node/old convo and new node/new convo).

I changed Debug Level to 'Info' and I can see a very long (and truncated) log...:

Image

...that seems to inform about the SimStatus "reset" to untouched operations.

This is perfect for me, but if you don't want to make it mandatory for all users due to performance issues, I'd be perfectly happy if you implement a checkbox for 'Safe_SimStatus'.

Oh, and thank you also for the new node colors. I can't wait to dig into the 24 bit color palette. :lol:

Edit: Mmm, I've just added a node to another convo and this showed up even though I set Debug Level to 'Warning':

Image

That is what you actually meant then, right?