TMS

Chiming in to let you know that I agree with this and everything you said in your previous post, particularly regarding the "muh investment" claims. Coincidentally, SpacebaseDF9 was also the bit of my learning curve that went vertical. I make the same assumption (you're buying what the thing is presently, not what the thing is promised to be) but estimated that KSP2 was overpriced for what it was/is and felt that it never got to the point of being worth purchasing (or actually investing in a supercomputer to play it).

LOL... as do I. Pepperidge farm remembers. And the gui skeumorphism. And the the noodle nodes. In his own words, he had to force the humour and kitsch. But he was committed to the bit, and he did at least publicly (accidentally?) commit squad to free expansions for original purchasers. His awkwardness at the first KerbalKon was charming in comparison to the PR-heavy slickness of today. It all seems so long ago now.

Reminder: multiplayer was a late-roadmap, long-teased (if not officially promised) feature of KSP1 which semi-officially disappeared (I have a vague recollection of an official announcement that it was being dropped from active development). If you want to know what the options are, the old wiki has some suggestions. The conceptual constraints will probably give you some idea on what the likely gameplay model can be. My opinion is still the same as it was eight years ago: I hope it never comes to fruition and that no developer resources are allocated to it.

Is anyone aware of a method of disabling EVE and scatterer on the space centre selector scene - like where you're switching between VAB, tracking centre, etc? I'm using the QuickGoTo mod to avoid the overhead of loading the enhanced scene, but it's sometimes unavoidable.

Rockets are tall. Vertical screenspace is premium. Keep the GUI to the sides.

Using the crafts above (3, 5 and 6), the update appears to work. The radial separators and subsequent stages activate as expected. I'll leave the updated mod in my game data and run with it in my main game to see if I can find any exceptions (may take a while because I removed engine plates from my repertoire) , but it looks pretty good from where I'm sitting. Thanks for fixing this. I know you have taken guardianship of a large amount of code, but this mod makes launcher development and testing so much more precise. Much appreciated.

Why use imprecise and awkward labels (SM, MD , etc) for part diameters when their numerical originators exist? How would future mods for custom diameters work around this? Also, the part variations added towards the end of KSP1 development were an absolute joy - especially when you realised you could combine a barebones variant of a 2.5m engine on a stack of 1.25m tanks without it looking odd.

lol... I just spent this morning trying to replicate my craft without seeing this post. I got there eventually and can independently confirm that this has something to do with the use of radially-mounted boosters. My original craft file used liquid boosters with fuel ducts in an asparagus configuration. My test files did the same with and without asparagus and swapping out liquid boosters with solid fuel alternatives. The results are all broadly the same so far: the radial separator fails to stage. However, the exact staging behaviour depends on where the radial stage is located, relative to the engine plate staging event. For example, using the image below (craft file), if the radial stage (3) is immediately before the engine plate staging event (2), then the gturn script will perform two stage events back-to-back when ALL the fuel is expired from the preceding stages (just allow the central core to keep running with expired boosters attached and it will eventually stage). If, however, there is a preceding stage that exists between the events, it appears to fail completely. Using the image below (craft file), if the radial stage (4) is followed by a stage (3) that precedes the engine plate staging event (2), then the gturn script will fail to perform any future staging completely. If we amend how that above ship works (craft file) and replace the engine plate with a a normal separator and an inverted fairing with interstage nodes enabled, the (otherwise) same craft will stage appropriately. Note to other users: The only down side to this approach is that you need to remember to set the fairing air pressure cutoff to zero in the mod GUI (or you'll have an early ejection mid-atmosphere). Maybe you already know all that and the reasons why... but those are my findings.

Also experiencing this with a similar craft file. I got around it by swapping out the engine plate with cubic struts as engine mounts with an inter-stage fairing.

The only disappointing thing about Multiplayer not happening... is that Squad would have unnecessarily burnt resources on something that most people recognised early on would be inherently compromised by the game's nature. I'd really rather Squad addressed the very long list of other fundamental issues with the game, rather than dicking around with multiplayer. That said, if multiplayer ever materialises, I'd totally spend a few hours launching SRB missiles at your perfectly constructed ISS replica. Of course, given that most of the original dev team have walked away from the project, I don't see either of these two outcomes happening.

I'm sure there used to be a bug where the intakes would carry oxygen as a resource - but not enough to run an engine on for anything more than a split second. As @MiffedStarfish says, it's just likely that 12 intakes scraped enough oxygen out of the upper atmosphere to run one engine. You can use this to your advantage by grouping your engines and shutting those groups down sequentially (thus diverting more oxygen to fewer engines) and squeezing out the last bits of velocity from the air-breathing engines.

When I originally wrote this, I had assumed that the group could be 'collapsed' into a single line (hence the green triangle on the group). For complete removal of visibility, I'd expect that the vessel type selector at the top of the Tracking Centre could perform that function - especially as there's now a 'relay' vessel type.

As somebody who never found the part filters menu to be particularly intuitive, I never venture there much. I find that sub-assemblies being hidden in there breaks the workflow, so yeah, I'd support this. The save-specific stuff just adds more weight to your argument.

Quick question to everybody else... is anyone else noticing that the "Default Burn Node Margin (KER/VOID)" option isn't working? Settings > Specifics > [Select] Maneuver Node Alarms > Default Burn Node Margin (KER/VOID) You can change these options but get no corresponding change to node alarms in the alarm list window - even if you delete the alarm and have it re-detect the existing node. I seem to recall this happening before after an update but I can't remember if it was a bug... or me not using the settings correctly??? EDIT Ah... seems it was me who reported it last time! Haha! God, getting old sucks.

Open Steam Right click KSP in library Select Properties in popup context menu Set launch options... "C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64.exe" %command% Amend path to whatever suits you. This will default all startup methods to 64bit.

Ah, this is great. I always did wonder what happened to the ridges and plateaus I remembered navigating in the DEMV mods (someone needs to resurrect those, BTW). One question: if this changes the height map, how does this handle Easter Egg positioning? Quite a few were buried by the 0.21 changes and have since been restored by the 1.2 release. Does this mod reposition them to their original pre-1.2 state?

So no change then?

Don't know if anyone else has flagged this, but I get a launch error (in KSP 1.3) at the same place every time:

I do! I ended up suggesting this here:

Hmmm... I installed the editor extensions mod and the ability to apply autostruts to every part is a feature. Not had any exploding yet... yet.

Most decouplers and docking ports have a module that specifies how strongly the part is ejected when decoupling/undocking: MODULE { name = ModuleDecouple isOmniDecoupler = true ejectionForce = 600 } I can't find an ejectionForce parameter (or anything that looks equivalent) in The Klaw's cfg file. I had hoped to target it with a modulemanager script. Anyone know how to do this?

This has only really happened to me on larger vessels. I had assumed it was either due to clipped parts or just a limitation in Squad's latter revisions of the SAS function. Not had the problem since I installed Kerbal Joint Reinforcement. Your example is interesting, however, in that the vessel looks like it has very few parts AND it looks like it's also occurring during time warp. ...gotta say, my first suspicion would be that PhysicsRangeExtender! If that doesn't solve it, try taking a backup of your save game, then continually remove half of your mods until you identify a cause.

Did a full tourist run to Duna in the Hermes II...

Is there a way of changing the autostrut default to always be "heaviest part"?

Seeing this also. It started with a recent "Science [x]" update (which is still throwing an installation error) and now this.