magico13

Vessel storage is still KCT only (for now at least, I've got longer term thoughts about that), ScrapYard only handles individual parts

@larkvi turn off the automatic creation of KAC alarms in the KCT settings and it should go right through everything else and only stop at the item you warp to.

That's a question for the KCT thread, not this one, but that feature still exists. Land a vessel anywhere on the home planet, then open the KCT window to the VAB or SPH tab and click the "Recover to Storage" button. You'll probably want to then edit the vessel to refuel it.

The latest dev builds have the ability to right-click a part and replace it with an inventory part, and also have the ability to scrap parts without having to load the exact part into the editor (you do still have to load a basic copy of the part though, for now). There are a few issues I'm working on where the modules don't copy over properly. For instance, if I place a command pod and then try to apply a tweakscaled version of it from the inventory on that part, it'll copy the module but the part won't physically change size.

So I'm like half a modder?

That sounds like something I'd need a log to diagnose. Check the linked forum thread for the log locations.

You are correct, it is the internal level which for stock maxes out at 2. The correct formula should have ([LM] - [L] + 1) in the denominator so that a level one pad (0 internally) in Stock should give (2-0+1) = 3, and a level 3 (2 internally) would give (2-2+1)=1. In stock that would cause the first pad to have 1/3 of the rollout/reconditioning time of fully upgraded one, the second pad level to have half of a full one, and the last pad to have the full amount of time. With 4 levels it'd be a quarter, a third, a half, and full.

RSS should work fine, but you still can only recover on the home planet (Earth in this case). Static beacons are in a file called Beacons.cfg in the NIMBY folder. It won't be generated until the first time you load a save.

I somehow keep missing details like that, sorry. You're not entirely out of luck, assuming you're running the last build for 1.2.2 from GitHub, try grabbing build 55 from the build server. It might fix your problem if it's an issue with the dry cost being slightly off. RP-0 is still for 1.2.2 so I'm already maintaining KCT for both, so I might end up back porting everything to 1.2.2 for ScrapYard once I get a full release ready.

Ah, ok that makes a bit more sense. It's not that it isn't entering the inventory, it's that it isn't properly being pulled out of the inventory. Are you on the latest dev builds? If not, do that first. I am very curious if pulling a command pod right out of the inventory would cause the same issue, and you can pull individual parts out of the inventory in the latest builds. If it isn't matching then there are a number of causes for that. I'm guessing the dry cost isn't agreeing for some reason. I can give you a build that will log even more stuff if you want, which would help figure out where it isn't matching.

EditorTime is extremely simple, just a single source file. The actual code that changes the time in-game just looks at the change in real time since the last run, multiplies that by the "time ratio" and then tacks that onto the current in-game time. Warping would just be changing the time ratio, plus you'd want to have the UI update. The real issue with warping is stopping the warp at important times (like Alarm Clock alarms), which is something that should be implemented at the same time. Thankfully KAC has an API for that, but I haven't felt any real desire to spend my time on Editor Time when I've got other stuff to work on. EditorTime source: https://github.com/magico13/Modlets/blob/master/EditorTime/EditorTime.cs KAC wrapper: https://github.com/TriggerAu/KerbalAlarmClock/blob/master/KerbalAlarmClock/API/KACWrapper.cs

You can except certain parts by name or parts by module templates to not enter the inventory, but it also doesn't hurt to have parts go into the inventory if you're not playing with the "override funds" option. Let me know if you want any help with excluding anything. I suggest looking at the part blacklist and excluded module templates in the ScrapYard folder (also in the GitHub repo)

@EvilMurk it's probably not too happy about downloading executables from a strange website that isn't really linked to anywhere. I do wonder what specifically it has an issue with.

@FishBone it's most likely the recon/rollout formula. It divides by (3-[L]) or something like that to make it so earlier launchpads have less reconditioning time. With stock at level 3 (internally level 2) it works fine, but going to level 4 would make it zero and a divide by zero happens. Just change the 3 to whatever the highest level is, or remove that whole division thing if you don't want the rollout/recon to scale with launchpad level. I really need to add a max level variable (if I didn't already...) and use that instead in that formula. Edit: I've now added a max level variable and updated the default formula to use that. I'd now recommend replacing the "3" with "[LM]"

@linuxgurugamer they've been compatible since April.

The log, assuming you're on Windows and using the 64 bit version of KSP, is in the KSP_64_Data folder and is called output_log.txt

It would actually be pretty easy to do since all of the passage of time in the editor is handled by Editor Time. I just haven't gotten around to it yet

They do have that config installed it looks like, based on the log, so @FishBone please try out that updated version of Custom Barn Kit and let me know if you're still having troubles. I worked out a lot of kinks with KCT and CBK in some earlier builds so I'd be a bit surprised if there are still more (although, at the same time not that surprised). Also, thanks for the log, it's appreciated. One minor thing (kind of addressed to everyone), KCT's version file isn't updated regularly right now so don't rely on its version. The version in the file doesn't change between builds so all of the builds from the build server have version 1.3.9.0. The real version is baked into the .dll and is visible in the properties if you right click it. In your case you're running 1.3.0.35, or just build 35. That's a more useful version number, but the log has it too so it's not a big deal that you get the mention the right one as long as you provide a log.

I have a feeling the (int)(n*20) returns 6. I ran into that problem when supporting Custom Barnkit in KCT. So my guess is something along the lines of "Test 6 6.9999999"

If you're using the Apply Parts button and it changes any of the parts, that will absolutely affect the build times. It will result in something that was already completed now having to be partially rebuilt so the parts can be swapped out for different ones.

If you change the name does the same thing happen? Ships are identified internally by a unique ID, not by name, so the name shouldn't matter. But I wouldn't be surprised if the BP value got miscalculated when editing, since editing is a bit tricky internally.

I have not fully tested it, but it should still remain in the inventory but you just can't interact with it at all. When I make it possible to view the entire inventory then you should still be able to discard/sell the part even without having the mod present.

I realize it's been a while since I've posted any new updates on this, but I just committed some code that makes the part selector functionality mostly functional. You can't see what modules are on the parts yet, but you can see the number of uses and can select to use specific parts. It's definitely still a work in progress however. I am hoping to do a full release after I get that UI completely up and running and will have to work on overriding funds after release. Right now this new functionality is only in the dev builds.

I did a little bit of work on NIMBY tonight but it's not quite ready for release, probably tomorrow. I fixed a bug where it was accidentally using a longitude instead of a latitude in an equation which resulted in incorrect distance measurements, and I also added a WIP module for mobile recovery beacons. Right now they require ModuleManager, a command pod, a science lab, and any antenna (including the built in one, I want to change that to a bigger one though). They also only work when within 2km of a vessel, in the flight scene only, and cannot recover themselves. I'm trying to get the flight scene requirement (they have to be loaded) eliminated since it also is causing them not to show up as the closest beacon when they're more than 2.5km away. You can grab it from here if you want to play around with it before I get it finalized: http://magico13.net:8080/job/Modlets/ Edit: The NIMBY update is now released and doesn't require the vessel to be loaded to work, meaning it will work from the tracking station and will properly tell you if a mobile beacon is nearby.

Jenkins is failing to load after an update it appears. Working on it now. Edit: So that was extremely frustrating. I have no idea why it totally stopped working, but I couldn't get it to work even if I went to an earlier version. I ended up using this as an opportunity to learn about Docker, so now Jenkins is running in a docker container on my server. I had to do some configuration changes to get it working, but it appears to be functional again.