magico13

A ship being completed causes all of them to recalculate, ironically it's because of the part inventory/part tracker which isn't currently in the mod. Unfortunately, the only way to fix it is to either roll back to a previous save (KCT makes one when you recover to storage that you could load) or edit all of them in the save file since they're all stuck with the new BP value. You might be able to "edit" them and get them to reset, but you'll probably lose any progress you made on them. That's an interesting bug with the edited ship that I'm not sure I can actually fix since it's buried within Stock code. It would prevent saving the ship at all. If it was recovered from flight then I'm not all that surprised though, since KSP doesn't natively allow going from a Vessel to a Craft file. If you revert or have to do this again in the future, instead of speeding up build times or modifying settings just modify the BP value of the ship in the save file while it's being constructed. Just open up the save in a text editor, search for the ship name and look for a line like "BP = 8234723.3723" and change the number to something fairly low. Then open the save and it should be nearly complete. The line in the save might be something different since I don't have a save file to reference right now, but it should be close to that.

I finally got a chance to take a look at that log. Unfortunately it's not pointing me toward anything useful I'm guessing it's a mod interaction but I can't tell with what from here. I'm really sorry I can't be of more help. If I get a chance I'll see if I can test the parts visible in the screenshot.

There was someone who had an issue with the flashing before which is why there is an option to limit the maximum warp that KCT will use. In the end they decided to just warp in the Tracking Station, since you can also warp in that scene and in flight. Unfortunately there are issues with launching from the tracking station and so that had to be disabled, so it's a bit inconvenient to swap back and forth. The node not showing up is an annoying graphical thing that happened with a KSP update. KCT used to show them when you opened up the R&D window, but that got messed up a while back and I never found a work around that I liked. You can safely unlock the node again and it won't cost anything. I can't leave the node as "purchased" because then you'd get access to the parts, so I manually lock it again, but the way I unlock it no longer updates the R&D UI right away. It seems like I might have to unlock it before the R&D screen opens. I may be able to tie into an event if there's one that fires between the button press and the UI opening, instead of using the event that fires when the UI is opened.

Can you post any pictures? What happens if you use just StageRecovery and RealChute and no other mods? Try testing without a decoupler at all. Are the decouplers from a mod? Can you post any of the log files (look at this post and scroll down to see where the logs are on disk)? It's likely a mod interaction. It could definitely be related to non-stock decouplers that use a different module (you did say you're using RO mods). Logs would show if any errors happened (if it's giving exactly 200m/s then that sounds plausible) and would provide some info that I could use to try to pin down what/where things are messing up at.

It's certainly possible since I just recently made some changes to reduce the likelihood of that happening. Make sure you're on the latest version (at the very least version 1.6.6, but you'll really want to update to fix a few big bugs) and if you're not going to ever use Kerbal recovery you can disable it in the settings (at the Space Center, click the SR button and turn off "Recover Kerbals"). If you were already using 1.6.6 or later then it looks like I've got another edge case to take care of. Unfortunately my plan of putting the Kerbals back into the ship if it wasn't destroyed within 10 seconds is proving to be more difficult to implement than I originally expected. There were some recent changes to KSP that make playing around with crew assignments more difficult since they have fairly strict verification checks now that I've had some trouble with.

The log confirms what I was thinking might be happening: it was calculating parachutes first, then if there was a chance of burning up it would reset the terminal velocity. I'm testing the fix now. Edit: Fix uploaded. Should be all that's needed for that to start working again. Chance of burning up is calculated first (with powered reentry burn if needed), then terminal velocity with chutes, then powered landing if required.

Does it actually say it burned up? Logs?

Either way you wouldn't have such high terminal velocities listed. It maybe could be calculating them backwards, I had that happening in development but I fixed it. Basically it would calculate with parachutes correctly, then recalculate for the burn (since Vt was calculated before change of burning up previously) and change the terminal velocity to be ~2000. The log would confirm that, since the two calculations have very clear debug messages. I'll try to test that again tonight I guess.

Hmm, weird that it sounds like RealChutes is working but sometimes not (hey, they added a face for that finally!) Could be RealChute itself I guess... Btw, for stages that are burning up like they'll now do a "reentry" burn if they're controlled. Same mechanics as powered recovery, but it'll first drop the speed to the DRMaxVelocity setting to avoid burning up.

Did those have RealChute parachutes as well? The chance of a 2069 m/s stage burning up is pretty low, but you should definitely get a message if that was the case. It looks like it's not recognizing the chutes, but it's recognizing that a realchute module is used. Could be related to the changes I made that were supposed to fix an issue with RealChute. If you get a chance, logs would be appreciated and I'm curious if the editor helper tool works correctly.

The Wiki on github is definitely the best resource, but if you want a simple change like that you can just change the Overall Modifier from 1 to 0.25. That should divide all the different rates by 4. Do keep in mind that KCT is already balanced against stock days and not Earth days. There are some remnants of when Earth days were the only option for displaying time in KSP (Kerbin time was added in 0.23.5 if I recall correctly), but all the actual balancing is for Kerbin time.

Well, that appears to be an actual error, not just the harmless one that pops up. Looks like it's not working correctly with RealChute I'll get that fixed tonight.

Alright, it's in the development branch right now but I haven't actually tested it yet. As of right now it's just one method that takes a List<Part> and you have to split into stages yourself. I need to think of a good way of representing different stages without using any custom classes (probably just a ConfigNode) and then I might add in another method that does the splitting automatically. If it's not really needed then I won't even bother with that.

I might be able to get it transitioned tonight but I'm not sure when the next release that would contain the change would be. I can shoot for by the end of the week.

It's not in the best of places and I've been meaning to move it to a more general place. There's no way for you to call it as it's too baked in. Here it is while in flight and here it is in the editor. Note that neither are working exactly correct with Stock stuff for some reason and I need to try to figure that out. The stock stuff is derived from RCS Build Aid. I'll move the calculation stuff at the very least into its own method (it should be moved anyway) and I'll figure out a way to tie it into the API so you can just pass in a Vessel (or just a List<Part>) and get an estimate straight from StageRecovery. I'll do it two ways so that you can pass an entire Vessel and have SR split into stages based on decouplers, or have it treat the entire passed Vessel as a single stage (in case you want to use Ship Sections or are alternatively determining stages).

The functionality was rolled into Stock KSP with 1.2. It's now an option in the game settings. Older versions are still available under the "No Longer Maintained" header of the OP.

No, I just apparently didn't see it. I was personally preferring returning null as "not implemented" and empty list as "none at this time" but both should probably be treated the same anyway.

It's a StageRecovery change. Before 1.2 it was using a really rough approximation based on some data I had collected. But now it actually uses the drag cubes of the vessel and parachutes for it's estimates. It should be pretty much exact, but for some reason the calculations are still a bit off. I believe they're closer to what they should be than they were before though.

It should be, but it's certainly possible it somehow is being omitted. A simple test would be placing a single part in the VAB, running the editor helper, then adding a drogue chute (or 12) and then running the editor helper again. If the estimated speeds aren't noticeably slower, then it would appear as if it isn't being included correctly. The save file would be appreciated! As mentioned by others, uploading the save and log files to another site like Dropbox is generally preferable to posting them here.

It's definitely possible. If RO uses a different module than stock does internally then it won't recognize it at all. It should recognize different materials though. The DR velocity definitely has to be tweaked for RO though, since 2000 is way too low. Keep in mind that there's no drag on the part when out of physics range but still above the cutoff altitude for automatic destruction, which is the only time SR activates. Ie, there's a lot of extra velocity that shouldn't actually be considered. Drops from high altitude at a low angle are the worst for burning up since it will be going really fast when it hits 25km altitude without any drag applied. It's velocity at destruction, which you can watch by hovering over the vessel as it falls in map mode. For now just up it manually. I'll probably add in retroburns for powered recovery sometime soon and mark that as 1.2.2. The current version should be working fine in 1.2.2. 95% of the things StageRecovery does only happen after a vessel has 1) left physics range and 2) gotten low enough in the atmosphere that KSP deletes it. If those two criteria aren't met, then there's a really good chance SR won't act on it. For stock KSP, physics range is 22.5km from the active vessel and the atmosphere cutoff is about 25km. Also, make sure you've got enough fuel in reserves (it can be locked if you keep a small tank for it) for powered recovery, but it sounds like you've got that covered.

The tracker and the inventory were very nearly the same thing, so when one went so did the other. The next tracker will hopefully be much better, if I end up implementing it the way I have planned.

For the 1.2 builds right now, until a new inventory system is up and running, both I and U are always 0.

In the build for 1.2, nowhere since it isn't tracked. In older builds it'll be in the save file in a node called something along the lines of "PartTracker" inside the "KCTData" node.

There's actually three @johnqevil also helped out for a while and is the one who made the mod this was based off. We all kinda fell off the face of Kerbin for a while. I'm totally for this mod continuing, I just don't know that I'll have time to help much.

Honestly, I wasn't planning on working on this any more. There have been quite a few new entries into this space that are pretty good and I've already been bad enough at maintaining my fully functional mods. However, if you (or someone else) wanted to cover maintenance I maybe could swing it. I need to unbreak KCT before I even consider looking at this though, which means getting an actual release AND a new inventory system. The fact that OnLoad runs so much earlier than before also broke KCT (I think it now runs before Start). I managed to work around it there (off the top of my head I don't remember what I did. It was either moving into Awake or doing better instantiating of things so they don't break, or moving some of the OnLoad code into Start. I don't remember.) I also had to redo how I create the scenario, but that might not be an issue with BROKE depending on how we did it. I vaguely remember doing it the "correct" way for BROKE using attributes instead of manually inserting the Scenario like KCT did. Your solution might work and sounds like the "better instantiation" fix by just moving the actual entities out of Start/OnLoad and updating their state at the appropriate time. OnLoad will run before Start, but I think the first FixedUpdate runs afterward. Though FixedUpdate should check for a valid state before doing anything anyway. It shouldn't be too hard to basically lazy load everything and just not act on anything until a valid state is reached, if that's how you were proposing doing things. For some similar alternative mods, see: (Monthly budgets covers a lot of what I wanted to do by default, but isn't as "core frameworky" as this)