Sibiro

Confirming. I almost gave up first time I'm curious as to what you use for makefile/C# projects? I ended up by creating csproj/sln from scratch and adding all files and references in VS.

@theJesuit confirming, KIS has some issues with 1.10 and I've got exact same behavior with stakes too (as well as some other parts). Upon inspecting the logs, I'm pretty sure it's on KIS side. As a workaround, I found that non-Kerbal KIS inventories are generally work fine with 1.10. So, if you can grab a KIS container and toss it around, either as a separate part or mounted on a rover, this can make the life easier until KIS is updated. Hope this helps.

@taniwha I've created pull request for you with the changes that should (in theory) fix the issue with KSP 1.10 as well as compatibility issue with kOS.

Hi @Nils277, first of all, I'd like to say KPBS is a great mod! Thank you for doing this! I've recently noticed one thing in the integration between Kerbal Planetary Base Systems and OSE Workshop. And I'm not sure whether it was something overlooked or it's intentional, so I thought it would be better to ask. As I can see, OSE Workshop added ExoticMinerals and RareMetals Harvesters directly to the stock drills, as well as scanners, resource distribution, etc. This was done some time ago, back in 2015, it seems. So, since then there were two ways to perform OSE - either sift Dirt or setup a base in place rich in ExoticMinerals/RareMetals (maybe secondary base or just a mining outpost). https://github.com/Aelfhe1m/Workshop/commit/24fb688579a176937373c518945e1fed25c108ff#diff-0d360eca26d9f578a6a98c910971ef1a However, as I suddenly found, there are no similar patches to add ExoticMinerals and RareMetals Harvesters to K&K Inline Drill. And, unlike Dirt, there are no dedicated K&K parts for these resources. (I learned it the hard way after landing the "mining outpost" with K&K inline drills on Duna). I just want to ask if it was a design decision or just something overlooked & not implemented. I've tried to make an MM patch with the corresponding ModuleResourceHarvesters for KKAOSS_drill with the Efficiency and other parameters taken from the Ore harvester (in between small and large stock drills). Overall, it seems to be working as expected. I can put it all together and make a pull request, if you interested.

@linuxgurugamer I've checked it today on a latest version 0.0.3.6 on a (mostly) clean install of KSP. The issue is still there, unfortunately. Moreover, this time I've got it right when the ship was spawned on runway from SPH, and it was the first ship spawned in the new game. Relevant messages in the log: ------------------- initializing editor mode... ------------------ editor started ... KSP_PartHighlighter: UpdateHighlightColors, id: 0 OSE.Workshop added to ship - part count: 2 ... [HighLogic]: =========================== Scene Change : From EDITOR to FLIGHT (Async) ===================== ... ------------------- initializing flight mode... ------------------ Loading ship from file: D:/SteamGames/ksp/sandbox_1/KSP_x64_Data/../saves/ose_test/Ships/SPH/Auto-Saved Ship.craft OSE Test loaded! [OSE Test]: Ready to Launch - waiting to start physics... ... [FLIGHT GLOBALS]: Switching To Vessel OSE Test ---------------------- ... KSP_PartHighlighter: CreateHighlightList: An item with the same key has already been added. Key: 0 KSP_PartHighlighter: CheckInit, id not found: -1 ... KSP_PartHighlighter: Stack: at System.Environment.get_StackTrace () [0x00000] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 at KSP_PartHighlighter.PartHighlighter.CheckInit (System.Int32 id) [0x00000] in <1ed612a5ff2247e48ae3b8c639ba4f98>:0 at KSP_PartHighlighter.PartHighlighter.SetHighlighting (System.Int32 id, System.Boolean active) [0x00000] in <1ed612a5ff2247e48ae3b8c639ba4f98>:0 at Workshop.OseModuleHighlighter.LateUpdate () [0x00000] in <d31ffa410ef0460a8ebc3e4a1ab78d84>:0 KSP_PartHighlighter: CheckInit, id not found: -1 (repeating) Here is the full log https://www.dropbox.com/s/6a014jo92zjv9bm/log_ose_parthighlighter_test.zip?dl=0 As I can see, the Source code linked along with the release here https://github.com/linuxgurugamer/SpaceTuxLibrary/releases/tag/0.0.3.6 still have static Dictionary and non-static highlightCnt. Maybe something didn't get into the main branch at some point?

@linuxgurugamer Thank you! It seems that I've stumbled upon a non-critical, but performance-affecting issue. Not sure if it's specific for 1.10 or it's something affecting 1.9 too. So far, I was able to reproduce it reliably if I quickload a game with kerbal in focus near the ship with OSE workshop. OseModuleHighlighter object ends up with highlightID=-1 and this leads to the following endless spam in the log: KSP_PartHighlighter: CheckInit, id not found: -1 (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35) KSP_PartHighlighter: Stack: at System.Environment.get_StackTrace () [0x00000] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 at KSP_PartHighlighter.PartHighlighter.CheckInit (System.Int32 id) [0x00000] in <1ed612a5ff2247e48ae3b8c639ba4f98>:0 at KSP_PartHighlighter.PartHighlighter.SetHighlighting (System.Int32 id, System.Boolean active) [0x00000] in <1ed612a5ff2247e48ae3b8c639ba4f98>:0 at Workshop.OseModuleHighlighter.LateUpdate () [0x00000] in <6860bce87fea4157971fd6d131e9f48d>:0 (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35) As it's inside update method, this can quickly inflate log file to hundreds of MB and affects framerate significantly. I was able to locate the following in the log before the first CheckInit error and I believe it's the main reason for -1 KSP_PartHighlighter: CreateHighlightList: An item with the same key has already been added. Key: 0 KSP_PartHighlighter: CreateHighlightList: An item with the same key has already been added. Key: 1 As I understand, this comes from https://github.com/linuxgurugamer/SpaceTuxLibrary/blob/master/KSP_PartHighlighter/PartHighlighter.cs and is probably because of highlightCnt not being static, while the Dictionary is. Not totally sure if this is the root cause or there is something more to the story, but I think it should be enough for debug. int highlightCnt = 0; ... private static Dictionary<int, HighlightParts> hPartsLists = null;

@taniwha I think I found the root issue with mods incompatibilities in my case. When getBuildCost() for selected craft is called, the temporary virtual craft is spawned to calculate required resources and kerbal hours. As a part of the initialization, ModulesOnStart() is called for each part, which is necessary to do the work. The problem is that kOSProcessor initialization triggers OrbitDriver initialization (to set up kOS variables state, I suppose). At the same time, the temporary craft has NaN orbit, because it's not actually a valid craft, so OrbitDriver removes the craft. It happens instantly, right within foreach parts initialization, so foreach fails as well as the resources calculation. This is the relevant part of the log file: ObT : NaN M : NaN E : NaN V : NaN Radius: NaN vel: [NaN, NaN, NaN] AN: [1, 0, 0] period: 0 [OrbitDriver Warning!]: EL craftVessel - DunaMiner-2 had a NaN Orbit and was removed. So, I've changed the following part of getBuildCost() foreach (Part part in craftVessel.parts) { part.ModulesOnStart (); } To this: foreach (Part part in craftVessel.parts) { if (part.Modules.Contains("kOSProcessor")) { var kos = part.Modules["kOSProcessor"]; if (kos != null) { part.Modules.Remove(kos); } } part.ModulesOnStart(); } Because temporary craft doesn't really need any kOS processor module activated. The overall part is still there, so the construction cost should not be affected. My preliminary checks show that the ships with kOS processor on board can be calculated and built. I'll play a bit more with this and prepare a pull request in the repo. (At the moment, I don't see any other incompatibilities in my setup)

@taniwha I've tried to run EL on 1.10 and has got the problems similar to what was already reported - the ship cannot be selected in ship list UI. Quick debug shows that the main issue is about some kind of a new KSP pipeline api approach - the callback OnFileSelected is not fired (the one that is assigned in ELCraftBrowser.Spawn). However, OnConfigNodeSelected is fired and seem to be working well. Adding the following callback function near other assignments (like, cb.OnBrowseCancelled = onCancel;) seem to be fixing the main issue (by the way, OnBrowseCancelled is fired as expected): cb.OnConfigNodeSelected = delegate (ConfigNode n, LoadType t) { Debug.Log($"[CraftBrowserDialog] OnConfigNodeSelected - " + cb.selectedEntry.fullFilePath); onFileSelected(cb.selectedEntry.fullFilePath, t); }; At the same time, I'm still experiencing quite a few issues, unrelated to 1.10, I believe. Most of them seem to be due to various unexpected mod interactions (I have about 90 installed). I'm currently looking into those and plan to prepare some notes and solutions for you (and maybe a pull request) based on my findings. This will probably take a few days, as I'm not an experienced modder.

@linuxgurugamer I've encountered the same "InvalidCastException: Specified cast is not valid." issue with OSE and Pathfinder and it was bugging me a lot, so I did a bit of debugging and the reason seems to be the following. KISWrapper.GetInventories (both overloads) checks moduleName (module.moduleName == "ModuleKISInventory") and pushes the module into ModuleKISInventory constructor that performs the casting (KIS.ModuleKISInventory)obj. Apparently, @Angel-125 inventories are something else, probably due to being a configurable parts/modules. I've added some logging into OSE code from Github and got these results: [OSE] - Module is not KIS.ModuleKISInventory - WBI.Ponderosa2 class WBIOSEWorkshop [OSE] - Module is not KIS.ModuleKISInventory - WBI.Hacienda class WBIOSEWorkshop Overall, the "root problem" seems to be on Pathfinder side, i.e. having (moduleName == "ModuleKISInventory") while not being derived from (KIS.ModuleKISInventory). Nevertheless, it's probably reasonable to do a defensive check in KISWrapper.GetInventories before passing the module to Workshop.W_KIS.ModuleKISInventory wrapper. I added the simple sanity check and it fixed the casting exception. if (module.moduleName == "ModuleKISInventory") { if (module is KIS.ModuleKISInventory) { inventories.Add(new ModuleKISInventory(module)); } else { WorkshopUtils.LogError("Module is not KIS.ModuleKISInventory - " + module.name + " class " + module.ClassName); } } Moreover, as I can see, Pathfinder's parts also have actual KIS.ModuleKISInventory, because the workshop production, favoring etc - it's all working okay with this adjustment. (I'll try to look into @Angel-125 code and his WBIOSEWorkshop and WBIInflatablePartModule to see why those moduleName's are "ModuleKISInventory" too, but I suspect there was a reason for that).