magico13

Is there any chance you can make a copy of your KSP folder and remove all mods excerpt ScrapYard? Given that I and others can run it just fine in 1.3.1 it seems like it's some sort of interaction with some specific mods. I can still make manual builds, the build server just builds and packages every change I make so it's extremely convenient.

Yeah, the main drive stopped being recognized all of a sudden. The main components are about seven years old so I'm going to try replacing all of them, so it won't be back up for about a week

Hmm, you're definitely running the latest so I'm not sure why it would crash there since you're also on KSP 1.3.1. Unfortunately the log doesn't say what mod it was loading when it crashed, but it doesn't look like it loaded the ScrapYard settings, so it's definitely possible that's the cause. Let me verify the .dll in the download is correct and I can upload a new one if needed. Edit: It says it's the same version but just to be safe I uploaded the exact .dll I've been using with 1.3.1. Try it again and let me know if it happens again.

All the builds for 1.3.0 still work with 1.3.1, but anything I put out now will be built specifically against 1.3.1 anyway. So yeah, it'll work https://github.com/magico13/KCT/releases That definitely doesn't seem right. Are you scrapping while in the VAB/SPH? Does it work properly outside of the editor (so in the Space Center)? It's definitely unintended. Can you upload the KSP log file after recreating the issue?

Yeah, sorry about that. The build server stopped recognizing my main SSD again but this time it appears to be the computer's fault and not the SSD. It was running on 7 year old components that had been active continuously for about 5 years, so I decided it was time to upgrade. I get the components this week and it will be back up next weekend. I can post the most recent build if needed.

We're not that bad!

Yes, in fact the latest build on the build server is compiled against 1.3.1.

There's a recompile available at http://magico13.net:8080/job/ScrapYard/ but I haven't gotten a chance to test it yet. If someone wants to give that a go I'll make it available on GitHub as well. The part selector UI is still a work in progress and has some known issues with things like TweakScale, so be careful if you decide to try that part out.

I think I got you right, I was just commenting that the reason that this is the only mod of mine breaking (everything) is because it's the only one I have that uses the stock settings system. If it's just a recompile then I'll have that fixed tonight.

Someone else just mentioned that the stock settings system changed in 1.3.1 so that's probably why this is breaking and not my other mods. About your Dangit idea, it sounds like something that would be a good companion plugin, not something I'd put into ScrapYard itself. ScrapYard is definitely able to store the MTBF but you'd need a separate mod that would alter it upon storing it in the inventory and would somehow affect the failure rate. I'd recommend it to Dangit first, since they'd likely be able to listen to the events that ScrapYard throws and handle it better than anybody else. Those events might need to be tweaked to allow another mod to affect the part before it is stored, or I could make a OnAboutToBeStored kind of event that fires before storage processing occurs for that kind of handling. Done right they wouldn't even need to reference the ScrapYard API at all.

That explains why ScrapYard is totally broken then since it does use the stock settings system. Good to know, thanks.

Thanks for letting me know. I'll get that fixed tonight since I need to get the 1.3.1 dlls on the build server. Funny enough, I'm pretty sure I saw the same problem when I accidentally updated to 1.3.1 and hadn't had a chance to figure out which mod was causing it.

Try setting UseToolbarMod to false in StageRecovery's Config.txt file. I can't look at the log currently but I wonder if you've somehow got two installs? At the very least setting that setting to false will cause it to use the Stock toolbar instead, so hopefully it shows up. Looks like it doesn't recognize the engines. Does RealFuels use a different Engine Module than ModuleEngine or ModuleEngineFX? I vaguely recall that they do, which means StageRecovery wouldn't support that right now. That's just some debug info for figuring out what mod (SR or FMRS) should handle recovering the stage. If you don't set a particular stage to be recovered by a specific mod using Recovery Controller then FMRS and StageRecovery will try to automatically determine who should handle recovering the stage. Because no mod was set and FMRS isn't active then StageRecovery decided it would attempt recovery.

1.3.0. I haven't put the 1.3.1 dlls on the build server yet. I'm not sure if the current builds have been tested with 1.3.1 yet either (I haven't tested them other than that time I nearly broke my save by updating from 1.2.2 to 1.3.1 without realizing it).

Yes. Both of those. Somehow the avionicsTechLevel value is null, which isn't valid, so it throws an exception. But ScrapYard should probably catch that exception and handle it. It may also be due to the way ScrapYard interacts with the module. I'm not sure of how to fix it off the top of my head and I'll likely have to set up an environment where I can reproduce it, which might not be for a while.

I'm assuming that's KSP 1.2.2, in which case I'd recommend this build since it's the last for 1.2.2: http://magico13.net:8080/job/ScrapYard/55/

It's basically stable. I was going to try to have a full release of ScrapYard and then release this, but I've been busy lately and haven't finished it. Plus the RP-0 folks have a branch with some changes they wanted and I was going to merge those in when they were done. Pretty much just those two things at the moment are holding it back.

Build server's back up! Had to get the main SSD replaced since the last one died after a year. Thanks to the fact that I set Jenkins up using Docker last time, it was pretty painless to get Jenkins running again (also since I didn't lose any data when the drive went down)

There;s an overview of all that here if you're interested. It's a little out of date but is mostly correct and it explains what all the variables are and what the formulas do, although some like the build rate formula do a lot that isn't directly mentioned (since it also affects rollout/reconditioning and also KSC upgrades)

If you add it right now you should be given all of the upgrade points automatically for the nodes you've already unlocked. Since you have a tech tree with more nodes than normal, you're going to be way over on upgrades so you might want to up the overall multiplier to balance that. There are about 60 stock nodes so if you set the overall multiplier to about 2.5 (2.67 actually) then your times should be better balanced against what is "stock". I'd try out a few different values until you find something you like, RP-0 tends to prefer longer build times so you might decide to up the overall multiplier to 5 or more. Reconditioning (and rollout) is dependent on the VAB build rates. As you increase those rates the reconditioning times will go down automatically. Assuming you mean 0.05, change the BuildRateFormula so that it is (just remove the "([ I ]+1)" part at the beginning): (0.05*[N] + max(0.1-[I], 0))*sign(2*[L]-[I]+1)

It should be the same as the last build from the build server. If you're already running that then you don't need to update, but with the server being down I needed to provide an alternate download location.

Both of you please try the following build (1.3.5.91). It is a manual build of the latest code. https://github.com/magico13/KCT/releases

The latest build can be gotten from GitHub here https://github.com/magico13/KCT/releases

Yes, my ssd primary drive suddenly stopped working and now I get to wait for the RMA to go through. I can get a build of it up today, though if you're looking for the 1.2.2 build you can also grab that from SpaceDock (accidentally said the old site, which is apparently filtered out)

StageRecovery appears to be running just fine, but I can't tell how you're trying to test. All of the messages I see from StageRecovery are on vessels that are being destroyed by crashing into the terrain, which means you didn't get far enough away from them. Are you making sure that you're dropping the stages from a high enough height and getting far enough away that they unload before they crash? If not, try setting the parachutes to deploy at 0.4 or 0.5 pressure and stage them when you drop that stage, they should wait to deploy until they get closer to the ground but that will hopefully let them survive.