Electrollama

Jebediah was reading an interesting book on Gilly... It was hard to put down. I was making a space station with a view... It took a cupola launches. We sent Val to Vall, then put flag poles on Pol's poles.

Jebediah was reading a book on Gilly... It was hard to put down.

I feel Minmus is an appropriate difficulty for new players, while Mun would be restrictively hard. I'd prefer keeping it easy and making science payoff less than Mun. The current science multipliers on the surface are: Kerbin 0.3x, Mun 4x, Minmus 5x, Duna 8x, Ike 8x I recommend re-balancing these to: Kerbin 0.3x, Mun 4x, Minmus 2x, Duna 9x, Ike 6x Science payoff should reflect difficulty of getting there, not just distance and delta-v. While Ike is comparable in gravity to Mun with the added challenge of reaching Duna orbit first, it has the same payoff as recovering science from the surface of Eve, one of the most challenging tasks in the game.

As a speedrunner, I find it slow and cumbersome to click around so much. Instead, I'd like to select an option in a pop-up window using a keystroke. A simple example is the messages at the start of a fresh career mode telling you about each building the first time you use it. I would like the "Enter" key to select the "Okay" option and close the pop-up. This could be extended to the window that opens after collecting science. "Enter" could select "Keep Experiment", "Delete" could select "Reset Experiment", and something else could be "Transmit Experiment". This is nitpicky, but I think it would be worth adding. An alternative could be using the arrow keys and Enter to navigate the options. This might help with long menus like when right-clicking a command pod. It might be a problem that multiple windows can currently be active at once. I feel this change would be minor, but I think players notice that this is not a feature.

I haven't read the long comments, but I agree that the trajectory prediction should be cropped at the SOI boundary. This would be consistent with unlocking patched conics, but you're only able to see the trajectory for your current parent body and no encounters.

I have a hard time deciding which time warp option to use in a given situation. If I need to wait until the next orbit, and the period is about 1 hour, is that "1000x" or "10000x"? I know a transfer to Mun takes around 1.5 days (Apollo 11 took 3 days), and from experience I happen to know "10000x" is okay but "100000x" would zip you right past it. With counting zeroes and the altered time system (6 hours per day, 425 days per year), these kinds of estimates are non-intuitive. I recommend new labels for each time warp option based on how much in-game time would elapse in 1 real-time second. To make them comparable to current options, these options would be: 1s, 5s, 10s, 1m, 2m, 15m, 2h (or 1/2 d), 5d Then you'd instantly know "2h" (10000x) would be suitable for a 2-day journey to Mun, but "5d" (100000x) would be too much. The new maneuver node editor uses this type of labeling in the sensitivity slider. For a game that introduces people to the time and space scales of space travel, time warp should effectively convey the passage of time. (P.S. I also think the time warp options should be re-balanced, but that's a different suggestion.)

As a reference, max time warp is 1.5 minutes per year. A Hohmann transfer to Jool takes 3.5 years or about 5 minutes of wait time with no user involvement (extra 10x would be 30s). An Eeloo round-trip would be 10-15 minutes of waiting at max warp (extra 10x would be 1 minute). This feature would cut out minutes of idle time. I recommend only allowing this when the parent body is the sun or in the tracking station.

I heard there is a work-around to complete these in one launch, I believe by changing sphere of influence as two separate crafts, or maybe something with loading a save. But I agree that the re-wording would help.

I see this as something the game could have done besides having science. This is why they limited the science payoff you can get from repeat measurements. You'd have to go to new places to unlock new nodes, as you suggest. With the current science system, it sounds like a slider for science payoff(increased difficulty option?) or a check-box to remove biome-specific payoff (encourages going to new bodies and not just new biomes). The "World First" contracts also encourage going to new bodies with much larger contract payoffs than other contract types.

I think this would be redundant with existing features in vanilla: 1) Advanced Part Filtering: You can disable a subset of parts based on size (similar to limited tech tree nodes). Otherwise, your idea could be implemented if the game added a custom filter category, like how the sub-assembly menu allows custom categories. The user could select which parts to include in the category. 2) Science Mode: This mode was designed to be Sandbox except for the existence of the Tech Tree. You'd still need to unlock nodes in the tree rather than toggling them like you said, but this isn't too much of a hindrance (see Tech Tree Speedrun). 3) Player Discretion: The feature wouldn't add playability. The player could just decide what parts to use, hence a sandbox. I think there are few enough parts that it's not hard to find specific parts, especially if you sort by mass.

Can you specify which stock craft(s) had this problem? I think I had a similar issue with custom crafts. I started a new science mode and tried launching a simple Sputnik (I haven't tried the stock craft). I gave up after several attempts and re-designs because of the problem you mentioned, and I consider myself an experienced player. This would no doubt be frustrating to new players who try using the Stayputnik. I think the issue in my case was drag at the top of the ship, where the radial size went from "tiny" to "small". Any small deflection would result in a large torque. The preferred orientation when falling was retrograde. If this was the issue, it makes sense that my manned crafts didn't have this problem. Fairings or an adapter would probably fix this, but they're unlocked much later in the tech tree. Slower ascent might also help. I had Aerodynamics quality set to "Low", which might play a role.

Small feature: In addition to the new "height from surface" feature in 1.7, maybe add "height from center of body". Knowing the height from the center encourages players to use equations when appropriate, and it make things easier for educators. It would have been useful for me when calculating orbital periods, before the new menu was introduced. While you're at it, the orbit info window could be updated when the "height from" option is changed. This might not be straight-forward for height above surface, but height of periapsis above surface would be useful for low orbits and landing.