magico13

Ignore the latest commit (build 6), keep using 5. 6 is a half built rollout based update that I committed to test auto-versioning the file, which seems to have actually worked I'll take a look at that scrapping issue. Likely found the bug causing that, so should be fixed in the next build Edit: Go crazy with build 7! It's got the first iteration of the rollout and rollback mechanics and some GUI changes for the build list. I'm interested in what people think of them. I'll do some more work on this tomorrow before trying to add direct recovery into storages (which will be tied to rollout time). Make sure to read the changelog for each build before downloading it by clicking the "recent changes" button. It will generally explain what changed and if the build is ok to be used.

Node unlock rate isn't configurable yet, but I can add that in. BP for buildings ships is currently entirely cost based, which achieves the goals you indicate. I can also add some mass dependence in there if you really want, but mass is currently only for reconditioning and rollout times.

I realized I'm an idiot and the internal version number is set manually while the external one is done by the build server. I wonder if I can write up some prebuild scripts to change that. The next commit might also break existing compatibility again since I'm adding rollout time and had to make some changes to how reconditioning works.

Double posting to announce that I'm opening up the development thread again for the open betas. I just setup a build server that will build new versions automatically whenever I push a github commit. They will update comparatively frequently and it's totally possible that a successful build will not actually be functional. I'll try to mention in the commit messages whether I know they won't work so you can avoid those. So if you want to try out the latest builds and are totally fine with really unstable builds that will likely break things, then come join the fun in the development thread!

So I finally opened up the beta versions for testing and am redirecting the purpose of this thread to be about the discussion of these betas. If you want to help, please READ THE FIRST POST. Remember that these builds are going to be UNSTABLE so I HIGHLY advise backing up your saves. I am not responsible for corrupted saves, you were plenty warned before testing these UNSTABLE builds. With that said, let me know what you find

That is intentional (but apparently missing from the OP, I really need to do some thread maintenance on here). It will only happen if Deadly Reentry is installed and the vessel is going fast enough. Fast enough means greater than 2000 m/s (but is configurable in the settings, and I THINK setting it to 0 will disable it. I wrote that a while ago and don't remember off the top of my head.) Importantly, it's not a strict cut off of 2km/s. That's just when there starts to be a chance of the vessel burning up. Here's a semi-quick overview of how DR support works: Above the DR cutoff velocity there starts to be a chance of the stage burning up. For the default settings this is 1% per 10 m/s above 2000 m/s. When you hit 3km/s there is a 100% chance of burning up. If you have heat shields it subtracts a percentage equal to 100 * (current_shielding / max_shielding), aka 100% with full shields, which will totally negate any chance of burning up until 3km/s. After 3km/s, even with heat shields there's a chance of burning up (for instance, at 3500 m/s there is a 50% chance with full heat shields (150% - 100%). With half used shields it's back to 100%! (150% - 50%)). After 4km/s no amount of heat shields will protect your stage from destruction. Best way to avoid this is to not drop stages at near orbital velocity (especially without heat shields). Do notice that I made no mention of the actual shielding amounts, only the ratio remaining. This can be exploited to use tiny heat shields on big stages to land successfully, but I hope that most people would feel bad about downright cheating This mechanic is mostly in place to prevent people from throwing things at the atmosphere at 5km/s with Deadly Reentry installed and still have them survive, but it also makes it so you have to consider whether dropping things into the atmosphere (especially uncontrolled) with orbital speeds is a good idea

I don't know why I didn't think of that! Sometimes I forget that option exists (and ironically is also bugged in the current released version). Like you said, the Reconditioning Rate is the sum of all the VAB rates. That kind of info would definitely be included in the Getting Started Guide. It's generally easy enough to calculate (add a couple numbers at most) that I never thought it to be that useful to be explicitly displayed, but perhaps when I do the GUI and/or upgrade overhauls I'll toss it in somewhere.

The good news is that I know what the issue is. The bad news is that the fix is implemented in a new update that is currently pretty broken and won't be out for a few days. I believe a majority of KCT users are also StageRecovery users, and while StageRecovery also has this issue present it comes up far less often. If you add StageRecovery you shouldn't have the problem (if you do, you'll have to turn off the "Try Powered Recovery" setting). If you don't want to add another mod you can either 1) wait a few days, 2) remove the vessel that's causing the issue from the save file manually, or 3) remove KCT, load the save and go into the Tracking Station, then exit the game and add KCT back. In case you want to know precisely what's going on, here's the rundown. A ship is being destroyed by KSP for being too low in the atmosphere while being unloaded. KCT kicks in and checks for parachutes and for a probe core (if there's enough parachutes then the parts get put in the inventory, if there's a probe core you get more funds back). When it checks for the probe core it tries to view some information in the COMMAND module, but since the current scene is the Tracking Station and not flight, that information doesn't exist (aka, the module is NULL). Then it spews out an NRE which causes the rest of the game to go crazy. StageRecovery avoids the issue most of the time because the default mode doesn't care if the destroyed vessel is controlled. When trying powered recovery it does care though, so there's a chance the issue could appear then. It will be fixed in both mods soon.

You should only be getting back the value for whatever amount of fuel is left in the tank. If you aren't then that's a bug. This is the function call that gets the value of a part: ShipConstruction.GetPartCosts(pps, pps.partInfo, out dryCost, out fuelCost); and when SR displays returned values it ONLY displays the dry cost, not the dry+fuel costs. Is this the tank you're judging this by (for those who don't click the link, it's the 2.5m 32 tank, full: 6400 funds, empty: 4931.2 funds)? As you can see, that tank's empty cost is well over 4000 funds despite costing about 6500 funds full. That's because rocket fuel is actually ridiculously cheap in comparison to parts (1468.8 funds for 1440 LF + 1760 Ox). So, your assumption that most of the funds for a fuel tank go toward the fuel is actually wrong, which is surprising to me as well! If you find that your returns are higher than what you're comfortable with you have a few options. If you're playing with the Variable Rate (aka, the default mode) then you can lower either the low cutoff or the high cutoff (or both) to make the same terminal velocities pay out less. Or, by switching to the Flat Rate mode you can adjust the return percentage directly (but then recovery is all or nothing based on the singular cutoff speed). You can also set some personal rules. I personally don't try to recover things that are going to be dropped when near orbital velocity, since they'd probably be very damaged or destroyed on reentry. I typically only recover things that I drop while still in the atmosphere (boosters rather than anything on the main stack).

Why don't we just build a base in one of the Moon's caves? Then you've got overhead support already and since they're in giant pits you've also got coverage on the sides. I suppose there is concern for cave-ins, but I figured I'd at least mention it. http://www.space.com/26592-manned-moon-exploration-lunar-pits.html

I can confirm RSS support is working and the new save system isn't COMPLETELY broken! I've handed off a very, very rough beta to JeffreyCor for testing and will likely be getting something out later this week for the rest of you. It isn't quite version 1.1 since there's not much in terms of new features (despite a massive internal rewrite of the save system), but I will get started on that this weekend (starting with rollout time, then recovering to the inventory, and finishing up with something for procedural parts support).

@Climberfx If I understand you correctly I believe you are asking for the ability to use ships as-is when recovering them. Currently implemented is the part inventory, which will make any ships you recover and rebuild take minimal time compared to a new one (to represent refueling and reconditioning of the vessel). However, there is a planned feature to let you recover ships directly to the inventory (see this GitHub issue) which may be closer to what you are describing.

I wouldn't be too surprised if they add something related to this in the future. Since 0.24 they've had a new Kerbal type called "Visitor" (if I recall correctly) that isn't actually used anywhere yet (just like they have a vessel failure reason called "reentry heating" or something similar). There is always the chance that these things were added when they were planning on taking one direction but have since changed plans.

StageRecovery has basic DR support already so that you can't toss something into Kerbin's atmosphere at 10 km/s and expect it to survive. There's an increasing chance of the stage burning up as you go faster than 2 km/s, while heatshields will reduce that chance (up to 3km/s, at which point there's a chance again. At 4 km/s everything will burn up all the time). The plans I have for the future will substantially increase the realism, but this is all a discussion for the StageRecovery thread.

I actually have some plans for StageRecovery that will require me to change that so chutes will automatically deploy, but I've been trying to get some work done on Kerbal Construction Time so SR hasn't been a big priority at the moment. Since SR and DebRefund both kick in when vessels unload (and are destroyed by the atmosphere) both would require you to manually deploy the chutes while the parts are loaded (unless that changed in DebRefund at some point, but I'm unaware of that occurring).

I'm gonna be really unprofessional for a moment and laugh about the juggling balls comment, then I'm going to thank you for your post. I like hearing about how KCT has influenced how people play, especially with the recent discussions about KCT-like elements maybe eventually being integrated into the Stock game. Unfortunately the developers don't see time as a valuable resource and gameplay mechanic, so hopefully we can show them otherwise Also, I'm so annoyingly close to getting RSS support working but I need to do some more tests and fix a few bugs. Not having any trouble getting the current KSC from RSS thankfully (except when first loading a save, in which case the value is empty. I either have to poll it again at a later time [assuming it's no longer empty] or I'll have to advise everyone to go into the tracking station before doing anything else). I seem to be losing track of which KSC is the active one when entering the VAB (likely just me clearing the active one on scene change and not loading it properly) but I just need to play with it some more. I should probably save which KSC is the active one when changing scenes/exiting the game and then setting that one active on scene change or game load. That'd likely fix all of those issues and is easy to do.

I haven't personally tested it yet, and multiple launch sites aren't explicitly supported yet, but I am working on an update that adds support for RSS' different KSCs so that each one acts independently with different build lists, vessel storage, and launchpad reconditioning. I was hoping to finish that over the weekend, but haven't had time to test any of the changes yet with an actual RSS install. NathanKell would know better than me how well this works currently with RSS/RO since I'm assuming he's been playing around with them lately. It should work as-is, but it might not function exactly as expected or desired. All the KSCs will be treated as one single one in KCT using the current version.

That was the plan! In GitHub Issue #12 where I talk about rollout time and reconditioning I added a comment discussing my ideas for what additional "launch slots" would mean. In short, they'll be alternate upgradable launchpads with their own rollout, reconditioning, and maximum mass limitations. There's been some discussion regarding FMRS in the past and JeffreyCor had tested FMRS with KCT's simulations. He found that the two definitely did not work properly during simulations, causing pretty gamebreaking bugs. Normal flight wasn't tested but I imagine it wouldn't be nearly as bugged, but there may be issues with KCT's parachute based recovery mechanics. I plan on adding a setting to disable the parachute based recovery, which I need to add to the GitHub issues so I don't forget.

This would probably lend itself well as an upgrade when I redo those. I'll add it to the list. Simulations ended up being a ridiculously useful feature when funds came out, which was a happy coincidence. I implemented it in the first release of mine (so, right after I took over, aka PreRelease 1) after spending several days building a craft that then couldn't make orbit. That didn't seem fair since I couldn't test it at all beforehand, thus simulations were created! They do need a bit of work to make them more game-y and some more features to make them even more powerful (primarily letting you start landed on another body), so those are on the roadmap. There is no direct support yet (though it is planned) but there also isn't anything explicitly preventing you from using the two together (and people actually do successfully). You have to set the launch site in the editor prior to pressing KCT's launch button and reconditioning doesn't make a whole lot of sense (so I recommend disabling it). I plan on adding some explicit support soon to let you choose the launch site prior to launch and maybe do some stuff with reconditioning or vessel rollout specifically for it.

The in-game settings menu! The value in the config file isn't a mass actually, that's the BP per ton prior to the OverallMultiplier. So you'd want to decrease that value to 1/4 or whatever (ie, 425). In general when I mention settings I mean the in-game menu since it's the easiest/simplest way of changing them.

Hyomoto has a way with words that I've found to be pretty unmatched. In some regards I like that KCT has many mechanics that won't become stock, because then I can control them how I want them. I do hope they change their mind somewhat about the value of time, from the current mindset of "It means nothing because of timewarp" to one that utilizes it as a valued resource. Maybe KCT will end up being the harbinger of that. Oh yeah, rollout is definitely a planned feature for the next major release. I am planning a smaller release first with mostly bug fixes and some basic RSS support (which will be 1.0.4) before a larger feature release with rollout time and either a GUI overhaul or the upgrade overhaul (or at least the beginnings of those). That first release will hopefully be out this weekend, while next weekend will be when I focus on the bigger feature release. Or I may throw rollout time into the thing I'm working on this weekend and call that 1.1. Who knows! Edit: @Ippo Just go into the Time settings and change the mass listed in there for reconditioning time (you'll want to increase it by at least 3 fold I would imagine, but it might be better to go 4 fold or higher [so 200 tons or more]). A future version will also have a maximum time for reconditioning. It won't affect the current one (since the BP is already calculated) so if the current one bugs you you'll have to disable reconditioning, save the settings, then go back in and re-enable it. That will "clear" the current one (so, it's technically cheating but I think that's excusable in this case)

That is a known issue, usually, but this case is a bit of a special exception. The usual case that would cause that issue is a vessel being destroyed while not in the flight scene and not having a Vt value less than the low cutoff velocity. What happens is that SR says "Hey, that's not going slow enough, let's try to land it with it's engines!" and starts looping through the parts to look for engines and some sort of command (aka a probe or kerballed command pod). In the flight scene there's no issues since the parts still physically exist, even if they're unloaded. In the Space Center or Tracking Station scenes the game knows basically nothing about the actual parts, so I can see that there are engines but can't pull any data from them (like the max thrust or ISP). Trying to pull that data (by accessing the module reference) results in the NRE you see (which SR is fully aware of. You'll notice this line just before that: "[sR] Error occurred while attempting powered recovery.") The reason it doesn't break your game is because of a try/catch block that prevents it from causing crashes and instead politely alerts the log to the issue. The reason your instance is weird is that it happened in the flight scene, which I haven't seen happen before. The good news is that I have actually found a way to get access to some of that information, or at least their default values, and should be able to prevent that error from occurring in the future. For the time being, don't worry too much about it. It just means that powered recovery couldn't be completed, but the parachutes should still try to do the recovery (and in that case they did. The Vt was about 10, which returned about 12000 funds).

I think we've both seen Harvester's response to the suggestion of build times and it's pretty obvious it won't be added to Stock. Which I mostly agree with because a lot of people wouldn't want to play with build times, but I definitely think that Squad is missing out on some really great gameplay potential by actually making time mean SOMETHING in KSP. They're so convinced that time could never become a meaningful resource in a game with timewarp, so they very clearly have never played with KCT or watched KSP-TV on Mondays with OverloadUT (who has posted multiple times in this thread). I feel sorry for them in some respects and sometimes question the direction KSP is headed. I haven't been particularly impressed with the past few updates' "major" features, but I'm giving them the benefit of the doubt and am hoping things work out well in the end. It seems a bit of a shame that some of the best new features are done by mod developers and not Squad themselves. As for the things more directly related to KCT in your post The BuildList+ window as I internally refer to it as isn't available in the editor because most of the functions aren't applicable there or will break things there and I figured going to the space center was easy enough. That might change in 1.1/1.2. It depends on how crazy I get with the GUI overhaul. Duplicating a ship in the VAB is as easy as loading the saved one and pressing the build button, so it didn't seem necessary to make the duplicate functionality available there. You're really not supposed to use the build list in the editor at all, but it was requested enough. I'm not positive about the last launched ship being saved as the autosaved ship, so take that with a grain of salt. There is a way to get a useful ship out of that though. The last launched ship is saved as a file called temp.craft in the save folder (go into the ships folder and you should see it next to the VAB and SPH folders). Just copy/move that and rename it and you should have a valid craft file. I'm getting excited about how I am planning on doing upgrades, but don't have enough to go into detail about it and it won't be for a little while. The basic premise will be a progression web (a tech tree in some regards) with a single unlocked starting node and several branches going off in varying directions (current model has 5 branches: VAB, SPH, R&D, Recovery, Simulations). You can unlock nodes down a branch to get more features (more assembly lines, discounted time on brand new parts, etc for the VAB/SPH) but will also be able to upgrade certain unlocked nodes (for instance, to increase build rates for an assembly line). Some nodes will have alternative ways of unlocking them (i.e. simulation bodies can be unlocked by purchasing them or by transmitting science from them). What have typically been considered core features will need to be unlocked (specifically the part inventory system and parachute based recovery of parts) and can be enhanced beyond their current capabilities (somehow ). This opens up a lot of freedom in my mind. If you don't care about recovering and reusing parts, then you can purchase upgrades to reduce build times for vessels using non-inventory parts. If on the other hand you recover everything (including fairings...) then you can spend some cash on upgrades that enhance that. You could simulate your important Jool mission by sending a small science probe around the system or just unlock the corresponding nodes with funds/science. Additionally, I'll be moving away from the point based system in science and career modes (but possibly using it, or a derivative, for Sandbox mode). I hope it will prove to be a straightforward system for users that enables a lot of choice, but it's probably going to suck on the back end. I am not that great at making GUIs so it likely won't be that pretty at first. I would gladly accept artwork to use for the nodes and background, assuming I can figure out how to display them, but I don't yet have anything to show to start from. I REALLY want to start working on it but I can't yet with school (in fact, I have a test I should be studying for...) but come Thanksgiving break I likely won't be moving from my computer for a few days

I'd say it's actually a tree right now since it has a single root and branches outward from there (turn it 90 degrees counter-clockwise, it's definitely a tree). It should be a web with a single starting point that goes every direction outward from there. I whole heartedly agree with this post. Have a single starting node and several different directions you can go with it. If I only want to play with planes, I should be able to do that from the beginning. Probes, manned rockets, rovers, planes, random structural pieces, etc should each have their own track (or diverge soon after some initial ones). This is the sort of thing I plan on doing for KCT's upgrades in the future.

So I'm working on an update for KCT that adds support for the different Real Solar System KSCs with totally separate build lists and vessel storages (and upgrades and all that). I was going to include KK support the same way, but I'm wondering if it would instead be better to keep it closer to how it currently is where there's only one KSC but you can launch from any site (since you don't choose KSCs in KK, but instead only individual launch sites). It seems like it would be a non-trivial amount of work on my side to figure out which sites are part of a single KSC and then split the lists up for each determined KSC (and then make sure you only can launch from sites corresponding to that KSC). I figured I should alert you that I'm working on this since I may need your help in the future. I think I will instead stick to a single set of build lists and vessel storages and just allow you to choose the launch site at launch time for KK, while having completely independent KSCs for RSS.