Manage Unique Asset IDs
How It Works
Each DataEntity has a Unique ID which is a Key that Vault uses to look it up in it's data dictionary. This makes lookups super fast plus it keeps the data sustainable and supportive of persistence. This is better than the previous Index based lookup which may change it's value if you added some data ahead of it and create problems for persistence.
So what do you need to know about Unique Keys / IDs?
The Key is assigned when you create the
DataEntityin the Vault Dashboard.The Key will never change unless you Hard Reload the Database or change it manually.
The Key is assigned as the next available ID, which is ticked by a local editor variable.
The iterator starting point value can be assigned manually in the Vault Dashboard footer.
The Dashboard will never assign duplicate IDs! When new content is added, it is checked against the existing data for overlap to guarantee it is unique.
Reconciling Multiple Developers And Version Control
Consideration must be given to projects with multiple developers actively adding to the database in separate editor sessions. Each user should set their Key/ID iterator value to a value that gives them space to work without overlapping other developers on the team.
For example, consider this scenario:
Sam and Alex are working on separate workstations on a project.
Sam adds several new weapons and his editor assigns them the next available, valid Keys of 12, 13 and 14.
Alex adds several new configurations for characters, and the DB assigns them the next available, valid Keys of 12, 13, 14.
Sam and Alex commit their work.
There are no merge conflicts, but the DB now has multiple entities with Keys for 12, 13 and 14.
They pull the latest, and there is a DB dictionary conflict.
Technically the system has done no wrong, but how can we resolve the overlapping IDs? Since the system cannot know what others are doing until they receive the pull, there's no safe way to resolve this automatically without some risky assumptions since we don't know which item should keep their Key and which should have a new one assigned to it without risking a break in the project's persistence systems.
Now, You can manually resolve this in the design stage by changing the Key variables and committing the change but the ideal solution is to simply assign each developer a starting value for their data.
For example, you can safely set Sam's starting Key in their editor to be 1000 and Alex will use 3000. This guarantees that Sam's new entities will be given numbers starting at 1000 and iterate up, but Alex will start at 3000 and iterate up. They have significant space to create thousands of DataEntities with no risk of overlap.
Set your Local Unique ID
Each developer on the project should set their own unique Key / ID starting point! Vault will use this as a starting point when creating new entities.
You can use the Upgrader to upgrade any unset IDs at...
Tools/Cleverous/Vault/Data Upgrader
If you are near production release and would like to flatten the DB ID's for some reason then you can perform a Hard Reset on it and every DataEntity will get a new Unique Key. This will break persistence if you have existing save games and is generally not advisable, but the function is available anyway as we need it for legacy version DB upgrades so feel free to use it however you see fit.
But I'm Working Solo!
Well then you don't need to worry about any of this unless you're working on multiple computers! If you're working on only one computer and using version control from there, then your Vault Dashboard will never assign duplicate Keys. If you're using multiple computers, always make sure that you commit and pull the latest before and after working on the project or just assign each computer a unique starting point in the Dashboard footer and never worry about it.
Last updated
