magico13

Any commits I make get built automatically by my build server. Links are at the bottom of the first post (links to the Dev thread which links to the build server) KSP does weird things sometimes Clamps are supposed to be in the ignore list, but I might have to adjust their entry.

I had a really stupid issue with nested if statements where it was essentially requiring you to use Stock chutes in order to use RealChutes, meaning RealChutes wasn't working at all. Should be fixed in the latest dev version (couldn't test, made the change on GitHub) If oversoul wasn't on the dev version then the calculation for terminal velocity is a bit different and even without chutes you could get less than 200. When finals are over I'll work out that issue. I'm pretty sure that should be recovering, but I need to test with those parts specifically.

I think your assumption is spot on. KCT loads (and then immediately saves) the settings on scene change, so likely during the crash it just wrote some random garbage rather than the actual config. I've never seen it happen before, so I imagine it isn't too likely to happen again, so no need for a github issue. I don't package the configs with the zip file, they get autogenerated when you load the game. That way you don't overwrite any changes when you update. Since CKAN will only remove files it installs (so, not the configs) uninstalling through CKAN will still leave the config files and the Kerbal Construction Time folder. The only way to do a clean uninstall would be to make sure to delete the folder manually after uninstalling through CKAN. The spec is pretty clearly laid out, and the most important aspect of the spec is to not overwrite or delete any files not controlled by CKAN. CKAN does exactly what it should, if you know the rules of its operation. Except when it encounters an error when installing a bunch of things and it forgets what you had selected, that always bugged me, but I think has been fixed. I like CKAN, to the point that I actually back pjf on patreon each month to help its development. Tourists have a slight bug in KCT that causes issues similar to what you're describing. I've got a fixed development version, but haven't gotten the time to do a new release (I've got at least one other bug I want to fix before a new release, but it's the middle of finals week for me). If you grab the development version from here and replace the .dll in the KerbalConstructionTime/plugins folder with that one, it should work properly in the future. You might have to open up your save and change any "idx -1" to "idx 0" under any tourists to get your save back. I'm going to add a warning and a link to the first post, since it's been longer than I had anticipated for the update.

Have you tried deleting all the KCT config files and then starting the game? I'm seeing the issue below in the logs, which would explain the symptoms, but am not sure how its happening. It sounds like a corrupted config file (specifically the KCT_Formulas.cfg file) NullReferenceException: Object reference not set to an instance of an object at KerbalConstructionTime.KerbalConstructionTime.UpdateOldFormulaCFG () [0x00000] in <filename unknown>:0 at KerbalConstructionTime.KerbalConstructionTime.Start () [0x00000] in <filename unknown>:0 If that for some reason doesn't work, below is a link to the default configs. Use these instead. http://www.magico13.net/files/KSP/configs.zip These go in the GameData/KerbalConstructionTime folder directly. As the plugin works currently, that might actually be detrimental to the player. They'd spend extra points on rates that might not get used as frequently, in which case they could just buy more rates and fiddle with the ordering of their builds a bit more. The current method ensures that every rate can be used, and that the fastest rates are always used first. However, where that could work well is if you can purchase additional buildings (which I plan on doing with LaunchPads at some point). So imagine you can buy a second VAB with funds+science that you can allocate your upgrade points to in parallel with the main VAB. So if you've got 10 upgrade points in your main VAB, you could put 10 into your secondary VAB (or maybe some reduced number depending on balance). So a similar idea, but it won't hurt the player as much as splitting up upgrades more than you already can. BTW, RSS already has a similar feature as each KSC operates independently, meaning you can have one entirely devoted to building manned rockets, one for mass producing probes, and another for only building planes. I need to convert that code over to the new KSCSwitcher that Regex has made, so when RSS for 1.0 comes out KCT won't work with it right off the bat.

The implementation of RealChute Lite in nuFAR likely doesn't work properly with StageRecovery (which you guys have figured out). Most likely, StageRecovery doesn't detect RealChutes (it isn't actually installed, so the method of checking for it won't work in the case of nuFAR) but it also isn't using Stock chutes. So no parachutes will be detected at all. I'll have to write a new set of code for nuFAR, but I won't have a chance to do that for a few days. Using full RealChutes should get around the issue.

Wow, if you're getting the simulation timer in the space center scene then something is seriously messed up. If the reinstall doesn't work, please send logs (preferably with the debug messages setting enabled in the KCT settings). In the past I had seen many reports about simulations having locked cameras and it was always with mechjeb installed, but it wasn't guaranteed to happen (I tested it, and so did JeffreyCor without any incident). After several months of the issue randomly occuring for a small percentage of users, someone finally submitted a video of it. There was a mechjeb window open behind the simulation configure window, so the mechjeb lock stayed on. I submitted a report to the mechjeb developer and it was fixed within a day Stupid things happen in this game to cause problems. I have similar stories about Tarsier Space Tech and Contract Configurator having minor issues and totally breaking KCT installs.

I wonder if it's somehow specific to that mix of parts. I'll try it out next time I start KSP now that I know what the stage is. Are you using any parachute mods (RealChute for example, or FAR which now includes RealChute Lite)? You can increase the DR Velocity setting if you feel things are burning up too easily, or you can add a heatshield. Both are options. You can set the DR Velocity to 0 or a negative number to disable reentry heating estimates altogether if you'd prefer. Unfortunately how Kerbinside works with recovery is that it manually moves the SpaceCenter position when something is being recovered, then moves it back afterward. I recently added some things to the StageRecovery API so that they can do the same thing with stages being recovered by StageRecovery, but that change isn't in the official release yet and it will require a small change on their side. If it's consistently showing up wrong (which sounds like it's the case) I added a hidden setting in the development builds that lets you override the distance calculation. You make the change through the settings file rather than the in-game settings. Setting it to 0.95 would be more than fair for a majority of stages.

This and the next thing are somewhat related (though maybe not directly). Somehow an Input Lock got stuck on. That sometimes happens when there's a window behind the simulate button (like a mechjeb or kerbal engineer window). Those mods recognize the cursor is over their window and lock down the editor, but when you press the simulate button they never realize their windows disappear and so they keep things locked down. The scene changes and the locks are still active. You can either clear them manually in the debug menu, or make sure there's no windows behind the simulate button. If that isn't the case, then I'll need minimally logs, but screenshots or video help a lot with these kinds of issues. Do you have build times active as well? That knowledge will help me narrow down where things are getting messed up. The KCTGUILock should only activate when you open the simulation options window or the launch window. If that window is open, then yeah the editor will be locked, but if it's closed then that shouldn't be there. Clicking Save won't trigger that. Clicking Launch will cause it to lock, but clicking Build Vessel or Cancel will unlock it 1 frame later. When the Simulation Configure window is open it will be locked, but clicking Simulate or Cancel will also unlock the editor a frame later. The KER lock would also have similar symptoms, but should only be active when the cursor is over a KER window. Make sure there isn't a window behind the Simulation Configure window (especially the simulate button itself) when you start a simulation. If there is, that's probably the problem. If not, then video or screenshots might help. That could be an option. I could physically move the vessels somewhere. Alternatively, I could make it so you can't edit them at all and just save them as Vessel objects instead of ShipConstructs. You would literally never be able to view them in the editor or make changes, but I could let you refuel (and could automatically clean science experiments). I could maybe have both as options. You recover it as a Vessel, but can try to convert it into a ShipConstruct to make changes. As for planes pointed upward, I knew about that issue before release. The instant you click on a part in the SPH it flips forward, like it knows the direction is wrong but just needs updated somehow. If I manually flip it 90 degrees, it'll point down when you edit it. It's a fun mess.

That shouldn't be happening, as SR should be finalizing the kerbal's flight log with a "recovered on kerbin" and should remove the "died". I'll have to look into that more when I get the chance. I'll open up an issue on github to remind me. You may want to try turning off the "Tie into Upgrades" setting and seeing if that fixes the issue with kerbals losing XP. Technically it had nothing to do with the tanks being blocked. It was actually because it wasn't able to find the SAS module on the probe because the Vessel was no longer loaded. Turning off the "Tie into Upgrades" setting also would have worked, but now that should be working properly in the dev builds. If you have reentry heating active then everything in the first post applies, and like futrtrubl mentions SR checks the speed at deletion (around 23km altitude). Because KSP doesn't compute drag on unloaded vessels, but does compute acceleration from gravity, it's possible that your stage is going much faster than 2km/s at deletion. The speed at deletion will be listed in the Flight GUI and (probably) in the small message. If you feel that it's too likely for your stage to burn up (apparently the 1.0.2 heating isn't even an issue at 3km/s...) then you can either increase the DR Velocity setting (remember, it's a minimum value above which there becomes the possibility for burning up. It isn't a hard cutoff) or set it to a negative number or zero to disable it entirely. Occasionally KSP reports completely false positions for either the vessel or the KSC. I'm looking into it more, but it seems to be more likely to happen if you do non-physical timewarp or use a planet altering mod. I just work with what values KSP gives me, it's a bug within KSP itself.

CKAN lists the currently installed version number. If you're on 1.5.5 and still having issues I'm going to need logs and precise reproduction steps in order to be of any help, plus I'm going to be fairly busy the next few days and probably won't get an opportunity to turn on KSP during that time (though, when do I ever? I average about 3 hours a week of KSP time, with minimally 2 hours of that being debugging things)

Are you running 1.5.5? KSP 1.0.1 broke SR 1.5.4 with that exact problem, so SR 1.5.5 was released to fix that.

I'm pretty sure it doesn't require a parachute, just a probe core or a command pod (or RealChutes parachutes). So it should work for what you want to do. It's been a little while since I played around with it though, so I could be wrong.

In 1.0 the physics bubble was increased to 22.5km, so it's much, much easier to create drop pods or to drop probes from planes. If 22.5km isn't enough for you, FMRS might be worth looking into. It doesn't require you to increase the physics range, but lets you fly each vessel separately in, essentially, parallel timelines which are then merged together into a final timeline.

This post contains the locations for the log files (on Windows, it's in the KSP_Data folder). Screenshots of the vessel in question, and perhaps a screenshot of just that stage in the editor with the SR editor helper window would be nice. Might be something wrong with the calculation for those parts. It could be also that the parachutes burned up due to the stock heating? Or that the stage itself burned up due to SR's interaction with the stock heating. When did you drop the stage? Was it at 2km/s at apoapsis, because it burning up is probably what happened (the destruction message, either the stock one or the one through SR's Flight GUI, will indicate if that's the case). The log should also indicate if that was the case. If you've restarted KSP since that flight, you'll have to do the flight again for any of that info to appear in the log. As futrtrubl mentioned, RealChutes has options that can let you deploy chutes at various altitudes/pressures. Additionally, once finals are over for me I'll probably add a feature to have the stock chutes open automatically so you don't have to stage them at the same time as the decoupling. If you can get outside of physics range, SR doesn't require that chutes be deployed for recovery, but it sounds like in this case you can't get far enough away.

That whole system is a bit buggy, due mostly to the fact that KSP isn't really designed to go from an in-flight vessel to a craft in the editor. Numerous things can go wrong in the conversion, and I imagine mod parts make it more likely to get messed up. My only suggestion would be to quick save before you recover the craft and if something goes wrong, load from the quicksave and try again. There's code in there to place the vessel on the ground, meaning it shouldn't appear in the ceiling, but like I said, the whole system is bound to have problems. I might be able to fix/reduce some of the issues in the future, but it'll always act kinda funky. My own disdain for that feature doesn't particularly help it's development either, unfortunately, but I spent a lot of time on it and it's a giant pain in the butt.

Not to be that guy, but why not go into the setting and mute the music when you need to (without having to close KSP or even switch scenes)? I can imagine there might be some use for a one press mute key though. Very nice!

It sounds like I might be able to make simulations with RT still have control. That would be awesome, so I'll probably add that (or enneract will in HoloDeck).

Powered recovery was definitely having issues detecting probes with SAS (checking the modules on each part in the Vessel apparently doesn't work, I had to instead check the protoModuleSnapshots on the ProtoVessel), but it should be working properly (including checking for SAS capabilities) in the dev version I posted a page or so back. So even if he included a probe, it probably wasn't detecting it. Just to drive the point in more, the log files would have told me that right away As for parachutes helping with powered recovery, as futrtrubl pointed out, it uses the terminal velocity as determined after parachutes. So you could use a small chute to drop the terminal velocity from 200m/s down to 50m/s, which would only require 75m/s of dV instead of 300m/s. There's probably an optimal mass of parachute to use to maximize the total dV of a stage, but I don't really want to try to calculate it right now Oh, and if a parachute drops the terminal velocity to below the minimum cutoff, then the powered recovery won't kick in at all, if that wasn't already obvious

Thanks for the report. There's probably a set of data that isn't being reset when exiting a save. New saves tend to make that worse, since the OnLoad event doesn't happen for them during the first load. Sounds like it's pretty easy to reproduce, so I should be able to fix it pretty easily when I get a chance to work on this again. In the mean time you'll have to restart KSP prior to starting a new save (but not when switching between already existing saves, that should still work fine).

It was something I had considered putting in, but just hadn't done so. I'll add it in the next time I work on Sensible Screenshot. When you're not flying a vessel, would you rather have it use the current in-game time or would you rather it just be set to 0?

I'll have to look into that too, thanks! I'm going to start logging the lat/lon as well when things go to be recovered. Something is definitely not right with it fairly frequently.

Right, so I have to manually split those costs and masses up into individual parts for it to work with KCT's inventory. Right now if you have the container in your inventory, all the parts inside it are considered to be in the KCT inventory as well, meaning you don't really have to pay much for their build times. By splitting it up you'll have to start paying in time for anything not in the KCT inventory.

Are you making sure that you go into the tracking station and select a launch site before you start building things? You should only have to do that once, when you start a new game. If you don't do that everything gets put into the "Stock" KSC which you can never switch back to without save file editing. Also, like I mentioned above, the build list will appear empty in the tracking station, but when you switch back to the Space Center everything should show up. If you're still having issues, come to the KCT thread and we can talk more (I don't check this thread very often, but I'm on that one all the time).

Flags also aren't "flying" or "suborbital" so that's especially weird. Let me know if you see it happen again, it's minor enough to not be an issue but if the ignore list isn't working properly then THAT is an issue Thanks!

No worries! I haven't taken a look at regex's KSC switcher code yet, but it should be simple enough to port over what I've got to the new one with just a couple changes to a few lines of code. It'll also solve (or at least seriously reduce) some issues people have been having with KCT and RSS when there's only one launch site (nothing too bad, just the KCT window being blank in the tracking station when people use the 6.4x config or other similar configs). Glad we're on the same page now And though I won't be able to get started on it for a few weeks, if you guys have any requests for the KCT API, let me know on this github issue.