issue with unique IDs

[urrmurrmur]

Hi Tony,

I have a strange issue with DSFU that I hope you can help me with.

My project is set up to use different databases. I have one per scene, plus a master database that contains information that should be shared between scenes. I load both databases uses an Extra Databases component (the master DB in the Dialogue System Controller component, the scene-specific DB in the Extra Databases component).

When initially setting up my project, I had not run the unique id tool yet, since at that point there was no master DB with shared data. At some point I introduced it, gave every DB a base ID, and ran the unique ID tool.

This somehow introduced a bunch of issues in my DB where actors were no longer tied to dialogue states, and I had to manually reassign them. Took some doing, but nothing crucial broke. More importantly though, it seems like I still have overlap in IDs, particularly with some variables.

Case in point, I have a DB (DialogDb_Scene6) whose base id is 60000. My master DB has a base id of 0. The Scene6 DB had a variable with id 270094, which is a strange id for a DB with base 60000, but ok, I don't know how the system works behind the scenes. I recently added a variable to the master DB, which somehow also got the id 270094. This broke a bunch of my conversations, of course, since they are now incorrectly using the master DB's variable instead of the one from the Scene6 DB. Aside from that, the variable completely disappeared from the Scene6 DB.


Do you have any idea what I could be doing wrong that is causing this behaviour? I had expected that the unique ID tool would simply append an incremental id to the base id for each DB, meaning that my master DB would have id's going from 1, 2, 3, 4 etc., while the Scene6 DB would use id's like 60001, 60002, 60003, etc. That doesn't seem to be what's happening though.

Should I run the unique ID tool again? It's definitely possible that I did something wrong the first time around. I'm a bit apprehensive though, since a bunch of stuff seemed to have broken last time around, and I don't want to risk having that happen again.

[Tony Li]

Hi,

Are you using a version control system such as Git or Unity Version Control? If so, you can run the Unique ID Tool and then compare the differences between the old and new versions of your database in your version control tool. I don't know your database element got an ID of 270094. I'll post a patch here today that has some improvements to the Unique ID Tool that are coming in version 2.2.51. Also, what version are you currently using?

[urrmurrmur]

I'm using 2.2.47 at the moment. And yes, I do use Git.

I'll make a backup of all the database files and run the unique id tool again tomorrow, to see what happens. I'll keep you posted.

[Tony Li]

Hi,

Sounds good. Please also give this updated Unique ID Tool patch a try:

DS_UniqueIDToolPatch_2025-03-04.unitypackage

If your databases have base IDs of 0 or 1, it will assign unique Base IDs in increment of 10000 and try to keep assets in the database within this Base ID range (e.g., 10000 - 19999).

Back up your databases before using the tool. After using it, check your databases to make sure they look correct.

[urrmurrmur]

Question before I do that: I now have one DB with a base id of 0, the others already have one assigned that I would like to keep. I essentially used the increments of 10000 myself, corresponding to my scene numbers (so scene 1 is 10000, scene 13 is 130000, etc).

The way I understand your explanation of the patch, you need to give ALL of your DBs a unique id of 0 or 1, and then it will behave as described. But what will happen if only one has a base id of 0, and the rest is 10000+?

[Tony Li]

In that case, it will keep the other base IDs intact. You don't need to set them back down to 0 or 1. Keep them at 13000, etc.

[urrmurrmur]

Hi Tony,

Apologies for not responding for a while, I was working on other stuff.

So I ran the unique id tool (patched), and I got the same issue as last time: some, if not most, conversations lost one or both of their actors. I think I could theoretically reassign them all through some find-replace fidgeting, but this is likely a bug in the tool, so I thought you'd be interested to check it out.

Example below.

THE FOLLOWING SCREENSHOTS ARE BEFORE RUNNING THE CONVERSION TOOL

These are two actors from one of my DBs before conversion:

actor_robin.png (19.26 KiB) Viewed 1140 times

actor_maya.png (18.61 KiB) Viewed 1140 times

This is a screenshot of the DB properties:

conversation_properties.png (25.63 KiB) Viewed 1140 times

And here's a quick overview of the conversation itself, where the pink states have Robin as the actor and the grey ones have Maya:

conversation_overview.png (315.8 KiB) Viewed 1140 times

THE FOLLOWING SCREENSHOTS ARE AFTER RUNNING THE CONVERSION TOOL

Here are the two actors again. It looks like their IDs didn't change.

actor_robin_AC.png (13.65 KiB) Viewed 1140 times

actor_maya_AC.png (13.05 KiB) Viewed 1140 times

The conversation properties. Note the actors have disappeared.

conversation_properties_AC.png (18.38 KiB) Viewed 1140 times

And the conversation overview. None of the states have an actor or a conversant assigned anymore.

conversation_overview_AC.png (284.54 KiB) Viewed 1140 times

If you'd like, I can send you my DB files so you can experiment with them. I'm not really doing anything special that I know of though.

[Tony Li]

Hi,

If you could send your DB files to tony (at) pixelcrushers.com, that would be great.

If not, are there multiple Robin actors with different IDs across the databases?

[urrmurrmur]

I've sent you the files.

And yeah, certain (if not most) actors are defined in multiple DBs, and Robin is one of those. I chose to do it like this because actors might be player characters in one scene, and NPCs in another.