Drake1500

My apologies. I play on Linux, the keys are all different on other platforms. For instance: So: Alt for Windows, Command for Mac, and right-Shift for Linux.

Personally, I think that if you do implement a pay-as-you-go option, it should be just that - an option. Some people obviously really like the idea (I think it would be interesting - it would allow me to start building a big ship that I don't have all the funds for right away, or at least put it in the pipeline to be built without actually having to pay for it). Other people will be against it wholesale. Once you have a way to implement it as a choice, then we should be talking about what the different choices could be. Right now, I'm seeing three major options that have been voiced: the pay-upfront (as it is now); pay-as-you-go (the idea that started this off); and pay-in-instalments. The pay-upfront option wouldn't have anything that would need to be calculated. However, the other two COULD be tweaked by formulae. For instance, assume that there are three stages to the build: 1) upfront cost; 2) building cost (pay-as-you-go); and 3) finalization cost (or launch cost). By setting a formula to calculate the percentage for the building cost (and also how quickly it is paid - quicker at the start, or slower, for instance), and another for the division between the upfront and launch costs (similar to your rollout/pad-repair calculation), you would then be able to tweak these three costs, giving you a range of options. For pay-upfront, all you need to do is set the building cost to 0, and the upfront/launch costs to be 100%/0%. For a completely pay-as-you-go, you would need to give some formula for building cost, and set upfront/launch costs to be 0%/0%. As far as I'm concerned, the only gameplay benefit is allowing me to build things - or put them in the pipeline - without having the necessary funds right away. If it were implemented, I would probably use it in my next game (after it was implemented), but I won't be upset if you don't implement it. Personally, I think it's more trouble for you than it's worth.

The answer for both of you may be the same: when you're in space, you can start physical time warp by holding Shift and pressing the ">" key (or whatever key increases warp speed for you). If you don't hold Shift, it thinks that you want "on-rails" warp, which doesn't let you accelerate. Physical time warp, on the other hand, does.

Sorry this took a while for me to get to, but I've made a config that works (at least, it works for me ). You can download it here: https://www.dropbox.com/s/c9742wtyria9swh/Strategies.cfg?dl=0 I used the grouping that I posted, but moved Live Feeds in with Defence Initiatives and Staff Downscaling, like you suggested. Let me know if you run into issues.

Can confirm. I use Kerbal Alarm Clock myself, and have not seen any issues. I also use SafeChute, and it interacts exactly as expected - although at high physical time-warp, SafeChute can activate a bit.... late.

After installing, there should be a little arrow beside the warp speed at the top left. Click that arrow, and you can change the set of warp levels, or even make your own if you fancy. Once you change it, just use warp like you usually would, but recognize each step will be different. (Eg: 1x - 5x - 10x might become 1x - 25x - 100x) The set you choose will show you what each step will become.

Can't say for sure about adding to an existing save, but there is a file in the KCT folder - KCT_formulas.cfg - where you can change the formula for the cost. For example, to change the cost in funds, take a look at the UpgradeFundsFormula: min(2^([N]+4) * 1000, 1024000) 1024000 is the maximum. Change that, and you change how expensive it gets. If you want a single, unchanging cost, just replace the whole thing with a single number.

If you'd like a history of the contracts you've completed, there is a history in the Mission Control building; go to the tab "Completed Contracts" and it will list all the contracts you've done in that career.

In the meantime, action groups are really helpful for this. No camera negotiation, even in midflight. And AG Extended is helpful for action groups. (http://forum.kerbalspaceprogram.com/threads/74195-1-0-2-%28May13-15%29-Action-Groups-Extended-250-Action-Groups-in-flight-editing-Now-kOS-RemoteTech)

This is what I see in your .cfg for incompatible groups: Appreciation Campaign/Fundraising Campaign/Defence Initiatives/Staff Downscaling Open-Sourced Technology Program/Unpaid Research Program/Science Academy Patents Licensing/Outsourced R&D Recovery Transponders/Outsourced Recovery Aggressive Negotiations/Conservation Directive Launch Spectating/Sponsorship Deals/Homegrown Parts/Safety Procedures Space Camps Meteorological Authority Live Feeds Some of these just don't make sense to me (like Defence Initiatives and Staff Downscaling being where they are, and why Conservation Directive and Aggressive Negotiations are incompatible). I would recommend something like the following: Appreciation Campaign/Fundraising Campaign/Sponsorship Deals Open-Sourced Technology Program/Unpaid Research Program/Science Academy Patents Licensing/Outsourced R&D/Space Camps Recovery Transponders/Outsourced Recovery Aggressive Negotiations/Homegrown Parts Defence Initiatives/Staff Downscaling Safety Procedures/Launch Spectating Conservation Directive Meteorological Authority Live Feeds Some of these I'm more convinced of than others. I'm not really sure Homegrown Parts belongs with Negotiations, for instance, but Safety Procedures and Launch Spectating really seem like they belong together.

Hm. Well, OP does say that it uses ORSX, although at a second glance, the changelog on the OP hasn't been updated since 0.90 either. - - - Updated - - - To be fair, I do use CKAN, and I knew for a fact that Karbonite was not required, as it is not one of the dependencies there.

No, Karbonite is not required, but it does use ORSX, a fork/extension of ORS. (It comes prepackaged with it) If you're concerned about dependencies, I would recommend using CKAN. It handles all the dependencies for you.

For what it's worth, here's my 2 cents: I don't feel any lack of 1.25m or 2.5m pods. On the other hand, as MarcAlain has pointed out, there is a bit of a dearth of 3.75m+ pods. I have definitely felt the lack of longer ladders, especially longer fixed ladders. If you had a pack that consisted entirely of ladders, it would probably be an insta-download. I haven't felt the lack of long service bays, but now that I think about it.... they would be pretty useful. I've definitely stacked up the stock service bays to get more space. I do like the look/functionality of the stock service bays but haven't seen any replications; is this something that is doable?

OK, thanks. I was worried that I was missing out on what little efficiency I had! I don't suppose there's any way to easily remove that option from the action group menu? Not asking for myself, but I'm thinking it'll save you answering the same question when others pick up this mod and think the same thing I did!

Fair enough. I decided to try creating my own categories (such as Planets,C) and they worked. I still don't know why, but they did. I do agree, though, that this feature NEEDS documentation. One thing I've figured out is that incompatibilities are in groups, which means you can't have the situation like A+B and A+C are incompatible, but B+C are compatible. Anyway, if you have an idea for how you want the compatibilities for SKB's strategies to work, I might be able to play around with the .cfg and find a suitable configuration for you.

Hey AlphaAsh, if I edit/add to your .cfg (for my own use), how do we set incompatibilities between Strategies? Based on my initial research, it seems that Strategies with the same groupTag are incompatible, but after editing some groupTags, it messed up the incompatibilities (such that Misc,H; Misc,Recovery; and Misc,D were all incompatible with each other). Are there only certain groupTags that can be used?

Yes, the radiator arrays do extend. Basically, you are saying that the radial radiator does not extend? If that is the case, my question is:

I realize that they will not radiate stock heat away. Here are a couple of pictures of what is going on: Note the Deploy/Retract/Toggle Radiator options in the Action Groups But in space, I can't deploy the radiators, and using the Action Groups to do so does nothing either. I can confirm that Final Frontier plus the reactors/radiators in my install do in fact play nicely together, so perhaps it's a different mod you have installed?

I am not running out of power; I tested this in a sandbox game by throwing a ton of Gigantor solar panels and several radial radiators (the first in the tech tree, since those are the only ones I have on my main save) on a ship, and then putting it in orbit and time-accelerating to 10k speed and watching what happened (including pulling out of time warp to see if I could deploy radiators once they got hot and started radiating some heat away). - - - Updated - - - Perhaps I do not understand how radiators work. Are they not just "put on ship -> waste heat is radiated"? (Aside from the missing deployment for my radial radiators)

Is there any way to rename missions/contract lists after you've created them? I can't see any way to currently do this, aside from deleting a mission, creating a new one with the name you want, and then adding all the contracts to the new mission. I like to group contracts together based on which launch(es) will be fulfilling them, but sometimes I don't have a good descriptive name when I start grouping them, or the mission changes.

Do radial radiators extend or don't they? When I go into the action groups while building the ship, I see options to deploy/retract/toggle the radiators, but no such option when I right-click them in-flight (and I did check in-game, nothing apparently happens when using these action groups; they still radiate heat when not extended, but are they supposed to extend, and have better efficiency?) If they don't extend, why am I seeing an option for them to deploy in the action groups menu? (as far as action group mods go, I have AG Extended and Auto Action installed)

Huh. It's the darndest thing - as soon as I moved that file that I had saved into my savefolder again to check, the bug did not reappear. I even tried rotating the ship really fast, to get it into the air (thinking that maybe I had to be in flight for it to trigger), but that didn't work either. So I can tell you that it happened while flying low through the atmosphere during re-entry. I suspect it may have been that I was passing over a biome boundary, and SA for some reason thought the new biome was "Water" when it was "Grasslands". The other times I saw the bug was when I was flying an airplane over Kerbin - sometimes SA would think I was over "Water" when I was actually over some other biome, and it would stay as "Water" when I landed (not 100% sure about the timing of this, though, since I had other things to worry about ). I've only seen the bug happen while flying low over Kerbin, can't say anything about other bodies like the Mun.

I have also encountered this bug a few times, but until now haven't gotten any evidence for it. As you can see, X-Science and KER both report the biome correctly. If you want to know which mods I'm running, it's easier just to look at my CKAN list (there are 164 of them): https://www.dropbox.com/s/oh2kfcxcwdy01yo/CKAN%20list.ckan?dl=0 And here's a savefile (if it's any use to you, because of my mods): https://www.dropbox.com/s/u1p4khn4dx8wg7m/SA%20biome%20bug.sfs?dl=0

If you really want to explain yourself, you can say they're LED lights, with one of those little watch-batteries built-in. Those will run for forever (although with not as much light output, as you've said). I think it makes sense; since they don't have enough light to illuminate anything, how much power would they really draw? Insignificant amounts, that's how much. I've had this issue with parts from other modpacks and stock parts as well. I think it might have something to do with the stock method of dealing with both node-attach and surface-attach things. What I do is create the whole assembly somewhere else, then move it to where I want it. Unless you're talking about the part trying to surface-attach onto the node when you want it to node-attach to the node, in which case you need to rotate your camera until you're looking at the part side-on. It's pretty finnicky, and this happens with every other part as well. If there's another way of doing these things, though, I would LOVE to hear it!

My apologies if I sounded like I was ranting about the decouplers. I understand that this is something that you are working on in your spare time, because you enjoy it, and I respect you for that. I appreciate all the hard work that you have put into this, and I was just putting my $0.02 into the discussion, and trying to throw some ideas out there to see what's possible and what's workable. Whatever work does get done, at the end of the day, is the work that is done. And we will all be grateful for it. Keep up the good work.