cakepie

@Galenmacil following up via DM.

@Galenmacil To investigate further I require the following information - I cannot identify the mod from the icon. Please specify what mod this icon is from is so that I can investigate and reproduce. - Also specify what your texture settings are set to (alternateively you can provide a screencap of your graphics settings screen) - Please specify the KSP version and OS used. - It would be tremendously helpful if you could turn on verbose debugging (see "For Modders" section of OP) and provide a full KSP.log file Please don't make assumptions if you don't actually understand what it does.

Yes, can confirm it will be compatible.

For some reason the changes to dependency info in the Toolbar.netkan are not reflected in the Toolbar-1.7.19.ckan? So the dependency didn't get automatically installed by CKAN as it normally should. As already noted, the workaround is to explicitly ask CKAN to install unBlur, which will fix the problem. Sniped!

Have you tried GameEvents.OnHideUI and GameEvents.OnShowUI?

0.0.11 is finally live. v0.0.11 for KSP 1.7.x - 1.3.x Requires Harmony (v1.2.0.1 included in download) Requires Module Manager (please obtain separately) Community Trait Icons is strongly recommended v 0.0.11 2019-06-02 add Harmony dependency replace many horrible ugly brittle hacks with safer patch-based approaches spawning EVA now uses patches on FlightEVA to feed correct data to hatch obstruction tests instead of tampering with passed arguments fix spurious results from FlightEVA.hatchInsideFairing being fed wrong information due to stock limitations fix strange positioning/orientation behavior of spawned kerbal probably caused by tampered data in passed arguments patch KerbalEVA to disable stock command hints during manual boarding instead of brute force removal at every frame patch KerbalEVA to safely disable stock boarding when auto boarding encounters full vessel instead of outright disabling of KerbalEVA patch CrewHatchDialog postfix to provide notifications when the dialog is ready/terminated discard hacks for checking if CrewHatchDialog populated and ready for hijack/augment rework timeout logic for matching airlock mod+click input handling to stock CrewHatchDialog spawning better cleanup when hijacked CrewHatchDialog is closed instead of only when EVA button pressed add crew type icons to stock crew hatch dialog when spawned via crew transfer PAW action rather than clicking airlock

unBlur v0.5.0 for KSP 1.7.x Should be backward compatible to at least 1.3.x if not older. v0.5.0 ~ 2019-06-01 ~ KSP 1.7.x - 1.3.x Added input validation Suppress repetitive logging for GetTexture() calls

I can't speak to the specifics within linuxgurugamer's mods, so you'd have to ask him if you want to know about TBC / CTB specifically. But in general for cases like this: a) Part of the reason why Mod A has a dependency on Mod B is so that Mod A can use features implemented by Mod B without having to implement it themselves. So typically there is little to no commonality of function in the first place. In this specific instance since I did make some of the upcoming changes in blizzy toolbar I can say for a fact that I was able to remove some of its code because unBlur also had code that did the same thing. This redundancy existed in this case because the upcoming changes are replacing toolbar's existing workaround for blurry icons with an improved solution. The redundant code has been removed in the process. b) Another reason to have separate mods and rely on dependencies is for reason of modularity. For example, there are other mods that require click-through-blocker. If you merge CTB into TBC that means other mods that need CTB must either force their users to install the whole CTB+TBC (even if the TBC part is not used), or else include their own copy of CTB-like code themselves (and you end up with multiple mods containing redundant code). So keeping functionally different mods separate from one another is an advantage, not a disadvantage. If you're using the current release versions of CTB/TBC/toolbar, then it's probably just your imagination. If you did downloaded the beta version of CTB/TBC/toolbar that linuxgurugamer made available for testing, then yes, they have some improvements gained from using unBlur, although I'm not sure how noticeable it would be.

The warning is harmless, you don't have to do anything to "fix" it. Extraplanetary Launchpads? I am unable to reproduce. Can you clarify if it's EL6.5.1 on KSP 1.6.1 or something different? A screencap would also be helpful for comparison.

PartModule inherits from MonoBehavior, so by virtue of that, it has OnDestroy(). Or at least that's how I've been doing it.

A bit belated since I've been ill for the past couple of days, but I do want to apologize for going over the top in the post that had to be redacted. I can only plead extreme frustration; I was trying my utmost to do the right thing for my end users and ensure that they could continue to be served without interruption, but failed to get any response at all. It should be pointed out that there is no technical hurdle involved here. What I requested is already possible within CKAN's existing capabilities. If CKAN acceded to my preferred method they could very easily accept and incorporate the settings changes that I submitted. If they declined, then I had a second option, a compromise approach that is also equally trivial to do. In any case, it looks like there is finally some activity on CKAN's part so we shall see what happens.

If you really must, you could try using Harmony to patch a prefix or postfix onto the click handler for the launch button(s) or somewhere else relevant to intercept a launch and do your stuff before allowing rest of the program flow to resume. I've had success with using this approach as a workaround for events that I am interested in but don't have any corresponding entry in GameEvents.

Hmm yeah, that's a problem, I don't see anything in the API that helps with that either.

-

Thanks @AmpCat and @DStaal -- looks like everything is functioning correctly.