Jump to content

Part ConfigNode persistence of UPGRADESAPPLIED.


Recommended Posts

I have a part module, "HeavyHelixSampleStorage", that inherits directly from PartModule. The class has a field called "MyValue" that is marked with KSPField (isPersistant= true).

Everything works the way I expect it to, except for UPGRADESAPPLIED. The module node in the .sfs file may look like this:

MODULE
{
  name = HeavyHelixSampleStorage
  isEnabled = True
  MyValue = 0
  stagingEnabled = True
  EVENTS
  {
  }
  ACTIONS
  {
  }
  SAMPLES
  {
  }
  UPGRADESAPPLIED
  {
  }
}

Once I have called the inherited OnSave I have a node with name, isEnabled, MyValue, stagingEnabled, EVENTS and ACTIONS.

Cool, that is everything taken care of except for SAMPLES, which on purpose isn't marked with the KSPField attribute, and UPGRADESAPPLIED.

My save logic so far has been to add/save the 'missing' items. For some reason it seems that UPGRADESAPPLIED breaks that logic; the node is not added in the inherited OnSave, but it is added later on, resulting in two nodes if I have already added one.

To me it appears it might be a bug, but it may also be that it is just quirky part upgrade behaviour; any insights?

Edit: I decided that it is weird enough to put on the bug tracker (marked as feedback).

Edited by Rodhern
spelling; bug tracker
Link to comment
Share on other sites

The UPGRADESAPPLIED node is KSP's way of keeping track of what part upgrades have been applied to the module.  You shouldn't need to touch it yourself.  I don't quite see why it would be a problem but maybe I'm not understanding what you're trying to do here...

Link to comment
Share on other sites

1 hour ago, blowfish said:

The UPGRADESAPPLIED node is KSP's way of keeping track of what part upgrades have been applied to the module.  You shouldn't need to touch it yourself.  I don't quite see why it would be a problem but maybe I'm not understanding what you're trying to do here...

Well, technically you are correct, it is not a problem, it is more of a nuisance.

In my naive implementation my custom modules would store the node information in memory when loaded, then write the in-memory information when saved. This way any information changed in the meantime would automatically make its way to the persisted node. In the naive implementation PartModule.OnSave (the inherited bits) would fill out everything except my custom data, so I just had to not overwrite the already added values and nodes and all was good. With UPGRADESAPPLIED in the picture I have to (at least indirectly) keep track of which data is custom data. Just seems like an unnecessary complication to me, but sure, it is manageable.

Link to comment
Share on other sites

4 hours ago, blowfish said:

Wait, but why do you even need to do any custom loading/saving?  KSP does that all automatically.

You make a good point; most people probably won't be bothered this 'issue'.

It is not so much that I need to do custom load/save, it is more that I find it more natural or elegant. In case you are wondering, I am happy to give an example:

My part module is a container that is supposed to store collected 'asteroid samples'. When you think about it, there is really no good reason why the part module needs to know every little data detail of an 'asteroid sample' at compile-time. In theory the part module couldn't care less, if somewhere down the road it is asked to store a sample with data like "colour = green" or "scent = odourless", even though those properties do not exist in the present code.

Link to comment
Share on other sites

2 minutes ago, blowfish said:

Sure, save whatever custom data you want.  But why try to save things that KSP is already saving for you?  Whatever you do is likely to conflict with what KSP is doing at some point in time and cause issues.

I think we agree on 90%+ of the stuff here. Obviously I don't want to save the stuff that is already saved for me.

Looking at "EVENTS", "ACTIONS" and so on, it seemed to me that there was a sensible pattern there (that PartModule.OnSave takes care of those). Then "UPGRADESAPPLIED" seemed to break that pattern. At first I was annoyed, and then I got curious if maybe there is a good reason "UPGRADESAPPLIED" can't fit the 'old' pattern. That's all.

Link to comment
Share on other sites

I do not understand the issue. As @blowfish says. You should not need to do custom saving, loading, etc.
KSP will do it for you if you are inheriting from PartModule.
The upgrades system is not breaking a pattern. It follows a different pattern. Upgrades are applied and loaded and saved differently because they must apply after everything else.
I still don't understand your issue. The inherited module will do the saving and loading for you. and if you use the PartModule attributes on your fields it will save and load them for you.

Sounds to me you would like to have something in a set way, that isn't something you can control when modding someone elses code. So you have to live with it and use what it gives you.

Link to comment
Share on other sites

3 minutes ago, JPLRepo said:

Sounds to me you would like to have something in a set way, that isn't something you can control when modding someone elses code. So you have to live with it and use what it gives you.

Yes, I think you hit the nail on the head there. I would prefer to have something in a set way, and I do realize that it is not my decision to make.

3 minutes ago, JPLRepo said:

The upgrades system is not breaking a pattern. It follows a different pattern. Upgrades are applied and loaded and saved differently because they must apply after everything else.

Thank you for taking time to answer that there is indeed a reason for the different pattern.

Can we at least agree, that if there had not been a particular reason for a different pattern, then you could as well use the pattern that is most pleasing to the customer/modder/player ?

Link to comment
Share on other sites

2 hours ago, Rodhern said:

Can we at least agree, that if there had not been a particular reason for a different pattern, then you could as well use the pattern that is most pleasing to the customer/modder/player ?

How is that doing everything by hand is most pleasing ? Asking everyone to write code just for handling the basic task of loading/saving seems to be less pleasing. If you do not like how it work then write your own partmodule implementation and have fun with it (and don't complain that your mod does not work with others mods).

Edited by sarbian
Link to comment
Share on other sites

5 minutes ago, sarbian said:

... Asking everyone to write code just for handling the basic task of loading/saving seems to be less pleasing. ...

I think you misunderstand what I am trying to say. I completely agree with your statement. I wasn't trying to say that doing it by hand should be the main way.

I noticed a pattern/behaviour that would allow several easy ways of implementing part module load/save, and noticed that a particular node got in the way. Now JPLRepo have explained that the upgrades system makes it so that it is not easy to do it the way I suggested. I am sure that sort of conclusion is obvious to those of you that are very familiar with the code. If I don't ask if a feature can be improved you probably wouldn't even have guessed how potentially confusing it can be for someone that only knows of the KSP code by a number of API signatures and some forum posts.

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...