New database format in the editor and its possible benefits

I already know the editor will need some major refactor in future and I'm currently trying to design it in a way that gives us the most features and benefits.

One issue with the current design is that object IDs are unique only in a specific project. When I add two different projects into the game, they can both add e.g. a completely different NPC, but with the same ID. Those projects didn't know about each other so far, so there was no way for them to pick a globally unique IDs. I'm currently using a cheap workaround in the backend to solve this problem, but it won't do in the long term.

One idea is to give each project a unique range of IDs to use. Currently the game has about 30k objects, and the highest ID is 30k-ish (because there are some holes). The highest ID allowed by game is 2bil, but in the editor we don't have any limitations. In the editor we could always allocate IDs greater than that, then in the backend, when applying the project onto the game files, check if it's > 2bil and pick a normal id for it instead. This would be also a nice indication of whether we're adding a new object, or modifying an existing one -> in the current project format it's quite hard to tell programatically. Also, to give each project a unique ID range, we could assign ids as follows: ID = 2bil + project_id * MAX_NEW_OBJECTS_IN_PROJECT.

Possible benefits of this? We could base our own projects on top of others' work. This is actually required -> we want to see content from other people that was approved and merged.

Then we have another problem that Entei has recently run into. When you do your changes thinking you're in project X, but it turns out you were in project Y, you most likely have to switch to project Y and do the same changes again. Due to autosave, project X also got all those unwanted changes and you might need to undo them manually. I imagine it can be a PITA.

Can we do better? Since projects need to be "stackable" anyway, we could consider each save (so about 5 or 15 minutes worth of changes) to be a sub-project of its own.

Then we end up with a project stack looking like this:

A changeset would be a list of modified objects. If you changed some NPC names, a changeset would contain IDs of all those NPCs as well as their new names.

After 5 minutes, the changeset gets uploaded to the server (because of auto-save), and a new, separate changeset is created.

All changesets would be stored both on the server, and locally in the browser. The user could browse all changesets and possibly revert various changes, restoring e.g. NPC's name from a certain timeslot. Or if we make a stupid change by mistake, we could just restore the state from 5 minutes before.

As for browsing changes, we could even have a nice GUI:

Since we store those changesets separately, they could be easily moved to other projects.

This would also allow for editing multiple projects at once (in different browser tabs, that is). Since most of the data would be stored server side, and the client will only need that last (unsaved) changeset, which can't be too big.