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.

Hm, that should have been fixed in https://github.com/steedcrugeon/REKT/pull/7 which is even before LGG took over the mod. Would appreciate if someone can confirm if it's still working. @ me if it's somehow broke again and I'll take another look.

@Tonka Crash Thanks much for your help! I missed this earlier -- you'll see no difference visually, but in the backend these changes reduce the amount of file I/O being done in toolbar etc. You will still benefit from that even if you're already running with full res textures in your KSP graphics settings.

@linuxgurugamer you got this? Let me know if you need any help tracking this one down or further changes needed on my end.

Yeah, didn't anticipate such use case leading to log spam but turns out it's actually harmless in this situation so I'll just suppress it.

Ah, sounds about right. Which is also at ae4e36f, just a copy of master. But no matter, since it looks like you've already found the culprit.

Just to clarify: for the same exact texture? unBlur doesn't do anything by itself in flight mode unless requested, much less on any kind of loop. So this is unBlur responding to repeated calls to it from one of LGG's mods, most likely there's been a hiccup with the integration somewhere. Thanks for testing and catching this, it's precisely why testing was needed in the first place. Also, if you have a more complete log that might help us track down the issue. Oh, and please don't assume it's unBlur's fault just because it is the one printing the log entries. @linuxgurugamer can you push your TC / CTB code to a branch on GH so I can help take a look later? I was only able to find 3-day-old master branches without any unBlur integration.

@wile1411 actually pointed this behavior of Crew R&R out to me when we were discussing about building a framework for modifying kerbal skills -- which is now in development as Kerbal Status Effects. I do have some ideas for a shared framework for mods that want to introduce other non-stock RosterStatus to do so without stepping on each others toes, but that'd be a different mod I think. For example besides crew R&R's "vacation" maybe Kerbal Health can have "hospitalized" or some mod may impose a "quarantine" duration upon returning to Kerbin from spaceflight -- and they can be set in some ordering/priority or allowed/disallowed to run concurrently. Anyway to address the question at hand AFAIK currently Kerbal Health only reads PCM.RosterStatus and does not set it at any point (obv @garwel would know better, so please correct me if I'm mistaken ).

how so? There is only one file, I have no foreseeable need to include anything else, so no need for a folder. The file is clearly named to indicate what the mod is. The filename includes version number for ease of checking/updating for users doing manual install. What are your concerns?

This is where you've misunderstood. MMPatchLoader was a subclass of LoadingSystem because that is the way to interface with KSP's loading scene. That part of the job is now taken over by PostPatchLoader. MMPatchLoader did not extend LoadingSystem for the sake of providing a way for others to use reflection to access it. It just so happens AlexW / girka2k were able to leverage this to build a workaround to gain access / emulate DataBaseReloadWithMM() in a way that is unintended and unsupported by MM devs. This was a long time ago and I don't know why they chose to do it like this, or whether or not there was any discussion at the time with MM side about better ways they might be able to do it. But there was never any guarantee that this should work or continue to work like that.

Yes, I've recently done that same homework independently from you when I was coding unBlur, so I know exactly what you're referring to. However, just because the class has been that way for 5 years shouldn't be taken as a guarantee of anything, especially given the unsupported nature of what the UbioZur Welding code was doing with it -- not part of any explicit contract offered by MM to other mods. Not really, MM never intended for other mods to be able to call DataBaseReloadWithMM() , it has been private since 2.4.0 and internal before that, which is why blowfish said the UbioWeld code was doing unintended and unsupported things. I don't think so. This is a fairly major architecture change in MM hence the major version number change. The rationale is clear: improve loading times in the load screen. This is not some random change, it is part of a well planned refactoring. It is not likely to get reverted, or to change again soon. The LoadingSystem of MM is now in the PostPatchLoader class, but you will obviously not be able to use it as a conduit to make a database reload call any more. I've already started writing MMWrapper.cs, but let's see if MM is willing to have something that is properly and officially supported so no cat and mouse would be needed.