General Support issue.

[Lisias]

This issue is for general support for people that have a github account and prefer to handle things here.

(way more practical than using dropbox!).

[Lisias]

Fellow Kerbonaut Krazy1 suffered a crash on his game (fortunately, without further consequences) after updating DOE:

I had the game hang when trying to recover a ship after splashing down. I didn't see anything obvious in the logs and now I overwrote them-oops. I relaunched and then recovered it normally. I'm only mentioning it in case a trend develops... last thing I did was update this mod version. \o/

Well… it really happens that DOE may be involved on the problem as VesselDraw needs to keep track of every living vessel in the viable zone (750 km on default) when you are not using the Target Only render mode. So I hooked into the GameEvents to be aware when a craft is destroyed and when it's changed.

What you describes implies on a GameEvents frenzy, with a craft being destroyed and many new ones (the surviving root part and attachments, and the debris) being created. This would surely fire a MeshEngine creation fest if you aren using DrawVessel with anything other than Target Only…

So… I made this test. :)

On KSP 1.4.5 (as 1.12.2 is terribly sluggish with this load), I reopened my savegame used to develop DOE with lots of crafts around on KSC, and fired up a full loaded B-36 Pieces Maker :).

(a pretty loaded scene)

After take off, over the shallow waters of KSC beach, I let the bombs away:

This scene I know will trigger a lot of GameEvents, as each bomb is now a a vessel on its own. And there's about 50 I think… Some of them are destroyed immediately due collisions, as the bomb bays are not shielding the bombs from the drag (damn).

(bombs away!!!)

Another GameEvents fest, with a lot of bombs being destroyed on water impact.

Then I successfully ditched the craft (without losing anything but the radial engines, that don't withhold any impact):

And to double check, I confirmed that the Render all the the Kitchen's Sink is activate:

And used the SpySat to see the mess from above:

E recovered the craft without incidents:

So, nope. There's no obvious errors on DOE/L.

This does not rules out something being triggered by it, however - it may be something else (perhaps on KSP itself?) that my be being induced to bork by the DOE's GameEvents fest. But this will need a lot of KSP.log checks after freezes to diagnose….

[Lisias]

Fellow Kerbonaus Motokid600 and SiCaRiO31 commented about not being able to see the stars while orbiting the dark side of the bodies on forum (here and here).

Firing up my test bed, I found no evidence of this misbehaviour!

Perhaps a glitch related to a custom skybox?

[Lisias]

Fellow Kerbonaut Vl3d reported a weird misbehaving involving DOE.

He upgraded KSP to 1.12.5, installed DOE and then the CommNET stoped working. By uninstalling DOE, things come back to work.

Logs: KSP Logs - DOE and Comms problems.zip

Problem: there's nothing wrong on them.

Building the test bed

So I built a quick&dirty test bed with a minimal set of add'ons and created the following scenario: 3 Stock Ion-Powered Space Probe orbiting Kerbin at 6267KM with a 120º separation, and one on Laythe. I enabled the need to have a comm stablished to control the craft to make testings easier, and I confirmed that the Laythe probe became uncontrollable when Laythe is hiding Kerbin from it.

Savegame: test-DOE.zip

I could not reproduce the problem. Looking on the reporter's log, I detected the following add'ons installed:

Folders and files in GameData:

• 000_ClickThroughBlocker
• 000_Harmony
• 000_Toolbar
• 001_ToolbarControl
• B9PartSwitch
• BetterBurnTime
• BoulderCo
• Chatterer
• CoherentContracts
• CommunityDeltaVMaps
• CommunityTechTree
• CommunityTraitIcons
• CrowdSourcedScience
• CustomBarnKit
• DistantObject
• DMagicOrbitalScience
• EnvironmentalVisualEnhancements
• HideEmptyTechTreeNodes
• Kerbalism
• KerbalismCompanionCalculator
• KerbalismSimplex
• Kopernicus
• KSPCommunityFixes
• KSP_Proximity
• ModularFlightIntegrator
• OrbitalSurveyPlus
• PartCommanderContinued
• PatchManager
• PersistentRotation
• PlanetInfoPlus
• PortraitStats
• ReStock
• ReStockPlus
• RestockWaterfallExpansion
• RocketSoundEnhancement
• RocketSoundEnhancementDefault
• SafeChute
• SCANsat
• Scatterer
• ScattererAtmosphereCache
• SHED
• SituationModuleInfo
• SmartParts
• SmokeScreen
• SpaceAge
• SpaceTuxLibrary
• SpaceTuxSA
• Stock folder: Squad
• Stock folder: SquadExpansion
• StationScience
• TrackingStationEvolved
• Trajectories
• TrimIndicators
• UnKerballedStart
• UtilityWeight
• Waterfall
• WaterfallRestock
• WaypointManager
• ModuleManager.4.2.2.dll

Hypothesis

I'm betting on an unhappy interaction between some 3rd party and DOE, perhaps even something related to the upgrade pipeline (wildly guessing now). Since Comms stopped working, I'm doing an educated guess on SCANSat.

Findings

I will edit this comment with my findings.

[Tequhella]

Hello,

I recently cloned this repository, hoping to find a solution for integrating Kopernicus, but I can't build the project because it tells me that there are 2 missing files, configuration.cs and version.cs in Source/DistantObject/Properties. Is this normal?

[Lisias]

Hi, @Tequhella !

I recently cloned this repository, hoping to find a solution for integrating Kopernicus, but I can't build the project because it tells me that there are 2 missing files, configuration.cs and version.cs in Source/DistantObject/Properties. Is this normal?

You need to manually run the Configuration.tt and Version.tt t4 templates. Right-Click, then "Tools" and then "Process T4 Template".

And, yeah, Vistual Studio should do that automatically. Don't ask why it doesn't, people are asking for it for years already!

Cheers, and keep me in the loop!

[Tequhella]

It worked fine for Version.cs, but the .tt file for Configuration.cs isn't in the repo. Is it generated automatically or something like that? And yeah, no problem, I can't guarantee anything since it's the first time I'm working on a mod but I'll try!

[Lisias]

It worked fine for Version.cs, but the .tt file for Configuration.cs isn't in the repo. Is it generated automatically or something like that?

Humm…. Now that you mentioned it (twice)… There's really no Configuration.tt file on the DistantObject project files…

(oh krap! found the problem!!)

I forgot a left-over lingering around on my rig!! Pretty lame mistake, really lame mistake!

Remove the reference for the Configuration.cs file. The thing compiles file without it, once you remove from the project!!!

[Lisias]

@Tequhella , I just updated the dev branch with the fix!

Thanks for the heads up!

[Tequhella]

@Lisias, Thanks especially to you for your help! I made a few changes, like switching to .NET version 4.7.2 to make it compatible with Kopernicus, and I modified the line in the update of FlareDraw.cs: Vector3d targetVectorToSun = FlightGlobals.Bodies[0].position - body.position; to Vector3d targetVectorToSun = KopernicusStar.Current.sun.position - body.position; Aaaaaaand.... Yeah boiiii

It works with the EventHorizon extrasolar planet packs. Given that, it's looking good for it to work with other packs. It needs to be tested. Apart from that, I had to change one line of code that appears in a few places: KSPe.Util.SystemTools.TypeFinder.FindByInterface() to KSPe.Util.SystemTools.Type.Find.By() in the file Source/DistantObject/Contracts/MeshEngine.cs, and KSPe.Util.SystemTools.Type.Search.By() in Source/MeshEngine/Contracts/Module.cs. I don't know why, but it was telling me that TypeSearch didn't exist and even after searching, I couldn't find it either. I don't know if it was important, but at least it works.

[Lisias]

Hi, @Tequhella!

@Lisias, Thanks especially to you for your help! I made a few changes, like switching to .NET version 4.7.2 to make it compatible with Kopernicus, and I modified the line in the update of FlareDraw.cs:

Wow! Thank you very much! :)

Incredibly simple, by the way. Thank you for your time on researching it!

A few notes: You don't really need to use .NET 4.7.2 to make the thing compatible with Kopernicus - the Mono runtime know how to handle 3.x SIL and 4.x SIL at the same time, no problems on that. You can use 4.x SIL code from 3.x SIL code and vice versa - as long you don't try to synchronise them (never synchronise 3.x SIL from 4.x and vice versa - do a wrapper for that).

I use .NET 3.5 because it keep the DLL compatible to multiple KSP versions.

Apart from that, I had to change one line of code that appears in a few places:

Ah, you are using KSPe! :)

DOE was distributed with KSPe.Light.DOE, a subset of the full KSPe compiled specifically to be used by DOE. KSPe is a working in progress library, and so now and then some bad ideas are detected. On KSPe3 2.5, it was time to get rid of some of the clutch from 2.3 and 2.4 era, and so some calls were gone.

Since DOE is released with its own interim Light version, it was immune to the changes until you tried to recompile it using the latest KSPe (full), where the calls were ripped off!

Again, thank you very much!

[Tequhella]

Ah, I see now! At least I'll know for next time. It's good that only the modification in FlareDraw.cs needs to be taken into account, that's rather advantageous. By the way, I was wondering: if we push this modification, it includes a dependency on Kopernicus. Couldn't we avoid that with a condition that detects whether Kopernicus is found in the GameData folder or something like that? And np, it's a pleasure!

[Lisias]

@Tequhella

By the way, I was wondering: if we push this modification, it includes a dependency on Kopernicus. Couldn't we avoid that with a condition that detects whether Kopernicus is found in the GameData folder or something like that?

Yes, of course! As I like to say, all we need are Good Interfaces. Once we have them, even the shittiest code in existence can be useful without hassle (and Kraken knows I write some now and then).

I'm pulling this stunt on DOE itself, see the MeshEngine implementation: the main DLL doesn't knows squat about "Parts", it really only understand Unity meshes. I wrote a DLL for some different Add'On that implements things differently - and I only loads a DLL once the dependencies are met, so I can have only one distributable for different use cases.

Cheers!

[Tequhella]

Hello @Lisias I tried to make an interface for Kopernicus on my repository. I don't know exactly what you imagine as an interface, but I tested by launching the game with and without Kopernicus, and it works. I created the ISolarSystem.cs interface with two classes (DefaultSolarSystem and KopernicusSolarSystem) which both define how the method GetSunPosition() will work. To instantiate the correct solar system, I added a method in Startup.cs to check whether Kopernicus is present or not. Here's the ISolarSystem.cs code:

using Kopernicus.Components;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace DistantObject
{
    internal interface ISolarSystem
    {
        Vector3d GetSunPosition();
    }

    // Default Solar System class
    class DefaultSolarSystem : ISolarSystem
    {
        public Vector3d GetSunPosition()
        {
            return FlightGlobals.Bodies[0].position;
        }
    }

    // Kopernicus Solar System class
    class KopernicusSolarSystem : ISolarSystem
    {
        public Vector3d GetSunPosition()
        {
            return KopernicusStar.Current.sun.position;
        }
    }
}

I haven't touched all the occurrences of FlightGlobals.Bodies[0].position in FlareDraw.cs, just the line I mentioned last time. Vector3d targetVectorToSun = Globals.SolarSystem.GetSunPosition() - body.position;

Here's the commit if you want to check, and if you have any comments or tell how you see an interface for Kopernicus, don't hesitate! (I've had a few problems with some commits, I've had unexpected commit squash with the last one you did...) https://github.com/Tequhella/DistantObject/commit/b7b5b4dd506be8c40c949fc22399f59bbf2aa7fb

[Lisias]

Hi, @Tequhella ! Thanks for the code!

I checked it, and it creates a hard dependency on Kopernicus here:

https://github.com/Tequhella/DistantObject/commit/b7b5b4dd506be8c40c949fc22399f59bbf2aa7fb#r144723275

I will prototype something tomorrow by afternoon so you can have a glance. Currently, I'm working...

[Lisias]

@Tequhella , check this issue https://github.com/net-lisias-ksp/DistantObject/issues/33

Feel free to comment there, even with the issue closed - I don't mind chatting about the solution there.