magico13

@Apollo13 Are the stages being dropped before running out of fuel? I see that they're having fuel refunds. Does the mechjeb part provide control like a probe core? If it does, then that explains why they're being recovered. Two things: 1) try without a mechjeb or any other mod parts on the stage. You can do the test in Sandbox, since SR works there as well, otherwise just launch a test craft and revert after seeing the result. 2) Check the actual SR gui that is available through the toolbar button while in flight. You can see more data there and in a nicer format. It should tell you if it attempted powered recovery (it did) and how much fuel it used. There are definitely some other parts that are being dropped that aren't being recovered, so I'm starting to lean toward the mechjeb case providing control.

Glad you got it figured out For posterity's sake, I'll still answer this, because I'm weird like that. Normally all you have to do is download the last official release, then replace the .dll with the one from the build server linked on the first post. With recent changes, you're actually supposed to create a plugins folder and then put the .dll in there, while also deleting the .dll from the old release. There was a slight change in the file name and it will need to be organized like that later. The betas are purposefully a little complicated to set up to deter people from installing them without fully comprehending that they are, more often than not, totally broken or missing features. Since they build automatically whenever I make a github commit, many builds may be when I'm half way through a feature and everything is broken

Hmm, I wonder if that's caused by the change I made to use the protovessel.WasControllable (something along those lines) instead of manually parsing the ship for command pods and probes. 4 m/s is what they should land at for powered recovery, so it might be erroneously thinking they're controlled. I guess that's what I get for relying on the stock functions to work how I expect them to! I'll have to switch back to doing it manually.

You've mentioned this a few times now but I haven't seen it yet in my limited testing. I'm curious if anyone else has seen this? Could you grab me a log next time you see it, right after it happens? Looking at the code there's not many points of failure between the ship being added to the list and the window closing. The two main ones are recounting the inventory and recalculating the build time displayed in the editor (which each have their own possible failure points). @karamazovnew I'll have to re-read through that again to try to fully grasp your suggestions, but I am planning on some more tight-knit Kerbal Konstructs support in the near future, so I'll be keeping them in the back of my mind while I do that.

Like JeffreyCor stated, the output_log.text file is the defacto "having issues, need help" file for any mod. Usually I see reports saying that SR isn't recovering things it should be, not the opposite, so this is very intriguing! Those stages wouldn't happen to have probe cores and fuel on them would they? In which case they are probably being recovered through powered recovery. How low are you when you're crashing them? Are they still loaded and you see the physical explosion but are getting a message about them being recovered? Screenshots would definitely clear things up, if possible. Thanks for your help in advance!

Yes, the class and level will be listed there in the next release. I'm unfortunately busier than I had expected this week and have a fairly large change I need to make (semi save breaking, so now is the best time to do it), so its gonna be a while.

I think I need to word that warning better. If you recover a vessel the normal way (with the recover button, tracking station, etc) then the experience isn't lost. It's only when vessels are "recovered" by StageRecovery (aka, dropped into the atmosphere and destroyed), since SR doesn't use the normal recovery mechanics in that instance. I'll go fix that wording.

In the last 0.25 build I added a check on my side to make sure the event listener only acts when in the editor, so that *should* take care of it. There's a fix I need to do to make sure parachute based recovery works outside of the flight scene (fixed it in StageRecovery but forgot to transfer it back here), but the normal recovery mechanics and parachute based recovery while still in flight should be working correctly. If you've got StageRecovery installed as well then you shouldn't be seeing any issues with parachute based recovery, since the fix exists there. Also, I've decided that since everyone will be starting new saves for 0.90 anyway (most likely) then now would be a good time to revamp the part inventory. It'll push the release back, but I'd rather not break the inventory after release. I'm going to be saving more information per part (such as the part cost, and for tweakscale and procedural parts I'll be saving relevant module info), so the current system will be incompatible. I likely won't take the time to make the current system compatible. If you download the betas now, you will definitely lose any inventory parts when I make this change. There is a good chance the inventory system will be unstable for several builds. I won't be starting this process until Thursday though, so if there's a build tonight it won't include these changes.

Well, I think a very very basic 0.90 compatible version is available on the development forum thread now (thoroughly untested), but it definitely should not be used for normal use. Things are definitely subject to change between now and release. I don't recommend using Procedural Parts and the dev version of KCT at the same just yet (including RealChutes, procedural wings/fuels/fairings, etc). I'm not putting a link because it should only be used by those of you who are genuinely willing to help test it. I don't want a bunch of people to install it just to get 0.90 + KCT when it has a good chance of breaking things, so you have to do some work to find it (there are links in several locations on the forums).

Ok, fixed the issues with launching ships so it should be at roughly the same state it was at before 0.90 came out. This is really important! The file structure has changed! Delete the Kerbal_Construction_Time.dll file, add a "plugins" folder under the normal GameData/KerbalConstructionTime folder and put the KerbalConstructionTime.dll into GameData/KerbalConstructionTime/plugins I need to ensure KCT respects the editor max sizes, fix some bugs, and figure out what's going on with procedural parts before I'm ok with releasing. Then I'll see about adding time requirements to upgrades and repair.

It should be. There's a different ckan file for 1.5.2.1_2 than 1.5.2.1 which is newer, so CKAN should be seeing it as an update (assuming you refresh the package database)

If you didn't download the update within the past 4 to 5 hours then make sure you do. That sounds like the bug I fixed this morning (well, it was supposed to be lsat night but I packaged the zip incorrectly and had to do a hotfix for a hotfix)

I'm gonna try to get a 0.90 dev version functioning in the next two days (I have work, and am seeing the Hobbit tonight, and have D&D tomorrow night, so we'll see how much time I really have...) so that will at least let you start playing. But a full 0.90 release that isn't just a compatibility update will have to wait until this weekend most likely, given my schedule.

But when you recover them they will still return the same amount, which is not easy to override. So doing this would be pretty nontrivial like doing it with build times is (not that that's trivial, but I at least have exclusive control over that and don't have to fight with KSP [much] to get it to work)

If it is possible (surely it is somewhere) it's definitely not as easy. Currently it's something along the lines of EditorLogic.fetch.ship.Parts to get the current vessel. But I suppose I could take a look and see if I can grab the inactive parts as well. They've got to be stored somewhere if you can reattach them without needing to reconfigure anything.

If it's a VTOL why couldn't it land on landing legs? Hence the "L" part of VTOL.

In regards to your original question: It is correct that Stock KSP won't let you recover anything that falls outside of physics range while still in the lower atmosphere. StageRecovery is designed to circumvent that issue by checking if there are enough parachutes for it to land safely (or if the vessel is controlled and has fuel+engines). If the part wouldn't land safely then StageRecovery won't recover it. This mod doesn't change anything in the current recovery system, so if you land a craft yourself it will function exactly as it would in Stock KSP. In fact, StageRecovery uses the exact same distance requirements as Stock KSP, so if you drop a booster on the other side of Kerbin you won't receive as many funds back as if you had dropped it right on the KSC (but you'll never actually get 100%, just 98%). In short, StageRecovery only supplements the current system and does nothing to impede it. Edit: Also, "drop a booster" or a "stage" are just colloquialisms of mine. StageRecovery works on any type of vessel. If you have a space station full of Kerbals and Science that has parachutes on it, you could deorbit it and StageRecovery will recover it (and all the science and kerbals, though there's a bug right now that will cause the kerbals to lose their experience). The "normal" usage is recovering spent stages/dropped boosters (or for some people, fairing halves. Yes, you heard correctly, some people recover their fairings... ), so that's what I tend to use in conversation. (Also, the original code came from KCT where it was referred to as the "Booster Recovery Code")

Due to the fact that programmatically determining what a "stage" is is difficult (and also I just haven't had the time) it check the entire vessel as one entity. Easiest way (especially now that we have SelectRoot as stock) is to test just the stage itself. With 0.90 you should be able to set the primary part of the stage as the "root part" (so for a stack based stage it might be the decoupler or top-most fuel tank, for a radial stage like an SRB, I'd just go with the SRB. Though radial ones you may want to test completely separate due to symmetry issues, in which case there is always subassemblies) and pick up the rest of the ship so it isn't attached. Then run the test on just that stage. It requires a bit of work, but it's easier than doing a bunch of test flights generally and once you know a configuration works (like if a booster always recovers fine with two radial chutes but not one) then you can just use that configuration in the future without worries. Maybe one day I'll see about splitting it into stages automatically, but I don't have the time currently.

Try downloading it manually. I wonder if the CKAN didn't detect the hotfix for the hotfix. If on Windows, go to the StageRecovery folder and right click on the StageRecovery.dll, then go to properties. Under the info tab (something like that) you should be able to view the File Version which should read 1.5.2.1 if you're on the latest one (just checking the SR.version file won't work, since that's changed manually). If you're on 1.5.2.1 and it's not working then there's something weird going on and I'll need to take a look at an output_log file. Edit: The NetKAN bot seems to have pulled the correct one about an hour ago (I wish GitHub gave an exact time) so it's possible it did it after you installed through CKAN. Check CKAN again to see if there's an update.

Those two options do very, very different things and it's likely that people don't want to earn science for building ships so they should be separate. In fact, when I completely overhaul the upgrade system (literally will not be recognizable as coming from the current one) I'm probably going to either remove that option, or throw it in as an optional perk with the other optional perks. Also, the upgradable buildings were just released, so I haven't gotten a chance to do any integration with them, but there will be substantial integrations with them (such as VAB level restricting number of lines and maximum rate). This was something I considered when I implemented the upgrade system originally, but to avoid feature creep too much (Jeb knows there's a lot of feature creep in this mod...) I drew the line at dealing with Kerbals directly. KCT will never involve/rely on individual Kerbals (actual ones or "code only" ones). It's a great idea for a mod, but its beyond the scope I want to deal with. KCT is purely about the space center infrastructure, excluding the personnel. That's why I was planning (and had some basic work on) a Kerbal focused mod that dealt with Kerbals needing training and downtime between flights. There's a GitHub page for it, but 0.24 released which resulted in StageRecovery and I lost all time I could have spent on it. With the new class system and kerbal xp there's a chance I may go back to it so you can train your kerbals outside of normal flight.

I apparently packaged the wrong version in the zip. I just went through and fixed it so the new download should fix all the recovery issues. One of my plans for today is to get StageRecovery onto my normal build routine, which will fix issues like this, which I think I've done twice now :/

Ok, unless I messed something else up along the way, 1.5.2.1 should be working fine. I think Squad made the editor text bold face in the parachute parameter text, which broke my parser. Regarding tying to buildings, you're right, I like that a lot more than the tech tree. I like the idea of tracking station = maximum range. How about admin building (or mission control?) = percent recovered. Whichever isn't the previous one could be Maximum Value returned? Keep tossing out ideas! I've got to go to sleep soon so I'm not exhausted for work tomorrow morning, but I'll check out what you guys come up with when I get up.

I do love configurability But this actually sounds like a great idea! I could either tie it to a tech node or to a building upgrade. I don't know which would be best, so I'd like to hear what all of you suggest.

I would be surprised if Squad didn't implement a similar feature at some point, but I imagine they'd take a more "polished" approach. StageRecovery's approach of assuming best-case scenarios, while simple and effective, is probably not the "best" way of handling things. With that said, it is still much better than the current system of not handling the situation at all! Edit: I apparently didn't test something before release because I'm an idiot. I'll be putting a bugfix out in a few minutes.

StageRecovery 1.5.2 is specifically built against 0.90, so it should be working properly. Seemed fine during my testing. Kerbal Construction Time 1.0.3 does NOT work with 0.90. I'm working on remedying that, but it'll likely be a day or two.