MiniMatt

Feels a bit cruel to keep dunking but I gotta ask - did the "...test like crazy... huge amount of QA bandwidth..." not pick up on any of this before release? Did they not notice the KSC tagging along on orbital excursions, or rockets falling to a pile of pieces and falling through the VAB floor, or the frame rate cratering everytime the camera pointed at terrain? Because it feels disappointing that every review, every stream, every preview, couldn't help but fallover these bugs but the "huge amount of QA bandwidth" missed them?

Not sure I'm adding anything to repeat what has likely already been said a hundred times, but adding my disappointment that my computer which makes Cyberpunk & Forza 5 look amazing, can track the movements of millions of moving parts in Factorio mega factories, fly around the world in MS Flight Sim, and has provided thousands of hours of entertainment in KSP1 won't even hit the minimum specs for KSP2. Not angry about it, it just is what it is. It's turned a day one purchase (even at that ~€50 price point) into either a months-from-now purchase when minimum reqs are tuned down, or a years-from-now-on-deep-sale purchase when I next upgrade. Wish the devs and the game the very best of luck, bit sad I'll be wishing from the sidelines this time.

not sure if it's the one you're thinking of, but atomic rockets - http://www.projectrho.com/public_html/rocket/ - has huge resources kinda primarily aimed at sci-fi writers covering in great detail all sorts of propulsion techs & rocket design (as well as typical sci fi tropes of time travel paradox etc) geocities era website design is jarring, but a badge of authentic nerdiness :)

If it is a Firefly reference then KSP is going to be a very different game if Jeb risks capture by Reavers every trip to Duna

https://www.kerbalspaceprogram.com/en/?page_id=499 - is likely to answer some of your questions edit: and now I see you linked that very page, and - well - the QA engineer listing doesn't particularly include any coding requirements in the same way other positions listed there do, so I think that may answer your question

Reaction wheels + SAS modes are another thing to try playing with - the default setting, as you note can cause the A/D keys to roll, but you can click through SAS modes and one of them (think "Pilot", can't remember) helps to maintain some stability without inducing roll or pitch. edit: some other tips - disable steering on the rear wheels as a way of restricting turning, and setting much lower braking force on the front wheels than the rear to ensure your rover tends to lock up and drag under braking rather than flip. And yeah, much lower speed - unfortunately to the point where roving any distance becomes more a chore than a joy, but yeah, 10m/s is ~22mph and already double that tried on the Moon.

Haven't checked on 1.4x but the space center rendering has long been a bit odd - i reported this two years ago, the R&D screen and Mission Control screen both being significantly, and measurably, more stressful than the VAB/SPH hangars: Now like I say, I haven't tested this in 1.4, I'm pretty sure it still existed in 1.3, but it might prove a useful technique for identifying the cause of the problem and quantifying it - ie run a GPU monitoring app and just log some data. The graph above has me sat in the VAB doing nothing, flipping halfway to sitting in the R&D doing nothing. The graphs show this imparted some quantifiable extra stress.

It's not the laser focused streamlined option I sense you're after, but Kerbal Engineer Redux has - among its multitude of other features - a terrain altimeter. The HUD overlay can be customised to just about any requirements, including height, and vertical/horizontal velocity.

Interested as to folks preferences of multi-port docking versus hacking a port part to restrict to certain angle snaps - think @5thHorseman wrote this hack into a module manager script, and I think I've seen it implemented in parts by RoverDude, Nertea, and others. Advantages/disadvantages? Strength/angle precision/aesthetics? Glad to hear multi-port is working again though, in the past it seemed to go squiffy after every other patch.

Clearly cartilaginous - the g-forces vast numbers of their species are regularly subjected to by incompetent rocket scientists* surely forgoes any bone based skeletal structure. They must be flame retardant too because.... well let's just say we've extensively tested this. Perhaps some kind of organochloride physiologoy. And (most of them) are extremely happy. Like, all the time. So. Earth. Summer of Love. 1967. Lots of lazing about in music festival fields reduced the evolutionary pressures for a rigid skeleton. At the same time a surfeit of joss-sticks advantaged selection for fire retardation, and an abundance of THC imparts care free fun into the atmosphere. Lunar Orbiters 3,4, & 5 distribute this chemical soup off-world. Kerbals evolve. They multiply. They explore, and they explode (in hilarious ways). You want to know where Kerbals came from? Look in the mirror! (or ask your parents) (or your grandparents) * that'd be me. And you. Yeah you heard me. You monster. How many kerbals have you exploded today?

Frequently, almost always, I'll look to tweak thrust to weight - it is, perhaps, unfortunate, that we must rely on mods (or maths) to inform us of this. Too much TWR can result in a rocket un-inclined to tip over. Too much TWR means an over heavy engine which could be replaced with something more modest resulting in more DV. Only really tune down TWR when alternate engine choices aren't available or if the margins are so slim it makes sense. Generally aim to have no more than 1.8 TWR at launch, try for a smooth path to 45 degrees & mach 1 at 10km, 30 degrees by 30km and fall to, but no lower than, 20 degrees thereafter through the atmosphere.

Honestly good news. KSP is undoubtedly my most played game of all time. And I'm getting on a bit now - my next most played game was loaded from cassette tape. Yet this iteration has felt for a while like it's nearing the end of its course. Increasingly, the future improvements we'd like would be realistically best implemented by dumping the codebase and starting again. We will always have KSP. This announcement increases the likelihood of KSP2. And equally it increases the likelihood of other devs and publishers taking a look at the genre this amazing game has pioneered and realising spinning up their own takes on it can be commercially viable. From a purely selfish consumer perspective, more KSP, or KSP-like games is always going to be a good thing. From a more empathetic perspective, I do hope Felipe/Harvester got a good deal out of all this and didn't leave just to see his baby sold behind his back - but frankly that's entirely none of my business.

Possible - likely - culprit will be as a result of upgrading an earlier modded install. Earlier ModuleManager.dll versions - installed in the root of your /GameData folder have been mentioned a few times as being particularly fighty.

Wow I've no doubt it's possible to infer all manner of drama, but in the spirit of "the simplest explanation is the most likely", if a bunch of people who'd worked on something cool for a long time began to burn out and so went off to make something else cool someplace else then that can only be a good thing. The world needs more cool toys.

you absolute beauty! thanks

Apologies in advance, as I'm sure I've seen the answer to this question in this very thread in the past but I can't seem to find it. In 1.1.x pre-release there was a brief stock bug whereby a shader update caused translucent squares to appear around lights - http://bugs.kerbalspaceprogram.com/issues/7802 I'm seeing this again in 1.2.1 & 1.2.2 when running SVE (medium) and I'm sure previous discussion has suggested those afflicted can flip a scatterer setting to resolve it, but I'm failing to recall what it was and I'm failing to formulate search terms to find the fix again.

Gosh! Early days but initial indications seem to be that the bug fixes have had a dramatic impact on my crash rate for the better. It might finally be time to call time on my stable 1.13 save.

Throwing some other potentials out there: Dew-na or Doo-na? Aware that S can sometimes be silent-ish in some languages, Drez or Drey? And thinking about it, don't Spanish & Portuguese differ substantially on the letter J? Jool or Hool? Or would it be closer to how a native english speaker might pronounce "Yool"? edit: perhaps best to limit to Joolian system as per the OP

Below is a neat thread on drag experiments in 1.2: The suggestion from that thread (particularly the appendix section) is that the shielded docking port is better than leaving the node completely bare, but considerably more draggy than an aero nose cone or shock intake. Further, though this potentially runs contrary to some stated dev clarifications, the experiments listed suggest that detached shockwave effects and resultant radial occlusion are not modeled, at least as they pertain to transonic drag. All that said, the shielded docking port remains a useful part, and likely viable if you can engineer around it's shortcomings. Edit: Oh, and a "trick" with the wings which seems to remain valid in 1.2 is to dial in an angle of attack in their placement - ie. rather than pointing the whole plane 10 degrees above prograde to generate lift, rotate your wings (say one shift-click on the rotate widget) - this allows the plane to point prograde whilst still generating lift through angle of attack on the wings. This results in less drag from the body, but more drag from the wings, but the net result is generally less overall drag.

(another vote for) KSP 2.0 KSP 1.x is great, don't get me wrong. It, and its pre 1.x releases have consumed more of my gaming time than any other game in history. But its long development cycle and ever shifting design priorities are beginning to be limitations rather than advantages. Every other devnote/squadcast regales with tales of fighting through "ancient" code, or starting new re-writes which will "lay the foundations" for future work but which never quite emerge. All this is natural in a game which has become far bigger than anyone could ever conceive at its inception. It has resulted in a great game with varied but unfocused direction; the various short term foci ultimately fulfilled (admirably) by mods - and the early decision to be mod friendly must be one of the great decisions in this process. It's beginning to look and feel a little old & unwieldy and I kinda think beginning again with a solid design vision, on up to date technology with artistic & technical resources from the outset would do wonders. Those artistic & technical resources weren't available at the outset of original KSP for entirely understandable commercial reasons, and the design direction was unfocused because, well, it was a "back of cigarette packet" design - albeit an awesome, well driven "back of cigarette packet" design. I see it in a similar place to Project Zomboid - although it has come out far better realised, and likely far more successful, than Zomboid. Years ago, the idea of a survival craft-em-up zombie game sounded awesome, Zomboid was the instigator and the big hope - nobody else was doing it, the public were enthusiastic. Now, every other game is a survival craft-em-up, and many of them are better focused & far more commercially succesful than that first Zomboid iteration - sure Zomboid remains a fantastic game, but it lacks something for being the first. Sometimes the subsequent iterations are "better" (at least commercially) than the first. KSP is arguably the first (successful) iteration in the "nominally realistic orbital construction-em-up" category, and Squad are lucky that few others are looking at their territory to make "better" subsequent iterations - they're ideally placed to make KSP 2.0 and they should do it before other houses do it for them.

Another quick balance note, possibly one which might provide some relief to the Minmus mission habitation timer discussion above. The viewing cupola versus the observation cupola. Both mass 0.35t, both provide a hab multiplier of 0.5 affecting 1 crew, both have identical impact/heat/pressure/gee tolerances, and both have identical mounting concerns But the viewing cupola additionally has a single crew seat, and additionally provides 1 hab-month. The effect of this is that in order to bump up a regular 2-crew cabin (eg Mk2 plane or lander cabins) to a ~20 day habitation one can add either 7 observation cupolas for 2.45t mass, or 2 viewing cupolas for 0.7t mass. Next one is more of a gut feeling rather than a directly observable inbalance: Hitchhiker versus Mk2 Crew Cabin Hitchhiker at 2.5t will keep 4 kerbals entertained for 165 days. Mk2 Crew Cabin at 2.0t will keep 4 kerbals entertained for 7 days. Now I realise that 500kg difference is significant - that's a lot of thumb drives filled with hard core Belgian trance-electro pop-jazz funk-disco fusion - but when you add other multiplier modules the disparity grows rapidly. In order to turn a Mk2 Crew Cabin into a 4-kerbal 165 day expedition you'd need to add 42 observation cupolas (14.7t), or 21 viewing cupolas (7.35t), or 8 PPD-12 Cupolas (14.4t) Suggestion would be to add some kerbal months to the other passenger cabins, whilst leaving an advantage with the hitchhiker to account for it's mass-per-passenger penalty and it's physical size. I'm finding multi-year missions quite straightforward (especially when adding the MKS modules), but ~20-30 day missions have a tendency to railroad toward fairly narrow choices.

Your estimates look in the same ball park as I would use, the difference seems to be in the return from the Mun - if you eject opposite to the mun's direction of travel, so ~90 degrees if on the Kerbin side, ~180 degrees if on the far side, you should get those brave green pioneers back home safe and at the dv costs you planned. edit: ignore me, I misread, as leafbaron says below, 3kms aerocapture is doable.

I know this sounds *really* pedantic for a config file but it occurs to me that posting it *could* be interpreted (if you really squinted funny) as distributing proprietary code without permission so the safest answer I can give right now would be to get the stock files back from wherever you bought KSP - if Steam, then nuke (or, safer, move someplace else) your existing config file and in the Steam listing for KSP right click, properties, local files tab, "verify integrity".

That gets to be a really wide question with a dozen different answers, all of them and none of them right. In short you can put your landing engines under your base module and try to keep them low enough profile, or you can put them to the sides of your base module to be jettisoned after landing, or you could put them above (and to the side) of your base modules as a detachable "sky crane". Each approach has it's merits. Duna will also allow for the use of some parachute assistance to further complicate or ease matters. As for docking them up once landed, you've options ranging from wheeled bases and carefully aligned docking ports, to mod solutions like KAS/KIS and the new USI Konstruction. Perhaps some pictures of your intended modules, and their intended final configuration would help? The Gameplay Questions & Tutorials section may also be able to provide more advice. edit: some shameless plugging - for smaller bases it may not even be necessary to break into smaller modules, you may just be able to launch the whole thing in one go - shameless plug link to the last Minmus mining base I launched as an all in one, aerodynamics be damned:

Ahh, my apologies, you're correct Just double checking in game, the Nom 5000 in agroponics mode is expected to eat 0.43 mulch/hour and produce 0.48 supplies/hour. Meanwhile a kerbal eats 10.8 supplies/(6 hour) day, or 1.8/hour. This means I've either misunderstood something badly (very, VERY likely - I get most things wrong on first glance) or I'm going to need to re-plan. edit: Ahh, the recycler efficiency of the MPL has changed quite a bit - from ~70% in 1.1 to 50% (up to 4 crew) in 1.2. So 2 kerbals with an MPL recycler would be eating 10.8 supplies per day total under 1.2. In 1.1 I'm pretty sure this could be covered by one Nom 5000 greenhouse, but clearly not under 1.2 - the changes Dstaal mentions are clearly worth noting here. The changes do kinda make sense of course, I could definitely not grow enough food to keep me alive on a daily basis in a space smaller than my car. edit 2: So it looks like the Nom 25k producing 2.38 supplies/hour (14.28/six-hour day) will do the trick for your 2-kerbal MPL recycled station - this coming at a cost of 1.148t and 1.32/s electricities; or four Nom 5ks, at a cost of half a ton, and 1.04ec/s will produce 11.52 supplies/six hour day.