magico13

You can always keep everything how you have it now, but you'll still need to make at least a small update since I removed the separate max values in the formula cfg in favor of using the min() function. If you don't change accordingly, the prices will just keep going up when people buy upgrades, so it shouldn't (hopefully) break anything too badly if someone uses an older config. Then you can spend some time making bigger changes later if you want. Unfortunately, the current release version isn't forward compatible, so you can't put out that config until the update :/ I could maybe add some functionality to read in the "max" values and wrap the existing formula in a min() with that max. I'll actually probably do that since I'm afraid people aren't going to remove their old configs when they update (especially if they install through CKAN). So it looks like you won't have to worry too much after all, so take your time, haha Edit: Build 98 of KCT has code that should auto-update any existing configs, so no need to rush. Things should be exactly the same for end users after they update, meaning you can take your time with playing with the other options if you want. Sorry if I made you feel rushed at all!

The physical parameters aren't changed, just how it's displayed to the user. So you'll have 4 sunrises per "day" and Kerbin won't be anywhere near where it was a "year" ago.

I'd like to hear more about this, if you're willing. For clarification, after removing KCT you could no longer save or load craft? I'd love to see logs from this, but I doubt you have them anymore. If anyone else in this thread sees similar behavior in the future, please let me know in the KCT thread. KCT doesn't actually touch the load or save craft buttons (except to disable them when a KCT window is open in the editor, or when "editing" a craft) so I don't know off the top of my head what would have caused that issue. Maybe it's my secret way of locking people in once they start using KCT... /s I wouldn't actually do that People should be able to add and remove mods whenever they want, so I don't want to wreck any saves on accident by removing my mods. Speaking of KCT, have you guys reworked your KCT configs yet? I've got a couple changes I want to make tonight for a future... thing... (there's a day coming up soon that I want to have a little fun on, but I need to add the code into the next release ) and then I think it's ready for release. I don't want to update and then suddenly have things break for you.

Claw, just a heads up that I'm borrowing some of your code from InflightShipSave for a small mod that I'm making that lets you modify a ship that's already in orbit (to add struts, fix fuel lines, or do other similar small tasks). Figured I'd let you know. I've got a really early proof of concept version here. It's the second one on that page, Re3. Also, not sure if I've said it before, but thanks for these! Especially the decoupler fix, which drove me nuts in 0.24.2 when it was introduced. The bug ruined several designs I had, and made testing kOS scripts with the Kerbal X frustrating. Even using Sepratrons didn't help much.

Yep. 24 hour days used to be the only option until some time around 0.23.5, when Kerbin days were added (and enabled by default). You can change it in the Settings menu in the Main Menu.

You probably didn't rename the icons folder when you put in the new build. From the OP: The name of the icons folder has changed. Make sure to change "icons" to "Icons" (capital I) in the files from the stable release. Otherwise the buttons will have messed up textures.

With dev versions, no. They're forced on because it's a development version and bugs are expected and I need to see that output when debugging issues. In the release version 99% of the debug messages are turned off unless you manually turn them on in the settings. I could add some filtering options (the output from the math parser really isn't needed 90% of the time, but was VERY needed in these past few debug cycles), but seeing as I'm thinking of releasing the current code as being official I don't really want to add anything else. Has anyone actually had any issues lately? I haven't had the time to sit down and test everything myself 100%, but if nobody's had any issues lately I might just release as-is. A few bugs in release is ok, since we might not catch them even if we test for weeks. I just need to spend some time to update the changelog and prep everything, maybe update the Getting Started Guide, then push to master (which will build and package everything on Jenkins) and take that zip and upload it to 3 different locations. It annoyingly takes a few hours, depending on how thoroughly I update all the documentation.

Did you figure out what was wrong? I HIGHLY suggest reading through the writeup I did on how the KCT_Formulas.cfg work (https://github.com/magico13/KCT/wiki/KCT_Formula.cfg-and-Math-Parser-Documentation). You're definitely trying to use functions that don't exist and are expecting it to follow order of operations rather than (how it actually works) left to right. To view the latest source you have to switch to the 025_update branch on github. The master branch is always (usually) synced with the latest official release. You also can view it by going to the "workspace" on the Jenkins page. It may also be nice to know that you don't have to totally restart KSP between changes. You can edit the file while KSP is running, but I might suggest exiting to the main menu, just to be safe. Also, BP is given by two formula, the "effective cost formula" modifies things on a per part basis, which is summed and fed into the BP formula. So you might set the effective one to [C] and the total BP one to [E]. Definitely read the writeup.

Alt-F2 brings up just the log, Alt-F12 brings up the whole debug menu, of which there is a tab for the log, but I personally find that one to be really awkwardly designed and never use it. The absolute best logging related thing for KSP is the output_log.txt file located in KSP_Data, as it reports far more than the KSP.log file does.

They are. They're recovered in a separate way from dropped stages, and since they're just debris it didn't seem practical to fire off a recovery message about them. They also aren't recovered using the stock functions (because for whatever reason those only were returning like 60%) so instead I just remove them from the game and manually add in all of the funds for them and any attached parts. I do fire an SR Recovery event, so any mods that use the API will be notified of their recovery at least. You should see the funds value go up and a message or two in the log about clamps being destroyed and funds being added.

I added automatic launch clamp recovery to StageRecovery around the 0.90 release (which actually works differently from how dropped stages are recovered) but I'm not 100% sure it has been functioning properly (as in, not always removing the clamps). You can turn it off in the settings if you want. In stock, launch clamps are automatically recovered when you launch a new craft, and you receive all the funds at 100% recovery rate. I proved that last September in this imgur album (no reason to embed it here, so I'll just provide the link). It's always bugged me that they don't get automatically recovered when they go out of range. There's no reason to keep them on the pad anymore. It's even more dangerous if you use them on the runway.

In addition to it returning less funds (which are then taken since you've "rebuilt" the craft, meaning you pay money to recover a craft that's far away) it also requires more time. The minimum time it takes to recover a craft is the time it would take to rollout the vessel (even for planes). The maximum is twice that. I might make some changes to that in the future, but it's a simple solution for now In short, the closer to KSC you land, the better.

Already implemented for next release in the development builds. It's potentially buggy since KSP doesn't really like when you convert a Vessel to a ShipConstruct (but is happy to do the opposite function), but I was doing some additional testing today and it seems to be working nicely. I even did a write up of how to add additional MODULEs to be reset, so that people can do that right away when I release it. Which might be tomorrow since I haven't been having any major bugs with the changes made in the dev builds. For those of you curious, the dev version is about 50 commits ahead of the release version, representing a surprisingly large amount of changes for what will probably appear to be not a lot of work. However, I think opening nearly every calculation KCT does to a user adjustable config file is a non-trivial addition There's also the recovering to storage and KSC upgrade time requirements. And bug fixes. Lots of bug fixes.

Maybe. It probably doesn't hurt to add it. I'm working on adding those other changes in now. I've got a button in the editor to reset fuel tanks to their full state, but I haven't gotten around to testing it yet. I'll push a new build once I get that tested. Edit: I think I have the first draft of the "simple" config now. There are absolutely no upgrade points in use, ever. All the rates are determined by stock building upgrade mechanics. Tech nodes take between 2 Kerbin days for the cheapest node, to 80 Kerbin days for the most expensive ones (but upgrading the R&D center early is a good idea). BP values are kept the same, but build rates progress with editor upgrades and R&D center upgrades (editor upgrades unlock more build rates, R&D center upgrades unlock faster rates). Here's the breakdown for that: 1 rate per editor level (so level 0 is 1 rate, max level is 3 rates). R&D lvl 0 possible rates are (1,0,0), lvl 1: (1.5, 0.5, 0), and lvl 2: (2, 1, 0.5). You also gain science for ship building as you level the R&D center. I haven't tested any of this yet, so it likely has some issues, but I got the actual code side working properly now KCT_FormulaSettings { NodeFormula = 9 * (1+[R]) / 86400 UpgradeFundsFormula = -1 UpgradeScienceFormula = -1 ResearchFormula = [R]^2/86400 EffectivePartFormula = min([C]/([I] + ([B]*([U]+1))), [C]) ProceduralPartFormula = (([C]-[A]) + ([A]*10/max([I],1))) / max([B]*([U]+1),1) BPFormula = ([E]^(1/2))*2000*[O] KSCUpgradeFormula = ([C]^(1/2))*2000*[O] ReconditioningFormula = min([M]*[O]*[E], [X]) BuildRateFormula = max(0.5*([R]-[I]+1), 0)*sign([L]-[I]) } Edit 2: I added RealChute to the default module templates. As expected, it was more difficult than other things I had to add the ability to reset ConfigNodes within the MODULE node (in this case PARACHUTE). You can either delete your template file and have the latest build regenerate it, or you can add the following to your file. MODULE { name = RealChuteModule armed = False staged = False launched = False oneWasDeployed = False PARACHUTE { capOff = False time = 0 depState = STOWED } }

Let's see if I can come up with it without testing first, based on a saved ship of mine: MODULE { name = RealChuteModule armed = False staged = False launched = False } That's just a guess. Might need a few more things. Might also need to add the ProceduralChute module, but that should be a good starting point.

Realchutes aren't supposed to be reset. Partly because I haven't added that module in, and partly because they have a strict limit on the number of spare chutes. Although I guess it would make sense that they'd get replaced. Feel free to add it into the ModuleTemplates.cfg file and post back what ends up working You don't really have to if you don't want to, but it's not too hard to add any module you want reset to that file. Just open up a craft file in a text editor that has the "pristine" state and copy the parts that need reset (for the stock parachute you just have to change DEPLOYED to STOWED, for instance). I'm not sure if that's too much to ask for a normal user to do, but it's actually pretty straightforward, so let me know if you do it and if you have any trouble with it. I'll probably write up a guide (with examples) before release. I don't know if I can fix the issue with ships being oriented wrong. The instant you pick them up they correct themselves, but they must be edited to do so, but that makes me think they're actually oriented correctly but the coordinate system needs updated. I might be able to apply a 90 degree rotation to ships going to the SPH, but then if you pick up the ship during editing it will rotate incorrectly I think (and then will point downward). It's a minor enough annoyance that I might release with it like that. The VAB orientation works properly, btw. I didn't get a chance to add the build rate formulas to the config last night (a bit too much work at the time, I made some breaking changes to the math parser that took priority) so I'll probably get that done tonight. I did get StageRecovery and FMRS to play nicely together though, so the dev builds of that have FMRS support and it's awesome

Unfortunately I'm really behind in updating the official release :/ It's been a few months and I really want to get these changes out since there are quite a few bug fixes and some cool changes. Which is why I'm glad people like you are testing out these development versions and letting me know what issues you find, since I don't get enough time to As for KK, like I mentioned in the main thread, after this next release I'm gonna try to get some tighter integration with KK so it isn't such a pain to use KCT with it. Things like rollout and reconditioning on a per launchsite basis, along with letting you choose the launch site when you go to launch from the space center or flight. It should also open up multiple launchpads in the stock game, which I have a kind of cool idea for how to handle (since each pad will be upgraded independently, I'm going to use the stock upgrade system and "replace" the launchpad with the one you have selected. So if you have a tier 3 launchpad as your primary, and a tier 1 launchpad as your secondary, when you switch from the tier 3 to the tier 1 it will actually switch the model to the tier 1 launchpad I'll need to figure out how to handle switching pads if you destroy one of them). Also, once I add in the things mentioned in this github issue (point 2 from the post I made at the end of the previous page of this thread) then I'm gonna try to come up with some example configurations that people might find interesting. RP-0 will obviously have one that will have some major changes, but two of the ones I'm considering are one that makes things in line with ExtraPlanetary Launchpads times, and a second one that "simplifies" things by relying entirely on the Stock upgrades and doesn't use upgrade points at all That second one sounds like fun to me. Things like having build rates have 3 tiers in line with the R&D center tiers, and the number of build rates in each building determined by their level. (So R&D tier 1 might have rates of (1.0, 0.5, 0.25) with only 1 rate unlocked with VAB level 1. If you up to R&D tier 2 the rates go to (1.5, 1.0, 0.5) or if you unlock VAB tier 2 you unlock the second rate (so 0.5 with R&D tier 1, or 1.0 with R&D tier 2). Tech node rates might depend only on their cost, or might get a boost with R&D tier (so if you unlock tier 2 without unlocking all of the tier 1 nodes, the remaining tier 1 nodes will unlock faster). I want to start a thread to have people submit configs so we can have a "library" of them, but I doubt too many people will take the time to play around with them that much.

Not having any rollout and having really fast rollouts are very different. The problems that cause one are different from what causes the other, so that added to my confusion. It also doesn't help that I haven't gotten to test anything in about a week I have some potential ideas for what is causing the ridiculously fast rollouts. I know it's due to the change in the formula, but might also have to do with the mass calculation of the ship (which are related). I'm going to look at what I changed compared to what it was before. I imagine reconditioning is similarly affected, since those use the same formula (and are, in fact, the same internal data types). Svm420 the way you can save a scene change is that now you don't have to roll out a vessel at the space center, go to the VAB to select the launch site, and then go back to the space center to launch the ship. Instead you roll out the vessel at the space center, go to the VAB to select the launch site, and launch from the VAB. You still have to do rollout in a scene where time passes (space center, flight, tracking station). They have to be totally rolled out to let you launch. I need to make sure that it works properly for the SPH and when rollout percent is 0. I actually haven't tested launching from the VAB at all. Edit: HA, found the issue! KCT_GameStates.timeSettings.BuildEffect is not the same as KCT_GameStates.timeSettings.ReconditioningEffect. I accidentally am using the Build Effect instead of the Reconditioning Effect. Oops... Should be fixed in 94.

No, it's a full on feature now. It's been in for a while now actually (a few weeks). Just open the KCT menu during flight and click the "Recover to Storage" button (has to be able to be recovered normally). Then it takes some time to be available for use.

It might have been mentioned a few pages back in here, or maybe that was the dev thread, both are somewhat active right now due to the state of the development version so I don't remember who said what in which Short answer is "no". Longer answer is "sort of". There's nothing that explicitly supports Kerbal Konstructs, but there's also nothing that directly prevents the two from working together and I know of people who do. There are a few extra quirks though. Whichever launch site is chosen in the VAB/SPH at the time of launch is the one that gets used. You'll want to turn off reconditioning and rollout times, since they assume a single launch site. In the development version I've made it so you can launch completed ships from the editor, which will save a step for KK users (since they won't have to switch back out after selecting a launch site to actually launch). I'm thinking the release after this next one I might spend some time adding additional cross-mod support. Kerbal Konstructs is on the top of that list, followed by more options for Kerbal Alarm Clock, and the TestFlight mod. Currently there's already basic KAC support, loads of RSS support (KCT is a recommended mod for RP-0, the career mode version of Realism Overhaul), and support for StageRecovery and DebRefund (not that DebRefund appears to exist anymore). CrewQ is also getting support in the next version, added by the author himself. I can't remember if I've added anything special for any other mods :/ StageRecovery is getting FMRS support though (and the dev versions already have it).

A couple things: 1) I obviously didn't release last weekend. The main reason for that is because I haven't gotten to test the recover to storage feature pretty much at all, especially after adding the module templates file. As such, if you try out that feature please let me know whether it works and any issues you encounter, no matter how minor. 2) I've got a few more formulas I want to expose. Namely, the build rate increases per build point. I also want to add KSC building upgrade level as a possible variable for pertinent formula, like R&D center level for tech upgrades, or VAB level for rocket building.

In short, no there isn't a way of doing that (currently) other than utilizing the full features of the KSP editor. You can make nearly any part a root part, so you don't have to use a command pod (you could use a light probe core, or even an SRB, or even any non-radial part as the root part using the root tool [hotkey 4]). If you want to get an idea of the difficulty of procedurally determining stages, just read today's dev notes. Those guys are professional programmers who are paid to spend their time developing for KSP and it's still a challenge for them. My suggestions are to use subassemblies once you've got a setup that you know will work, and to use the root tool to make just the section you care about the root part. Any of the "floating" parts in the editor aren't used in the calculation, so you can make a stage the root one, remove all the other parts, calculate everything, then replace and reroot the old parts. Or build from the bottom up, doing the same thing. Or standardize your designs. Or use the real chute mod and manually designate your chutes to land things at the right speed (what I do). I do want to add better editor features at some point, but it's a lot of work and I don't have the time for it right now. Plus, the current ones work just fine if you take time and carefully design your craft. If you want to quickly build things and toss out stages without testing and other preparation, that'll generally work just fine too, but you'll probably have somewhat lower refunds. StageRecovery is fairly forgiving. The kind of funny thing is that you often end up losing more funds by recovering SRBs than you do by tossing them Edit: I did a bit more work on FMRS support. StageRecovery should now still recover uncontrolled stages that use stock parachutes (FMRS won't try to handle those) even if FMRS is active. FMRS handles controlled stages and/or stages that use RealChutes on them when it's activated, and StageRecovery will handle everything if FMRS is turned off. This only applies to the development builds.

You know, I think I noticed some strangely short rollout times for me as well. Could be an issue with the mass calculation. Keep an eye out and let me know what you all find. Edit: I'm an idiot. I know what the problem probably is. Try deleting your KCT_Formulas.cfg file prior to the next time you launch KSP. I made some changes to it that could be affecting things.

I've already got one in the development builds. I was talking to the FMRS dev about increasing compatibility, but haven't heard from him in a while. I might try to add some compatibility in on my side anyway since I want to start using FMRS in my game as well. Edit: Well that was fun! The latest development build has the first pass of FMRS support. If FMRS is enabled and armed then StageRecovery won't try to recover anything. Otherwise, it'll behave as normal. There's at least one instance where you can have stages not covered by either mod: FMRS active but no way to control the dropped stage. At the moment I can't think of a way to cover that base other than checking for control manually (but apparently if you've got RealChutes on the stage FMRS still tracks it, so that's a special case I'll have to add a workaround for if I just check for control). If you want to try out the development build, replace your StageRecovery.dll with the one you can get from here. Be warned that this isn't thoroughly tested and has some other WIP changes that you may or may not want.

Hmm, glad you found a solution to that problem! Are reconditioning and rollout not functioning at all with the latest build? I haven't gotten a chance to fire up KSP since I made it so I haven't gotten to test it. It shouldn't be affecting reconditioning (but it wouldn't surprise me if it did some how) and it should only affect rollout when you've got the slider set to 0% rollout, 100% reconditioning. If you had a one-time loss of reconditioning then I'm not going to worry too much. I annoyingly have had several launches where reconditioning hasn't kicked in like it was supposed to.