ADDON BINDER and others
Gordon-Dry opened this issue · 4 comments
What I see in 2.1.1.10 experimental
[LOG 21:53:30.670] [AddonLoader]: Instantiating addon 'SettingsGui' from assembly 'DistantObject'
[LOG 21:53:30.674] [KSPe.Globals] INFO: KSPe.cfg does not exists. Using defaults.
[LOG 21:53:31.642] [AddonLoader]: Instantiating addon 'Startup' from assembly 'DistantObject'
[LOG 21:53:31.775] [KSPe.Binder] Hooked.
[ERR 21:53:31.776] ADDON BINDER: Cannot resolve assembly: MeshEngine
[LOG 21:53:31.778] [KSPe.Binder] Looking for MeshEngine.dll on GameData\DistantObject\Plugins\PluginData\...
[LOG 21:53:31.778] [KSPe.Binder] Found it on GameData\DistantObject\Plugins\PluginData\MeshEngine.dll.
[ERR 21:53:31.782] ADDON BINDER: Cannot resolve assembly: MeshEngineStock
[LOG 21:53:31.783] [KSPe.Binder] Looking for MeshEngineStock.dll on GameData\DistantObject\Plugins\PluginData\...
[LOG 21:53:31.783] [KSPe.Binder] Found it on GameData\DistantObject\Plugins\PluginData\MeshEngineStock.dll.
[LOG 21:53:31.784] [DistantObject] MeshEngineStock 2.1.1.10 /L Experimental
[ERR 21:53:31.785] ADDON BINDER: Cannot resolve assembly: MeshEngineTweakScale
[LOG 21:53:31.786] [KSPe.Binder] Looking for MeshEngineTweakScale.dll on GameData\DistantObject\Plugins\PluginData\...
[LOG 21:53:31.786] [KSPe.Binder] Found it on GameData\DistantObject\Plugins\PluginData\MeshEngineTweakScale.dll.
[LOG 21:53:31.787] [DistantObject] MeshEngineTweakScale 2.1.1.10 /L Experimental
[LOG 21:53:31.808] [DistantObject] ERROR: Could not find a model for part ROHS_PresetTransfer_Lunar. Part will not render for VesselDraw. at error:0
[LOG 21:53:31.808] [DistantObject] ERROR: Could not find a model for part ROHS_PresetTransfer_EarlyLunar. Part will not render for VesselDraw. at error:0
[LOG 21:53:31.809] [DistantObject] ERROR: Could not find a model for part ROHS_PresetTransfer_Gemini. Part will not render for VesselDraw. at error:0
[LOG 21:53:31.809] [DistantObject] ERROR: Could not find a model for part ROHS_PresetTransfer_Mercury. Part will not render for VesselDraw. at error:0
[LOG 21:53:31.809] [DistantObject] ERROR: Could not find a model for part ROHS_PresetTransfer_Heatsink. Part will not render for VesselDraw. at error:0
[LOG 21:53:31.914] [DistantObject] MeshEngine 2.1.1.10 /L Experimental ready.
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).
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.
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:
- Saving 3rd party add'ons on
persistence.sfs- This, IMHO, is the worst place to do that. No only you risk ruining the whole savegame by a mistake of yours, as if by any reason beyound your power your add'on ends up being not loaded (due the Assembly Loader/Resolver problem, by example), your settings will be permanently lost.
- And you can bet your SAS the user will be mad with you, not with the real troublemaker (see the years long drama on TweakScale!)
- This, IMHO, is the worst place to do that. No only you risk ruining the whole savegame by a mistake of yours, as if by any reason beyound your power your add'on ends up being not loaded (due the Assembly Loader/Resolver problem, by example), your settings will be permanently lost.
- Saving settings inside
GameDatais also bad (besides less worst), because:- It's a "system wide" data store, anything you write there will be valid for all savegames, and any change will affect equally all the savegames
- You screw up backup schemes, as things that are transitory will "infect" things that are immutable. It's a huge waste of resources as disk space and network bandwidth for 3rd parties willing to do the Cloud stunt. This makes the prospect of having KSP supported on the long run a risk, because as soon as the demand drops a bit, the Cloud provider will have every incentive to drop support for KSP as a cost saving measure.
- Keeping your profile the lowest as possible will increase the chances that the cost of deactivating you is bigger than the cost of keep supporting you, increasing our chances on the long run.
- Forget everything they told you on the Flight School: what makes a plane to fly is MONEY. Software is the same.
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:
- Patchable Configuration Data should be on a Config file that will be internalised by KSP into the
GameDatabase- TL;DR : exactly what we usually do :)
- Non patcheable Default Configurarion Data should be placed inside a
PluginDatainside your add'on folder onGameData.- TL;DR : exactly what we usually do :)
- Customised Configuration Data are the real problem here, and I will address it in two steps.
- System Wide Configuration Data - i.e., things that should affect every savegame all the time.
- KSP is creating (and using) a folder directly into the KSP's root called
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. - Problem: cloud backups. It would be marvelous if I could convince Steam and Curseforge folks to add this directory into their backup efforts. I'm trying to work this out.
- KSP is creating (and using) a folder directly into the KSP's root called
- Savegame Specific Configuration Data - i.e., things that should be persisted on a savegame basis and should not affect any other one.
- As said, using
persistence.sfsis suicidal - But adding these configurations on a internal folder on
saves\<name>\add-onswould accomplish the task - safer and simpler than any other alternative I had studied in the past. - And yes, current Cloud providers backup everything under
saves, so at least on this aspect this solution is viable now.
- As said, using
- System Wide Configuration Data - i.e., things that should affect every savegame all the time.
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