magico13

Hyomoto, thank you for that well constructed post (something I generally am not good at doing)! I still feel that KCT-Lite has some merit. It gives you an introduction to the gameplay aspects that time as a valued resource brings about without everything else. Some people who want a semi-casual experience may find it appealing as it wouldn't require significant config reworking while you try to figure out how the mod works. I know that I don't always want to try out a mod and immediately have to start doing configurations of a bunch of things I don't understand (something KCT could certainly do better). Someone suggested presets for the configs, and I think that might help a lot for newcomers. There'd be presets for feature settings (easy disables reconditioning and tech unlocks, etc) and for time setttings (shorter, normal, "realistic", "reuse-centric"). One or two custom presets would probably be good too. Click two buttons and you're on your way, no fuss with configs. Probably also something for quickly spending the first upgrade points (All VAB (1 or 2 lines), All SPH (1 or 2 lines), split evenly) I agree that the GUIs need improvement. One of my weakest abilities is making anything visual look good. I've tried to improve their quality over time, but I'm thinking it might be time to do a total overhaul of the system now that I have a better idea of what I'm doing. I think something more minimal would be good, like Mission Controller's funds windows in the editor (pre 0.24) which are unobtrusive yet informative. Perhaps have the build list be like the drop down menus for resources/contracts in the stock toolbar (with a separate window probably for detailed interaction with it) Regarding visual things and mostly unrelated to the rest of this post: Would anyone like to make a banner and/or flag for KCT? I need something nice to put up on the forum page and KerbalStuff and you don't want to see what I would come up with. It could be made from screenshots (preferably just stock+KCT) or drawings or both (or anything else really). Upgrades could definitely use improvements and I don't know the best way of going about that, so thank you for your suggestions. I'll think about how to implement something along those lines. I like giving the player choices and having those choices mean something, and while the current system does that to a degree it's also kind of, well, bland. If I had unlimited time and resources I'd love to integrate with Kerbal Konstructs to have physical building upgrades, but it looks like Squad is going that way themselves. I may wait for that to be released and then tie KCT upgrades to KSP upgrades, so better VABs can build faster/more ships. Either way, the upgrade system "works" as is, so I likely won't make any massive changes to it for some time. I have time off (I think) in mid-late November that I could use to make some larger changes to various systems. I'm far from a game designer (and didn't actually become a modder entirely of my own volition, but am certainly glad I did) so I have a hard time making things fun. Functional, sure, but fun is a different story. Because I have such little time as of late, I've really considered either a) partnering with someone or handing KCT off to someone else. I don't want to do either (especially because I enjoy working on it and like having control over it (I know that sounds bad, but it's been my labor of love for months and I'm reluctant to let other people change a bunch of things on their own). If I get a particularly good offer I'd probably be willing to work with someone else (even if it's just for a feature set), but I'm definitely not ready to hand anything over. Edit: You've made a few edits (mostly for clarity/expansion) but I think my responses all apply just as well. Just acknowledging that I've re-read everything (twice now in fact )

We haven't thought about that too much yet, but you bring up a good point. For SR I'll have to add an option to require manually deciding to recover a stage, meaning I'll need to make the recovery list persist (in some form at least. I'll likely just store the name, vessel id, and cost to recover/refund. Probably the parts list would be good too, so you can decide if you want it. Kerbals/science would be recovered always and for free though). For normally landed craft you obviously can just choose not to press the stock recover button (I like the weird side effect that Kerbals are free to recover but the ship sitting right next to them would cost substantial funds to recover, despite the fact that you still have to send out a rescue craft either way). You'll be able to sell parts, so in the end it pretty much balances out with Stock (selling will likely be at a slightly reduced rate) but you're right that the loss of funds could be prohibitive for a time during longer/larger missions. Good thinking!

When we finally get the ScrapYard up and running there actually will be a recovery cost (since you won't get refunded for parts on recovery, even manually) which SR will support. Basically you pay the difference between the part value and what you'd normally get back for recovery (so 0-2% at KSC and 90% on the other side of Kerbin). Otherwise, the decreased recovery value as a function of distance covers what TeeGee is suggesting, and I agree that you shouldn't ever be penalized for recovering a part (which also wouldn't fit with Stock at all, since manually recovering parts on the other side of Kerbin still earns you funds).

Make sure you don't have anything in the UT box in the simulation configuration window. There's a chance that it's changing the time if there's something in there (since that box lets you change the time of the simulation). Otherwise there shouldn't be discrepancies in time like that. I'm glad you've enjoyed playing with KCT I also find that TAC + KCT leads to a far more rewarding gameplay experience since rescue missions require delicate planning. You can't just send up new rescue missions when your previous one fails, and if there's any time at all to send a rescue it's probably only enough for one anyway!

I think where it is likely having issues is because KCT's version of reverting the save file after a simulation is manually overwriting the current save prior to it being loaded by KSP. Which when you think about it is actually kind of terrifying and malware-ey if it were applied to anything other than a game. KSP has no idea that it's loading a different file, so FF has no indication saying that it should reload its own database. Maybe I can switch up KCT's post-simulation load code to make the game load from the backup instead of manually overwriting the save. That's probably safer anyway and might fix any issues that FF is having regarding simulations/KCT (since KSP would be fully aware that it were loading an older file)

Up the build times as in decrease the build times? For the lite version there'd be not part tracking/inventory/upgrades so the total build times would be set to something reasonable (there's also no build list, so they can't be TOO long). Probably balanced to take 1/2 to 1/4 as long as the same ship in a brand new KCT game. KCT itself likely wouldn't receive any changes to the build times (partly because they're very configurable). edit2: Do also keep in mind that build times drop off fairly steeply at first. 4 builds with the same part cuts the build time in half and the inventory drops things as well. Also, since build times follow a square root law, increasing cost doesn't 1:1 correlate to longer times. New games have exceptionally long builds that even out later on. As for reading the sun, for short times you'd be alright Edit: Aaaaaaannnndddd you edited For inventory stuff, installing The ScrapYard by itself when that eventually gets released would be sufficient for building an inventory that full KCT could use later, but you'd have to accept the ramifications of that (changes in how funds work with parts). Alternatively, I could include an optional basic inventory system, but I'd rather keep it as simple as possible, so that goes under the "maybe" category. Like I said, I don't think most KCT users in this thread would use it (maybe a few would switch) but its more for new people who don't want to have to learn a bunch of new stuff/do a bunch of configuration changes to get into the basics.

And that's when we sell them the idea of using full KCT for the build list Those people would likely enjoy full KCT more, since that implies more advanced planning requirements. Part of the idea is to get people to try out what construction times can really do to your gameplay experience, without the initial learning curve that full KCT requires (which I am led to believe can be a bit confusing/intimidating at first for some people. I am the absolute worst person to ask about it). If they like it and want more capabilities then they can move up to full KCT, if not then they haven't spent a bunch of time trying to figure out a mod that they don't want to actually use. And there may be some people who just want a simple, no nonsense, basic version. For instance, I prefer playing with NEAR rather than FAR because I don't want to worry about aerodynamic failures or mach effects but can't stand stock aerodynamics. I still get better aerodynamics but dumbed down for gameplay. It feels somewhat more natural/integrated to me.

The context of the conversation was that contracts in KSP have ridiculously long time limits and that KCT provides a purpose for time. It seems to me that they want a progression of time, but want the process to be extremely simple/seamless without a bunch of fumbling around with GUIs, which I can respect. KCT Lite would still let you go manage other missions, but the ship would be placed right on the pad and would be uncontrollable. If you wanted to just click launch, see the ship on the pad, and launch with some time passing, there'd be a button to do so. If you wanted to put it on the pad to build and then go manage your Duna colony until it's complete, you could do that too. It would still provide a value to time (and prevent spam of rescue missions and require planning) but in a simpler, more integrated into vanilla KSP form.

I don't generally double post, but I figured this question would be better served in its own post (maybe even its own thread)... Would anyone be interested in a KCT Lite version? Without upgrades (or likely simulations or the inventory/part tracking system) basically just what KCT was like in the early days (Pre-PreRelease 3) where you click the launch button, the vessel is placed on the pad, and you can't control it until the timer's up. I'd basically have to rewrite it (though I think I still have the source from back then, so maybe not) but it's so simple in comparison that it wouldn't be that difficult to do. Most people in this thread probably like the full KCT version, but I can see how it might be a bit too complicated if you just want a simple feature. KCT Lite would be the NEAR to the FAR that is KCT, serving as an entry level, no fuss version that adds the core features without the extra complicated GUIs and all that. The reason I bring this up is this post (trimmed a bit):

Semi-implemented as-is because everything will get recovered meaning the total time for a "new" ship is substantially reduced (compared to brand new, never before used parts its 1/10 of the time, so a 4 kerbal day build becomes a 2.4 hour build [<1/2 a kerbal day]). I (eventually) plan on adding the ability to just refuel and relaunch a vessel without waiting times (or severely reduced wait times) but use the ship as-is (so no new parts can be added, all damage is kept). It's just not a high priority and since I don't have loads of time anymore it'll be a while. Current priority list: 1) Vessel rollout time instead of reconditioning 2) Max reconditioning time 3) Revamped simulations 4ish) Contracts (regarding simulations and other things, like build a vessel worth X BP and launch it) 5ish) Improved recovery mechanics And then somewhere mixed in is support for the ScrapYard, which is not currently updated to 0.25 and the KCT version for it doesn't work yet. That'll need a good chunk of time that I don't want to actually spend (especially because it doesn't add a whole lot in terms of new features to KCT and requires a major rewrite). Revamped simulations will probably take the same amount of time, has a big end-user effect, and is more interesting so there's a good chance I might work on that first.

@severedsolo That's definitely not intended behavior (but would be a somewhat entertaining method of handling things). If it happens again, send me the logs. If it doesn't then it was probably just some freak accident. Originally you couldn't do vessel switching at all, but I enabled it because otherwise you couldn't switch from EVA'd kerbals or between vessels that you're trying to dock. Or when you drop a payload you'd either control the payload or the main ship, but couldn't switch to the other one. In the end, convenience won out over "realism" or whatever that would be considered (reduced functionality for gameplay purposes?). Do you happen to remember which video he mentions this in? I've watched all of IQ (I think... might have missed one or two) and don't remember it being mentioned. It may have been before I had taken over for Ekku Zakku (so, around January/February) in which case I likely wouldn't have been paying too close of attention. Someone should get Scott Manley to use this in a future video/series We do have at least one KSP-TV streamer who regularly uses KCT (OverloadUT. Gonna shamelessly plug his videos because I enjoy them a lot. He does streams on Monday nights at 10 EST. Tell him I sent you ) and I've seen several other modders in this thread/the dev thread who have at least tried it out.

Any luck with fixing that/regenerating the stats? Released an update for Kerbal Construction Time on the 17th and it says it has about 14 thousand downloads on the 18th, which I am thinking is probably not the actual case since it was only about a thousand total before and the number of followers isn't substantially higher that day.

Umm, so I just looked at the KerbalStuff stats for the first time since the 0.25 release and I'm not sure if this is a bug in kerbalstuff or not... If that's real, then holy f***! Welcome to all the new people! If not, then aww But still, KCT has done better than I ever expected with its modest userbase of several hundred to a thousand. I used to get excited when it hit 200 or 300 on a download in the pre-release days Edit: Just checked the KerbalStuff dev thread and it looks like it's a bug, darn

The calculations for terminal velocity won't be correct without parachutes (this will underestimate in most circumstances), but with parachutes the difference is negligible. In short, yes it's compatible. From a gameplay perspective everything will work fine and nothing will seem out of place or wrong. If I get some time later maybe I'll make a short video about rocket construction with SR. I'll try to explain things as easily as possible through words for the time being. Addressing the questions first, 1) Pressing the SR button will take the entire mass of the rocket and ALL of the parachutes and see if that could land. Generally that's not what you want for recovering stages though. It's not a simple task to be able to split stages programmatically so at the current time SR doesn't even try. 2) Generally bottom up is a good idea for totally new craft, or make stages by themselves and save them as subassemblies (or just remember the configuration: if an SRB with two radial chutes is enough for a safe landing, just add two chutes onto each SRB you use). With RealChute it isn't as big of a deal, just determine the dry mass of the stage in question (the new engineer is good for that) and enter the mass manually into the chute configuration tool (I usually add a little bit extra and aim for 5m/s touchdown, just to be safe). You can even save RC presets if you use similar configurations a lot. You can use parts other than command pods as the initial part, so to see if a radial SRB will be recovered just make a new craft with the SRB as the root part and add parachutes as necessary. Then either save that as a subassembly, save the RealChute config as a preset, or remember what was needed for it to work. Center stack stages can use a stack decoupler as a root part, or a probe body, or a fuel tank. Using the decoupler will let you save it as a subassembly. Powered landings usually require a bit of testing to be sure, but a totally empty rocket will have a terminal velocity of 100 m/s (without chutes). Therefore you'll need at least 250 m/s of delta-v in the stage (with atmospheric ISP). If there's still fuel in the tank then that increases the terminal velocity, so it's safer to leave 300-400 m/s of dV in the tanks for a safe landing (terminal velocities of 120-160 m/s). If you add parachutes (even if its not enough for a safe landing) then you drop the amount of fuel required by a LOT (the terminal velocity can drop to closer to 20 m/s for instance, which drops the dV requirement to 50 m/s). Even with parachutes SR requires the rocket to have a thrust-to-weight ratio of greater than one. If you develop a launcher that works for you, you can just save the whole thing as a subassembly and use it in the future without worrying about it landing safely.

Just wanted to let you know that Kerbal Construction Time is using the KAC API now for automatic creation/handling of alarms for vessel completion. Really basic integration stuff, but wanted to let you know. I did run into an issue when calling the InitKACWrapper and version 2.x of KAC was installed on the system. It recognized the assembly as being KAC, then tried to get the instance. Instead of just seeing that as null it throws an error that caused Start() not to finish execution. Surrounding with a try/catch avoided the issue. Figured I'd let you know, in case you hadn't tried that yourself yet. Here's a snippet of the error, after it's been caught by KCT. It's simple enough to recreate and there's not much more to actually say about it (just use something that has the v3 API with v2 installed), but if you need more let me know. 10/17/2014 10:10:34 PM,Kerbal_Construction_Time-KACWrapper,Attempting to Grab KAC Types... (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) 10/17/2014 10:10:34 PM,Kerbal_Construction_Time-KACWrapper,Got Assembly Types, grabbing Instance (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) [KCT] Caught exception while trying to init KAC wrapper. at Kerbal_Construction_Time.KACWrapper.InitKACWrapper () [0x00000] in <filename unknown>:0 at Kerbal_Construction_Time.Kerbal_Construction_Time.Start () [0x00000] in <filename unknown>:0 I should say that this might not be with the absolute newest version of the wrapper if you've updated it recently. I will double check with a fresh copy of the wrapper. Edit: Tested with newest wrapper version. Same problem. You may want to add a check for the version number and ensure it's > 3. Or add a try/catch around the GetField.

What's this? A wild 0.25 has appeared! Magico13 used update. It's super effective! Enemy 0.25 has been defeated! I figured the betas were stable enough, which undoubtedly means that something will go horribly wrong now. Here's an excerpt from the changelog: v1.0.3.0 (10/17/14) - Update for KSP 0.25 - Added ability to simulate at any time (currently requires the exact UT) - Made Build List viewable in the editor - Added confirmation dialog when scrapping vessels - Bug fix to ensure effectiveCosts can't be less than 0 - Unified GUI appearance throughout scenes - Workaround for starting in air when launching from Tracking Station - Added basic Kerbal Alarm Clock support. If enabled, alarms will be automatically made for the next thing that is set to complete. Updates when the Build List is open - Fixed some bugs with tech nodes, some of which may have been present before 0.25 - Halved reconditoning times by default (50 tons instead of 25) and made simulations much less expensive Download is in the usual places. I removed the beta link for the time being (it will eventually be located in the development thread, to keep this one tidy). When I eventually get around to doing some of the changes on simulations I will request your testing aid. For now, go wild!

I saw it and appear to have forgotten about it. I'll take a look at that tonight and see if I can fix it. Is the build time estimate you quote the one in the editor after reverting the flight? Might be as simple as manually calling an update of that when the editor loads but after the persistence is loaded.

Have you made sure the mouse cursor isn't hovering over any of the KCT windows? Unfortunately there's a bug with stock KSP (since 0.24) that causes time to stop advancing when the KSC locks are activated (which shouldn't be related at all and I'm very frustrated about it). I have to enable those locks because of another bug in 0.24 that causes windows to get clicked through to the buildings behind them. I'm very unhappy with the GUI changes Squad made in 0.24 and then subsequently ignored my bug report about, only to later realize were a big issue and (possibly) haven't realized that they weren't issues prior to 0.24. I get unhappy about that particular bug's existence, I'm sorry. So yeah, check for that first, if it still doesn't change and you're sure the cursor is off the window then it's definitely a bug.

Yes, I plan on adding a way to sell parts/resources. I'd like it to be a part of the backend system, but from discussions it sounds like each mod will have to implement their own method. We might end up doing a mixed system where the backend has a simple system in place. It's absolutely necessary in my opinion that you be able to sell parts and especially resources, for the very reason you state. There are some mods that add resources that are only designed to be sold for funds, and I don't want to make those not functional anymore. That would be sad

Just uploaded another beta version, 1.0.2.3. Current Beta users should be notified through the KCT update checker if it is enabled. Only change is that the default mass for reconditioning is double what it used to be and simulation costs have been cut substantially. Actual rework of simulations will occur in a later update (likely to some degree, if not entirely, in the next one). If this beta is without severe issue, then I will promote it to the official release after a recompile in release mode and a version change. I don't foresee any issues with this beta though.

I'm liking the ideas that hatterson provided as well, especially with regards to atmospheres. I'm planning on making some finishing changes to the current Beta tonight and hopefully doing a full release tomorrow. The bigger changes will be in a future update. Since we're talking about it and its exciting I might do it for next update, but I've got other features I need to put in first (vessel rollout). And the whole switch to the other inventory backend is still like halfway done and not anywhere near functional. Don't worry, when I redo the simulations everything will be configurable. Don't want to pay for simulations or upgrades or deal with upgrades at all? No problem. Don't want to have to visit atmospheres or even planets before simulating there? Done. And also likely configs for increasing or decreasing prices for things. I like making things configurable

Like, display that all the time? The main issue is that you generally are checking only for stages (like some side boosters) and not for the whole vessel. I'd like to do a break down by stages eventually, so you can click the button and see right away which stages will make it and which ones won't, but the amount of work required for that is more than I can commit at the moment.

It is strategy-esque, but I'm not sure if it would fit perfectly into the strategies system. Is there a limit to the number of strategies you can accept? Or can you accept all of them? If there isn't a limit and I can either create a new category or can easily add what I want to an existing one then I may put it in there. If I'm restricted to only modifying currencies with the strategies system then it definitely won't help me. I know for a fact that I can easily do what I want by not tying into the stock systems, so I'm really tempted to just do it my way and not mess with strategies, if only because I don't have loads of time to figure all the new things of 0.25 out. I have played for a total of about an hour so far

Sparing the actual math details (you can check the source code if you really want to see the complete derivation. In RecoveryItem there's a function called DetermineTerminalVelocity or in the Settings class there's DetermineVtEditor) here is a, hopefully thorough enough, explanation. Distance from KSC is the easiest, so I'll start there. When a vessel gets unloaded in atmosphere (and thus deleted by KSP), SR takes the latitude and longitude of the vessel (according to what KSP reports, which is apparently not always correct if you look a page or so back) and does a calculation of the surface distance from the space center (the Great Circle Distance). This is the exact same thing stock KSP does for normal recovery. A consequence of this is that the height above the surface doesn't matter, so 10km straight up is the same as being landed right at a place. Note that KSP returns 98% for a KSC landing, and only 100% for launchpad/runway. SR will only return a max of 98%. The check for enough parachutes (lets do stock first) is done by calculating the total drag of the vessel with the chutes deployed (they don't have to be deployed for this check to work) and comparing that to the total mass. It calculates the terminal velocity at sea level using that info and if its below the cutoff then it will recover. The variable recovery rate model (default) returns a percentage based on the terminal velocity. 100% below the lower cutoff, and 0% above the cutoff. Between them it's quadratic, so close to the lower cutoff return rates change slowly and close to the high cutoff they change quickly. Theres a picture of the default curve in the album on the first page. With RealChute is does something similar, but the calculations for terminal velocity are different and are the same as the ones that RealChute uses for its editor configuration things, so you should have nearly 100% agreement between them (RC doesn't take into account changes in the mass of the parachute when you resize, so you can get slightly different values). If you want to know if something will get recovered, you can build a "test model" in the VAB/SPH (in your case, your first stage. You can do that with subassemblies I think) and press the StageRecovery button. It will then calculate everything and will tell you if the current design will be recovered (current fuel levels and empty) and what percentage of the total will be returned. Also the terminal velocity, which is handy for checking that you have enough chutes on your lander. No guesswork required RealChute is handy for that too, since you can design the chutes to be the right size to land at whatever velocity you want.

I see no reason why that couldn't be included. It'd likely be free to setup and have a slight cost to remove (that way you don't do it 100% all the time and just turn it off when you need to do a simulation, it'd be better IMO to contribute a small amount for a long time. I want some penalty so you can't say "here, use our servers. Except in 20 minutes we'll need them, and then again 10 minutes later"). I'm thinking that it could be cool if buying hardware would let you simulate craft for free, up to their limit. Past that you'd have to rent time on someone else's hardware which would have an associated cost. Maybe then there's a static "maintenance fee" each day which could be mitigated by selling unused processing time. Valid points. One of the reasons I made simulations in orbit was so you could test lander designs BEFORE trying to actually land. I'll let you land/enter atmosphere, but may restrict SOI only to ones you've purchased the package for. You'd have to have landed science to start a simulation landed on another body still, so that seems fair to me.