serialization question

k

I've been having a problem where a cap I'm working on

suddenly the Preview exe's crash immediately

once it happens once, it's done, no undoing or removing of events will fix it.

this coincides with the Cap being unloadable

if I exit construct, and try to load the cap again, it just hangs.

also, if I change the events back to a noncrashing config manually (not through undo),

it does not fix the problem. Once it happens once, the cap is corrupt,

or so it seems

I will make a bug report if I can isolate what's causing it

I'm using 99.3 and originally I thought this happened only when I attempted to load caps after changing the plugin in between saving and loading, but that isn't it, sometimes it's in the middle of editting the cap

first, is this a known issue with 99.3?

if not, could this be caused by not Serializing data?

as I understand it, I only need to serialize data if it is something edited in properties, for instance.

if all the plugin variables are set through events or conditions, it doesn't affect the edittime at all, so it need not be edittime serialized, correct?

Well if your plugin crashes don't submit a bug to the tracker, fix your plugin If your plugin has a bug in its serialization code, though, it can cause other parts of Construct to crash after your plugin code has finished running, which is probably what's happening here.

You can't recompile an edittime plugin while Construct is open (the compiler can't write to the CSX file because construct has loaded it). However, you can recompile a runtime plugin, as long as the loaded serialize data is backwards compatible. If it's not, it will crash on preview, and as above, it might not crash in your plugin, but your plugin will have caused it. It can be very tricky to debug these problems.

If you change your edittime plugin's serialize data while Construct is closed, it must be backwards compatible. If it's not, all .cap files using that plugin that already exist become invalid and will not load with your new plugin. Have a look at some other plugins to see how they do this. Here's a quick example:

Say your plugin initially uses this data to save:

void EditExt::Serialize(bin& ar)
{
	int Version = 1;
	SerializeVersion(ar, Version);

	if (ar.loading) {

		ar >> myint;

	}
	else {
		
		ar << myint;

	}
}[/code:2etwz5zu]

Suppose you want to add a new value, 'myfloat', to the saved data.  Increase the 'version' number to 2.  The loading code must still support version 1 (to still be able to load old .caps with the plugin's old format).  The saving code only needs to save the current version.  So you'd change it like so:

[code:2etwz5zu]void EditExt::Serialize(bin& ar)
{
	int Version = 1;
	SerializeVersion(ar, Version);

	if (ar.loading) {

		ar >> myint; // both versions 1 and 2 load a myint first

		if (Version >= 2) // version 1 doesn't have this
			ar >> myfloat;
	}
	else {
		
		// Save the current version
		ar << myint << myfloat;

	}
}[/code:2etwz5zu]

If you don't do it fully backwards compatible like that, all old .caps using your plugin break and will fail to load.  Again, lots of plugins and behaviors use versioning, so check out some on CVS.

Two important points:
[ul]
	[li]In this case, you must initialise 'myfloat' to a default value in the edittime constructor.  If you are loading an old .cap (using Version 1), 'myfloat' will contain undefined data unless it has a default in the constructor, because otherwise nothing is ever written to it.[/li]
	[li]The runtime loading code [b]must support all versions[/b] of the edittime serialize data.  If you open an old .cap using Version 1, and immediately hit Run, the runtime is passed the Version 1 data ([i]without[/i] 'myfloat').  Again, it will crash on preview if you don't support the old version.  So you basically need the same loading code in OnCreate() as you have in the EditExt :: Serialize() loading code.[/li]
[/ul]

thanks ash

but what I meant was

let's say that all my values are set either on OnCreate, OnFrame

or through Actions, and no values set through properties

I wouldn't need any Edittime serialization at all, right?

If you don't need any of the edittime data at all, then no, you don't need it - but you should still at least serialize the Version number, in case you later decide you do need some properties or data. If you release a plugin which doesn't serialize anything, it instantly becomes permanently impossible to ever add any new data to that plugin, because you can't distinguish between versions