damerell

I have a stupid question; those are my job. Can't bump-stop largely be handled by a protrusion on the part the shape of the wheel (less a bit for tyre compression fore and aft) with the suspension fully compressed?

No, I think a polite request to the modder for a simple change with a clearly stated rationale was my next best bet, which I did. Next after that (if RoverDude doesn't feel like it) would be going back to building the module myself, which I've done in the past (and didn't involve Visual Studio). Asking you to stop making suggestions to me is probably on the list somewhere, too. Please.

I checked before asking.

Can I be a nuisance and request some kind of option to turn that off for people who want to run prototypical Orion missions, please?

While your craft is undeniably impressive, I don't think that would be appropriate. Elcano tends to be a leisurely process, a contemplative journey [1], etc. Speed records would detract from that and would also increase the problems with assessing whether almost-flying craft are permitted. [1] Yes, I sound a bit up myself. :-/

I doubt it, unless it's ElectricCharge. Converters catch up in large globs after timewarp, which can confuse the issue. Can you describe the symptoms in more detail?

Please answer the question. What does the log say about what happened to them? Quote it verbatim.

What does the log say about what happened to them?

I'm not really in a position to give you useful advice since, by a happy coincidence, I only was using hollow parts from the mod in question - Lack Luster Labs. This meant I could just edit LLL_Scale_Type.cfg in that mod to make all 2x1 parts have a different mass exponent.

No. That's the value I decided was correct and mod in when I'm upscaling parts enough that it matters.

I eventually went with 2.5. 2 is clearly too low, 3 too high. When I looked at what various mods had done for distinctly sized hollow parts, mind, I tended to get a scale factor around 2.3...

Necrobones - some combination of Space-Y, Space-Y Extended, or Modular Rocket Systems. Plenty of big adapters there. Or Tweakscale, I suppose.

Context is a valuable thing. I said that in response to the silly idea that MechJeb's extra features are somehow a downside. I already said more than once that Gravity Turn does it _better_.

Something I said some time ago. That's the reason to use Gravity Turn; it's better. Not this silly idea that MechJeb hurts you by having functions you don't use.

You certainly aren't going to convince me when your argument makes no sense whatsoever, which it doesn't. You draw these silly analogies to physical tools - analogies which aren't valid because in the case of the physical tool the all-in-one tool is heavier or more awkward. I point out facts: you can use MechJeb's Ascent Guidance exactly like Gravity Turn - one button, one window, one piece of functionality.

Yes, super lightweight. If you have no use for those windows you need never see them. You can put one button on the Blizzy toolbar for MechJeb Ascent Guidance and have done with it. The analogy to a physical tool simply isn't valid.

That's certainly something that is true of physical objects in a way that it isn't true of KSP mods, something I tried to explain above. In the hypothetical case here, the multitool doesn't weigh any more or take up any more space [1] - so then why not carry it? [1] The load time from non-part mods that don't do heavy computation at load time is effectively zero.

If the ironmonger's shop is free, why not? The reason to prefer Gravity Turn to MechJeb is not that MechJeb has many other features. It's that Gravity Turn does this one thing better.

You find it surprising that people often like KSP mods to have some reference to reality? Or that people "preached" (or as we say in non-polemic-land, "talked") about Kerbal engineering being perfect just because, er, it is? (Never mind reactors; you can smash a full orange tank into the ground at 100 m/s and nothing will explode). It didn't have a snowball's chance in hell of becoming a mod, indeed, because if you want a mod you have two options: do it yourself, or convince other people it's a good idea. If your response to any criticism is to blow up and insult the critics, you're not going to get anywhere with the second option - and you're not going to get advice for the first option, either. You did directly insult essentially everyone who replied to this thread. My remarks about your handle are entirely called for; your handle is inappropriate for an all-ages forum. (It's not super appropriate anywhere, to be honest). You should change it.

An excellent way to get your idea implemented, I find, is insulting everyone who has tried to discuss it. It helps if you write in a sort of stream of consciousness punctuated by ellipses and ideally if your forum name is that of a fictional psychopathic (here was a noun describing someone who commits a certain serious assault).

It does raise the question of whether the stock wheel module is going to go back to being good enough to use it. (Particularly on track parts where angling the fore and aft wheels outwards will mask the main issue that stock wheels only work in one direction).

As far as we can see everything they build works flawlessly. Kerbals might be foolhardy but their engineering is perfect (which perhaps is why they are foolhardy).

That was overwhelmingly the effect of this mod, yes. (Or, if you prefer, to increase the number of mods / texture resolution usable). As mentioned, the OS is more than capable of swapping out textures on parts that aren't in play, but it can't work around the overall address space issues. Hard crashes are why people leapt on it with cries of glee, not the ability to look at all the part tabs in the VAB a bit more quickly. Since it essentially has never worked well in a 1.1 world (the first of many bug reports is from the 20th April, the day after 1.1 was released) I am deeply sceptical of claims that it would improve performance in 1.1. How could anyone know? These are all things you can verify by reading the thread. You'll also see that essentially no-one saw any benefit to using it on Linux. Why? Linux had 64-bit already and didn't need it because what it primarily did was to prevent hard crashes.

Crikey, what's the part count on that monster?

The OS's swap algorithm is more than up to working out that a texture that isn't on a part on the craft isn't needed. That's what DTL got you, minor improvements in the VAB aside. I'm not trying to disparage people for wanting a useful tool. I'm pointing out they're largely imagining the utility. DTL was a killer idea in the days of 32-bit KSP; now it's not. It's unsurprising it hasn't been updated now it's largely obsolete. Only if it touches the RAM it's leaking - and if it does, either DTL or swapping out unused textures is equally useful (good in the short run, futile in the long run) in dealing with such a leak.