Figure out deserialization mapping of non-public fields about bosphorus

[bobsummerwill]

Yuck. Got some more deserialization working to get the fileIDs at least read in, but it's an abomination!

a369f61

kitsilanosoftware/BosphorusEngine@1d8ef29

I think that the file-format that Unity are using here is really non-idiomatic YAML. In particular, this in GameObject:

m_Component:

• 4: {fileID: 1099934815}
• 20: {fileID: 1099934814}
• 92: {fileID: 1099934813}
• 124: {fileID: 1099934812}
• 81: {fileID: 1099934811}

Actually appears to be a sequence of mappings of mappings, and the outer mapping is NOT using a consistent key name. The key value (the object type) is actually being used as a key. Maybe this is some manifestation of their underlying C++ code? Whatever the case, it is just horrible.

I did something horrific to get the data read in, and will have to try to simplify it now I now what the events are being mapped as.

Or maybe I will just shelve that horror for now and move onto getting the runtime fixing up the references and actually running a bit.

I see that the YAML also has fileIDs which aren't listed in the YAML itself, which are presumably for external assets, like the script code, meshes, etc.

I found something online describing the hashing used for fileID, which is some hash of the object type name and object name concatenated.

[ztzg]

Hi Bob,

I'll do something quick-and-dirty for now, and then clean it up later.

I want to get a running tiny Unity scene with a MVVM abstraction soon,
based on deserializing EmptyUnity2DProject, which just has a camera and a
cube and those various "settings" objects.

Sounds good!

Yuck. Got some more deserialization working to get the fileIDs at
least read in, but it's an abomination!

a369f61

kitsilanosoftware/BosphorusEngine@1d8ef29

Well, one step at a time :) This doesn't look bad at a glance; the only
mistake would be to not schedule a clean up once the required mechanics
are better understood.

I think that the file-format that Unity are using here is really
non-idiomatic YAML. In particular, this in GameObject:

m_Component:

• 4: {fileID: 1099934815}
• 20: {fileID: 1099934814}
• 92: {fileID: 1099934813}
• 124: {fileID: 1099934812}
• 81: {fileID: 1099934811}

Actually appears to be a sequence of mappings of mappings, and the
outer mapping is NOT using a consistent key name. The key value (the
object type) is actually being used as a key. Maybe this is some
manifestation of their underlying C++ code? Whatever the case, it is
just horrible.

C++: most probably. The serialization format doesn't seem to have been
"designed," but rather to stem from their internal object model.

I did something horrific to get the data read in, and will have to try
to simplify it now I now what the events are being mapped as.

Or maybe I will just shelve that horror for now and move onto getting
the runtime fixing up the references and actually running a bit.

I, for one, would try to get something useful running ASAP, because
I'm sure you will discover some other warts while doing so. Refactoring
is likely to be more successful with a better knowledge of the graph :)

I see that the YAML also has fileIDs which aren't listed in the YAML
itself, which are presumably for external assets, like the script
code, meshes, etc.

I found something online describing the hashing used for fileID, which
is some hash of the object type name and object name concatenated.

Really? "fileID"s seem to be 32-bit integers; they would need to
somehow cater for collisions. Or are you talking about the other,
longer hashes?

Cheers, -D

[bobsummerwill]

Ah, yes, I misspoke slightly. The reference I saw was for this "fileID" only ...

m_Script: {fileID: -1167294237, guid: 2b16a1acf52a2a64e916f8a9e6d5df31, type: 3}

http://forum.unity3d.com/threads/yaml-fileid-hash-function-for-dll-scripts.252075/