I'm just curious if you could explain if it's possible to serialize the data of script object properties, and if so; how? Primitive objects are easy, and I think I figured out handles, but I'm not sure how to do non-handle members of complex types. What I want to do is make it possible to recompile scripts in my engine without losing too much state. My idea was to scan through the script objects, store their properties (make a copy of the necessary data), recompile, and then write the members that still are available back. Is this at all feasible? Maybe type ids and stuff will go all haywire so there's no way to easily map it back?

Yes, is should be possible to serialize the data of script object properties.

Keep in mind that AngelScript stores all non-primitives on the heap, including members of script objects. The script object member that holds another script object is actually just a reference, and should be handled as such.

You'll need to translate the type ids, because there is no guarantee that the type ids will be the same on two different script compilations. If you store the types as script declarations, you can then find the correct type id by asking the engine at load time.

You will not be able to serialize the script contexts, so you need to make sure you do the serialization at a moment where no script is currently running or suspended. (Maybe in a future version I'll implement support for serializing the contexts as well).

Regards,
Andreas

Quote: Original post by WitchLord
Keep in mind that AngelScript stores all non-primitives on the heap, including members of script objects. The script object member that holds another script object is actually just a reference, and should be handled as such.

Do you think you could elaborate a bit more on what's returned from GetPropertyPointer? In the case of primitive members it seems to be just a direct pointer to the data, and in the case of handles it's pointer to a pointer to the data, right? But I haven't really managed to figure out what it points to in the case of non-handle members. (I realize that, as you say, they're actually just references, but... Somehow I can't figure out how it references it. I might just be blind tho. :))

Quote: Original post by WitchLord
You'll need to translate the type ids, because there is no guarantee that the type ids will be the same on two different script compilations. If you store the types as script declarations, you can then find the correct type id by asking the engine at load time.

Is this also true for types registered in the engine configuration? I mean types exposed from C++?

Thanks in advance
/Anders

Sorry for the confusion. GetPropertyPointer() returns the pointer to the actual object (it dereferences the internal reference stored in the object structure). I had to peek at the implementation of the method to refresh my memory ;).

Yes, the type id for registered types is also not guaranteed to be the same each time (though obviously if nothing changes in the application, then it is very likely that they will indeed be the same).