PARTDATA ConfigNode in save files?

[Diazo]

Alright, I was going through the various save files (.craft, .sfs) this morning, and I noticed that every part has a PARTDATA config node in it's save file.

This is just before the MODULE config node for that part and is present on the same level along with the ACTIONS and EVENTS config nodes.

However, PARTDATA is always empty (or was in the parts I checked), and I can't find any references to it in the object browser in Visual Studio. Additionally, I can not recall any mention of it ever here on the forums.

Does anyone know what this is?

My first thought was for storing science experiment data, but that is in the ModuleScienceContainer partModule.

D.

Edited December 26, 2014 by Diazo

[xEvilReeperx]

Good find! Looks like it's a way for us to store persistent per-part data for custom (or config-modified) parts that doesn't necessarily require adding a PartModule. You subclass Part to use it:

class PersistentPart : Part
{
    public override void OnSave(ConfigNode node)
    {
        base.OnSave(node);
        node.AddValue("ThisValue", "That I saved");
    }
}

PART
{
name = probeCoreSphereTest
module = PersistentPart
...
}

[snip]
	attm = 0
	modCost = 0
	modMass = 0
	modSize = (0.0, 0.0, 0.0)
	EVENTS
	{
	}
	ACTIONS
	{
	}
	PARTDATA
	{
		ThisValue = That I saved
	}
[/snip]

Data is also saved with .crafts from the editor (I checked) so that could be quite handy

[Agathorn]

My lord, and I just built an entire complex system to do almost the same thing.

[Diazo]

Wow, that sounds like it is going to make my life so much easier.

Off to test.

D.

edit: This is actually a horrendously dangerous piece of code that I am going to strongly suggest only part creators use, it's a huge can of worms if someone like me who is editing existing parts uses it.

This reason is that in EvilReeper's example above, that is changing the part.cfg file of the part. To use this I would have to make a custom extended Part class and change module = part to module = MyPersistentPart which means no one else could use this as there can only be one module= line in a part.cfg file.

To work as I need it too, I would have to change every part in the game to MyPersistentPart and if someone else tried to use this, only one of us can and it will lead to people fighting over who has the right to use it.

Which is why it is safe for part creators, they know there is no one else fighting to determine what the module= line says, they get to define it as they are making the part.

Unless someone with more C# experience knows a workaround, I'm staying far away from this feature.

edit the 2nd: This is actually the old module system that the partModule system replaced. Documentation link here. As such, I'm not sure this is something we should still be using.

Edited December 27, 2014 by Diazo

[xEvilReeperx]

edit the 2nd: This is actually the old module system that the partModule system replaced. Documentation link here. As such, I'm not sure this is something we should still be using.

You've always (well, that I've been here) been able to subclass Part but as far as I can tell the PARTDATA segment is new. If you were writing a Part subclass before, you'd also need a PartModule to deal with storing persistent data. I suspect PARTDATA was added to support CompoundPart...

And yeah, you definitely don't want to replace every part instance with your own Custom parts only