magico13

May's Patreon poll is now open until the 5th of May: https://www.patreon.com/posts/9607929 This is a poll where my patrons can decide what they want me to work on for the month of May. For April I focused on KCT and ScrapYard and was able to make significant progress on getting a working part inventory system up and running. A public Beta build of ScrapYard (rather than the Alphas that are available now) should be available soon (as soon as I finish some configuration work, which might take a few days with testing). What I focus on in May is entirely up to you! I likely won't post when new polls are available on my threads in the future, but people may have missed that I started a Patreon last month so I am mentioning it again. I will make a post when I decide when the May live stream will be, since that's open to everybody

@MarcAFK should be corrected in the latest build now. Whenever a part gets removed from the inventory it will also be removed from the currently active editor vessel. Unrelated but avoiding a double post, May's Patreon poll is now open until the 5th of May: https://www.patreon.com/posts/9607929

Did you check the actual build time of the second vessel? The UI isn't currently updating but upon build everything will recalculate. See my rather long update on last week's progress (quoted below). Also, a small thing, rates != build times. Rates are how fast builds progress and are very different internally from build times, which are the BP value of the vessel divided by the rate. It's a nitpick, but it could be confusing to say one but mean the other since I could end up looking for bugs in a totally different set of code. As for Kerbal levels not working correctly in formulas, I'll look into that. Most likely a simple fix.

Let me know if you see it again. I haven't seen that exact problem before but it might have to do with the rate caching I was doing. Not sure

Hmm, looks like it is actually something failing when trying to save the KCT data to the persistence file but I'm not sure why. That only happened the first time you were in the editor in that log, the second time it was fine.

There was a breaking change a few weeks ago. You either have to update both or downgrade both. You can go back to the previous release of magicore if you don't need the time change or the new event, or update KCT which should be pretty safe to update.

Technically just MagiCore, but there was a breaking change a few weeks back that requires a newer KCT version as well. Easier just to grab the latest KCT as it includes the updated MagiCore, but you can always try just updating MagiCore if you really want. It'll break pretty fast if you've got the wrong versions together. The change I made to MagiCore is to not use a hardcoded 6 hour day or 24 hour day based on the KSP Use Kerbin Time setting, but instead to get the number of seconds per year/day/hour/minute from the KSPUtil.dateTimeFormatter under the assumption that that's how the time was being changed (at least in regards to the UI). If that's not the case then I'll provide a config that lets you set an arbitrary number and I'll have to make another change to MagiCore to accept those settings.

Yes, the latest dev build should hopefully (crosses fingers) work correctly. If not, let me know over in the KCT thread or the KCT dev thread and I'll sort it out.

You can either turn off failed recovery messages entirely (I do, I just use the main GUI if I care about anything failing to recover) or add all the parts to the ignore list. If a vessel contains only parts on the ignore list then it won't print a message.

@Akira_R I don't believe I've made any save breaking changes within KCT, but I don't recommend adding ScrapYard quite yet. Adding KSC switcher to an existing save would result in no longer being able to access the "Stock" KSC. The fix for that is to rename it in the save file. It shouldn't break anything else though. I can't say that I've tested that in a long while. Edit: MagiCore was updated on the build server. If you grab the latest KCT from the Beta build then it should have it already. That should hopefully use the correct times.

@Akira_R I am guessing that the change I suggested above would automatically work with those mods, since (if I recall correctly from working on BROKE) there's a "seconds per day" value in KSP that is likely set by those mods to get everything to display correctly for maneuvers and such. If I use that rather than a hardcoded value based on the Kerbin Time setting then it should just workTM. As it stands, KCT's display of time (internally it is all seconds, as you guessed) is actually handled by MagiCore which is the one with all of those hardcoded values in it. MagiCore doesn't have a config file and arguably shouldn't, but could be refactored to allow an arbitrary number of seconds per day to be passed along, in which case you could change it in KCT's config if I add that feature. But I likely won't add that config option if the automatic stuff works as I expect. If you're up for testing things in the next day or so I'll probably have that up and running in a few hours, I've got some other stuff to take care of first.

I think I can get the length of a day out of KSP rather than checking for the Kerbin Time setting and using a hardcoded value. Cool thing is that it's a MagiCore change so KCT shouldn't need to change for it to work. Unfortunately some recent breaking changes made to MagiCore means new versions aren't backwards compatible with KCT 1.3.4, but it is compatible with the dev builds of KCT. I can backport the change if that's needed. I have to see if what I'm thinking actually works in the first place.

Is that a standard flag? I should be able to do that pretty easily tonight but if you'd rather do it yourself and submit a PR, it'd be here in the GetAvailableCrew method. The development branch is the one that's most up to date. I'm really considering getting rid of that branch after the next release and just doing everything in Master now that I actually use source control correctly, especially with the build server up and running again Edit: Updated to not grab kerbals who are inactive. Also MagiCore updated to not hard code lengths of time for days/years

In general I'm seeing some unexpected things regarding half of the max building upgrades being set to -1 and half set to 2 (Personally I was seeing them all set to -1 in the editor and 2 in the space center) which I'll have to add in some code to work around, but I didn't see anything crazy going on around decoupling. I did realize I need to put some logging around the vessel tracker, so there's a bit more in the latest build. Nothing (other than the building upgrades) obviously screwy in general though.

It's an interesting problem. I think it'd have to be fixed in both, though I could maybe fix it KCT side by manually calling functions within KK. So, it used to work great and you could rollout to wherever you wanted and it would launch without issues. Then something changed in a KSP/KK update so that only the current KK launchsite would work correctly and all other ones would catastrophically fail. I did find in my personal testing after the issue first started that as long as you load the KK launchsite once per game session before trying to launch with KCT from the site then it would work for the rest of the game session. So I'd just fire up a simulation at the desired site before actually launching later. I'm not sure if that's still the case, but I don't think it's as difficult as that other post makes it out to be, but again I haven't tested it in a while. I'd like to fix it so it isn't as ridiculous, but I've obviously been working on other, arguably more important, stuff lately

As far as I know, it's still an issue.

Part tracking is pretty much only at KCT build creation, KCT build completion, and rollout (or just rollout without KCT). Post rollout KCT/SY shouldn't be doing anything. Definitely shouldn't be anything on separation. Feel free to send me some logs and I can check if something is happening on separation.

Are you running any other mods? Try with just KCT+ScrapYard first. Could be related to RecoveryController and StageRecovery+FMRS if you've got those three installed. I haven't seen that, but I also have a rather beefy computer.

I haven't done anything with decouplers. Can you elaborate? Long delay as in build time or as in they work differently during launch? If it's build time then nothing has changed at all. Maybe the decouplers are really cheap, or if you've got scrapyard and have built a bunch of things with decouplers then that would reduce their build time

There's no code to override the cost visually yet. That will require a lot more work and I haven't officially started on the "override funds" feature yet. Right now it's got function (as in the costs will get worked out correctly overall), but not form Unfortunately for sandbox it's not going to do anything for now, but the Trello has that tentatively set for 2 weeks from now, after the first Beta.

There is now. I haven't actually tested if it reads the config correctly, but a config file will generate after the first scene change now (ScrapYard/PluginData/ScrapYard.cfg). That will likely change in the future, but I figured I could at least make that really quick. Also, there's a new dev version of StageRecovery that supports ScrapYard now. Oh, to everyone, if it wasn't obvious, ScrapYard requires ModuleManager but doesn't currently come with it. I'll fix that later, but if things aren't working right and you don't have ModuleManager, that's why

For the first, as of right now ScrapYard doesn't override funds. It's been set up in a way that should let it, but that setting is off right now and the UI wouldn't actually update (yet). For the second, yes I plan on integrating the two but I haven't gotten a chance to yet. I can make that happen pretty quickly, maybe even tonight as a dev build.

Alright. I know there was a build of the dev version that had this problem so make sure you're up to date. Build #15 should have fixed that issue.

Is this with the 1.1.3 version or the 1.2.2 dev version? The only way I can think of that happening is if the persistence data isn't loading correctly, which would be a pretty major bug. Or if the vessel is just not being removed, which is also a fairly big deal. I'd definitely like to see logs if you can provide them, preferably with the "debug logging" setting active in the KCT settings.

Another quick update regarding ScrapYard and KCT. Per the ScrapYard Trello I am a bit behind schedule. Some IRL stuff came up this week so I didn't get to spend as much time on things as I wanted, but it's not a serious set back. I also spent a bunch of time working out some bugs and integrating KCT and SY together. The good news is that KCT and SY are at the point now where they work together, but not every case has been covered (scrapping works and even doesn't count as a "recovery" so it can be used for ordering parts to put in the inventory, but I haven't looked at what happens with recovering a vessel to storage). I'm very happy it's gotten to this point where it's actually almost a functional thing with only final tweaks and improvements needed. One fairly major change is that instead of parts automatically being pulled from the inventory and applied to the vessel on rollout, the inventory is applied within the editor and then the parts are removed upon build (either KCT build or rollout). It may not sound all that different, but it's a decent sized shift from how the inventory worked previously. It also opens up the option to have a UI that lets you grab specific parts out of the inventory and place them on vessels. For now there's just a button that will automatically apply the inventory to the vessel in the editor. There are a few known issues that I'm going to try to fix regarding that change. Symmetry is a problem, since if you pick up a part that's had the inventory applied then all symmetry partners become "fresh" parts and you have to reapply the inventory if you want them to be inventory parts, which makes it harder to manually define which parts should be new and which should be from the inventory. That will still be an issue (potentially worse even) when it moves to the UI that lets you select individual parts. There's also an issue where when you build a vessel in KCT the parts in the editor will still appear as if they're pulled from the inventory, but those parts are already removed from the inventory from the previous build (it makes sense when you see it, basically it's "cache invalidation"). I've got a solution in my head for that, basically to just replace them all with fresh parts whenever the parts are removed. The main other feature I wanted to have at least partially done by now is a way to define which modules are tracked. That's not done yet. At this point I wanted to just have the ability for the user to make a list of modules in a config file. That's ultimately a really crappy way to do it but it's the way it works internally right now. That causes problems with parts before and after installing/removing a mod being treated differently than before (for instance, if you track tweakscale (true by default) and then install it later, suddenly your entire inventory is no longer valid since they don't have the tweakscale module on them). For the tweakscale problem I'd like to just not track the module if the scale is the same as the default scale, but there's not a good general way to do that. Also, it might not be a good idea to track every part of a module, but instead just the relevant ones (the current scale for tweakscale, for instance, but if "staging" is different then that doesn't make it a different part). Also, the PartUpgrades system is defined by a node within every module that is empty by default. ScrapYard needs to track that inner node for every module but is currently not designed to do so. I don't want to hard code any exceptions, instead making the system general enough to handle everything in a user-defined way. As such, I don't think I'm going to even do the basic "here's a list of modules you can change" since that's just going to be rewritten anyway. The proper way of implementing this system is gonna take a while and I have to figure out exactly how to make it work. For instance, how does a user in a config file say to track the TweakScale module only if the default scale on the node is different from the current scale, but in a general way that also works for other modules? I've got ideas for it, but I need to play around with it for a while until I find something that I like that isn't also a pain to use. There's my weekly wall-o-text about progress. TL;DR: Slightly behind on the configuration front because I want to do something better from the start regarding module tracking. KCT and ScrapYard are working together now but it's not finished. Feel free to test that out on a save you don't care about and let me know how broken it is Keep in mind that everything is still Alpha quality and there's a 95% chance it'll break stuff.