Fata morgana

After all, hsk won't be able to work with all sectors at once (for the live feature to work [testing, editing, viewing]). Simply because several objects (in different sectors) can map to the same object (for instance, sector roots).
If a node references the sector root, then it must be the sector root of the sector the node is in
Yeah, but each sector root, deserialized from sector, requests a sector root with ID 1. (If the sector is not common, ie. 0)
This is because the level buffer contains only 2 sector root objects (the second gets overwritten by the new sector root, on sector load).
So, if I were to load all sectors, each sector would have a sector root pointing to the one with ID 1 (except sector 0). And sure, I could manually overwrite them, but there could be more of such instances + the K code is in the hands of the user.
You are trying to keep it unmodified?
I call these sector objects, which get requested while reading the level file, *sector dependent*
I don't think it's impossible to figure out the *sector dependent* references and the benefit is that you can edit multiple sectors at once. Also, what if you are editing sector, but want to copy an object of or look at another sector, then what would happen in hsk?

In the XXL-Editor, if there is a reference that is *sector dependet* its binding (figuring out the object) is postponed and pretty much all objects can be figured out, but I can understand if it breaks compatability
Note that you will have to patch the level files anyway to move the "DRM" values back into them, maybe you could also implement a new referencing system?
Yeah, I can't do that- because the game could access some of those objects, and the references would be invalid. And besides, what would be the "current sector"?
Not that I'm trying to make the editor "live", that is, you can edit while essentially playing the game. If it were static, nothing would access the references, one could fix it the same way as the XXL-Editor.
That won't be a problem, one just replaces the values. Right?
It's possible, by patching the whole level file & replacing every sector dependent object ID with its proper ID.
This breaks compatibility though.
I guess what I could do, is read it, patch it like so, and if the user desires, output a compatible version? Maybe that's what the devs did too?