cakepie

The MMPatchLoader class may be public, but you should notice that DatabaseReloadWithMM() has been private since MM2.4.0 and it had no access modifier before that, i.e. defaulted to internal. The way that UbioWeld had to use reflection and copy part of MM's code to emulate it is definitely unsupported. If it was intended for other mods to be able to trigger a database reload there would have been a much nicer, properly exposed way for us to do it. --- Edit: @blowfish I think I can fix UbioWeld's code without too much difficulty, but perhaps a properly supported and documented wrapper class would be better? Some things it could do, off the top of my head: 1. Check if MM is installed, and if so, which version, and whether MM is ready (finished patching in loading screen) 2. Since MM 2.6.7 there has been support for other mods to be notified via ModuleManagerPostLoad() once MM has finished doing it's work in Loading screen, but relying on that makes MM a hard dependency. A mod might want to: - if MM is installed, once game database is loaded and MM has finished patching, do_stuff() - else once game database is loaded, do_stuff() so in unBlur I had to jump through a few hoops to handle both possibilities 3. Provide a way to trigger a database reload (e.g. what UbioWeld needs)

CreateShortestPathTree is protected, I don't think you're supposed to use it the way you're probably imagining. FindPath's bool return value is probably a success/failure flag, for instance there may not be any path between the given start and end nodes. The path param probably behaves like an out or ref param. Try something like this? (Note: purely speculative from reading API and not actually tested) CommNode start = vessel1.Connection.Comm; CommNode end = vessel2.Connection.Comm; CommPath path = null; // may need to instantiate if this causes null reference exceptions CommNetwork network = CommNetNetwork.Instance.CommNet; // not sure if needed, seems like a good precaution: if (network.IsDirty) network.Rebuild(); if (!network.FindPath(start, path, end)) { // did not find a path Debug.Log($"Failed to find a path between {vessel1.vesselName} and {vessel2.vesselName}") // ... } else { // do things with path, like Debug.Log($"Signal strength between {vessel1.vesselName} and {vessel2.vesselName} is {path.signalStrength}"); } hth

@Lisias would you like me to help take a crack at MM4 compatibility? If so are you willing to require MM4+ dependency or would you insist on keeping backward compat for people using MM<4?

Looks like it uses reflection to emulate DatabaseReloadWithMM() , to apply new patches at runtime: https://github.com/UbioWeldingLtd/UbioWeldContinued/blob/12aef85739bc7a6deca52c73930456035971e8bd/UbioWeldingLtd/DatabaseHandler.cs#L111 https://github.com/net-lisias-ksp/UbioWeldContinuum/blob/7ef3f5fbfd76b00fc9d01cef4c80caf4215beafc/UbioWeldingLtd/DatabaseHandler.cs#L128 <- lisias' fork Perhaps that's something that could be exposed to other mods? Edit2: also pulls the ProgressFraction

If I release the next version without CKAN updating their metadata, it will not install the mod correctly for CKAN users when they update. I would prefer not to leave users in the lurch like that.

I agree with blowfish, this all seems out of scope for MM. If you're going to copy files out of zDeprecated into some other location in GameData, that's something that only needs to be done once, during mod install, and not everytime the game starts up. If on the other hand you want to force certain files to be read from zDeprecated and made available in the gamedatabase then something like unBlur's code could possibly work. Not sure about your use case, maybe unBlur code and my notes on MM compat here may help.

I'm glad you find the mods useful. Hm? I just double checked, the release looks like this: BSS.0.0.4.zip - GameData - 0Harmony.1.2.0.1.dll - BetterSpecializationSettings - BetterSpecializationSettings.cfg - BetterSpecializationSettings.dll - LICENSE.md - localization_en-us.cfg You should have it as long as you downloaded from the github release, which is the only place it should be available. Install should be as easy as copy all GameData contents from the zip file to your KSP's GameData. Did you only look inside the BSS folder and miss the 0Harmony.x.x.x.x.dll in GameData? Note that you should put 0Harmony.x.x.x.x.dll in GameData -- multiple mods can use it, so it is best to just have one copy in one place to avoid any problems and also makes it easy to keep it up-to-date (similar to module manager).

@linuxgurugamer In case KSP version check would help at least identify whether there's zDeprecated directory and what's in it: it's issue #116 , I wrote up some code to do it a while ago but it's got some loose ends that needs tied up, see here if you want to chip in and help get it implemented and integrated.

Dear users: I apologize for this interruption to normal functioning of this thread, but I regret to inform you that CKAN has been ignoring me for over a month, and as a result the next version of AirlockPlus has been delayed for nearly two weeks now. At this point I feel I have no other option but to call them out for this behavior. I have issued an ultimatum on CKAN's forum thread demanding that they take immediate action; a copy of this included in the spoiler below [snip]. CKAN users: if CKAN refuses to make the necessary changes in order to be able to install AirlockPlus correctly, I may be forced to release AirlockPlus v0.0.11 without the correct CKAN metadata support. Consequently, if you attempt to install or update AirlockPlus via CKAN it will most likely not work properly. In that case, you would need to uninstall CKAN's copy of AirlockPlus and perform a manual installation by yourself. I hope that you find AirlockPlus useful enough to be worth the additional effort of performing a manual installation. Thank you for your attention and apologies again that it had to come to this.

[snip] I opened github issue NetKAN#7131 on Apr 15 because I perceived a need for CKAN to index the Harmony C# patching library. This request was driven by the fact that I would soon be using it in my mods. My goal was (and still is) to have CKAN index it so that it can be installed once and then used as a shared dependency by multiple mods; this would conserve disk space and forestall any potential problems with having multiple copies of the library, possibly of different versions (a known issue in some other games). In response to a question from CKAN project members about how Harmony behaves when multiple copies exist, I put in the effort to run some tests and reported back the results on Apr 18. A discussion ensued over the next few days about whether or not it should be indexed; I continued to state the case for indexing with concrete reasoning and use cases, and countered what I saw as flawed arguments from the other side. Discussion ceased after Apr 20 with no formal decision or resolution on the matter. More than two weeks passed, during which time I continued to make progress on developing my mods. As they the point of release gradually approached, on May 6 I offered to take additional steps to assuage concerns expressed by CKAN team members about perceived risks if they indexed the Harmony library. No response was forthcoming. On May 10 I completed updates to the AirlockPlus mod, such that it now has Harmony as a dependency. Since making it available as a full release would break installations for existing CKAN users, I opted to temporarily offer it as a pre-release, while pointing out to CKAN that the the lack of progress on issue #7131 had become a blocker preventing me from releasing the next version of my mod. Still nothing. After a further >10 days had passed, I decided to attempt to spur some on progress the matter and submitted PR #7200 on May 21 to make the necessary changes so that I could properly publish the next version of AirlockPlus. @DasSkelett was quick to help fix a problem I had with the CKAN syntax, but after that, nothing again. Before anyone counters that the PR has only been up for a bit over 48 hours -- let me reiterate that I had provided notice about the urgency of the matter on May 10, and as of right now, AirlockPlus v0.0.11 has been delayed by almost two weeks. Furthermore, for over a month (since Apr 20) I might as well have been talking to a wall. Throughout this time, CKAN project members have been active on other issues and pull requests, as well as on the KSP forums. This morning, I even interacted with a CKAN team member in a different github issue to discuss other unrelated things -- but when I made an aside appeal to have PR #7200 looked at, it was quickly shut down as off-topic. That would not be unreasonable in any other circumstance, but suffice to say I am frustrated and all out of patience after [snip] so long. So, here we are at the end of the day and there is still no progress on #7131 or #7200. How hard is it to merge a PR, or drop a quick message explain the delay, or provide some reassurance that it will be looked at soon? I understand we all have other commitments outside of modding, and CKAN's priorities are different from my priorities [snip]. If a delay is needed, you should inform me and explain why. If you've decided to turn down my request, let me know so that I can proceed accordingly. [snip] For the record: I am not be a CKAN user myself, but I understand and appreciate its place in the modding ecosystem for trying to make it easy and convenient for end users to install mods (albeit that is not always the goal of the modder, and CKAN has been known to mess up installs to the point that some modders refuse to support or allow CKAN installs.) In CKAN#2732 when I asked for explicit opt-out of my mods from CKAN to prevent prototype code from being distributed outside of my control, it was correctly observed that I was "not antagonistic to CKAN" like most people on the opt-out list. I am well aware of the circumstances of the controversy back 2016 that led to that opt-out list. I was not personally involved in those events and so bore no ill-will against CKAN, but was cautiously hopeful that the CKAN organization had improved since then. Notice the use of past tense. My stock of goodwill for CKAN has now been depleted. To cite some of CKAN's policies: CONTRIBUTING.md: CKAN purports to welcome ideas and contributions. I have freely shared ideas and use cases in various threads in CKAN's various GitHub repos. I have no problem with being told that I am wrong when I've made a mistake (See NetKAN#7144). In the past I have even considered contributing code to CKAN, although that has not happened due to time constraints. Code of Conduct I believe I have made all reasonable effort to reach out and collaborate, and have behaved in a civil manner throughout. Unfortunately, that has failed, so things have now come to this [snip]. I do not enjoy having to do this. [snip] If this matter cannot be resolved in a timely fashion, I reserve the right to unilaterally publish the next version of AirlockPlus without the necessary fixes in place for its CKAN metadata, thereby breaking installs for CKAN users when they attempt to upgrade the mod. I've tried everything I can, so at that point the fault would lie squarely with CKAN. [snip] Note: I consider NetKAN#7201/#7202 to be an unrelated matter, and will deal with separately after this is resolved.

The functionality provided by this mod has been subsumed into Better Specialization Settings:

v0.0.4 adds control over requirements for repacking parachutes. Parachute repacking code is a tentative first pass -- please let me know if you notice any discrepancies in is behavior when compared to stock. Better Specialization Settings v0.0.4 for KSP 1.7.x (backward compatible with KSP 1.6.x - 1.3.x) Caution: Dev build. Backup your saves before proceeding. Requires Module Manager (please obtain separately.) Download includes the Harmony library, version 1.2.0.1. See this comment for explanation. v0.0.4 ~ 2019-05-22 ~ KSP 1.7.x - 1.3.x Dev Build - Harmony 1.2.0.1 included Add restrict parachute repacking to engineers Add adjust level requirement for parachute repacking Fix bug in engineer (repair skill) requirement check for wheel repair

I would suggest registering for these events: GameEvents.OnVesselRecoveryRequested GameEvents.onVesselRecovered GameEvents.onVesselRecoveryProcessing GameEvents.onVesselRecoveryProcessingComplete GameEvents.onGUIRecoveryDialogSpawn Confirm for yourself what order they are called and what each one does. There's a couple of them that give a handle on the ProtoVessel being recovered as well as the MissionRecoveryDialog so you may be able to do something there, update some values to reflect your extra rewards, maybe inject some additional UI into the dialog to provide feedback to player, all that jazz.

v0.4.0 fixes a bug. v0.3.0 came out unannounced a few days ago, it was mostly improvements for modders, and was not aimed at players. v0.4.0 ~ 2019-05-17 ~ KSP 1.7.x - 1.3.x Fix unreadable textures still being blurry Implement DDS file reader with DXT1, DXT3 & DXT5 support v0.3.0 ~ 2019-05-13 ~ KSP 1.7.x - 1.3.x Add GetTexture() for convenience Minor optimizations and improvements

@CyanAngel CTI maintaner here, I've managed to reproduce your issue on KSP 1.6.1 with CTI 1.1.1 and KCT 1.4.6.4 + MagiCore 1.3.1.5 so it's not just you. Unfortunately the latest KCT broke something, you can try rolling back to KCT 1.4.6 or 1.4.5.10 instead to get the icons to show up. @linuxgurugamer I've looked at the log file supplied I think the problem is that you initialized static bool useCTI which means it will check with CTIWrapper as soon as any KCT_GUI is instantiated anywhere // Find out if the Community Trait Icons are installed internal static bool useCTI = CTIWrapper.initCTIWrapper() && CTIWrapper.CTI.Loaded; This worked when you first implemented it, but in commit commit ede985b you created a new Addon KCT_GuiDataAndWhitelistItemsDatabase with KSPAddon.Startup.Instantly which has this: void OnGUI() { if (!GuiInit) { KCT_GUI.InitBuildListVars(); //KCT_GUI.InitBuildPlans(); GuiInit = true; } } And I suspect this is responsible for introducing the regression -- now you're checking CTIWrapper in LOADING, waaaay before CTIAddon has loaded anything -- so CTIWrapper.CTI.Loaded returns false. From user's log: L229 [AddonLoader]: Instantiating addon 'KCT_GuiDataAndWhitelistItemsDatabase' from assembly 'KerbalConstructionTime' ... L301 [KerbalConstructionTime|CTIWrapper] Attempting to wrap Community Trait Icons... ... L305 [KerbalConstructionTime|CTIWrapper] Community Trait Icons found: ver 1.1.1.0 ... L15671 [HighLogic]: =========================== Scene Change : From LOADING to MAINMENU ===================== ... L15685 [AddonLoader]: Instantiating addon 'CTIAddon' from assembly 'CommunityTraitIcons' ... L15689 [Community Trait Icons] Tinting icon for Pilot. ... L15693 [Community Trait Icons] Tinting icon for Engineer. ... etc CTIAddon needs to let GameDatabase finish loading as well as allow ModuleManager to run any patches. It is set as KSPAddon.Startup.MainMenu . The earliest time to (easily) call CTI is SpaceCenter. It can be done in MainMenu but there are caveats there -- will probably work later in the scene (e.g. when adjusting new game difficulty settings) but if you want to do it in Start() or even Awake() you have to start taking into consideration possible issues due to the order in which addons are loaded (apparently BFS alphabetical, but don't rely on it). I had to grapple with that when doing integration for Indicator Lights and found a couple of solutions [ 1 , 2 ] but seriously it's not worth the trouble if you don't absolutely have to do it that early. hth.

PR submitted for the above requests. Also addressed a quirky bug I found (issue #22) but the solution may need to be rebalanced for prohibitively high hiring cost -- will leave balancing decisions up to linuxgurugamer.

Version 0.0.3. Mod is slightly renamed. Added setting to limit repairs in sandbox to engineers only. Added setting to adjust required engineer level for repairs in career. (An old mod called EngineerLevelFixer used to provide this feature) OP has been massively fleshed out. Better Specialization Settings v0.0.3 for KSP 1.7.x (backward compatible with KSP 1.6.x - 1.3.x) Caution: Dev build. Backup your saves before proceeding. Requires Module Manager (please obtain separately.) Download includes the Harmony library, version 1.2.0.1. v0.0.3 ~ 2019-05-13 ~ KSP 1.7.x - 1.3.x Dev Build - Harmony 1.2.0.1 included - Add restrict wheel/leg repair to engineers - Add adjust level requirement for wheel/leg repair - Rename mod due to feature for career mode - Refactored code

More info for the mods to start looking into, to bring back the lost art of the "red tag" This is a feature of the invision forum software, called "prefix" Normal, gray tags are "tags", and you can add many tags to a thread. For each thread it is possible to select one of the tags to become the "prefix" The guide page is here: https://invisioncommunity.com/4guides/how-to-use-ips-community-suite/content-discovery/content-tags-and-prefixes-r72/ Under the first heading, "Tagging Content" it mentions: And you can see in the animated screenshot that after adding some tags, there is a little dropdown list from which you can select the prefix. This is a function that is probably restricted to some users, as at the bottom of the guide there is a section about "Restricting use" which mentions: So to use this requires certain permissions which Sal_vager probably had. Hopefully there are some current mods who do have those permissions, or if not, squad forum staff may be willing to grant those permissions to some of you. EDIT: sniped by James Kerman! Guess we've found someone who has those permissions I mentioned! Not everyone is able to do this -- I tried on one of my threads and the little dropdown does not show up. So if you want a red tag you have to ask an admin or mod, I guess?

Yeah that sounds reasonable now that you've explained that its function is to lock/unlock multiple ModuleAnimationGeneric on the part. A bit of a mouthful perhaps but clarity is more important than a short name.

I'd suggest calling it ModuleSequentialAnimate to stick with the convention, also definitely not generic anymore.

This edit was not in OP when I suggested that this should be a config issue: Solar panel tracking is in KSP code, not Unity, and to get it working properly with part model is achieved through the part's config file, which is why that is the natural place to start trying to solve the problem. @raidernick can you maybe elaborate why you've concluded that this is a thing between blender export / unity import? I don't believe there has been a change in unity version being used between KSP 1.6.x to 1.7.x so could it be something on your end in terms of how you are exporting your model? Also you didn't answer: re which specific parts this are affected or is it just outright everything. Edit: Solar panels pack v1.6 is working out of box on KSP 1.7. You'll need to be more specific about what your problem is; these existing models seem to be working fine @James Kerman I meant "General Mod Development Help and Support", not the end-user support or discussion section. No wonder OP got miffed.

Which parts in particular? Or just all of them in the solar panels pack? Aside: This is a config question re: stock PartModules rather than a modelling and texturing issue, better chance of getting the right attention and assistance in the general modding help section.

The link to the source code in the original thread is a dead link. There is no source link in your continuation thread. Nothing can be done without the source code.

Because that's not a part that they have "ownership" of, it is in another mod that they have no control over. The part in question is from SEP, which has been officially discontinued, so there is no chance of getting it renamed at source. If you'd read the post, you'd see that the goal is in fact trying to use MM rename the original part (with space in name) so that the new version won't have a space in the name.

Hey @Snark, I've been doing a bit of digging into engineer repair skill requirements and learned some things that indicate that your config needs some fixing. Specifically this part: @PART[*]:HAS[@MODULE[ModuleWheelBase]:HAS[#wheelType[LEG]]] { MODULE { name = ModuleCrewRequirement profession = Engineer minimumLevel = 2 importance = 0 } } @PART[*]:HAS[@MODULE[ModuleWheelBase]:HAS[#wheelType[MOTORIZED]]] { MODULE { name = ModuleCrewRequirement profession = Engineer minimumLevel = 3 importance = 0 } } I suppose this is based on info in the wiki re: skill level required to repair legs and wheels. However, that information appears to be super outdated -- it applies to long long ago when there used to be ModuleWheel, ModuleLandingLeg, ModuleLandingGear. They were all changed to use the new wheel system in I think it was KSP 1.1, and ever since then it looks like both legs and wheels damage and repair functionality are in ModuleWheelDamage and requires engineer level 3. It seems quite hard to "organically" cause leg damage so I wrote a small piece of code to let me trigger it manually for testing purposes //------------------ // Plugin //------------------ using ModuleWheels; namespace BreakALeg { public class BreakALeg : PartModule { [KSPEvent(guiActive = true, guiName = "Break Leg/Wheel")] public void BreakLeg() { ModuleWheelDamage mwd = part.Modules.GetModule<ModuleWheelDamage>(); if (mwd == null) return; mwd.DamageWheel(); } } } //------------------ // Module Manager //------------------ @PART[*]:HAS[@MODULE[ModuleWheelDamage]]{ MODULE{ name = BreakALeg } } And KSP complains if engineer is not at least Level 3 when trying to repair a broken leg. The BetterCrewAssignment MM patch should be changed to @PART[*]:HAS[@MODULE[ModuleWheelDamage]] { MODULE { name = ModuleCrewRequirement profession = Engineer minimumLevel = 3 importance = 0 } } This will take care of both wheels and legs -- and only gets added when their configs are setup so they can actually be damaged/repaired. If you want to be extra specific with the targeting you can add a test for cases where ModuleWheelDamage has explicit field isRepairable = false and exclude those parts. (it defaults to true if omitted) hth