Closed Gordon-Dry closed 2 years ago
Closing it as "invalid" (hate this term) because the whole Settings became screwed up when I added customisation options to 3rd parties without a way to patch them using MM!
About the ADDON BINDER, it's a KSP idiosyncrasy. There's nothing I can do about. It affects everybody, from EVE to MechJeb (that besides not loading DLLs, triggers 3rd parties to load them under its call chain).
The "Could not found model" is a hint that some Parts are incomplete and can't be used by DOE. This is something to be solved by ROHS. Every part on KSP should have a model.
@Gordon-Dry ,
Having tagged this as 'invalid' doesn't means that it's meritless (it's the reason I hate the term "invalid"). So I will try to explain some things here as a (hopefully) better response to the Report:
persistence.sfs
GameData
is also bad (besides less worst), because:
Studying carefully the KSP Scene since the inception (I'm a maniac archivist, I go deep trough when I research the past history of everything! Including KSP itself), I concluded that the current dudes dictating rules on KSP missed some huge opportunities - worst, actively contributed to user's data loss on all this time!
EVERY SINGLE SAVEGAME LOSS can be tracked down to a problem on the current Modus Operandi of this Scene, and not to the bug itself. Bugs happens all the time, to highly paid developers (see Boeing!) to the open source enthusiast burning the midnight oil for free before going to bed.
Bugs are not the problem. Ignoring they will happen is.
The best (at this moment, at least) solution I found to all of these problems (and some minor ones I didn't mentioned) is:
GameDatabase
PluginData
inside your add'on folder on GameData
.
PluingData
. It's completely out of the GameData scope, are not affected by any automated installation tools and so, the data there are 100% safe from being tampered.persistence.sfs
is suicidalsaves\<name>\add-ons
would accomplish the task - safer and simpler than any other alternative I had studied in the past.saves
, so at least on this aspect this solution is viable now.Additionally, all that mess is not handed by DOE (or TweakScale, or anything else) but on KSPe. By using KSPe I can deliver different deployment models customised to the end-user (or distribution channel) specifications. So I can just develop things on the Add'On and any local details will be handled by a customised KSPe DLL on the target appliance. (and this is why the report is "invalid" on DOE, these problems are tackled down on KSPe).
Fell free to extend the conversation on this issue, even by it being "Closed". The "Closed" status (another term I find lacking) means "this is not something I will further work here", and not "This is something I want to ignore from now one". I don't see issues on a github repo as a bad thing, I don't use them as a Quality Metric (and I don't want any relations with anyone that does that, so it's a win-win for me), so don't mind keeping posting here or in any other issue you open in the future (being it closed or not). You will know when I'm not willing to further discuss any subject, so if you don't know if I'm willing to discuss something, it's because I do! ;)
(keep in mind that sometimes I may take a long time to respond due Real Life® issues - or sometimes even forget about - pinging me usually does the trick!)
Cheers!
As I'm used to have backups of settings which are usually inside GameData/blahblah/PluginData I'm not used to just look into the main KSP folder's PluginData folder. I can try to hammer into my brain: Lisias == PluginData
What I see in 2.1.1.10 experimental
and the settings are not saved, neither in DistantObject\Plugins\PluginData\Settings.cfg (which is preferred) nor inside the persistent.sfs (which is not preferred).