cantab

I'm recreating some craft I did a long time ago. At the moment it's my Dirty Rascal V/STOL cargo plane, now built with Breaking Ground parts. It's not finished (I'm using infinite electricity for a start), but I was able to take off vertically, hover around a bit, transition to forward flight and reach a speed of 180 m/s, then transition back to hover and land vertically (ish). I have prop torque on the main throttle, rotor torque and rpm on a custom axis (setting both gets more precise response), and propeller pitch (authority limiter) on another custom axis. (And assorted AGs to turn things on and off). I admit I resorted to reaction wheel spam to control it in the hover, and I'm having issues with the nose wanting to dip when hovering. I need to experiment more with authority limiter on the rotor blades, it seems effective at controlling vehicle pitch but very very sensitive.

I've never attempted an Eve return. As far as stock worlds go, I think I'll actually have to give it to Duna of all places. I've landed and returned Kerbals from everywhere except Duna and Eve. If I remember rightly every Kerballed Duna mission I've done has gone horribly wrong. I've had craft disintegrating on parachute opening, impacts into the ground, and rover crashes. Eve, Tylo, and perhaps Moho might be "objectively" more difficult but they are widely known by reputation. Duna's problem is being harder than I expected. Much like Mars, it's got enough atmosphere to cause trouble but not enough for an easy chutes-only landing. Partly it's been influenced by whether or not I allowed reverts in the save (and indeed whether I go to Duna at all), but Duna is my nemesis. EDIT PS: Laythe I didn't find particularly hard, but I did send a boat. If your lander needs to come down on land rather than water I can imagine it taking trial and error. As for Moho, I just take ion engines, loads of xenon, and a TV show on the second monitor

I don't know. As with many others, if KSP2 doesn't have the Linux port at launch then I might not play it much until it does. Rebooting into Windows to play a game is a nuisance. Plus yeah, we know nothing about KSP2 except for what the developers have said. That said I think if it's done right and once it gets all the ports, KSP2 is the kind of game that could very thoroughly supersede its predecessor.

Technically the deepest might be on Kerbin, but the atmosphere is in the way of orbiting through that. Otherwise in stock I think the only two are Mun and Dres.

KSP has performance problems running on OpenGL on Linux too. There are other games on Linux, some using Unity, that don't have issues like KSP has. In particular the garbage-collection stutter has everything to do with Unity's outdated version of Mono, and KSP's code running on top of that, and little if anything to do with DirectX. I've seen nothing to make me think any other general-purpose engine would be better than Unity for KSP2. I don't know any games in other engines that come close to KSP's scale and range of speeds. I've long advocated a custom or special-purpose engine, perhaps Space Engine, but Star Theory have decided not to change. For what it's worth, Simple Rockets 2 also uses Unity.

If I remember rightly 1.0.x was awful, abysmal performance. 1.1 improved that a lot. 1.7.1 gave me so much painful VAB lag that I can't yet call it my favourite. But then Breaking Ground is awesome, so...

So far. Biggest improvement: Visuals. Biggest let-down: Appears to still be discrete parts, not fully-procedural. Biggest concern: I've never heard of the developers.

If it already has Windows 10 on it, MIcrosoft now uses "digital entitlement", recording details of your hardware (including the unique MAC address for the ethernet and wifi adapters). You can do a fresh install of Windows 10 and it will connect to MS's activation servers which will recognize that yes it's the same laptop, so you don't need to enter a product key. There should be a key sticker on the laptop anyway in case you do need to put it in. And you can actually download Windows 10 freely from Microsoft. They're happy now for us to make our own install discs / usb sticks. The "Media Creation Tool" is a bit lousy but it does work. Note that if you want to use a DVD, the most recent versions of Windows 10 don't fit on a regular DVD, you'll need a dual-layer. Worked for me putting an SSD in our laptop a couple of weeks ago anyway. If it currently has Windows 7, I've found Windows 10 will usually activate using a Windows 7 key, even though the "free upgrade" has officially ended. If there's no key sticker on the computer, you can use a program to get the product key before you take the old drive out. EDIT PS: And yes, it's made a huge difference. I'm now able to actually turn on the laptop and use it, whereas with the previous awful hard drive I just spent so much time waiting. I opted for a Crucial MX500 512 GB (the same drive I have in my desktop), and also added RAM to a total of 12 GB. Probably overkill on both counts (the drive being one of the best-in-class) but as the saying goes, buy cheap buy twice.

Known bug with Kopernicus. Disabling both terrain scatter and Breaking Ground surface features may mitigate it. Otherwise rollback to KSP 1.7.1 until Kopernicus is updated. EDIT: I didn't read. But double-check that Kopernicus isn't still in GameData by mistake. Even if no planet mods are present, Kopernicus alone causes the issue.

Junos can make stuff go like a bat out of hell.

Research, practice, and experiment. And above all else be patient and methodical. I've been known to spend multiple play sessions just getting a single gravity assist right. If you're trying to get gravity assists off a moon, for example using Tylo or Laythe to capture at Jool, then an important technique is a mid-course correction that balances pro/retrograde and radial burns. This allows you to keep your *trajectory* into the Jool system approximately the same, but change your arrival *time*. That's how you meet the target moon at the right time and place. As mentioned it's not everyone's cup of tea. I for one take great pride in my gravity assists which is why I'm willing to put in the effort.

VAB lag. It made building my Saturn V torturous rather than enjoyable. Trying to lock a gimbal only to find the lag means I've ripped a chunk off the rocket (and undo will have me w a i t i n g ages ), trying to rotate the camera and having it jerk and judder. It completely killed the fun. That's why I'm staying off KSP for a while. Sure, the rocket was big (about 700 parts), but I and others have built bigger. Flight lag I can tolerate, if only because after the launch to orbit usually most of the parts are going away, but VAB lag is different.

Thunderpants. Adds a new resource, Fartpower, and high-performance engines that run on it. The "Bean" is a basic model, then there's the more powerful "Sprout" and "Egg", the vacuum-optimised "SBD", the 5 metre "Vindaloo" engine, and "Cabbage" high-thrust RCS quads. Fartpower cannot be loaded onto a rocket in the editor. Rather, Kerbals with the FlatS trait convert liquid fuel into Fartpower at a certain rate. In Career mode these Kerbals can only be obtained by doing special rescue contracts.

Do you have any mods that add items or resources to Kerbals. For example any life support mod, or KIS/KAS? They can make the Kerbals heavier which will produce the results you describe, especially if they have a bug and give the Kerbal excessive resources.

Radiation makes superheroes right?

Except we can't. The new fuel tank version, when emptied, is significantly more massive than the deprecated structural-only version. This affects use cases where you're not using much LFO tankage on the relevant stage, for example nuclear ships. You can still find deprecated parts through the advanced part filters, for example show all 3.75m parts and the structural adapter is there. But it's quite possible Squad will remove deprecated parts in future.

Yeah, the simple solution has always been to put a probe core in the correct orientation. (A docking port works too). Now that we have robotics, a refinement is to put a probe core on a hinge so you can dynamically set the control direction in flight. People have been using this to make rocket autopilots - by rotating the probe core, SAS will tilt the whole rocket in order to keep the probe pointing straight up.

How KSP has moved on. Anywhere it's nowhere near my biggest stuff in stock, but I set my RSS record as part of my Saturn V recreation: 186 tonnes in LEO. LEO established by cantab314, on Flickr Mass in orbit by cantab314, on Flickr Of course this invokes the old discussion of what counts as payload. You can argue the 186 tonne mass is "payload to LEO" in the context of a Moon mission, but that doesn't mean it can put 186t of whatever you like to LEO. I think a fairer payload figure in a case like this would be to count the upper stage remaining fuel, but not its structure, on the grounds that if you short-fuelled the stage you could add that much payload. In my Saturn V's case, subtracting the 39 tonne dry mass of the stage gives a "true" payload of 147 tonnes to LEO. But then it could probably actually lift more. It's hard to know exactly without testing because adding more payload but not removing fuel will affect TWR and delta-V across all stages. For a rocket that already has a low TWR that may be an issue, especially in stock with high payload fractions.

@qromodynmcdo you have intra-vessel collision enabled on the rotors for added realism peril? As for me, did my one small step. That's one small step for a Kerman, by cantab314, on Flickr And the flag planting and ground experiment deploying. Learned that you don't actually need the ground science radio dish - an alternative is to have a regular relay nearby. I also passed some time taking in the Collins-eye view of the lunar farside. Because my Columbia was in a highly-inclined orbit I cut short the stay, launching the Eagle after about 4 hours on the ground. I combined the 7.5 degree plane change with my circularisation burn, and proceeded to a routine rendezvous. An inauthentic flight profile, the real LM ascent engine was not relightable, but if I wanted ultra realism I'd play RO. I rendezvoused at night and opted to station keep until daylight. Despite refilling from the LM's ascent stage, Columbia ran out of Ec on the way home. With a Nerv as the main engine I only had limited oxidizer storage and evidently I miscalculated my power needs. It's a good thing the Mk1-3 pod has RCS to control it through the re-entry, otherwise my trio might have been toast! As it was they pulled 17 gees, ahem. Splashed down in Indonesia. That counts as the Pacific, right?

I learn something knew every day - I don't think I've seen that tower before!

I can't say as much about the technical details, but I do know that newer versions of Mono (since 2017) can avoid the "stop the world" garbage collection. Some other C# runtimes also avoid it. But again, we're back to decisions taking years ago - in this case, things Unity did that means they can't easily upgrade to the new Mono. (In fact if I remember rightly Unity are planning to switch to .Net Core.) So basically, KSP's problems are because of unresolved technical debt.

We choose to go to the Moon in this month and do the other things, not because they are easy but because everyone else is doing them too. So this beast has finally done it. Full scale, full speed, full stock. Liftoff! by cantab314, on Flickr S-II nearing burnout over the Caribbean by cantab314, on Flickr TLI by cantab314, on Flickr Moon's SOI reached. by cantab314, on Flickr Into the vertical descent by cantab314, on Flickr Khouston, Thundery Base here. The Eagle has landed. by cantab314, on Flickr Full album: https://flic.kr/s/aHsmFiZMij I'll be saving the Moonwalk for a little later.

Well first up, no game can prevent a buggy or flawed mod from slowing it down, not without heavy restrictions on modding that would eliminate most popular KSP mods. I think KSP's performance problems come from a couple of sources. Firstly, the way KSP simulates vessel physics as a set of connected rigid bodies. It's a "natural" way to do it when your vessel building works that way, and a lot of somewhat-realistic structural behaviour emerges from it. But it's inherently difficult if not impossible to multithread and CPU demand scales worse than linear with part count. Optimising the physics engine will only ever increase the part count needed to lag the game, to actually get rid of physics lag would require a completely different way of simulating vessel physics. Treating the whole thing as rigid (besides robotic joints) would do the job but then you wouldn't get the spectacular vessel explosions that the game has become famous for. A second source is the Unity engine's problems with garbage collection. In simple terms, the entire game has to periodically freeze for the engine to do some behind-the-scenes stuff. This is why KSP often experiences regular stuttering. The problem affects any Unity game. It can be mitigated with clever programming but that requires coders to do that. Important to the current discussion, that includes developers of game mods. The garbage collection problems will only really go away when Unity fix it. (And then KSP has to be updated to use the new Unity.) In short, KSP's performance problems come down to decisions made by Squad when KSP was first made, and they were at that time entirely reasonable decisions. Many years on, it's not easy to change it.

Failed to do my Saturn V launch recreation today. After many RUDs of the first stage - each one taking over 10 minutes real time thanks to infernal game lag - I finally made orbit, only to find the third stage is still affected by fatal kraken strikes and anyway wouldn't have had enough delta. I'm starting to doubt I'll even have it done by the 20th.