Hagen von Tronje

It has nothing to do with either rocket size or stabilizer length, but placing stabilizers outside the launch pad zone. Any stabilizer outside the circle in VAB will probably be subject to this. It tends to show up more on gigantic rockets because they naturally fill up the pad. For huge rockets, make a level bottom on the first stage and ditch the clamps. 3.5kt is perfectly reasonable and don't let anyone tell you otherwise.

I've gotten interesting experimental results. I have a nice, midweight (10t) prop-driven STOL that's been very nicely tuned in construction. It's by far my favorite flyer. It sports two tailfins, carefully aligned. With all control surfaces enabled, it takes off at 42m/s. With airbrakes disabled as a control surface but all others enabled, it takes off at 39.5m/s. With tailfins on yaw only, it doesn't take off until 48.5m/s. Presumably the fairly large tailfins are able to pitch into that much extra lift on takeoff. I find this trait is preferable enough for my purposes to be worth more than the cost in drag or high speed handling - its top speed is under 300m/s even at altitude. Makes for an exceptional bushplane.

I simply think that the incidence of advanced life is sufficiently rare on both a spatial and temporal scale that it's highly improbable that any signal has or will ever be sent within our detection range within our species' existence. Even if a shockingly high percentage of stars do in fact harbor life at some point in their existence (say, 1 in 1000, even 1 in 100 would make only so much difference here), consider the fraction of a microcosm of time in which our own planet has harbored life capable of generating signals. Now take a nice, generous (but finite) guess as to how long we'll survive. You'll find that the odds do not favor two such civilizations existing anywhere near each other with most even halfway reasonable numbers - it takes something really, really extraordinary, like a multi-million year starfaring civilization, to improve probabilities of overlap. I, personally, don't think such civilizations are likely to be common, if they exist anywhere. But it has led me to an interesting thought in the past. The wonderful thing about astronomical numbers is that even conservative Drake estimates suggest there are/were millions, billions, or more, planets harboring life throughout the universe. However improbable, the universe is vast enough that the improbable becomes practically inevitable. This suggests to me that somewhere, in a galaxy far, far away (and maybe even long, long ago ), there very possibly are two planets, both harboring some kind of advanced life, maybe both orbiting one star, maybe closely neighboring stars, but close enough that contact became probable - and reality. For those two planets, our fanciful sci fi is a reality. Who knows what wonderous saga played out for those races?

I like using stack separators for orbital drops where several pieces will chute into my target area so none of them have decoupler remnants stuck to them. I don't think I've ever used the micronode, or the bigger node either. There are probably a couple airplane parts I haven't used, like the FAT aeroplane parts, but it's not because they're bad parts, I just haven't made something using them. Have also never found a practical use for the RoveMax 3 wheels despite loving rovers and attempting to make them work. I've certainly made designs that would greatly benefit from jumbo wheels but the performance was just too abysmal to consider it for field use, plus the way they drag over terrain looks so glitchy I have a hard time believing it's not kraken bait.

If you haven't played Mount & Blade Warband, try it. It goes on sale for a couple bucks regularly (like every month) and is one of the most glorious games I've ever played.

I have the most fun with Mk2 personally.

Just to rule this out, are you alt-tabbing during the load? I ask because OpenGL loads are long and boring so tempting to alt tab, but I've found that doing so will cause glitches very much like the ones you are showing here. If that is the case, either don't alt tab, or set fullscreen = false in the config (have heard this fixes it, I just sit through the load).

One of the big barriers I find is that it's just more practical to have reusable vehicles for each leg. SSTO to LKO rendezvous? Easy enough. Reusable transfer from Kerbin to planet of choosing? Also not THAT hard, especially if you have fuel stations at the destination. But not on the same vehicle. I just think it's simpler to make a reusable travel network where you SSTO then transfer craft at the station. Still, like you, I love the idea of a "personal space yacht" a la Heinlein (esp Lazarus Long's personal craft).

You'll be happy to find that Near Future already offers VASIMR engines that run on either/both argon and hydrogen (and LOTS of electricity), and are well balanced to be a lot of fun to use either with fission reactors or with capacitors also from NF (or whatever else you can think of for that much EC). They also sport even higher ISP than you asked for plus variable thrust settings with the obvious caveat that you must find a way to power those hungry engines! As a rule of gameplay balance (if not realism), high ISP engines really should have some tradeoff, either difficult secondary requirements like tons of EC or heat management, very low thrust, or whatever. I personally am not interested in magically powerful engines, as this presents no design challenge to overcome, though to each their own enjoyment!

I find building spaceplanes a lot of fun but the closest to "practical" I can make them is retrieving kerbals from orbit. I keep chasing the dream of a SSTO spaceplane that goes to LKO, refuels, goes to Eve orbit, refuels, lands on Eve, refuels, then does the same in reverse, from runway to Eve surface back home. It...is not an easy dream.

Intel's octocore is a state of the art CPU intended for high end applications. It's certainly much more than up to the task of gaming but it's really meant for workstations. AMD octocores are frankly mid tier CPUs. The key thing to keep in mind is that most (not all) games are more dependent on one or two strong cores than having a lot of cores. A quadcore i5 with great single core performance will do much better for you than an octocore with weak single core performance. Very few games can do anything useful with all eight cores from either manufacturer. CLC units don't impart miraculous cooling. Their main attraction (to me, anyway) is stabilization, they produce far fewer heat spikes than a fan. They're also good for displacing heat, as the heat will be moved to the radiator which may (or may not) be more convenient for your design than blowing it out the back of the case, and they can raise the ceiling on overclocks if you want to do that. However, I've never once heard the pump on one without trying to stick my head inside the case to do it, tiny high-speed GPU fans are many orders of magnitude noisier than either the pump or the radiator fans on mine. But are you talking about CLC or custom/full immersion? There's quite a difference both in what you can expect out of it and expense/difficulty and risks. What are you trying to get out of it? Just great gaming performance, or do you want a computer to tinker on, or a competitive overclocker, or what? Full immersion on an X series Intel is maybe a little ambitious if you just want to game.

Major rockets/landers are typically named after Norse mythological figures, mirroring NASA's use of Greek and Roman mythology. Not a hard rule though, I will use any mythological figure, or something else entirely. Spaceplanes typically get named after birds. Atmospheric planes typically get names reminescent in some fashion of real planes; for example, a series named after clouds. Rovers usually get canine or animal names. Rockets and landers usually get unique names if only because I rarely launch the same such thing twice, but serial production models usually get more utilitarian names because they serve a pure utility purpose (like a minimalist mining stack for placement anywhere needed, or a MPL harvesting lander). Especially favored designs usually get several variants with similar/related names.

A simple toggle in settings for science (and relevant buildings), money (same), xp, sandbox SAS, etc? Let's be honest, all modes are really the same thing with resources/buildings toggled, and a few tangental settings that are mysteriously career-only. There's already considerable customization of difficulty, a little surprised it isn't just a simplified "set up your game" menu. If you wanted, you could still keep selectable preset/default configurations and preserve both the named "modes" and presumably functionality with old saves, they'd just exist as preset difficulties in a game start menu. Even if you're playing sandbox, you may not particularly want a Stayputnik to be the same as the Remote Guidance Unit.

I voted "Other." I think it's a nonsensical question. It will be "finished" when Squad ceases development and the modding community collapses. It's impossible to place a percentage value on an indeterminate total. Further, the game models reality, or a reality. There's no expected number of levels or playtime, literally every aspect of the game is limited only by hardware, programming restraints, and desire to make it happen. Is it finished now? It's got much more content than most "finished" games, yes. Is there room for more? Many, many times more, if everyone involved is interested in that much. Either way, you're asking for a fraction of an unknown. But I clearly do not share the dissatisfaction that many express. Between stock and mods there's more to do with the game now than I have hours in the day to do it, and yet all signs point to there being even more of this to come, and engine upgrades that will make modding even greater than it already is. What can I say, it feels good to like something enough to overlook a few things, especially knowing many of them will get fixed, for free, and I need only have patience (not hard with this much to do already!).

That's a better practice anyway. A lot of things can come out a little wrong with ctrl+z so I don't really use it unless it's a purely structural, preferably singular, part involved. Typically I just save any time I'm satisfied with the work I just did. At least during building phase. Once I'm in bugtesting phases I never use it, I change one thing at a time and save/launch each time, any mistakes result in a full reload of the verfied working model.

I had this error for a long time. If you so much as touch your craft in such a state, you're probably going to come back to it missing a bunch of parts. Bizarrely it hasn't happened in weeks. I installed a bunch more mods and it just quit doing it (none were even bugfixes!), I wish I could offer a better explanation of why!

...that was literally my first sentence bud.

I know about the clickable up at the top, but if there's a hotkey for it, it's eluded my best google fu. I found an old post where Sal makes mention of double tapping B in the same sentence as the parking brake, but that produces no result for me and google suggests that others report it does nothing for them as well (just as well, this would make pumping the brakes impossible). There's certainly no configurable hotkey, so I suspect it doesn't have one. May we please have one? Even assigning Brakes to a custom action group will produce only half-functionality; your brakes will indeed be locked but no indicators will be flagged (i.e. the brakes indicator at the top that lights up when brake is pushed does not light up, mods that offer "brakes engaged" type feedback register nothing, etc). This makes it impossible to engage parking brake on an all-IVA flight (crucial for a STOL bush plane, no?), besides just being inconvenient. Might I suggest alt-B, which seems to be unused now, reuses the intuitive hotkey, and has been suggested informally in the past? I'm not going to gripe too loudly though since I've played hundreds of hours and only now thought I should "brake" the habit of clicking the button and use a hotkey instead.

Hi, I downloaded Blowfish's maintainance port, for the explicit purpose of extracting the MFD and attempting to implant that functionality into existing cockpits. This worked just fine by just going into the internal_RPM cfg files for the cockpits I wanted to update, and changing the props to B9RPMMFD. Everything works pretty nicely, but the APFD isn't giving me the forward and landing cams. In the MFD config, I see: cameraTransform = B9ForwardCamera and then a similar for landing camera, and it would appear that these two cameras are added to 1-9 external cameras. Is this a functionality I need to add in to the cockpits? If so, how do I do this? EDIT: Or would it be smarter to just change the MFD cfg to use external cameras 1 and 2 (or whatever I like)? EDIT2: Got it working on ExtCam1 and 2, just have to align those to taste. Awesome RPM interface, going to make F2 cockpit flying much more fun.

Squeezing two more runs (Kerbin and Laythe all-water) out of me? Challenge accepted, buddy. Prepare to put sails on that custom badge...a year or two from now.

3440x1440 @60 Makes for a pretty awesome cockpit view.

Ironically, heavy rovers work marvellously on Minmus. The reason rovers are hard to deal with on low g bodies is because they have poor traction; poor traction is countered with downforce, which can come from downthrusters/RCS or it can come from just having a bunch more mass, so long as you keep the COM low. You can prevent most of the flipping by merely having a low COM (wide wheelbase) but only downforce will give you traction for more...sporty performance, though cornering you'll always want to either go slow or have downthrusters. The nice thing is that downthrusters and "more mass" are one and the same goal, just carry fuel tanks for both ballast and for fueling downthrusters and you'll find Minmus's gravity is just a number. Minmus also has nice natural highways built into it. You should be able to do top speed on all flats at x4 physics warp no problem as long as you are careful about heading changes, making any two craft landed on the same flats accessible to one another risk-free if you have a rover active. This can be a handy thing if you have shipwrecked crew or a craft out of fuel as you can count on being able to reliably cross the flats in really short time spans to save them. Plus, most of Minmus's terrain is reasonably smooth, the slopes are gentle compared to mountains elsewhere and there are no craters. I am curious about the 7 Mun biome spot though! That sounds like a real find! It is. They have a pretty low structural strength, actually. Better off bolting wheels directly to structural panels IMO.

Kind of moving the goalposts from "beyond a speed at which they can safely collide with surfaces," isn't it? My experiment demonstrates precisely that they can safely collide with a surface at their own top speed. If you're using an antenna as the bumper, then kerbals on EVA exceed the top speed for safe impact on that. But to be honest I'm a little surprised acceleration would be an issue, at least in terms of wanting to turn it down. Either analog control or just tapping keys seems to do a pretty good job, no? Though to be sure I'm in favor of any and all additional tweakables, though I'd personally prefer things like ride height, stiffness, etc, as I think that would do a lot more for customization to the vehicle/terrain.

Generally I find it's less about where you're putting the wheels and more about what vehicle you're putting them on. I also think their potential applications are fairly obvious by looking at them, with the note that rugged wheels are more or less a direct upgrade to balloon wheels (better wheel, more power efficient), though balloons are perfectly servicable. But it's worth mentioning that landing gear constitutes a whole other class of wheel that can be perfectly viable on rovers. In particular, landing gear are ideal for high speed "land ships" that pretty much sail over the ground on external thrusters, and also great when you need a wheel to be a point of abusive or high speed contact, and some landing gear can be deployed as well making it a viable option for moving parts on a stock rover. If you find yourself dissatisfied with the wheels and thinking about mods, first try Claw's bugfix for wheel brakes, a lot of folks find this gives them just the thing they needed to be acceptable. Are you sure? Build a rover like this: - 4 rugged wheels, all motors engaged, all touching the ground level with each other - 2 small wheels, turned facing to the front, motors disengaged. This is to act as a bumper Drive this into the side of the VAB at 25m/s, the top speed for rover wheel motors. The small wheels should survive the impact, they will have flat tires but not be destroyed. An engineer can then repair them and you can repeat the experiment indefinitely so long as you repair the wheels. Even if you don't repair it might take you a few tries to get one to explode. I've had countless rover fails by now but I've yet to have a single rover wheel be permanently destroyed unless the entire vehicle was pretty much annihilated in the impact. They're pretty durable parts so far as that goes.

Part seven of my Kerbin Elcano is up, featuring more exciting mountaineering exploits! Climbing rough terrain is always the hardest part of driving but also the most interesting, especially when you don't know if you can even get back down! As always link in my sig. Fengist, I finished my Minmus run a couple weeks back, I have no idea if you've even seen it; I posted completion but I think it keeps getting buried. Mostly I'd like to make sure I'm doing everything kosher with my challenge since I'm going to be doing so much.