magico13

There was a similar issue in Release Candidate 2, but it was fixed for release. If the vessel isn't even being removed from storage then there's likely a bug that is preventing KSP from loading saves completely (could definitely be my fault), and I'd need to see the output_log.txt file to figure out what it is.

I'll admit, the procedural parts support didn't get a very thorough testing. I'll have to take a look at this. Are you using full Realism Overhaul, or just procedural real fuels? This was an issue with launching from the tracking station, but I believe I disabled that, and it shouldn't be happening when launching from flight or the space center. Can you send me an output_log.txt file (check this post if you don't know where it is located) after causing the issue to occur, perhaps something will be logged there that explains what's wrong.

Well, I technically said that it does not not work, meaning there's no bugs that I know of, but it's also not explicitly supported. Basically, they both have no idea the other one is there, so they both work just fine, but the balance between them is a bit skewed since a base with 5 kerbals can build ships faster than the entire planet Kerbin can. They work just fine together other than the balance issues, sorry if there was confusion.

Are they the stock launch clamps? Is there anything else attached to them (lights, etc)? When they are going to be recovered, there is some debug text that appears in the output log file, so if you can get me that file I should be able to tell if it's at least trying to recover them. The best way would be to load up a game, launch a craft with clamps attached, fly up at least 10km just to be safe (though only 3km is really needed), then revert the flight, exit the game, and send me the log. You could alternatively just send me a log from a normal play session when there were clamps in use, but that means I have more to sift through.

It doesn't not work with EPL, but the time requirements are very different. EPL's build times are way shorter and are mass based, while KCT's are longer and are cost based.

It should be turned on by default, but you do need to go a couple hundred meters away for them to get unloaded and recovered.

I haven't seen any new reports recently, so I'm going to release the latest RC as the official 0.90 update. Here's a rundown of the changes since 1.0.3: v1.1.2.0 (12/26/14) - Fixed issue when toolbar mod is used instead of Stock AppLauncher - Fixed issue when recovering parts that have no modules on them - Fixed rollback that's happening after launch when rolling out new vessel v1.1.1.0 (12/23/14) - Fixed tech tree issues with TechManager trees - Fixed several issues with rollout and rollback, but added new ones it seems v1.1.0.0 (12/22/14) - Update for KSP 0.90 - Build List got a redesign - Added vessel rollout - Added support for RSS - Added basic support for Procedural Parts - Small change to file structure (added plugins folder, renamed .dll to remove underscores) - Fixed several bugs - Check the GitHub commit log for more. This took a long time. Get the download from the first post!

Well, you could set up an Eve orbital simulation with the orbit near the SOI edge, then use an extra stage to deorbit and burn toward the surface. Not exactly what you're suggesting, but a decent substitute

This eliminates the ability to remove or add parts through docking and staging, or damage from crashing. I don't care for the limitations that method creates, and it removes the feeling of reusing the same exact vessel. We'll see though, since it certainly would be easier. I had a method of turning an in-world craft into a craft file, but 0.90 broke that and I need to find a new way.

I was working on a similar feature (recovering straight into storage) but was running into issues, which 0.90 made worse. It was going to require at minimum the rollout time, and at maximum twice the rollout time, based on distance. Normal recovery isn't trivial to "overwrite" but I likely will try to add time requirements to normal recovery as well. BTW, if you revert to the editor after launching a vessel, it will still be in storage, meaning you can then edit it and make small changes without having to totally rebuild it. It'll save you a lot of time. If you're on a no revert save, then you'd need the feature I was working on, which I'm going to try to get working again, possibly for the 1.2 release. Edit: Release Candidate 3 I've still got a few things to test (supposedly there's an issue with real fuels that I need to look into), but I've built another Release Candidate that should fix some other issues I've been informed about. http://magico13.net:8080/job/Kerbal%20Construction%20Time/lastSuccessfulBuild/artifact/KerbalConstructionTime.zip v1.1.2.0 (12/26/14) - Fixed issue when toolbar mod is used instead of Stock AppLauncher - Fixed issue when recovering parts that have no modules on them - Fixed rollback that's happening after launch when rolling out new vessel

I thought I fixed that issue in build 48 (which is after RC2). I've seen it reported twice before and both cases said that recovery worked fine with build 48 but not RC2. I might get a chance to do some work today, but as you can probably imagine I've been a bit preoccupied the last few days. I was under the impression that it was due to the part not having any part modules, but maybe it's also something else. Edit: Build 49 (whatever the latest is now) added some additional checks which should hopefully help prevent this. JeffreyCor (or anyone else) can you check if real fuels volatiles are boiling off when they shouldn't be (ie, liquid oxygen)? I though that was fixed, but someone was reporting it wasn't on github.

The low cutoff is the speed needed to get 100% recovery (if its 6 and your stage has a terminal velocity less than 6 then you'd get 100%). The high cutoff is the speed needed to get any returns at all. Above that speed you get 0% returned. Between those speeds you get a fractional return, following the curve in the last image of the imgur album on the first post. If you need more explanation, let me know. Its generally best to leave them as-is, but you can tweak them as you feel appropriate.

So far it has been an enjoyable one. I'm playing some mostly Stock KSP in 0.90 to get a better feeling for it. The new contracts have required me to do some weird maneuvering, like trying to get below 8.5km around the Mun while going orbital speeds all for a crew report worth 0 science Also, due to the still broken Outsourced Science strategy I have way more science than I can spend (I unlocked Tier 2 R&D, bought everything I could, then still had 6000 science left). I'm low on funds though. The fix for the rollout issue was simple, I just had the removal code in the wrong place so it was removing the rollout, then loading the save file (thus recreating the rollout). I just had to move it to after the save being loaded. But I also fixed some other issues I saw in some logs.

I'm partially responsible for the Trajectories API being a thing in the first place, so I intend on using it in the future. I was contacted earlier by an author of another recovery mod about increasing compatibility, which may have some fun implications in the future and might help solve some problems with SR's recovery methods.

It looks like NP uses the normal parachute module, so I'm not 100% sure what the problem is. You can try the version I'm about to link, which might work instead. http://magico13.net:8080/job/StageRecovery%20Development/4/artifact/StageRecovery/obj/Debug/StageRecovery.dll

I think I've fixed the issues with rollback (and a couple other issues), but I'm not making a new Release Candidate until everyone in the dev thread has had a chance to test it out a bit. As for the issues you mention Athlonic, the Build List GUI isn't supposed to be draggable anymore since KCT is going along a stockalike route, meaning all GUIs appear fixed in the top right corner under the button. I can make it appear open if when you left the KSC screen it was open, but I generally found that to be more annoying than clicking the button again only when needed. As for your suggestion, it is possible to do but requires a bit of code to handle reconditioning/rollout differently from ship building along with my least favorite task of GUI design It's not too hard to differentiate between a ship and reconditioning, but that section is designed for quickly viewing/warping to the next "thing" to finish. You can warp to the completion of a specific ship or technode, btw, by clicking on the asterisk button and then clicking "Warp To".

I think I've fixed the crop of problems that have been reported so far. I'll let you all do a bit of testing on it before I make it RC 3.

And by squashed you mean that I made the tech not get disabled until the R&D window is closed or the scene changes. Which hopefully won't have any weird repercussions.

The condition for deletion is atmospheric pressure above 0.01 atm, which is about 22km altitude. Since unloaded objects don't get physics applied, no atmospheric effects are applied, so the path you see in map view is the path it takes. When the object gets deleted, then SR looks at the latitude and longitude of it as reported by KSP. For whatever reason, KSP often doesn't report these coordinates correctly. I'd like to manually determine where the path intersects with ground level (still doesn't account for atmospheric effects though), which should hopefully help prevent that issue. I'd also like to integrate with Trajectories to use that for determining landing location after atmospheric effects. Eventually I'd like to provide the option of keeping physics loaded on the ships until they actually land.

Uploaded a new Release Candidate with improved rollout/rollback mechanics and potentially fixed issues with TechManager tech trees. Here's the link again: http://magico13.net:8080/job/Kerbal%20Construction%20Time/lastSuccessfulBuild/artifact/KerbalConstructionTime.zip I haven't gotten a chance to test everything thoroughly, so let me know if you find any issues!

Welp, I feel silly. I accidentally left some code in that doesn't work in 0.90 for a feature I was working on but ran into issues with. I had planned on keeping it available if the user had the "Debug Messages" setting active, but 0.90 broke all of it so I meant to disable it. I apparently missed a spot, but it should be fixed in build 45.

All .Anything files/folders are hidden in Linux by default. CTRL-H will let you see hidden folders, or you can press CTRL-L and enter the path (without the file itself, so end with Program/ ) to go straight to the folder. Or open a terminal and type "cp (the path from above) ~/Desktop" (without quotes) to copy the file to your desktop.

The first thing is a non-issue, KCT can't check for updates but that's not too bad. The second thing is a concern though, but I'd really need to log to figure it out (since the in-game log doesn't print stack traces). From the post linked in the first post, here is the location of the log on Linux: ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log

Linux has a different file. There should be a link in the first post to a post that explains where all the logs are. On Linux it is called player.log (I think). Take your time cause I'm away from my computer for a bit

Upload the log to Dropbox or some other file sharing site and post the link here. Make sure its the output_log.text file and NOT the KSP.log. If you're using the development builds, make sure you're on the latest one. I'd suggest using the 1.1 release client posted in the main KCT thread instead for normal play. Here's a link to that post: http://forum.kerbalspaceprogram.com/threads/92377-0-25-Kerbal-Construction-Time-1-0-3-%2810-17-14%29-Unrapid-Planned-Assembly?p=1622986&viewfull=1#post1622986 Edit: @JeffreyCor and other testers, I am still making some changes in the dev version so they can get tested before being put into another release client. I just did one that should fix issues with rollout status being lost when reverting and with the TechManager trees not letting you upgrade past the current one.