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

[Abelius]

Hi there,

I'm getting this error...:

Dialogue System: Lua code 'return Dialog[thisID].SimStatus == "Untouched"' threw exception 'Lookup of field 'SimStatus' in the table element failed because the table element itself isn't in the table.'

...when I use a saved game file from before I've added that (conditional) node to that conversation.

I understand the logic behind that: DS can't find that dialogue node ID in the SimStatus data from the old savegame. Fine.

But the default behavior of throwing an exception and not continuing on that path prevents me from adding new convos to the game and making them compatible with old save files. And that's a real pain...

I mean, in this specific case what I'm checking with that conditional is if that node has been seen by the player yet. So if DS can't find it in the table in the first place, that's the same as saying that indeed the players didn't see it, right?

So it would be a nice feature if we could get to choose if DS doesn't throw an exception and consider the condition 'untouched' valid. Again, in those specific cases where we're checking against a not seen node.

Could this be implemented as a checkbox in the Dialogue Controller, or something like that?

Thanks for reading!

[Tony Li]

Hi,

I think I can fix this in version 1.8.6 so you won't need to tick a checkbox. It will just automatically handle it. I'm trying to get versions 1.8.6 and 2.0.5 done by the end of the week.

[Abelius]

Great, thanks Tony!

[Abelius]

Hi again Tony.

I've noticed another issue, more or less related to this, in the sense that it makes harder to have compatible savegames between game versions.

It's with the Quest Entries in a quest. If you add more quest entries, they don't seem to exist in old savegames.

Well... that's actually pretty obvious and normal, hehe... but I'm wondering if it could be possible to apply the same behavior you added recently when all non-existent variables are initialized when loading a savegame where they don't exist (?).

It would be possible? Otherwise, I see myself adding lots of placeholder quest entries in future quests.

[Tony Li]

Hi,

Good thinking. I'll add that now, since I just finished testing the other fixes (SimStatus and quest entry dropdowns in wizards).

[Abelius]

I've been thinking about this and I'm actually quite surprised that it didn't get arisen as an important issue before.

Maybe I'm depending too much on DS to make my game. But if you're supposed to have compatible saves between versions, the lack of initialization of...:

- Variables
- Quest and Quest Entry states
- Node SimStatus states

...render previous save files useless if you add any of those items in new game versions.

You already fixed that with Variables, which it was great at the time. But I failed to realize that the rest were not handled as well.

Please, don't think I'm trolling you with this unnecessary post (because you're already taking care of this in 1.8.6), but it really, really, REALLY surprises me that nobody else saw a problem with this behavior in all these years! (including me, lol)

Just for curiosity, is there some way that I've missed to manually initialize those entities at load time? Something like "Hey, take a look at what the default values for these things are, and set them like that right NAW!"

At any rate, thank you for your work, Tony. I wouldn't know what I'd do without this plugin.

[Tony Li]

Despite their usefulness, SimStatus isn't as popular as one might expect, so maybe it just hasn't come up as an issue.

It's likely that most games that support compatible saves between versions leave "Include All Item & Quest Data" unticked, which is the default and shouldn't have any problems between versions.

BTW, these issues are all fixed in 1.8.6 and 2.0.5. Sorry it's taking so long to release. I try to release 1.x and 2.x updates at the same time because they go through the same QA process, and 2.0.5 is taking a little longer than anticipated. (Mostly updating third party support packages. The core updates are done.) I'll put together a 1.8.5 patch today that's really just 1.8.6 without the full QA test battery.

[Tony Li]

Hi,

I set aside the time to run the full QA battery and make it an official version 1.8.6 release. You can download it on the Pixel Crushers customer download page. If you need a reminder of your access info, just PM me.

Release Notes

[Abelius]

Oh great! You've just made the entire process of new content testing so much easier now!

Previously, I needed to create a new savegame everytime I wanted to test a dialogue event in the game (I don't have a fancy debugging console), but now I can just go along with an old one without seeing a horde of critical errors coming my way.

I'm crying of joy and almost sexual pleasure at this moment. You don't know how much easier my dev life has become with this.

I've got another question though, as the nonconformist bastard I am. I've just realized the existence of these config settings...:



I'm not sure what these do. The tooltip goes like this...:



Does this mean I could create a custom text field in both 'Conversations' and 'Dialogue Entries' templates and move all save info to them? If that's the case, where they're saved by default? It says it uses the ID by default, but that's not a field, right? Unless it's hidden, I guess...

Actually, I don't mind much where the SimStatus info is saved, but that description makes me wonder if by moving it to a custom field, then I could freely re-sort dialogue entries IDs and DS would still be able to locate and read them correctly from a savegame file of an older game version in which I stilldidn't re-sorted the IDs...?

A little far-fetched I know. And I don't really have a pushing need to re-sort IDs at this moment, but I'm curious. If by moving that info I could make save data even more flexible and non-dependant on fixed IDs, that would also be a nice feature, I think.

However, if I do this, I guess I'd somehow need to generate those custom fields in already created dialogue entries, right?

Oh, and I'd also forfeit old savegames because previous game versions wouldn't have those custom fields to be read. But that's okay for me if it's the last time I need to tell my players "hey, you need to start over, sorry", thanks to 1.8.6.

Anyway, this version has totally made my day. I don't even know how I survived without it until now. You put together a very nice data (variables/quest/simstatus) system and I'm amazed that people don't use it much if what you say is correct. But I'm a weird person, so who knows...

[Tony Li]

The custom fields feature works similarly to the way you suspect. But it's more trouble than it's worth unless you're using an external editor such as articy:draft because you need to manually assign a unique value to every single dialogue entry. The feature was added for the Disco Elysium team, who are using articy. Every node in articy has a unique TechnicalName field, and they wanted to be able to refer to nodes' SimStatus by TechnicalName.