Persistent Guid are not a thing

[linuxgurugamer]

I've been going crazy here for a while.

I'm using Guids to identify a number of things, but they keep getting reset to empty.  I finally figured out that while you can create a persistant Guid, like this:

        [KSPField(isPersistant = true, guiActive = false)]
        public System.Guid travelbugId;

it doesn't load it.  So I'm having to save it as a string, and then after loading, convert that string back to a Guid.

Am I missing something here, or is this just one of those things that was never implemented?

What seems to work is this:

        public System.Guid travelbugId;

        [KSPField(isPersistant = true, guiActive = false)]
        public string travelbugIdString;


void Start()
{
	travelbugId = new Guid(travelbugIdString);
}

Kind of annoying, because I now either have to replace all my Guids with a string created from a Guid, or add extra code to convert a Guid to a string for saving, and then more code to convert it back

Either way is not optimal

[Dagger]

That's because the "BaseField" class doesn't implement specifically the GUID type in it's "Read" method.

[Shadowmage]

On 9/29/2018 at 10:09 PM, linuxgurugamer said:

I've been going crazy here for a while.

I'm using Guids to identify a number of things, but they keep getting reset to empty.  I finally figured out that while you can create a persistant Guid, like this:

        [KSPField(isPersistant = true, guiActive = false)]
        public System.Guid travelbugId;

it doesn't load it.  So I'm having to save it as a string, and then after loading, convert that string back to a Guid.

Am I missing something here, or is this just one of those things that was never implemented?

What seems to work is this:

        public System.Guid travelbugId;

        [KSPField(isPersistant = true, guiActive = false)]
        public string travelbugIdString;


void Start()
{
	travelbugId = new Guid(travelbugIdString);
}

Kind of annoying, because I now either have to replace all my Guids with a string created from a Guid, or add extra code to convert a Guid to a string for saving, and then more code to convert it back

Either way is not optimal

 

KSP will not respect fields for persistence/serialization unless the classes were included during compilation -- at least that is how it plays out for user-defined classes.  Likely more of a Unity engine issue than KSP per-se....

For example the stock Propellant class serializes just fine.  Create an identical class (CustomPropellant, or w/e), and load it through a mod .dll, add a field/member to a Part-Module with proper decorations ([Serializable] or w/e), and it will not serialize (methods are never called).

Yes, extremely annoying.  Breaks all sorts of things.  Makes for ugly code.  Not sure that it can be fixed though....

[linuxgurugamer]

2 hours ago, Shadowmage said:

 

KSP will not respect fields for persistence/serialization unless the classes were included during compilation -- at least that is how it plays out for user-defined classes.  Likely more of a Unity engine issue than KSP per-se....

For example the stock Propellant class serializes just fine.  Create an identical class (CustomPropellant, or w/e), and load it through a mod .dll, add a field/member to a Part-Module with proper decorations ([Serializable] or w/e), and it will not serialize (methods are never called).

Yes, extremely annoying.  Breaks all sorts of things.  Makes for ugly code.  Not sure that it can be fixed though....

If it hadn't worked at all, that would have made sense.  The thing which threw me was that it actually did save the data to the file, it just couldn't load it.

[Shadowmage]

2 hours ago, linuxgurugamer said:

The thing which threw me was that it actually did save the data to the file, it just couldn't load it.

Interesting....

I wonder if KSP's serialization simply uses the .ToString() and .Parse() functions for a given Type?   Does Guid.class have a .Parse(string) method in it anywhere?

Or perhaps the 'serialization' uses .ToString(), but the 'deserialization' uses, as @Dagger says, some sort of hard-coded switch-statement or dictionary based lookup....

[Dagger]

9 hours ago, Shadowmage said:

Interesting....

I wonder if KSP's serialization simply uses the .ToString() and .Parse() functions for a given Type?   Does Guid.class have a .Parse(string) method in it anywhere?

Or perhaps the 'serialization' uses .ToString(), but the 'deserialization' uses, as @Dagger says, some sort of hard-coded switch-statement or dictionary based lookup....

Yep. Thats it

For writing it uses a simple ToString (which makes sense as config nodes are string based) But for reading it uses a "if stair" (as Types don't accept switch statements) and it can only read basic types (bool, int, float, vector, etc).

You can override this with reflection or some other libraries and implement your own read, it might be a bit dirty but it will work.