Tyko

I kind of follow this path. I'm playing at 2.5x scale and 30% science, so I have to get some early probes out with whatever tech I can early just to start unlocking more.

Which mod adds those rockin' sunglasses?? too bad she doesn't have a nose to hold them up

I'd try a mod that offered a) higher quality planets than stock b) a different set of challenges than stock Maybe your survey choices should be around what qualities people want in a planet mod Higher quality textures or optimized low res - easier on potato computers more or less biomes - should every planet have a bunch of different areas to explore requiring more time spent per planet or would players rather keep each planet simple and focus on going to more planets access to science and contracts - should it be easy to gather science and fulfill contracts in the local system or do players want to be forced to go interplanetary earlier on in their playthrough to progress? smaller systems with lower travel times or more spread out systems and longer travel times - think compact system like Trappist-1 versus a system around a hotter star that's more spread out Other details could be: more or less anomalies more or less asteroids Asteroid belts - either around planets or around the sun more or less rocky inner planets more or less gas giants with their own systems of moons single star or multiple stars Should it have more than one "earthlike" planet to visit?

You'll have more success asking this on the Scatterer group instead of just lobbing your question out to a general group.

@1straycat A great way to learn is to look at examples others have created. The community database of module manager patches has a ton of simple patches that each do one thing, so it's pretty easy to look at those and see how they work. The actual editing is done in a text editor. You just have to save your patches as ".cfg" files and put them anywhere in your GameData folder. Personally I have a folder called TykoMods that I keep all mine in. They're easy to organize that way and I can just drop that whole folder into a new game install.

Not sure if you've come across this yet, but their designs and some of their methods are surprisingly kerbal

You can turn the stock indicator off??? wow...never knew

Has this been reported as a bug? every time I turn around I discover more ways they cut corners/slipped up on MH development. It seems like they're doing better now, but MH was definitely a low point in KSP quality.

'Cause there's no way to predict a vessel coming into render range ahead of time, right? And of course the only way to load files from disk is by stalling the main thread in I/O at the last possible second... When you replied you cut off @DMagic's last sentence in which he actually said something similar...

I know of at least one issue - if you autostrut to "heaviest" and the heaviest part switches because a heavy fuel tank empties or you dock with a heavier craft, the struts have to recalculate their connection points and this can break things. In general I just don't trust them entirely because of that need to recalculate occasionally. So I just reduce my risk by using as few as possible.

There's a development branch on GitHub that was updated last month. Also, the current v0.10.1 seems to work just fine. I've been using it for both 1.5.x and 1.6.x games for a while.

@Aegolius13's approach is similar to what I do. I autostrut the engines from each lower stage to "root". This ties the ship together really well without too many autostruts. I avoid using "heaviest" on any craft that will be docking with another craft because that can get wonky and break ships.

Perhaps @Chumpes was being sarcastic LOL...regardless, my challenge still stands for anyone who actually believes you can play w/o time warp

The problem with adding exoplanets is that they're light years away from your home system. Even at max time warp it would take a crazy amount of time for any Kerbal craft to transit to the other star. Some mods add another star orbiting Kerbol - like the Grannus expansion pack. I'm not sure if that's technically an exoplanet though since you're really dealing with a binary system then, not a different system

To anyone who thinks the game can be played w/o time warp...help us out and demonstrate that this is fun/playable...Just do a Kerbin local system mission - here's your challenge: Launch an Apollo / Saturn V style mission to the Mun including using a separate lander and a lunar orbit rendezvous and NEVER use time warp for the entire mission. This is a very classic mission that many players try and it's not too time consuming by space travel standards. Play the whole thing without time warp and report back on your experience. The whole mission should take less than a week. I'm particularly interested in how you plan your schedule for the week around various mission stages...Do you set alarms? Do you carry a laptop with you the whole week? Since you can't time warp you have to leave the game running to move time forward. If you're taking your game with you on a laptop how do you keep the game running continuously? Oh, and don't forget that you can't save and reload because you can't go back in time. So if something goes horribly wrong you have to launch a new mission.

When: within an hour of my first install - install KER Why: because I wanted a DV readout and other stats like time to AP.

I've had this happen a number of times. In my case I think autostrutting was the problem. Not sure if this applies to your situation, but it looks nearly identical the issues I'd faced (look in the pic below at the service module with the solar panels attached. You can see how it's misaligned with the parts on either side). I traced mine back to using autostrut to "heaviest" combined with docking or undocking. My best guess was that when craft docked/undocked the heaviest part would change causing all the autostruts to reconnect. It wouldn't change instantly, but when I re-loaded the craft parts would go askew. Using autostrut to "grandparent" instead of "heaviest" seems to work a lot better. Hope this helps.

I was showing just the part the full config i use. I actually go the other way with my setup and force checking more often. but then I never use time warp to collect science. Using Labs is an integral part of my game and I have it IMHO, balanced. Here's how it works I use life support (USI-LS) so maintaining a lab takes quite a bit of planning and effort I downgraded the data -> science conversion ratio from 1:5 to 1:1 - If an experiment is worth 8 science normally I only get 8 extra science using a lab, not the 40 extra science stock labs return. This means that at max I can double my science for a given experiment I reduced max storage from 500 to 250, but I increased the rate conversion happens a bit. - these two changes result in me having to check in every few weeks to maintain my lab. I will only process an experiment through 1 lab. Never will i gather a bunch of copies of the same experiment and take it to a bunch of labs. I reduced science transmission rates on any experiment with a material component - goo, material bays, EVA surface samples - to zero. The only way to get value for those is to return them to Kerbin or process them in a lab Finally my overall science rate is set to 30% What does this all mean? I have to send up science labs on stations or mother ships including planning life support and keeping an eye on how long crews are away from home and, for all that work, I only end up with about a total of 60% (counting each experiment twice) of Stock science. Using this setup labs aren't OP, they're a necessity and it gives me a great excuse to build bigger structures, plan crew exchange missions and special sample return missions. @PART[*]:HAS[@MODULE[ModuleScienceConverter]]:FINAL { @MODULE[ModuleScienceConverter] { @scientistBonus = 0.15 @researchTime = 6 @scienceMultiplier = 1 @scienceCap = 250 } }

Really nice design work The parachute/RCS ring on the capsule works really well and also like how you handled RCS for the lander/ascender!

Funny timing. Scott Manley just released a youtube video about something like this:

Does this work with GPP or RSS? (sorry if this has been asked before, didn't see any compatibility note in the OP)

Cool idea, but the examples in the pic you shared aren't actually the same type of "fuel lines" as those used in the game. The fuel lines represented in the game are for moving a LOT of fuel from one tank to another very quickly. Because of that they'll be as straight as possible because any twists or turns disrupts and slows down fuel flow. The best example of a real-life fuel line is the LOX pipe that goes between the Shuttle and the external tank. Here's the best pic I could find. You can see that the main pipe really is just one big thick pipe, like the Stock fuel line Not to stop your creativity, greebles are always fun, just thought this might help you understand why the stock design looks the way it does.

Probably with the right config. I haven't tried. My issue, and the one I think the OP was having, was having to frequently stop time warp when labs fill up. Increasing the capacity reduces how often you have to stop time warp.

Thanks! I tried that and it's not always worth it. Here's what I found in testing: If you have side boosters that you're discarding - like STS, Soyuz, Falcon Heavy, Delta IV Heavy - your approach works great because you're shedding tank and engine mass at just the moment you don't need them anymore. If you're using traditional stack it's a different story though. When you're on initial ascent, when weight matters the most, you're fighting gravity with the dead weight of a second stage engine, which really saps efficiency. On the other hand, if you keep your first stage longer into the flight and throttle it you're also carrying some dead mass because you're not using the full potential of the engine, but you're doing so when you're already into your gravity turn, most of your thrust is horizontal and weight isn't as much of a concern. I subscribed to your approach originally and it wasn't until I did some actual side by side testing that I discovered that, in a stack, keeping the first stage longer is actually a good idea. I'm still trying to figure out when it makes sense to stage. Using as few stages as possible seems like the best plan. If you can SSTO there's no reason to add a second stage. There's a point of no return in which the first stage can't lift enough fuel to SSTO and this is when additional stage(s) needs to be added.

@Starhawk & @OhioBob Thanks for the ideas and for the link. I'm out of "likes" for the day I'm playing with 30% science returns in a 2.5x (or 3.2x) scaled system. When you have limited engine tech and 5000-6000 DV to orbit it's tough to pull off higher TWR. Also 1.3-1.6 is "realistic" for 20th century rockets. American rocket stacks had pretty low TWR Saturn V: 1.18 Gemini/Titan II: 1.24 Mercury/Atlas: 1.26 Russian craft, with the 4 huge side boosters, had higher TWRs Vostok: 1.65 Soyuz:1.6