DoktorKrogg

This is mostly for @Wyzard but to others following along as well: The converter changes made in the latest version of USITools (and thus all mods in the USI suite that rely on USITools, i.e. MKS, USI-LS, etc.) were necessary because the previous implementation of swappable converters could not support running the same recipe in multiple bays simultaneously on a part that has multiple bays. You could set all the bays to the same recipe but you would only get the output of a single converter. This ended up being a result of the way the system was designed, not a bug. So the only way to fix it was to overhaul the entire system. Unfortunately, the new system just isn't compatible with the old way of doing things. We could have left the old code in to ease the transition but what would have likely happened is that other mods would have never gotten around to updating their parts to use the new system and then a year from now, when we finally decided to remove the legacy code, a bunch of mods would have broken and no one would remember why. Better to tear that bandaid off now in my opinion. Breaking changes are as much a headache for us as they are for everyone else. We try to avoid them if we can. I play KSP with mods that integrate with USI-LS as well and will be impatiently waiting on them to update (or writing the PRs myself if I get too impatient ). In the meantime, I'll be enjoying Assembly Plants that can make Machinery in all 3 bays at the same time. The good news is that updating part configs is pretty easy and I'm sure the other modders would happily accept pull requests. I'll be glad to help anyone who wants to take a stab at helping the other modders get their mods updated to work with the new converter system.

I just submitted PRs this afternoon to fix the multi-bay converter issue you described. Turns out it was a design issue, not a bug, so I had to re-engineer how swappable converters work just to fix this one issue. The good news is that the new system will give us more flexibility in terms of what a multi-bay converter can do and opens up some interesting possibilities for future parts. The bad news is that all the converters in existing saves will reset back to their defaults and shut down. @RoverDude already made a post explaining how to minimize your pain if you choose to upgrade an existing save. We're also adding some new in-game settings to allow you to adjust the cost of swapping converters (all the way down to 0 if you want), as well as toggles for the EVA-only and RepairSkill requirements. The official stance on backports to previous versions of KSP is that we don't do backports. That said, I have been testing these converter changes on both 1.4.5 and 1.5.1 simultaneously while I've been working on them and so far I have run into no issues. So once we do finally put out a new release, just try it on 1.4.5 and see if it works. Chances are it will. Just don't come back here qq'ing about bugs in 1.4.5 if there are any because we probably won't fix them.

There might be one or two people who will be happy to hear that I tracked down the cause of the GUI issues that sometimes occur with Orbital Logistics. Just submitted a PR with the fix. I tacked an enhancement onto the PR as well to show the available amount of TransportCredits in the part action window (aka right-click menu).

It's the resource consumed by Orbital Logistics. https://github.com/UmbraSpaceIndustries/MKS/wiki/Functions-(Logistics)#orbital-logistics-within-a-sphere-of-influence

Since OrbLog is working in a new save game, then to fix your current save game, I would suggest: Make a backup copy of your save game file. Open the save game file in a text editor. Find the ScenarioOrbitalLogistics section. Make a copy of each of the TRANSFER sections. Delete all of the TRANSFER sections from the save game file. Save the file. Start the game, see if the error has gone away. If the error has gone away, then exit the game without saving. Go back to the text editor and start adding the TRANSFER sections back to the save game file one at a time (save, start game, look for error, etc.) until you find the one that's causing the error. My suspicion is that there is a transfer referencing a vessel ID that doesn't exist in the game anymore and that's making the dynamic UI generation for OrbLog to fail.

Sorry there's been no response to your posts regarding OrbLog yet. I actually wrote that code. I have been mulling over what the problem could be but I'm coming up blank. If this was an obvious bug in the code, then lots of people would be having this same issue. As far as I'm aware though, no one else has reported this problem. So since no one else has reported this issue, I'm thinking it's a version mismatch or some kind of incompatibility with other another mod. If you download your mods via CKAN, I'd recommend downloading from GitHub instead (making sure to grab the correct version of MKS for the version of KSP you're currently running). Also, you could try starting a new save game and see if you are able to reproduce this problem. If you are able to find a set of circumstances that always cause this issue, then that will be a huge step toward finding a solution. If we can't reproduce the issue on our end, then it's basically impossible for us to troubleshoot. To answer your question specifically regarding manned vs. unmanned, the OrbLog code currently doesn't perform any crew checks. It probably should but currently it doesn't. Side note: If you're still on KSP 1.3... I'm not actually sure the last version of MKS we compiled for 1.3 had the latest OrbLog code in it or not.

@RoverDude Couldn't the text on the DIY kits be applied as decals?

I expect we (and by 'we' I mean @RoverDude ) will be putting out an MKS update soon™ with the new GC binaries bundled. Thanks for the update, @allista!

I ran into this same issue with another mod a couple months ago. Downloading the source and compiling it myself seemed to get Defender to stop complaining. So this may just naturally work itself out in the next release.

Yeah the idea with OrbLog is that you have a central transport hub to handle getting stuff into orbit. Of course, that doesn't stop you from having a more distributed network but that does mean you have to create TransportCredits at each station. Just comes down to personal preference there I guess. (PS we plan to allow Kerbals to be transported via OrbLog as well once I get around to writing the code for it, so that's another thing to consider if you want to 'future proof' your current saves). In terms of being able to transport resources between SoIs, we are working on that too but it won't be part of OrbLog.

Considering the amount of content Squad has provided FOR FREE since the initial release of the game (including this update), accusations that they are just going for a cash grab with the DLC are completely ludicrous, unfair and ungrateful. The folks at Squad have to like, you know, eat if we want them to continue providing us with improvements to what is already a fantastic game. So to that end, please Squad, take my money.

Unless a certain blue haired elf can manage to stop playing games long enough to get some of the other stuff done we've talked about adding to OL.

I feel like we need a bot that just looks for the word 'Kerbalism' and automatically replies so we don't have to keep answering this question every other day.

Ditto. Never been a fan of CKAN. KSP-AVC ftw.

I don't think it will ever be our intention to break saves if we can avoid it but in the case of pre-releases in particular, we can't promise that there will be an upgrade path from the pre-release version to the final version without running into a problem or three. I commend your discipline in being able to resist clicking those download buttons in KSP-AVC as soon as they appear. I cannot.

@Puckpuck @Urses @voicey99 and anyone else who cares... Don't get too attached to how Orbital Logistics works in the pre-release. It was marked pre-release for a reason. We have already talked about making some potentially save-breaking changes to it. So if you want to help us play test it and help us find bugs like resources not being transferred, etc., that is certainly encouraged and benefits us all. But please, please don't dump hundreds of hours into a save that is dependent on any pre-release feature we put out. They are subject to change and I can tell you for sure that Orbital Logistics is going to undergo some changes before final release.

Unrecoverable failure is probably not going to be a thing, at least not in the first iteration of the new wear mechanics. We're leaning toward something more along the lines of what you just described here (i.e. part will go offline until you spend the necessary resources to get it working again). If at some point in the future we made unrecoverable failure a possibility, it would definitely be a difficulty setting the player could toggle on or off (likely off by default) and it would only be a consequence of habitual neglect, not just a random event. In other words, it should always be preventable. It would only happen if you chose to risk it. I would also want there to be some kind of advantage to be gained by taking that risk. I currently don't have an answer for what that could be though. So that's another reason I don't expect we'll be including permadeath as an option at this point. I still like it conceptually just because I think it would increase the entertainment value of people's Twitch streams but we need to have a better justification for it than that. Yes.

If you have permadeath enabled in your settings, yes. You would have to figure out a way to work around it (GC, construction ports, KAS, whatever). If you have permadeath disabled, parts can be overhauled an infinite number of times. If you're the type of person who likes their base to look a certain way, then yeah I can see how trying to tear a part out of the middle of it would be problematic. I was thinking more along the lines of leaving it and putting the new part on wherever you can find a spot for it. I think maybe an easier way to simulate reliability issues is to increase the consumption rate of ReplacementParts. @RoverDude can explain better than I can but my understanding is that the primary goal is to decouple wear from efficiency completely. The reason being, that it makes the other complimentary mods (USI-LS specifically) easier to balance for both players who use them with MKS and players who use them standalone. I think the plan is for Machinery to still affect efficiency as well. It just won't be consumed anymore. (Which is why I like the idea of having it be consumed as part of an overhaul. MatKits too. Gives you a reason to keep making them.)

Ulterior motive... now that Ground Construction is a dependency, I like the idea of giving people a built-in reason to use it. @Nergal8617 nailed it, making it optional is the key. (In case anyone missed it, in-situ deployment of DIY kits is coming.) If it's a fixed hit to efficiency, that would probably be alright. Gradual degradation is the sticking point. Totes. Enjoy your free ride while you can, Drills. It may not last forever.

Some follow-up thoughts on wear after sleeping on it and reading thru responses... Having a part fail because you neglected your base should hurt. Is having an unrecoverable failure in a core structural part of your base too severe? Some would say yes, others would say no. (I personally think a little chaos makes things more interesting, otherwise we're just playing Spreadsheets in Space.) Easy solution: Make unrecoverable failures a setting folks can toggle on or off in their save. We already have configurable failure states for Kerbals who run out of of supplies or hab time. Wear could work the same way. I don't really like the idea of gradually diminishing efficiency as a failure state. That just puts us back to square one since that's how Machinery works already. I do like the idea of part overhauls. ReplacementParts could be consumed for maintenance, Machinery/MatKits could be consumed for overhauls, with overhauls being the way you "reset the health bar". I particularly like this idea as a way to allow for the concept of replaceable drill heads.

Sorry, I'm kind of late to the party on the Machinery discussion (fell behind on my daily forum digest emails). I'm glad to see it sparked a lively discussion! I don't really have a ton to add that hasn't already been brought up but I went back thru our previous conversation in the USI team chat and thought I'd pull out some of the highlights to move into the discussion here: Currently, Machinery plays several roles. It lets you reduce the launch mass of parts (MaterialKits also do this). It affects the efficiency of the part. It simulates wear by being consumed over time, thus reducing efficiency. What @RoverDude is ultimately proposing is that we decouple wear from Machinery and simulate it another way. Machinery would still be "like MatKits, but for parts that do something", i.e. still a way to lower launch mass and still affects efficiency. It just wouldn't be consumed anymore. Whereas MatKits are consumed when you use them to build something, Machinery would stay around forever, allowing you to move it around your base to tweak the efficiency of parts. Frankly, removing wear from the efficiency calculation makes our lives easier when it comes to balancing and maintaining code (especially in regard to keeping MKS and USI-LS as separate, yet complimentary mods). It makes base planning easier too. We want to keep the concept of wear and tear though. So really what we're asking is, how do we simulate wear if not with Machinery? A couple possibilities: Give parts a lifespan and when that timer is up, they stop functioning forever. (I like this idea for smaller parts like drills and the Ranger bits.) Bring back ReplacementParts as a consumable. As long as you have a staffed workshop and keep ReplacementParts around, your base will continue to function indefinitely. (I like this idea for larger parts.) If you choose not to have a staffed workshop or don't keep enough ReplacementParts on hand, you run an increasing risk of parts breaking down the longer you let it go. I tend to agree with the concerns people have expressed in regard to overlap with mods that simulate random failures. So I'm not in love with the third option in that list. I think instead, we could just give every part a "health bar" that drains on a timer (it could be slightly different for each part to avoid having your entire base shutdown simultaneously). For smaller parts, like drills and Ranger parts, when the health bar runs out, the part is used up. Find some way to replace it (KAS, OSE Workshop, recycle it and deploy a replacement via GC, send replacements from Kerbin, whatever). For larger parts, the health bar stays at 100% (or at least depletes much slower) for as long as you have a staffed workshop and a steady supply of ReplacementParts. Fail to meet either of those requirements, and the health bar starts to drain on them too. In all cases, the health bar can never be refilled. Once you let it hit zero, the part is broken forever. I think the "failure state" for larger parts could just be a severe efficiency penalty as opposed to complete shutdown (this could be a setting). And/or it could just consume ReplacementParts faster until it's replaced. I also agree that it would be ideal to have some kind of an alert system for parts that are about to fail/have failed. I have some ideas on how to implement that.

Just an update on the virus situation, I've had no more complaints from Windows Defender since compiling my own versions of the dlls from source.

Getting the same thing here. Windows Defender on Windows 10. It doesn't like SCANsat.dll or SCANsat.Unity.dll. Tried to download the compiled version again from GitHub and Defender blocked that as well (warning in Chrome that says Failed - Virus detected). Downloaded source code from GitHub and recompiled on my machine. Seems to be happy now. I'm part of Team USI, just fyi. Love SCANsat! Never play a save without it.

If you're playing with something like the Galileo Planet Pack and have it setup as a second solar system, saves easily expand well past 50 years if you aren't using warp drives of some sort. I believe it's about a 200 year journey from the Kerbol system to the Ciro system.

I've always thought it would be nice to have a nursery module of some sort that is required for making kerbabies where you can control birth rates. Seems that it would be fairly trivial to just add another specialization called Child for Kerbals who aren't old enough to work yet. It would also be nice to add a mechanism to the academy module that allows the player to setup ratios for the types of specializations you want in your colony that affect what job children take when they become adults. Would make the academy a more relevant part of a base, IMO.