NeilC

Yeah, being a benevolent dictator can be time consuming. Not everyone can make KSP their full time job like Carl. Anyway, I'm sure you can think of some way to vet participation in the first short-list vote that wouldn't eat up too much of your time. I think that's where the problem is: we have too many entrants and too few voters, so corruption reigns supreme. Maybe it would be enough to post clear goals for the craft, and make it a requirement that entries prove they meet those goals to be considered for the short list. The entries to this challenge span the range from barely-orbits-Kerbin to lands-and-returns-from-Duna. Kind of hard to pick the "best" one given the wide range of capabilities.

This is the internet. Keep your expectations low, it leads to less frustration. Seriously, be more autocratic about selecting the initial candidates. Democracy is good and all, but it breaks down when the voters have a personal stake. Don't be afraid to step in and say some designs are better than others - You're setting the challenge requirements, you should decide which designs meet them best. After all, rockets are designed by meritocratic dictators called engineers, not by committees of politicians with vested interests. When the politicians take over the rockets tend to blow up.

I'm not sure any amount of "security" will ever let you distinguish votes for "I have tested this ship, it is a solid design that fulfils all the requirements" vs votes for "Lolz, this guy's my friend XOXO #weare12yrsold". Given the low number of participants in this process, even 3 friends who decide to put all their votes to the same candidate can completely skew the results - which is why the current frontrunner is a ship that can barely make Kerbin orbit and is significantly worse than the Kerbal X we're meant to be improving on. Can I suggest you eliminate open voting entirely for the "short list" candidates? I can see this taking two forms, both better than what we have now: 1) Xeldrak tests all the craft. Xeldrak decides who makes a short list of 5 or so finalists. 2) Xeldrak accepts and tallies votes only from those who post in the thread showing that they have tried more than one of the craft, and give reasons for their voting. The final selection can be left to open voting once we have a short list of candidates that actually meet the challenge requirements.

Presenting the Kerbal X2: This craft has been designed to guide KSP newbies through their first trip to the Mun or Minmus. It is the spiritual successor to the Kerbal X, much more capable but with the same style. Special attention was given to the launch process. This craft isn't just capable of reaching orbit, it also teaches newbies how to do so easily and efficiently. No throttle control is needed, and the stages are sized to cue the pilot on when to begin gravity turn and when to coast to apoapsis. Features: - 164 parts, 190.6 tons on the pad - Land 3 Kerbals on the Mun or Minmus and return them home safely - Maintains the visual style and form factor of the original Kerbal X - Craft is stable and easy to pilot - No throttle control needed during launch. - Launch process is visual and easy to describe to newbies - Staging is logical, with each stage sized to its purpose: ---> gravity turn starts on 2nd booster separation ---> Core booster sized to burn out when ~75km apoapsis reached - Noob-friendly: Plenty of extra delta-V for orbital maneuvers - Lights for night landings Building techniques Showcased: - Asparagus staging - Stable lander: short and wide design makes it hard to tip over - Robust lander: Low mass and large strong legs let it absorb high impacts like a champ - Logical stage division, with each section designed for a specific job - Compact payload design: ---> radial mount points and tiny in-line decouplers used instead of large radial decouplers ---> Fuel routing allows re-use of the single LV-909 for both descent and ascent stages - Proper engine selection: ---> Solid boosters for initial burst of speed ---> Asparagus boosters for sustained thrust through the atmosphere ---> Mainsail core booster for high TWR above 30km ---> Poodle for high-efficiency orbital maneuvers Kerbal X2 .craft file:

Great work Cilph, thanks! With flight computer working, I think I'll start a RemoeTech save this weekend... I'm not familiar with kOS - is it required, or just optional? Do you have any plans to integrate the flight computer with the maneuver node system, and include a "program this maneuver" button?

Good point. How do you think those good ideas got there? At one point or another they were suggested in this forum and got a lot of support. If another good, well supported idea is brought up here, it will also be put on the list. I'm sure Devs don't read every thread, and they sure don't participate in a lot of the pointless griping and sniping that happens in here. But when a good, detailed and thorough thread comes up and gets linked in the WNTS list, I'd be surprised if they didn't read it. Or at least the non-gripe posts in it - after all, that would really cut down on their reading time.

Yes, for optimal launch under KSP's drag model you want to maintain terminal velocity - but you want to get to terminal ASAP. At sea level terminal is about 100m/s, and rises exponentially - there's a table on the wiki. Because drag causes huge losses while low in the atmosphere, you want to get through that quickly - a good KSP ascent profile is usually straight up until ~6-10km depending on TWR, then pitch over and start your gravity turn. Why pitch over? Because of another kind of loss: gravity. As long as your thrust is straight up, gravity gets subtracted directly from your accel force. When you pitch over, you get to "keep" the horizontal component of your velocity as orbital speed - gravity doesn't reduce that. While you're ascending vertically, 1G's worht of thrust is wasted just hovering - you only get "credit" for anything above TWR=1. That means, for your craft's 1.1 TWR, at launch you are accelerating at 0.1G, or roughly 1m/s per s (1m/s^2, unit of acceleration). At that rate, even with your mass constantly decreasing due to fuel burnage, you won't reach 100m/s for 60-70s. About 80% of the fuel you burned for that minute is totally wasted - very inefficient. If you had a launch TWR of 2 instead, only 50% of the fuel you burn for 10s would be wasted - much better way to get to terminal velocity. An optimal ascent would be to reach 100m/s instantly (or as close to instantly as possible - think high initial TWR using small SRBs), then maintain terminal velocity (~1.2-1.5 TWR) straight up until about 8km, then start pitching over and give'er all you got while remaining just under terminal. Above 20,000km you should always have your throttle pegged - you'd need a crazy TWR just to keep up with how fast terminal velocity is increasing at that altitude. I'll post soon with my Kerbal X design, its launch is something like that.

It's the "quickly" part of getting heavy stuff off the planet that makes it less efficient. You don't really want to get going too fast too soon, or you waste a lot of delta-V to drag. Standard asparagus staging is the most efficient way to launch because it sheds maximum weight as you go, while maintaining a near-liftoff TWR for the whole burn. If a craft has a decent TWR at launch (I shoot for 1.3-1.5), it will have excessive TWR after staging off a few sets of drop tanks. Anything above 2.5-3 really is overkill, if that kind of TWR is needed at any point then the ascent profile is... shall we say "interesting"? If you're going for efficiency it's better to drop the engines with the tanks, decreasing the dry mass and increasing overall delta-V. Not saying this method is bad, just that it values launch speed over efficiency. We can afford that in KSP!

It's not standard asparagus, since all your engines appear to stay connected. Usually you want to drop the engines so you don't have to carry the added weight. You need peak thrust at launch, as you start to burn fuel your thrust demand gets ever-lower. I'm guessing you either throttle that wayyyy down as you climb, or you start seeing some pretty crazy re-entry effects on ascent. I'd call this drop-tank-asparagus staging. I think it's less efficient than standard asparagus. Why carry engines you don't need?

Can you elaborate a bit on the difference between cryo tanks and normal tanks? What's the difference in implementation? Are they useful only for LH2/LO2, or will they work for any fuel regardless of making sense? Do I need to use thermal fins with them? What's the boiloff rate (if there is one)?

If the module would be "used up", then that's a cost it can determine. If your instrument is a thermometer, I'm assuming that's not the case. Of course the game should never "use up" something on you without asking. Good point, this would be annoying. Could be fixed by consolidating the dialog to ask about all currently empty slots, instead of one dialog for each. Fair enough. But please remember that "Don't bug me again" would be an option. This idea would take experienced players like you out of the experience exactly once, on the first second of your first launch. For others, it could provide them with continuing guidance on how to get the most out of Science. And whether you're experienced or not, having a "Probe mode" toggle is pure grind-removal. Is repeating the same 15 clicks to sample and transmit all your experiments as you fly over the 10th Mun biome really the immersive game experience you're looking for?

UberFuber, I think you're missing the point. boomerdog2000, I addressed your concern in the OP already: "If the 0.23 model makes it impossible to discard and repeat measurements, this wouldn't work - maybe a prompt instead? Maybe a config option to make it auto, prompt, or do nothing?" I know the system will change in 0.23. The devs have said experiments won't be "endlessly repeatable" - there may still be some value in repeat measurements. Even if not, there will still be transmittable science and some players will want to build small, unmanned, long-range probes that aren't intended to return to Kerbin. Especially once money becomes a factor later on. My point is that in all situations where you have A) an empty science slot and a valuable sample you could take, the game should either: - take it for you, if there's no cost to doing so - prompt you to take it, if you might not want to - do nothing if you have said "don't bug me again" to a previous prompt To me, that's a no-brainer and will seamlessly introduce players to new ways of collecting science. A "Probe mode" to let you automatically collect unmanned, transmitted science while under timewarp seems like a good idea to me. Do you see a down side to these?

I'm looking forward to 0.23's rework of Science to reduce the "click grinding" feeling of the current mechanic. I hope these two ideas will be considered for inclusion in the new framework. 1) At all times, automatically fill any empty science "slot" with any first-time measurement as it becomes available I see this being implemented as a task on a ~10s counter, or once per time-warp step above 10x timewarp, that cycles through all available science options and automatically fires any collections as long as A) the science "slot" is currently empty, and the current biome has not yet been sampled. In the current model, the player can always discard the automatically collected science and take another biome measurement so this is a no-brainer: it's always the right thing to do, the only question is whether the player knows enough/remembers to do it. If the 0.23 model makes it impossible to discard and repeat measurements, this wouldn't work - maybe a prompt instead? Maybe a config option to make it auto, prompt, or do nothing? Making no-brainer collection automatic (or prompting for it) also serves as an intro to new players who may not know how many biomes there are, or how many options they have for science collection - on their very first rocket launch every instrument would fire immediately on the pad, letting them know exactly what their craft can do, and also that there is value on doing science on Kerbin itself. 2) Add a "Probe Mode" toggle that does the above whenever there is still value in sampling the current biome (not just first sample), and also enables auto-transmission of the data. I know the transmission model will change in 0.23, but I assume there will still be some value to transmissions. Hopefully the small, data-only instruments (thermometer, seismic, gravioli) will get 100% from transmission, as they are just sending numbers anyway. But that remains to be seen, and isn't really the point. Regardless, a "Probe mode" would allow players to go hands-free on science and removes a lot of redundant clicking without changing anything else about the game mechanics. Data rate is still limited by electrical charge, you still have to pilot your craft to the right spots, this would really just automate the tedium of clicking through 10 "collect-transmit-recharge" cycles during a Jool flyby. It would also enable most probe Science to be done during timewarp - believe it or not, having to babysit Science collection by clicking your craft repeatedly in 5 locations for 10-minutes at x1 timewarp isn't very much fun. I'd much rather blow through the flyby at 10x warp and actually enjoy the view for a minute or two. Let me know if you agree, disagree, or have any similar ideas!

NathanKell, I just started a new sandbox game that I've called "Hard Mode", and I'm really excited about all the mods you're maintaining! Keep up the great work! I have installed your MFS, DRE, and Stretchy SRB. I also have Ferram's FAR and KIDS. I don't want to take the plunge into a full rescale yet as I like KSP's short orbital periods, but I want to use KIDS' "Far to Real, Adjusted" to approximate realistic rocket sizes and 9k dV launches. When I change the tech levels on your MFS engines, they clobber the ISPs set by KIDS. It seems that sometimes I'll get KIDS numbers and sometimes the MFS numbers, depending on what I've touched last. It's a bit frustrating. Have you/Ferram done any testing on the interaction between MFS/KIDS? Is there a way to get them to play nice together? Thanks again for your contributions!

I'd love to see it done! You mentioned you had some previous experience with these calcs. Care to put your compiler where your mouth is? Please, be smart! My gut says that any adaptive-timestep method is going to waste a significant portion of its 1/30th of a second just calculating dt_next for a few hundred timesteps. Besides, what if you want to gravity assist around Duna on your way to Jool? Or do any other post-encounter orbit prediction? You can't use large timesteps in deep gravity wells. Any time you go from a closed-form solution to an iterative simulation, you have introduced a huge technical problem that must be overcome. Leaving the orders-of-magnitude lower performance out of it, you suddenly have to deal with numerical precision, solution stability, repeatability.... it's not a simple system anymore. You can hand-wave that away if you'd like, but until I see an experiment to back up the idea that maneuver nodes could be implemented using a simulation-based orbital solver I will remain highly skeptical.

Minor point: If you do this, timewarp may break. To get the position of a craft at the tesired time, you are no longer changing the "time" input variable in a linear 1D patched conic equation, instead you must simulate the entire orbit from present up to the desired time. Let's assume you're right that 1 second is a decent physical timestep for that problem. Now go to 100,000x timewarp. Can you do this calculation for all craft in existence in 1/100,000th of a second? You might argue that yes, you can. On decently modern hardware, you might be right. MAJOR POINT: If you do this, maneuver nodes will definitely break. Instead of calculating the sim on an ongoing basis, scaled by timewarp, maneuver nodes require that you calculate the entire new orbit at a refresh rate high enough to allow dragging the handles. Can you simulate an entire 1.5 year trip to Jool, with a timestep small enough to ensure stability of the calculation, at 30Hz? Even on a massively overclocked i7? The answer is no. Emphatically, NO. The devs have taken multiple-gravity calculations off the table, and are sticking with patched conics. This discussion has been had over and over again and always comes to the same place. The first 2 or 3 times I've been a part of it, I was also arguing for some Lagrangian implementation - because cool, right? But you know what's also really, really cool? Maneuver nodes. The gameplay tradeoffs for N-body aren't worth it. Patched conics are a better solution for KSP.

My suggestion was to adjust either the value of the first node or the value of science on the pad, such that you can not earn the first from the second. I have no desire to make the first node difficult. I just don't like that it's trivial.

Contrast that to Civ, or most other strategy games, where the paradigm is to click a couple things, then wait a while before unlocking the tech tree. I agree with your point about getting too much too quickly, but I think the current Science concept is fun and playable. It just needs balancing. More than anything, I think it needs the introduction of money and Kerbonomics to act as an additional brake on what you can build.

That's not really my point, which is why I made a separate post. Sure, elite players can game the tech system to the point it seems broken. That's true of Civ too, or Hearts of Iron, or any other game I've played with a tech tree. My point is that any monkey who can plop a pod and right-click can game the first node. The tech tree itself can't teach you how to do science - that's the job of a tutorial, whether in-game or video or printed manual. Once you know how to do the basic mechanical point-and-clicks of science, unlocking the first node doesn't require building anything in the 0th node except the pod itself. Hell, if you could get the Kerbal out to the pad any other way you wouldn't have to build anything at all. The first node isn't challenging. It isn't even fun. I think it's just broken.

Heh, fair enough. But we wouldn't be doing that unless we'd let a whole generation of rocket designers retire early to "cut costs" without training any replacements. Maybe if Kerbals had a backstory of epic resource mismanagement?

I just started a new game and "launched" the Mk1 pod. That was all. Just the pod. I created a crew report. I went EVA, took a sample, and filed an EVA report. I earned 12 science. I used 5 of it to unlock Basic Rocketry. This makes no sense. I did only what would be covered in the first 15 seconds of any Science tutorial video, without even lighting an engine, and I advanced a tech node. If I hadn't watched or read or in some other way been told that I had the ability to do these things, I would not have known how to do these things. Why should I be rewarded for them with an entire tech node? It makes the first node meaningless, you might as well grant decouplers and Goo from the start - which is probably a good idea. You should not be able to earn tech from the launch pad. Certainly not a node's worth. Kerbals already had to build the launchpad. What can they learn from it?

I'm sorry, but calling that assumption "logical" only makes sense to me if the only previous exposure to software development you've had is learning how to count. If that's the case, my apologies - no offense intended. The first release version of software is referred to as 1.0. KSP will be released at 1.0 the day Squad decides to stop calling it a work in progress, whether the dev version from the day before was called 0.99 or 0.22 makes no difference.

Check the time. It's the 16th where I live. It could happen at any minute.

I've updated the OP to reflect the current state of this discussion. Let's keep fleshing out this slider idea! Does anyone want to make a nice GUI mockup of the slider option, and possibly the Block Upgrade option to replace my crappy ASCII version?

+1, I agree! I also consider the current behaviour bugged, not just unclear.