net-lisias-ksp / DistantObject

Distant Object Enhancement (DOE) is a visual enhancement mod that makes objects realistically visible over large distances.
Other
11 stars 3 forks source link

ADDON BINDER and others #24

Closed Gordon-Dry closed 2 years ago

Gordon-Dry commented 2 years ago

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).

Gordon-Dry commented 2 years ago

Some side info: https://forum.kerbalspaceprogram.com/index.php?/topic/190040-rp-1-realistic-progression-one-for-ksp-1123/page/13/#comment-4100122

Lisias commented 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.

Lisias commented 2 years ago

@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:

  1. 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!)
  2. Saving settings inside GameData is 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:

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!

Gordon-Dry commented 2 years ago

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