-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Deserializing world only works within the same process as the serialization #40
Comments
Thank you! I also think I already know why. Because the client does not know which components are registered. If you manually register all components in the correct order, it should work. There is only one small problem. You have to make sure that the order of the components is identical. There is not really a way around that. I can't think of a more elegant way to solve this... e.g. Server 1: Builds world, registers Transform, Velocity, Sprite We have to see how to fix this. Due to compile-time-statics there is not much room for maneuver here. |
Alright, that's an acceptable workaround for my case, thanks for the quick reply! |
I think a good way to solve this would be to attach a hash of the components and their order, so at least it says order is wrong, and not just crash. |
I store the list of registered components along the save file. When loading that I clear the ComponentRegistry (had some reflection hacks because removing a type doesn't subtract some counter (I forget right now)) and load those types from the save file first, and then any new unregistered types. |
I'm trying to serialize and deserialize a World, using Arch.Persistence. If I do it in the same process, it works fine. But if I send that byte array over to a different client and try to deserialize there, all hell breaks loose. In order to not use some pipe or networking I just write the byte array to a file and read it again after restarting the app, as a simple repro scenario.
In my FlaxEngine project, this causes the client to crash with a
the thread tried to read from or write to a virtual address for which it does not have the appropriate access
error inside the minidump.
In the repro C# console Net7 project I get
Repro steps:
The text was updated successfully, but these errors were encountered: