KCT integration

[NathanKell]

In #35 Felger mentioned KCT, and also in https://github.com/magico13/KCT/issues/17 @magico13 asked what we're looking for. Thus I'm opening this issue so we can brainstorm what additions/changes/etc to KCT we're looking for.

We've tossed around the idea of manufacturing cost being different from launch cost. That's something to consider, with perhaps multipliers for "payload has never flown", "crewed mission," etc. Further, KCT can handle integration costs, and per-launch infrastructure costs (per-pad infrastructure costs would, I guess, wait for 0.90).

@magico13 has already (thanks so much!) added support for RSS's multiple launch sites, and for configurable time per science point (to unlock nodes).

Other thoughts:

• Time to unlock parts (Development, as well as research, takes time).
• Deep integration with PP (the idea of stretches and propellant changes requiring very little money and time, whereas diameter changes need new tooling)
• Recognizing subassemblies (an oft-used upper stage is far cheaper and faster than a hand-built one)
• Manufacturing lines (say you want to pay a sum in time and money to set up a manufacturing line for a sub-assembly; you then get, say, one stage [subassembly] every few months). You can expand the line, or freeze it, as time goes on costs go down, minor changes don't require new lines, etc.

Further thoughts?

[Felger]

How can we tell if a subassembly has been modified after being added to the vessel? Is it as simple as regex match between the text of the subassembly and the vehicle? Or would we have to come up with something more complicated?

Additionally, at this time subassemblies lose their struts and fuel lines, which means that at least that portion needs to be unaffected by the cost / time to launch code.

[NathanKell]

It shouldn't be that hard to compare the trees to make sure the same parts are in the same order. However, for procedural parts it would entail making sure that that module's .OnSave output matched the stored data.

Also, weird about the struts/fuel lines. That hasn't been a problem for me.

[Felger]

Perhaps that's from an earlier version, or from the subassembly mod that existed prior to the stock implementation, it's been a while since I've built a subassembly.

[NathanKell]

Yes, that was very true of the mod, but stock subassembly code seems to work ok with them.

[magico13]

I have also heard similar issues with struts and fuel lines but thought I read somewhere that it was being fixed. If I ever find a source for that I'll post it, but I can't think of where it was off the top of my head.

I should warn you that I won't be very active starting next week for a few weeks as I am a first year graduate student and have finals + projects/presentations to do. After the 19th I'll be done though and will have time after work/on the weekends to do more dev work.

Regarding the given list:

• individual part unlock times should be doable. I'll have to look into how to disable specific parts rather than whole nodes, but it's obviously doable since Stock does it.
• deeper PP integration: I hate to set up something and then change it immediately afterward, but I agree that the current implementation between PP and KCT is pretty lackluster. The best way of handling this may be a rewrite of the KCT inventory system to save more details rather than only name and quantity, and instead to save copies of certain modules, costs, etc. When that time comes we'll likely have to discuss this in detail more.
• Sub-assemblies: I have always veered away from dealing with subassemblies specifically because, despite KCT being somewhat realistic, I have typically favored simplicity and gameplay rather than strict realism. Obviously that mindset doesn't work as well when integrated into Realism Overhaul. It should be easy enough to compare the tree (and relative positions and orientations) to ensure the user hasn't modified the assembly. KCT can easily get a subassembly storage as well.
• With a sub-assembly storage it's easy to add a manufacturing line (presumably with an initial currency cost) to automatically create more sub-assemblies. Allowing for expanding the line (aka, speeding it up I presume) and freezing it would also be easy. Not requiring a different one for slight changes is harder but pretty much anything is doable with time.

I haven't read through a whole lot to see what you guys are planning on doing with costs, so I can't comment on it much. I imagine KCT will need some extra code to handle it properly though. There's a non-zero chance that I'll have to integrate with this through an extra dll (on my side) rather than relying on reflection for some features, but that's fine by me.

Like I mentioned before though, this will all have to wait on my end until mid December unfortunately. The update with basic RSS and PP support will hopefully be out soon, but it's got some bugs I'm trying to take care of before this weekend while also visiting family and friends for Thanksgiving.

[Felger]

More thoughts:

• There should be flat infrastructure costs for every launch site you use. Perhaps the first time you select a launch site you pay X cost, and the cost goes down per launch site, as you build up launch site manufacturing expertise? (And at the beginning of the career, you're allowed to select one launch site as the starting point?)
• Integrating some kind of stage flyback would be awesome. FMRS already does a good job of it, perhaps making that a recommended mod?
• Part Recovery returned cost, I'd say dependent on tech level. Early part recovery should be inconsequential, maybe 1% recovered cost. If anything, it should give you science, or reputation. Higher tech levels, increase the recovery multiplier, with the later levels (near to far future) increasing to maybe 50-80%? Keeping the distance multiplier seems a good idea.
• Ideally, time to build multiplier should be a 'fuzzy' function. Essentially, something of a fit to previous vessel designs, the further removed from previous designs the longer it takes to build it. This could be accomplished using some kind of statistical model, getting an R value for the fit between the new craft and the old. (IE a vehicle with 1 more of the same engine at the bottom, a bigger fuel tank, and an extra upper stage motor would be cheaper to produce than a vehicle with completely redesigned engines, and more stages.) I believe using procedural parts memory would solve some of this, but only for tanks.

[magico13]

Unlock costs for new sites would be best as something on your guys' side, same with part recovery returned cost (though there likely would be some crossover with KCT's part inventory to figure out).

KCT has a basic stage recovery mechanic, StageRecovery expands on that even more, but both make assumptions for simplicity. StageRecovery has an API you could tie into to make changes, otherwise if you used FMRS you'd just make changes during the vessel recovery event. Using FMRS seems to have incompatibilities with KCT's simulations from what I've heard, but otherwise should function correctly.

Making large changes to the build time function is something I'm generally uncomfortable with, primarily because KCT has existed for almost a year now and has been using the same system that entire time. One of the unfortunate effects of utilizing an existing mod for functionality is that it won't quite be exactly what you'd want. With that said, I am willing to make a lot of changes for you guys, but as you can imagine I've got my own users (with their own expectations) to manage. I also have to make sure that KCT remains totally usable without RSS, since a majority of the userbase doesn't use RSS.

Moderate changes to the build time function (such as special handling for procedural parts) I'm fine with. Perhaps with a KCT-RSS integration .dll an alternative function could be used for RSS, which I'd also be ok with. KCT's build times are based on costs, so if you make changes to the costs yourself to use the fuzzy function, KCT will automatically respond (but may need some tweaking to respond how you'd like)

[Felger]

Don't worry about it, The change to construction time was a pie-in-the-sky idea, definitely not a make-or-break suggestion.

Personally, my ideal scenario for non-parachute stage recovery would be to do it manually once, then have the game remember that stage can be flown back or landed safely, and auto-recover from there out. In any case, for RP-0, I don't expect that to become a necessity or even a possibility until the later tech levels due to engine re-ignition requirements.

[pjf]

I have always veered away from dealing with subassemblies specifically because, despite KCT being somewhat realistic, I have typically favored simplicity and gameplay rather than strict realism.

Chiming in with a +1 here. RealismOverhaul already presents a rather steep learning curve, and while KCT complements it in a fantastic way, I'd hate to see KCT be too difficult for newer players to pick up.

In particular,that means that I'd favour simpler to understand models over realistic ones. If we're going to put a restriction on what can be launched, then I'm cool with that being a maximum tonnage, along with the ability to pay for the pad to be upgraded. That's easy for players to understanding. Putting restrictions or penalties based upon widths of parts would likely be a fun-spoiler for me; after I've designed a ship, the last thing I want to do is go back and adjust it so the volume of some parts remain the same, but the dimensions are different.

I'd advise caution with sub-assemblies. I think it's perfectly reasonable to have an assembly line or similar which allows parts to be ordered, and sub-assemblies are an easy way to indicate which batch of parts one wants; however I think doing anything other than just putting those parts into the player's inventory is going to open up a whole lot of complexity that will be hard to get right.

With regards to recovery, I believe KSP already has strategies or whatever it calls them regarding this, with one of the options being making parts more expensive, but increasing their recovery value as a result. That seems like an obvious thing to integrate with, as it means the player can control their trade-offs based upon their own gameplay. However I've mostly ignored strategies (I'm still not sure what prestige is supposed to do), so I'm speaking from a position of ignorance here.

With regards to specific parts, I think it would be reasonable to have per-part min/max recovery percentages which can be set as part fields, with these defaulting to 0 and 100 respectively. This means that consumables such as heatshields can be made non-recoverable, and items which need extensive reconditioning (such as engines) can have a cap on their re-use value. If this is done, this information (maximum, maximum, and current re-use percentages) should be clearly visible to the player in the part view, and part values should be scaled rather than truncated between these values. (If an engine is capped at 50% value, and the player's strategy gives them 70% recovery, the engine should provide 35% when recovered, not 50%.)

~ Paul

[NathanKell]

@magico13, obviously real life comes first! :) Best of luck!

Also, absolutely, this thread is for brainstorming, not Must Have Features (that May Screw Over Other KCT Users)...and even above and beyond that, not a list of Things We Want You To Do; we realize this is work and we can certainly help make them.

• Great to hear re: part unlocks!
• Regarding PP, as I said on your issue, I think what you wrote is great for the stock+KCT players. Given how Stretchy Tanks were originally justified in-universe (gah), it's even keeping with canon. But given how RO uses them, and for people who want a little more realism (or complexity) without RO, I do think making a distinction between diameter and length makes sense; this also makes sense because one could use a series of, say, 1.25m tanks to make most any length series of tanks, but one can't use them to make a 2.5m diameter tank.
• Subassemblies (and, blue-sky) manufacturing lines are IMO quite low priorities compared to the above.

I definitely agree unlocking new sites should be on our side, although I would be interested to hear your ( @magico13 's) thoughts on rollout (and your earlier plans, IIRC, re: multiple pads per site), since the VAB infrastructure is already handled by buying BP upgrades for the VAB, or buying a second VAB buildrate. I am away for the holiday or I'd be trying the dev build out...

Regarding cost and time, the major costs and time-sinks are:

1. Pure research (in, node time cost)
2. Hardware development (part cost handled, part time not yet)
3. Hardware tests (right now it makes more sense, IMO, to skip the obnoxious part test system than to try to model this with it...)
4. Stage development (neither in)
5. Stage tests (counting as a regular craft launch, time and cost are in)
6. Manufacturing line setup (neither)
7. Launch complex infrastructure buildup (during phases 2-6) (somewhat in, counting VAB build rate etc, though that increase in BP/sec is instantaneous)
8. Crew training (neither)
9. Actually building the stages (neither)
10. Integration (in, though with no cost)
11. Launch. (12. Recovery and refurbishment, going back to 10, with bits of 8 and 9 perhaps)

Did I miss any?

Your build time function already, AIUI, tracks how many times a part has been built before, so the fuzziness is already somewhat in. That should be enough to work with, IMO. And an excellent point about costs.

@pjf: the idea is not that you'd be prevented from designing a craft, the idea is to give advantages to reusing existing stages. Nothing (other than time and money) would prevent you from making a bespoke LV for every mission, but from both a realism and a gameplay standpoint, it's worth encouraging LV reuse. I don't disagree that it's a constraint, but good constraints can lead to good gameplay, not bad.

Further, as @magico13 was suggesting, the stage mechanic (subassemblies, manufacturing lines, etc) might well be something that, like Engine Ignitor, is recommended but not required; I am certainly not about to tell people what they should find fun (though I am happy to evangelize if they don't know yet).

[magico13]

So I was planning on redoing the whole KCT upgrade system after 0.90 comes out (since upgradable facilities likely will require a bit of special handling), and in that I was considering allowing multiple "launchpads" that would let you rollout multiple ships at once at one KSC. That's actually how I'm going to handle KK integration (since there's only one KSC but multiple launch sites). Rollout is already in the dev build of KCT for the launchpad and is associated with launchpad reconditioning in that it is mass based, the speeds are based on total VAB rates, there's one per launchpad, and there's a slider to let you choose between all rollout/all reconditioning/or anything in between. The "total reconditioning" for a build is the sum of the rollout and the reconditioning it would create, so if you set the Max Reconditioning setting to 100 and the rollout-reconditioning split is 25%, and the ship would normally have a total reconditioning of over 100 then the rollout BP will be 25 and the reconditioning BP will be 75. I've also got code in for similar time requirements for recovering craft, currently only for recovering them straight into storage, but I could probably extend it for all vessel recovery so you don't get funds/parts until the time requirement is paid.

While VAB/SPH upgrades are applied instantaneously, they are acquired slowly while your program builds up, which adds that sort of progression. Currently all KSCs have the same total number of upgrades available to them, but after I separate the upgrade system from the tech tree I can make it so each KSC has to purchase upgrades separately, though some upgrades will be global (like simulation improvements). I also don't know what 0.90's upgradable facilities will do to help add this progression. It certainly seems that it will be possible for me to tie into that to make building upgrades take time.

The build time function does in fact account for how many times a part has been used (once again only tracked by the part name, so procedural parts are interesting in that regard again), with a configurable effect. Btw, if RSS has a "recommended config" for KCT for build times (conveniently the time settings are in a separate file from the main KCT settings) then it should be possible to configure the CKAN to auto-install that. I can also add it as a preset when I add config presets later.

I can also add an API if there's things/events you guys will need/want to listen to (such as vessels being added to a build list, builds finishing, being rolled out, or after recovery is completed, etc).

[NathanKell]

@magico13 sorry to have let this drop! I had a bad case of .90 craziness for the last few weeks...

Per the forum I'm back to using KCT (I had, but did not recognize, the same issue pjf had...just in case in RF for .90 I'll not fire that event out of the editor, too). I love that the build times and node unlock times are now configurable! Alas, however, that tees up another short-term request, however: would it be possible to make the cost of points configurable as well? Right now it's fixed as doubling, with certain original values. Perhaps a configurable original value and a multiplier for each method?

[magico13]

@NathanKell when I read through that this morning I read it wrong and thought you were still talking about tech upgrades and had formulated a way of providing more customizability for that. Only now am I realizing you were talking about purchasing upgrades, which the method I came up with will probably also work for.

Basically, I can take the math parser for the Brownian Dynamics simulation program I wrote at work and translate it into KCT. Then you can just set the formula to whatever you want! I'll probably have to provide an extra way to set a maximum value, since the math parser can't handle that.

An example of how this might look currently for funds based purchases(note, does not follow order of operations but does work with parentheses, N=current level): 2^(N+4)

If you wanted it to be linear, starting at 2000 funds and increasing by 500 each time: 500*N+2000

Or quadratic: 500*(N^2)+2000

Also, I need to make simulation costs configurable, at least for the base cost so they can be scaled up and down.

One slight issue, like I mentioned previously I'm planning on redoing KCT's upgrade system soon^TM, so the whole "upgrade point" thing will be completely removed and upgrades will no longer be tied to the tech tree directly, so this change won't end up lasting long. But I'm hoping that the new system will be able to be altered with ModuleManager, but can at least be changed by overwriting the file that contains the upgrade "tree" (or shipping a new one that loads later than KCT's), and it will support this type of formula based upgrade costs. I'll hopefully have more on that in the coming weeks since I'm trying to figure out my development roadmap for after I get the 0.90 update out.

A rough roadmap is: get 0.90 update out with just a few changes, get second 0.90 update out that adds time for repair&upgrading of buildings, then start 1.2 with a revamp of the inventory system (and externalizing it to a separate mod known as the ScrapYard which I am going to be totally rewriting) so that I can save more info for procedural parts + others, then a revamp of the upgrades (also being externalized to a different mod that I'm tentatively calling Spyder, since the way I'm doing it might be useful for other mods as well), then config presets (like what stock has for difficulty settings), and likely tossing some random other fixes/improvements in along the way. If I'm lucky, 1.1 will be out before next Monday, 1.1.5 will be out before New Years/shortly after, and 1.2 will be out before I go back to school around January 20th.

[NathanKell]

@magico13 that all sounds awesome!

Regarding settings--I definitely like the MM idea. It'd be great if KCT's settings were saved in config nodes such that they could be patched by MM. That would save a lot of headache, I think. You might want to try a system like DRE's or FAR's, where the base settings are in a cfg and custom settings are in a MM patch for that cfg that the plugin writes to whenever the user sets custom settings. That means that if the user has no custom settings, then other mods can patch KCT's default settings, but if the user does have custom settings, they (being on a later pass, perhaps :FINAL) will take precedence.

[magico13]

The latest KCT dev version has a new cfg file where you can define the functions that tech nodes and upgrade purchases follow (and separately their maximum values). I tried to set it up in the way that I think you need for MM to work, but I'm not sure if I need to change other things on my end to get that to work.

Setting a max of 0 or below is interpreted as having no maximum limit. The node formula is the "build rate" for all nodes, not the total BP per science, which I should probably make configurable also.

[N] is a special variable that gets translated into "current number of upgrades". Order of operation isn't followed, it's interpreted left to right, but parenthesis are interpreted wholly as soon as they are encountered (So the ([N]+1) is done in time for the 2^([N]+1) to function as intended)

Here's the default contents of the KCT_Formulas.cfg file as of right now. I may make changes between now and when you see this, but mostly just to add another formula for calculating the BP per science:

KCT_FormulaSettings
{
    NodeFormula = 2^([N]+1) / 86400
    UpgradeFundsFormula = 2^([N]+4) * 1000
    UpgradeScienceFormula = 2^([N]+2) * 1.0
    NodeMax = 0
    UpgradeFundsMax = 1024000
    UpgradeScienceMax = 512
}

Edit: I am an idiot and realized that there isn't a separate formula for the total BP, since it's all dependent on the rate formula, so that's already implemented as intended.

Edit2: Though I'm thinking of adding another variable that's the science value of the node, but that will require some tweaking to not have all the nodes progress with the same amount.

[BevoLJ]

Played a good bit with the latest KCT RC2+ yesterday's config commit (https://github.com/KSP-RO/RP-0/commit/f357699c16edd2846d978dcd7c3f2d072be03f89). So far everything has been awesome! Only issue I had was entirely my own fault in which I set this up on a new instance and forgot to change the time in the KSP settings to 24 hours. Was quite a shock when it said it would take 9999.99 days to unlock Early Orbital Rocketry. :D

[BevoLJ]

I seemed to have run into a funds dupe. I'm going to post this here since there are some changes made to KCT in RO0 and just ping @magico13 hoping he will see it.

I built and went to launch a rocket and then realized I put the wrong fuel in stage one so when I staged for lift off, it just sat there. There were no reverts or anything like that, but when I tried to "recover" using the button at the top (at least I think I did) it took me right out to the KSC screen but my rocket wasn't recovered. So when I would click on the launch pad to recover it I could do so and got the recovery pop-up screen and get all the funds back. However, the ship still wouldn't actually get recovered. So I tried again and got the pop-up screen and all the funds again and so on and so on. As long as I kept doing that I would keep getting free funds! WOOT! \o/ So much free funds it is like Christmas! oh, wait it IS CHRISTMAS lol

Anyway the free funds are fantastic and all but I've not been able to clear the launch pad yet. I tried recovering it from a variety of places such as the launch pad and com center and such but no such luck yet. I tried to build a new rocket but once build when I went to launch it gave me a "recover and launch" pop-up which could not successfully clear the pad no matter how many times I clicked the mouse (one of these days spam clicking will work).

I'll edit later when I play if I am able to clear the pad, and how I did so.

log: http://puu.sh/dIKhK/95166f79cd.zip save: http://puu.sh/dIKm7/32f9dd029d.zip

Edit: Ok, after restarting the game I some how managed to clear the pad. Not entirely (at all) sure how I did so. One other issue I noticed is that I had the right fuels in there, but due to the build/roll-out time the liquid fuels had burned off.

[magico13]

Don't worry, I hear everything even without a ping ;) Ok, totally not true, but I do get email updates for everything posted in this thread. The symptoms sounded like something I fixed in the latest dev build, and looking back at the log it does appear to be that issue. I'll get a new release candidate, or more likely at this point actually do a release, likely today. Though it is christmas, so I imagine many people won't get a chance to take a look at it. Until then, I recommend trying the dev version (the same configs will work in it)

Regarding the boil off of volatiles, I thought I had fixed that on my end (by manually changing all the times in the parts to the launch time), so unless there was an update to RF that broke that it should still be working. I'll have to do a bit of testing to confirm and see if I can fix any issues I find.

[BevoLJ]

Ah, you already had it sorted! Awesome. Please enjoy a hopefully wonderful Christmas! :)

[BevoLJ]

Just threw in the Jenkins dll and am no longer experiencing any boil off. I checked the recent builds and didn't see any notes regarding it, but it seems from my two launches so far tonight that the fuel is working as intended. Rock on. :)

[BevoLJ]

Hmm, nvm. It seems it was fine, but after building a new rocket all my lqdO2 was boiled off when I went to launch.

[magico13]

I was talking to the developer of TestFlight about whether we should have any sort of integration between it and KCT, and it got me thinking that I should probably start working on an API at some point. I figured I'd drop in here and post a link to the GitHub issue I opened for it, since I don't know if there's anything you guys would want or need from it.

I still have some things I should do regarding RP-0, primarily regarding Procedural Parts handling and adding unlock times for individual parts in tech nodes. I am working on time requirements for KSC upgrades and repairs. Also, when I get around to reworking the settings to use presets, I'll make sure to make it simple for RO to overwrite the settings without worrying about overwriting anyone's custom settings (you'll just provide a presets file for RO. If you update it, anyone using the preset will be updated accordingly. If they change anything then their settings will remain as-is. Other presets won't be affected.) That will also ensure CKAN won't freak out about overwriting any files if they're got KCT configs already on their systems.

[BevoLJ]

@magico13 Might it be at all possible to add more launch pads? IRL a launch site can have more than one, and I really would prefer not having to use multiple launch sites for when interplanetary transfer windows are open as where I launch from is pretty important in my mission planning. Like it wouldn't need to be something that shows up at the space center, but just something to help us deal with the launch pad repairs. Typically repairing a launch pad makes it very hard to do multiple missions while transfer windows are open.

[magico13]

@BevoLJ I realize I'm responding to this waaay late, sorry about that. I do plan on additional launch pads, but with RSS you can just launch from different sites already. At the moment it's not a big priority, but if/when I get around to Kerbal Konstructs compatibility then the necessary changes for having multiple launchpads per site will be in place.

Now, for the actual reason I'm posting here. I just committed a change that you guys are probably going to love and I figured I'd give you a heads up since I'm planning on making the changes official soon after a period of bug testing. Basically, I just made it so that you can define precisely how build points are calculated _in the KCTFormulas.cfg file. So you guys (or the user) will have (near) total control over how things are calculated. It uses the same variable and math system as the other things in that file, but the number of variables available for BP calculations is a bit higher.

I'll try to give a basic rundown. There's a few other important changes that I'll highlight at the end of this post.

So, KCT has two stages to BP calculation: 1) calculate an "effective cost" of a part by taking the cost and doing some stuff based on if it's in the inventory and how many times it's been used, and 2) take the sum of the effective costs of all the parts and do a bit more manipulation on it. Those two stages still exist, but you can define the formulas used for them. The "effective cost" has two variants, the normal "EffectivePartFormula" and the one for procedural parts called "ProceduralPartFormula".

EffectivePartFormula: Variables available (must wrap in square brackets): C=cost, M=wet mass, m=dry mass, U=part tracker, O=overall multiplier, I=inventory effect (0 if not in inv), B=build effect

Note: O, I, and B are the normal time settings that go by the same name.

Default: "min([C]/([I] + ([B]*([U]+1))), [C])"

ProceduralPartFormula:

Variables: C=cost, A=cost covered by inv, M=wet mass, m=dry mass, U=part tracker, O=overall multiplier, I=inventory effect (0 if not in inv), B=build effect

"A" is a bit different here. Since the inventory for procedural parts is handled differently (the amount is part cost * 1000), A is the amount in the inventory divided by 1000, or the part cost, whichever is lower. It's used to calculate how much "material" is available to be reused.

Default: "(([C]-[A]) + ([A]10/max([I],1))) / max([B]([U]+1),1)"

The final part is the final BP calculation:

Variables: E=total effective cost, O=overall multiplier

Default: "([E]^(1/2))2000[O]"

Additional notes: You may have noticed the use of min(x,y) and max(x,y) in those formulas. I've added a few functions to the math parser. "l(x)" (lower case L) is the natural log, "L(x)" is the log base 10, "min(x,y)" will take the minimum of two values, and "max(x,y)" will take the maximum of two values. There are a few formatting restrictions to these that you should be aware of though. They MUST have parenthesis following them and cannot have spaces between the command and the parenthesis [ie, "min (x,y)" == bad, "min( x, y )" == good]. Spaces inside the parenthesis are fine. They are case sensitive, so you can't use "Max", you have to use "max". You can (theoretically) nest a min inside a max, or vice versa, but must put the nested function in the second slot (I need to verify this). It's a side effect of how it detects the comma. So "min(x, max(y, z))" should work as expected, but "min(max(y,z), x)" won't work. Like I said, I haven't tested that yet.

As a result of this, I've removed the "UpgradeFundsMax" and other similar settings since you can just use the min() function to achieve the same thing. You'll want to update accordingly.

It's possible I've missed a thing or two, or that the formatting/my generally dispersed mind has made this unintelligible. If you need any assistance/have questions don't hesitate to ask. Hopefully you guys find the changes helpful! I've also fixed some other bugs and made a few changes (like adding time requirements to KSC upgrades) in the dev builds. I have a few more functions that I should open up (like the KSC upgrade one) at some point as well, but I may release without them unless you guys want them ASAP.

E: Oh, also, I added a formula for the amount of science you get from building ships and made it so that upgrade ("research"), the funds based upgrade purchasing, and science based upgrade purchasing can be disabled by making the formula return a negative number. Figured that might interest you all as well.

[NathanKell]

@magico13 that's awesome!

[pap1723]

KCT now supports all of this.