magico13

Based on suggestions, here is the version I have tossing around in my head. This is by no means a confirmation of what I'm going to do and things are definitely subject to change. 1) In order to simulate in orbit/landed/maybe even in atmosphere you must first transmit/recover science from the appropriate place (or better, so landed could count for all three). 2) After getting science from a location, you can purchase a Simulation Package for a heap of funds and/or science which then lets you perform simulations at that location. For example, you visit Duna with an orbiting probe and can purchase the Duna Simulation Package which lets you select Duna as a simulation body. This may or may not require time to unlock. Prices will be subject to planetary mass/atmosphere constraints, but independent of distance. Moons will have their own packages that require the parent package, but will cost less than the parent package. 3) After a package is unlocked you can choose it in the editor. You can do orbital simulations if you have any science from the planet. You can do landed sims if you have landed science. If you enter the atmosphere without atmospheric/landed science the sim is terminated/restarts. Same for landed (on touchdown, sim ends). These simulations will cost a fraction of the current costs/the package cost and you'll have better control of time limits (able to set any number of hours/days you want). I haven't decided if it's worth the effort to make subsequent simulations cheaper, but if I do it will likely be like the system I described in a previous post, since that's actually pretty easy to do. I don't like the idea of individual simulations taking time to prep (unlocking packages, maybe) since that would suck from a gameplay perspective. Simulations are supposed to let you test a craft without having to waste a bunch of time building it, and quick test-alter-test-repeat sessions would be substantially more tedious. They will certainly take zero time (and even if they didn't, it'd be like 30 minutes). As for purchasing hardware for additional max lengths of simulation time, I kind of like that idea. Maybe I'll just add a new window that lets you upgrade your simulation hardware: installing new planetary packages, upgrading your "processing power" or something similar to allow you to simulate larger vessels, and your "memory" to allow longer simulations (gotta store the data somewhere. Maybe instead of memory it's just "storage" since you'd actually store that data on a hard drive). You could also purchase upgrades like "Low Power Components" to reduce simulation costs by X%. I could make it like strategies where you trade one thing for another (ie 10% more processing power for 5% more money each time, with a commitment value that changes the amounts), or I could make it so there are just general upgrades that only provide benefits for an initial cost (spend 100k funds to reduce costs 5%, costing more each upgrade). I personally like the second one but I'm interested in what you all think. So yeah, that's my current idea in my head. Like I said, nothing is finalized and I may change all of it if I get some other good suggestions

I can try to look into it, but its likely because StageRecovery doesn't call the normal vessel recovery functions and instead has its own. I may be able to cause it to manually complete a contract, which would work for that specific case but not in the general case for all contracts. My development time has been pretty small lately and its recently been focused on KCT (since StageRecovery in most instances just works as it is) but I do want to spend some time on StageRecovery soon. But soon could also be like, a month from now. So new features and bug fixes will come, but it may be a while. For the most part though I think everything is working mostly well right now.

Not yet. I've got a very work in progress version of it in my dev version, but haven't made that public yet (because it frankly doesn't work yet). If you put in 0 for your altitude, it will actually try to put you into a stable orbit at an altitude of 0, which is definitely not a safe altitude You either need to land a ship from orbit or wait until I get that out, which might be a while since I have to rewrite half the simulation code due to the above discussion

You know, I'm not positive what will happen, but it likely will do its recovery and let you do stuff with FMRS, which isn't really balanced. I will add an option in next version to let you disable the automatic recovery aspect. As for everyone else, I'm listening to what you've got to say about the simulations. Keep the ideas flowing. I haven't picked anything in particular yet, though I'm thinking that update is going to have to be a separate one at a later date. Hoping to get some dev time on Thursday to finish up some stuff for the 0.25 update so that can get officially released. For those of you new to the party, the current official version doesn't work on 0.25, but there is a development beta that is mostly working a few pages back. I'll put a link in the OP.

Maybe I'll save this for a later date and do a larger overhaul of simulations where I make the modifiers customizable and do some other stuff. Maybe let you buy "packages" or whatever to reduce the cost of simulating at a specific place (costs break even after 10 moderately sized sims or something along those lines). I like the distance multiplier because it makes it so not everything is the same. And how its implemented it will work with any mods that add extra planets. I think orbital sims just need to be brought down in cost pretty substantially. I do kind of like the idea that subsequent sims shouldn't be as costly, so maybe if you revert to the editor any sims at the same place don't cost as much until you leave the editor. That way you can make small changes as necessary without blowing the bank. Just thought of a way to make it so you couldn't just simulate a command pod and then get the discount on your mega-awesome expensive ship. Keep track of the total funds spent on simulations that session and once it gets above, say, 2 times the cost of the most expensive one you don't have to pay any more. Otherwise you pay the total cost as normal, or the difference of the max amount and the current sim cost, whichever is less. Ex: Sim costs 10k funds. Max amount then is 20k. You simulate that, then go make some changes. New sim costs 11k funds so the max goes to 22k. Total is now 21k spent. You make some small changes and the newest sim will be 10k funds again. Max is still 22k, but you only have to pay 1k. Future sims, as long as they're below 11k initially are free. If one is, say, 12k the max goes to 24k and you pay 2k. I had originally considered ending simulations when you entered places you hadn't been before (space if launching from Kerbin early on, atmosphere/landed of other planets/moons) but decided against it for simplicity. I do want to require that you actually have landed on another planet/moon before you can start simulations there though. I haven't decided between letting you input any landed coordinates you want, or requiring you to start near a flag/probe/base that currently exists. At the very least there will be a list of those objects you can choose from and it will pull their coordinates and input them automatically. I will add a maximum amount of time for reconditioning. Maybe like 7 Kerbin days before the Overall Multiplier gets multiplied in. Alternatively I could set it so it can't have a BP higher than the vessel's. @DopeGhoti Simulations in orbit around bodies you have visited is already implemented. Just choose a different Body in the simulation configuration window @shand Glad you figured out the setting for reconditioning. The one in the file is BP per ton at an Overall Multiplier of 1. For whatever reason it made more sense to me to save that number (since that's what's actually used in the formulas) rather than the mass (which is what can be changed in game).

Launches from Kerbin I think are fine, but ones in orbit (especially around Laythe. Laythe costs more than Eeloo) might be a bit too high to use frequently. I'd be curious as to what others think. The trade off with them is that you typically aren't simulating an entire rocket (launcher+payload) but instead just the payload when you're starting in orbit (or soon-ish, landed) so the total cost goes down. I'm mostly thinking of reducing the distance modifier and the atmosphere modifier, especially if I'll be adding another modifier for landed simulations. I could also make the time modifier be an actual function instead of arbitrary so you can enter whatever time limits you want.

First question: You can scrap a partially completed vessel and will gain some of the parts in your inventory, but otherwise there isn't much of a benefit. The shorter times for using the same parts in mutliple builds requires the build be completed entirely to count, so it's usually better to build them all the way. Other people may have their own views on the subject, since I don't honestly get to play a whole lot, so there may be some gameplay reason why you may want to scrap something early. Second thing: That's actually the suggested feature I mentioned is currently delayed Some people want there to be time before launch, some want it afterward. I plan on making both options, but it's pushed back for a little while. I personally double the mass requirement for reconditioning, but I wouldn't blame people if they turned it off entirely. It's something I added in after a user suggested it. Maybe I'll double the mass by default and reduce simulation costs next update. I've been feeling that simulations may be too costly to use frequently, especially in orbit around distant planets.

Glad you're enjoying the mod The way the inventory system was developed was to make subassemblies not take substantial time to affix onto a larger craft. Simply build the subassembly ahead of time, "scrap" it, and then use it in a new build. The parts from the subassembly will add nearly negligible time to the total build time for the craft. Alternatively, if what you're adding on is very inexpensive (like a small satellite onto a prebuilt launcher) you can "edit" the constructed launcher and add the satellite in (should save more time than scrapping the subassembly). I purposefully designed the inventory system to not treat subassemblies specially, but instead to treat all parts separately. This provides far greater freedom than if I required the use of subassemblies for similar functionality. Also, actually checking for subassemblies would be much harder to program, in addition to being more restrictive. Hopefully you can see that what you suggest is already implemented (since the very beginning) in a more abstract way and I hope that is satisfactory. A total rewrite of that system is virtually impossible at this time (in the manner you describe at least, it is actually being rewritten right now to use a different mod for handling the inventory system, which has been a real pain to get working properly, which will make it even harder to do anything specific to subassmeblies). If you've got any other suggestions, I'm always willing to hear them. I try not to shoot them down too often, and a large amount of KCT's features came out of user suggestions. My development time has been slim as of late, otherwise I would have already implemented some that I promised to include in the next update (sorry guys, but rollout instead of reconditioning is still on hold :/ )

Even though SR doesn't properly track landing sites based on predicted trajectories I agree that should have had a distance of near 1000 km. The way distance is calculated is by finding the Great Circle Distance using the latitude and longitude of the craft at deletion (as reported by KSP) from the Space Center. It seems KSP isn't correctly reporting the latitude and longitude values for some vessels. Nonphysical timewarp has been known to cause strange issues and I wouldn't be surprised if it were related some how. I have seen similar behavior once or twice. It's likely the same problem as above. I'll look into finding a different way of determining the latitude and longitude of the craft at destruction. I know it isn't the Great Circle Distance calculation, since that is a stock function that would affect all recoveries and no one has reported similar issues with stock games. Powered recovery shouldn't affect this, but thank you for double checking

I've got one more update that will hopefully fix/avert the issues with KAC v2 and has a couple other fixes. Usual warnings apply. Here's a copy of the commit message:

No problem I think I probably made a call to the KAC API without first verifying that the API was ready, which is a silly thing to do on my end.

Thank you for that severedsolo! I have an idea of what the problem may be, if it's not that I think I have another idea of what it is. Either way I'll try to get that fixed up tonight! Also, when Blizzy's isn't installed, the KCT button will show up in the stock toolbar, as you observed. That's been like that since 0.24 came out I should provide a config option to let you select which one you prefer, but I'm too lazy

Noventta, I'd like to see the logs for that if you can get them. There shouldn't really be anything like that happening (obviously). I've seen a similar issue in the past with an out of date StageRecovery API being called, but I doubt that's the issue. Could be KAC API related. Are you using the v3 beta of KAC? If you're using v2 then it's possible that's causing issues, but it shouldn't be :/ Btw, all those bugs are caused by the Start() function not completing, which is all caused by the same problem. So all those bugs are really just one bug

If those of you currently trying out the beta would be so kind as to redownload, I've posted another update. Mostly just fixes for tech node issues and support for Kerbal Alarm Clock version 3.0 alarms. If KAC is installed, KCT will automatically create an alarm for the next thing that's set to complete. It will also check to make sure that the times don't drift apart too much (I need to look into why they drift at all, KCT may not be updating times at a 1 to 1 ratio). You currently can't turn off that feature: welcome to betas Remember, beta means possibly game breaking, so it is not suited for everyday use if you aren't willing to risk your save file. It should be fine, but bugs like to creep in in weird places sometimes. Additonal note to beta testers: because I updated the internal version to 1.0.3 you won't be notified of an official update through the KCT update checker (because they'd be the same version). KSP-AVC will still alert you though, since that's tied to the .version file that you would have from 1.0.2.

Unfortunately all of the KSC locks freeze time. I believe it's being worked on (look at one of the recent dev notes) and I reported it when 0.24 first came out (since it plagues KCT). I really liked in 0.23.5 (and prior) when the "click-through" bug didn't exist. It's not even a click through, it's a "cursor was over a building prior to entering a GUI window, all clicks will go to the main KSP window, even if they're not actually over anything" bug. If you find a way around it, I would love to know.

Everyone having issues with KCT and 0.25 don't worry, I'm working on an update and things appear to be going mostly well so far. I have a bug or two to fix, and depending on time may try to get some basic support for adding alarms automatically with the new version of KAC. I'm currently at work and so can't work on it, but when I'm done today I plan on coming home and trying to finish things up. For those of you who absolutely cannot wait (please, I urge you to wait just a little while longer) I will release the current dev version. Note that this hasn't been thoroughly tested and is not guaranteed to not TOTALLY BREAK EVERYTHING. Aka, don't blame me if it nukes your save It's just the .dll, you'll have to download the rest of the files from the latest release. Not for the faint of heart @LethalDose, the funds changes are due to switching the inventory back end to another mod called The ScrapYard that I am co-authoring with the guy who does Kerbal 4X. I MAY be able to provide a way to keep the current system, but it wouldn't be as easy as adding a config option and a couple if statements like it would be if the code was internal to KCT. How it works is that when you recover some parts, KSP gives you the funds, and Scrapyard takes the total amount (before recovery modifiers, aka MORE than what you were given) back. When you launch a ship KSP takes your money and Scrapyard gives it back. That way parts in the inventory don't effectively cost anything, but you still have penalties for recovering far from KSC. You could then sell the parts for funds (at a reduced rate that we haven't determined, I like 95% personally).

As of right now it's just raw time values, so if you don't really care about the position of everything you can just set it to "0" and it will be sunrise on the first day. I do plan on letting you enter the time as Year Day Hour and maybe Minute and Second either as the set time, or in addition to the current time (2 years, 3 days, 4 hours could either be the exact time, or, if it's currently year 4 day 17 hour 1 it could make it year 6 day 20 hour 5, if that makes sense). Not sure if that will be in the next release or if I'll just save that for a later date. There seems to be some incompatibilities with another mod (probably action groups extended, but not positive) that are causing testing to be slow. I'm gonna see if I can figure those out before release, but things seem to be running smoothly on my end with just KSP + KCT 1.0.3 (but I haven't tested much myself). Edit: Nonventta, I've got a feeling that with the internal changes to currencies that 0.25 brought, the old version of KCT won't work. I'll try to get the new version out ASAP, but I am at work currently.

Ah, I see what you're getting at! SR will totally ignore it and it will be destroyed. I don't personally want to change that, since if you're gonna be landing on another planet you should probably actually do the landing FMRS may make that easier if you have to land a bunch of things at once (assuming FMRS works on other planets. I recommend it to people a lot because its implementation is pretty cool, but I have not used it myself yet). So unfortunately for some, SR will not be taking its adventures extraplanetary. We're a Kerbin only corporation

Probably not perfectly, but it may work. I've already got a 0.25 update in the works and JeffreyCor was testing it out last night. I *hopefully* will be able to fix up any issues with it tonight and will release it as soon as possible The update is pretty much just a compatibility+bug fix update so none of the new features I've been talking about will be in it quite yet (there is one new feature, the ability to start a simulation at any time (UT) for testing things out during a transfer window and stuff like that).

StageRecovery has an update (1.5.1) designed for 0.25 which is hopefully fully functional. Probably needs some tweaks to support the recovery transponder strategy (or whatever it's called) but otherwise is recompiled and ready to go.

That is actually what SR is designed for. When the vessel gets unloaded from reaching about 22km (0.01 atm) SR does some checks to determine what the landing speed would be, and if it falls below a certain value then it recovers it. The Variable Rate model (which is the default one) recovers it at a rate dependent on the landing speed (7 m/s may be 90% or something like that, but 10 m/s might only be 10%. Note, not actual values, but I believe the defaults are around that). SR also checks if Deadly Reentry is installed, and if so does some very very basic checks to make sure you can't throw things into the atmosphere at 6 km/s. It also can do checks based on if the unloaded craft is controlled (I still need to check if having kerbals works properly, but I know probes do) and it will try to burn fuel to land, if parachutes aren't installed or aren't enough. In short, yes SR handles that, since that's exactly how SR works It's just not 100% accurate because I have to make assumptions.

Very small update for 0.25 compatibility. Let me know of any issues! There's one known issue where it doesn't change the recovery percentage when using the strategy that normally increases recovery. I couldn't figure out how to access that in a convenient way. I may have to manually check the "commitment" on that particular strategy and manually compute the change, but that's lame. Download is on the first post. KerbalStuff and mediafire should be updated, Curse should be soon. Edit: You know, I haven't tested it, but since I define the addition of funds as being for vessel recovery, it MIGHT add the extra percentage in already. I haven't figured out the nuances of the Strategies system yet, that parameter might just be for record keeping later on in career mode.

I'll add a note in the Known Issues that Tarsier Space Technologies appears to be incompatible (for some strange reason...). If I get a chance I'll try to take a look, but my free time has diminished to nearly nothing recently and I don't expect that to change any time soon. I am planning on trying to get a 0.25 compatibility update out as soon as 0.25 hits, but It'll just be a compatibility update. It'd be cool to integrate with the strategies system (build faster at higher costs, stuff like that) but I won't be doing that right away. Maybe not letting you build ships if the VAB/SPH are destroyed or unlock tech if R&D is destroyed. I'm hoping for a quick update without too much to change though for the initial update. @Nori: It should be that the reconditioning rate is the sum of all of the VAB rates. So when you upgrade any of the rates, or unlock new ones, the reconditioning time should decrease. The total BP is based on mass (and Overall Multiplier) so that won't change, but the rate should be. Reconditioning takes place as a secondary rate slot since repairing the launchpad would be independent of the warehouses building ships (but higher rates = better crew and better/more crew means faster repairs). You know, if I ever rewrote KCT I think I'd take a similar approach to the whole thing. You'd hire crew with funds or science that could build ships faster, maybe even have them earn experience for every ship built. And you could buy upgrades to your facilities to build mutliple ships or have reductions in costs. Basically, gameify it even more. Though I have no intention of rewriting KCT. I definitely don't have the time for that

That's very strange. I don't see the node cost listed anywhere either. It works fine if you remove KCT and load the save? Could you get me the output_log file? (check the bottom of the first post to find out where it is). KCT doesn't directly interact with the GUI elements of the R&D center, but weirder things have happened as a result of bugs.

Feel free to! I don't have the time to do it myself right now, but if you do I'd gladly add it. Alternatively, a window that pops up when you press the launch button that allows you to choose your launch site. Whatever you prefer. If you'd rather I write it I can probably take the time to do so (since KCT is not written in the clearest way) but some "example code" or something like that may make it easier for me. Let me know what you prefer.