magico13

@WuphonsReach If you edit your posts I think they still show up as new posts in the "following" stream on the forums, instead of double posting I'm back to work today so I won't be able to get to things until I get home later. Thank you for testing things for me, an extra set of eyes helps a lot more than you'd expect. I'll fix the bugs you've mentioned with the names not being updated during upgrades (I could have sworn those were done by id and not by name, though the upgrades themselves have names I think and I'll have to update those). New launchpad cost is given via a new formula that defaults to "100000*([N]^3)" so 100k, 800k, 2.7M, 64M sounds about right. Might be a little high, but the first few pads are pretty reasonable I think, and it's freely adjustable. All the upgrades use the stock costs for upgrading. I want to improve the KAC support in the next update (after this one), but I can at least make those changes in this one. All KSC upgrades don't complete until you return to the space center scene because the building cannot be upgraded in-game in any scene but that one. The upgrades just sit at 0 until you switch back, otherwise the upgrade won't "go through" and you'd have to pay for it again and go through the time requirements once more. Launch pads are the one thing that could be an exception since they're handled differently by KCT. I might not change that so that everything stays consistent.

Was that with two pads that you switched between? The whole upgrade timer system is setup in a hacky way and I had to add an even more hacky workaround for switching launchpads. I wouldn't be surprised if there were some bugs like that, I've already squashed a ton of similar ones. If you find a way to reproduce it let me know. I wish I could override the upgrade buttons on each building and write my own code to handle the upgrades, but I can't. I could make a new GUI to handle upgrading the KSC but I'm trying to integrate into the stock system more (which is a giant pain in the butt when most of it isn't [easily] moddable).

Look into the UpFree Preset (comes with KCT). Everything is defined by the KSC building levels rather than upgrade points. If you want to customize things a bit more then look into the Preset formulas. 1.3 will have variables for kerbals too (those currently at KSC and all living ones) if you wanted something more like ExtraPlanetary Launchpads Edit: @WuphonsReach those issues should be fixed now and you should be able to rename launchpads to whatever you want (I'm an idiot and forgot to include their level. One minute) [Edit2: Done as of build 176]

@WuphonsReach I'll look into those issues. Maybe I'll add a way to rename launchpads to whatever you'd like them to be named (which would have some slight problems if I didn't update everything correctly, since their names are how they're referred to internally).

That sounds like you're missing a command pod/probe core. Is this during a simulation or an actual launch (build -> timewarp -> rollout -> launch)? I highly suggest grabbing the log file (read the following post, it contains the log file locations and other info I'll need) and uploading it somewhere so I can view it. Without the log I can pretty much only guess at things, so you'll have to be thorough with your reproduction steps. Edit: Regarding your edit: was Jeb actually in a command pod? The hitchhiker module and several mod parts don't provide the ModuleCommand module. I'm pretty sure KCT doesn't warn about missing a control source.

Yes, it only counts kerbals who have the status "Available", aka those at the KSC. Engineers that are off in space can't really contribute to the construction of a vessel. I could see arguments for scientist kerbals still providing a benefit to tech research when they're off in space, so I'll probably add another set of variables for all living kerbals, just to provide options

I made a gif showing an extremely brief overview of how the multiple launchpads work, in case anyone is interested. I also fixed a few bugs regarding the "damage state" of the launchpads. Some more testing and things should be ready to release soon. https://gfycat.com/PiercingEasyAnglerfish

The Tracking Station actually does factor in, but it starts with penalties and has the "standard" at Tier 3. Tier 1: MaxDist is cut in half such that recovery is 98% at KSC and 10% a quarter of the way around Kerbin (and any further distances) (about 1000 km up to 1/2 way around Kerbin which is ~1900km) Tier 2: MaxDist is 3/4 normal. 98% at KSC and 10% at 3/8 of the way around Kerbin (about 1400km) Tier 3: MaxDist is normal (1/2 Kerbin circumference). 98% at KSC and 10% at 1/2 Kerbin (~1900 km, the absolute maximum distance from KSC you can get) StageRecovery should never give higher returns than a manually landing, so I went with slight penalties for lower tiered tracking stations. If you recover stages near KSC nearly all the time then the differences aren't even noticeable; it only comes up for recoveries that happen far away from KSC. Here's a chart that demonstrates all this: Edit: Released version 1.6.2 which should fix the issues with the Heat Management mod and fixes a bug where things that unload below 23km aren't added to the Recovery Queue (the thing that makes pre-recovery work)

Anyone want to do me a huge favor any test out a development version of KCT? I think it's ready for release but I'd like a few more eyes on it before sending it off into the wild, especially since some of the features were programmed way back in August and haven't been touched since then. Major changes: - Multiple launchpads! You can purchase additional launchpads so you can launch multiple things in short succession (each pad has its own rollout and reconditioning). Each one is upgraded independently (they all start at level 0) and there's a new formula to control the cost of building a new pad. - Kerbal stats added to several formulas. [PiK], [EnK], [ScK] are the number of pilot, engineer, and scientist kerbals currently at the KSC. [PiL], [EnL], and [ScL] are the total number of pilot, engineer, and scientist levels at the KSC. Using this you can set build times to be based on how many engineers you've hired, for example, or tech unlock speeds based on the number of scientists. - Warnings when ships are missing parts (from uninstalled mods) rather than breaking the game. Allows you to safely remove them from the save and provides a list of all missing parts in the save folder. - Improved support for KSCSwitcher. No longer requires changing the KSC when starting a new game. Upgrades can be shared between KSCs differently (normally each KSC gets its own upgrades, with this you can make them all share a single upgrade pool). Each KSC can have its own separate launchpads. - All time entry fields (simulation length or UT for example) now support y,d,h,m,s instead of only a colon formatted option. So to have a 3 day, 15 minute simulations you can enter "3d 15m" instead of "3:00:15:00" - Delay before moving to orbit in simulations is adjustable - Wheels, Goo and material bays are properly reset on recovery to storage - Tech node research cancellation must be confirmed before being cancelled - "Warp To" uses the stock Warp To functionality. Ends faster, but doesn't reach as high of speeds for short timespans If you're gonna run it on your main save, back up the save first. The launchpads change was save breaking for a while. I'm pretty sure I fixed that though. Get the development version from here (grab the .dll from "Last Successful Artifacts"): http://magico13.net:8080/job/Kerbal%20Construction%20Time%20Development/

Alright, I think I fixed it now. StageRecovery expects things with ModuleAblator to have the Ablator resource on them (aka, heat shields), but the radiators from Heat Management use a different resource. I've changed StageRecovery to now look for whatever resource is defined as the ablativeResource in the ModuleAblator on the part. If you grab the latest .dll from the build server than I think it should work properly for you

Hmm, unfortunately those modules don't seem to provide the info I need in an easy to access manner so I'd have to do a pretty decent amount of work for them to work with powered recovery. This might be an instance where FMRS might serve you better. I'll make a not on GitHub to look into supporting those in the future though. I'll have to dig around in the source code of whichever mods add those modules to figure out how to extract the info I need. Can you upload that section of the log again? I'm curious if it made it any further in the process. I didn't get a chance to change up the code today like I had planned, though there are already checks that should prevent anything from happening unless the vessel is either packed or unloaded (and I'm not sure explosions can happen in either case, though maybe in the packed case). I'm still having trouble wrapping my head around what is happening and what could be triggering the error.

@CatastrophicFailure Funnily enough the error message popped up because the message telling you there's something wrong with the ship tried to use a skin that wasn't valid. Build 169 should fix that, so you shouldn't see the "your game is totally screwed" message anymore. Build 169 should pop up a message letting you know the stored ship is missing a part (or a few) and provide the option to ignore it or delete the vessel. If you delete it, you should get the funds returned. Currently it only pops up once even if multiple ships have parts missing and it doesn't tell you which parts are messed up. I'll probably change that tomorrow so it writes a file listing all the vessels and all the messed up parts and I'll see if I can get it to do one message per ship. Jenkins is a build server software. Sarbian uses it as well. CKAN uses Travis, which does basically the same thing but isn't hosted on your own computer. My Jenkins build server is the same one that runs my (currently totally broken thanks to mono) website and stores a bunch of my files and it sits on my desk behind my right monitor. What it does is automatically builds the source code into a .dll whenever I push a commit to GitHub. Makes it super easy to have public betas, since I never have to touch anything to release them. If you look at the other projects available on there, there's also projects for KCT and StageRecovery that build the .dll from the source and create a .zip file automatically so that all I have to do when making a release is grab that zip and upload it to all the sites I host things at. I could probably integrate KerbalStuff and GitHub Releases into the build script so that whenever I push a release build it automatically updates those, but I like doing that manually for now. Those projects only get built when I push a commit to the "master" branch on github. I do all my development work in a development branch which is what the "KCT Development" and "SR Development" projects watch for changes. It's super handy and cuts down on the amount of work I have to do for releases and the amount of things I can mess up (I messed up a few SR releases pretty badly before setting up Jenkins) Failed builds are just builds that for whatever reason couldn't compile. I generally test compiling code before committing it, so they're infrequent. They most frequently happen when there's a KSP update and I update the .dlls I'm referencing on my desktop but not on the server (so it builds code for 1.0.5 against 1.0.4's .dlls, for instance). Other times they fail because of connection issues with connecting to GitHub. Other times it's because I messed something up on my server.

Yep, same link as before. If you'd rather wait I'll probably have another one tomorrow that will avoid trying to process exploding things.

@smjjames are these things just blowing up, not going out of physics range? SR shouldn't really even be activating on those, but I can't think of a good way to avoid that off the top of my head right now. I surrounded the code that's currently throwing an error in a try/catch block so it should move past that part now, but I'm half expecting it'll hit a snag later on in the processing. If it does, let me know. I might have to come back to this tomorrow when my mind's fresher because there's probably an easy way to filter these situations out.

@smjjamesthe fps drop might be because of the exception spam. You're seeing StageRecovery exceptions still being spammed with that new .dll? Can you upload the log again? There's not anything else I can think of that would be null and causing that exception

@amo28 alright, this time the vessel isn't having powered recovery do anything, presumably due to the engines. Can you upload the craft file you're using? I'd like to see the ModuleEngines in use. I'm adding some more debug code as well so if you can try out the new build when you get a chance and upload that section of the log again, I'd be grateful. There aren't any changes other than additional logging.

@amo28 and @smjjames, can you try out the latest .dll from the build server (just click the StageRecovery.dll file under "Last Successful Artifacts")? I think it should fix the problems you're both seeing (hopefully). If not then I'll do some more experimenting.

Science equipment itself is already reset, but the animations should be too. I'll look into adding that one myself, so don't worry about it too much. When I find it I'll post back here Thanks for taking the time to figure out wheels, seems like it's a pretty simple one to add! Edit: Well, I figured it out but it possibly has larger reaching effects. The module is ModuleAnimateGeneric, which a lot of parts use, meaning all animations that use that module would get reset. I'm going to see if I can easily come up with a way of defining which parts to reset the module on (so you specify the goo and materials bay parts in the KCT_ModuleTemplates.cfg file as well) so that way it doesn't reset everything. MODULE { name = ModuleAnimateGeneric animTime = 0 } Edit 2: In the latest dev version I've added the ability to restrict which parts a particular module reset works on. It won't hurt anything to add it into the file now though. The "parts =" line defines which parts it works on and you can put as many or as few as you want (comma separated, no spaces). Omitting the line means it will be applied to all parts. MODULE { name = ModuleAnimateGeneric parts = GooExperiment,science.module animTime = 0 }

They're not in the default modules to be replaced. If you want to take the time to add them and send me the config I can add them to the defaults, otherwise you might just need to send out an engineer/replace them manually. Here's the tutorial that walks you through the process of identifying the module and figuring out what needs changed: link.

It seems that the vessel isn't being added to the RecoveryQueue, thus it isn't found in there when the destruction happens, hence it not recovering properly. I think I know where to look, so I'll have something for you to test later today. That's only for the flat rate model and only applies to the speed percentage. I'll update the OP to make that clearer. It's an artifact of when the Flat Rate model was the default, rather than the variable rate model that's used now. With the variable rate you don't need a probe or command pod at all for 100% speed percentage, just to be below the low cutoff velocity (default of 6 m/s). The distance percentage is always less than 100%: it starts at 98% (same as recovery at KSC) and drops to 10% at some distance based on the Tracking Station level (either quarter of the way around Kerbin, 3/8 of the way around, or 1/2 way around). So maximum total recovery you can get in 98% with any model. If you have any suggestions for it, let me know. The current version is just a first draft for it since I'm not sure how many people will actually use it, or what info they want to see in it. I'm thinking some way of calculating powered recovery from within the editor would be useful, but I don't want to take the time to add that if it'll never be used Try just letting the stage "crash" into Kerbin by itself. It should still work, though pre-recovery of Kerbals doesn't work there. For whatever reason stages aren't destroyed around 23km like they should be in the Tracking Station, it seems the atmosphere no longer can be polled while in that scene. If it's not working after the stage crashes and is deleted, let me know. Simulations and other tests are always the best, but the Editor Helper is nice when you just want a quick and dirty check to see if things will be recovered. There's also a discrepancy between what SR thinks the landing speed will be and what physics thinks it will be, and SR's value is the one that matters for recovery through SR (obviously). The Editor Helper gives those estimates, but testing and watching something land will frequently give different values. The new Helper is much nicer than the old one since you can get estimates for each stage on a full ship, rather than having to break it into pieces to check each stage individually.

That usually happens when a ship is missing a part that it used to have. The development version of KCT has a check for that and will just disable access to that vessel instead of totally breaking, if you want to try that out, though I'm actively working on it so things are bound to change a lot in the next day or so. If you want to just extract that ship out of the save file then open up the save and search for KCTVessel. Find the one that corresponds to the messed up ship and just delete the entire node. It's big, since the whole craft file is saved in there. Make sure not to accidentally delete anything else. You might also make a note of the total vessel cost (listed under the KCTVessel node simply as "cost") and add that to your funds.

@Tortoise that feature actually already exists! It's the 9th thing in the feature list on the first post. All you have to do is open the KCT menu after landing the craft and you can recover it into the storage directly, then edit that craft to refuel and fix things. But be warned that KSP doesn't like going from in-flight vessels back to craft files and it can cause save file corruption. KCT automatically makes a backup prior to even attempting the conversion that you can load later if you find it doesn't work, and often loading that backup and trying again results in it working correctly the second time. Also note that planes get flipped weirdly when you recover them this way and you have to go into the editor to reorient them before launch. Repairs and refuels have to be done manually, though there's a button that sets all fuel tanks back to their default fuel values to aid in refueling.

Ah crap. I forgot to test powered recovery with pre-recovered kerbals. Try it with a probe core and it should work. I'll have to add in some code for pre-recovered kerbals. I might not get a chance to do that today. Edit (12/29/2015): Small bugfix update to make powered recovery work with pre-recovered Kerbals. Should work properly now for you @amo28 but let me know if you see anything else weird. Sorry I didn't get to it sooner, the holidays has meant lots of travel and time with family.

It looks for ModuleEngine or ModuleEngineFX and fuel for those engines. Could you upload the log file and the planes craft file? It should work with mod engines but I haven't tested it with those ones before.

I'll look into coming up with a workaround for that issue. It crops up more often than I'd like and there's probably an easy fix I can do so that it's not an issue anymore