Andersenman

Came here manually and reset pw manually after receiving the mail in case it was an elaborately crafted phish. If this was actually legit and indeed triggered by admins, it would have been plenty smart to put an announcement in the, well, Announcements to be read even without a login. If so, then I guess someone wasn't plenty smart enough, wink-wink, nudge-nudge …

Here we are, it's 2020, 1.9.1 has been released not too long ago, I'm still getting notifications about people visiting this thread, and there's still nothing. Apart from bewing not being listed with some form or another of affiliation with Squad anymore, but that just as a curious anecdote. Squad, will there ever be any development as to making this Normalizer function more comprehensible and documented to the user, please?

SQUAD uses it in the stock tech tree to mock players with its utter uselessness as a control module thanks to its horrible, completely unrealistically unshieldable drag (fairings come MUCH later) and colossal ugliness when trying to surface-attach anything but a 16. But at least it has a polished finish now, so there is that. This is why I keep with me a small mod part that essentially stuffs the Stayputnik's innards into a nose cone: Weight, cost, tech tree placement, and typos adjusted, of course.

I bet you say that to all the girls bugs/quirks/shortcomings/design decisions./s Respectfully, that's nonsense and I don't believe you. I highly doubt that SQUAD (no matter whether before or since you joined) deliberately provisioned the game and/or the stock vehicles in such a way that they malfunction during regular gameplay just to teach players some passive-aggressive lesson. Coding costs money, and coded nonsense is still code. That said, why is changing tyre friction something that should be invoked in the first place? Let's ignore the fact that for some reason it must be hidden by a switch in the Settings that governs its accessibility in the first place for now. In reality, reducing friction is not an option, let alone desired. If, as a vehicle engineer I have to rely on the behaviour of my tyres to specifically lose traction at a certain moment to keep my vehicle stable, then there is something seriously wrong in my design. So, recommending just this method, to slap a baby buggy's rubber wheel on an airplane instead of the regular landing gear so that it starts slipping when it exceeds a certain amount of cornering force just to prevent it from performing the litho dance, does not sound sane, practical, or realistic, let alone self-evident or intuitive.

Fun with integrals: "daily snacks" means the same as "snacks per day". Using both together multiplies them into "snacks per day, per day", or "snacks per day squared". Which is not a consumption, but an increase in consumption.

Thank you, I will investigate. I shall point out again that this happens to the stock, SQUAD-provided Velociteze, and does so from about 50 m/s and upwards, and thus very much so upon typical landing speeds.

Again and again and again. Every bloody landing, KSP does this screwup to planes, even stock ones like the Velociteze: How is this a thing and how do I make it not a thing, please? Thanks.

For when one wishes to exclude gimbaling engines from throttling to keep authority, like the Cub or the Thud. Deferring to the thrust limiter option is impractical for all but those constructions which only consider a single engine. And yes, this is still valid, so I will revive this thread.

Duly noted.

No.

I don't think in said four years anyone has stopped any mod from moving it there ...

Isn't it just! (Yay, my 2^8th post!)

Another handful of updates has gone by, another handful of updates without clarification on this functionality. So once again I'd like to raise this still relevant thread from the dead and ask, Thanks. Kind regards, A.

Hey there, thank you for this neat addition to user-friendliness. I wonder, would it be possible to not entirely hide but reduce opacity of the unwanted orbits instead? Thanks! Best, A.

Let's please not be presuming what can or what cannot be expected to be known depending on registration date, especially for a game that is as … fluid as KSP. Thank you.

I appreciate that, but that's not the point. It should work intuitively for all parts. Full-stop. And even if that fairing is one of the earlier items, it's still at tier 4, costing 90 science, and is preceded by one adapter and one nosecone.

Not when, but if. Those items aren't plentiful very early, so it's only reasonable resort to things like nose cones and (visibly hollow) decouplers to form shielded bays. That is, if they actually worked like that and didn't just mislead the player into thinking so.

Yes, I tried a simple centrifuge, but it didn't produce any usable forces. It's weird that you don't get any "usable" centrifugal forces when in fact the parts get visibly torn apart at the joints (before they actually fail).

Darn.

What Signo said. OP placed the tanks on top of the probe body, then covered it with an adapter. What now, is the player supposed to assume that the adapter is solid (why would it be?) so as to satisfy the "clipping inside" part in that, thereby telling the player that doing it this way is bad and verboten? This is unfit for purpose and unintuitive to the player. The whole point in these adapters is to provide aerodynamic transitions between body sizes. Now, if using them comes at the price of A) dead, unusable volume, and B) the need to fall back to either putting the parts that could be stowed at drag-inducing locations OR putting them in one more compartment (with its own drag and additional weight), the user may as well just forego using them at all. Be it adapters, nose cones, or similar stackable items with no other excuse than their shape for the volume they occupy; if they look like they would cover items, they should do so, especially when the model clearly suggests they are hollow.

Thanks for the insight. I've tried to find threshold and responsiveness in the Unity documentation, but to no avail. I did find a compressor and a ducking functionality described, but all of them require a lot more parameters to be set rather than just those two, so I tentatively presume this is some functionality wrapped around the listener. The problem to easily deduce the functionality from these sliders aren't just their missing units, it's also their ranges. A threshold of 0 might suggest that ALL signal, all the way down to silence, was affected, and a threshold of 5 (as in, 5 sources at playing at 100 % at once, theoretically) could easily be exceeded by multiple engines firing at once, or many parts crashing into water, making this threshold rather pointless. Also, where's the compression or limiting in there? Is it somehow tied to the Threshold slider? In the end, these are but wild speculation. This isn't really a technical issue, it's usability and accessibility! These sliders are presented to a PLAYER, a PLAYER shouldn't need to try and guess their inner workings, it should be obvious and clear from their presentation alone what they do!

The plane idea is nice, but prioritising the acquisition of the necessary plane parts from the Tech Tree seems unreasonable over what potential can be unlocked with the rocket parts instead. I do like the centrifuge idea. That way the whole contraption could A, be recovered easily, would B, have to go neither very far nor very fast (in fact, it could even perform while already dangling from a chute), and C, would be throttle-able to avoid structural destruction. Thank you for these creative suggestions, I shall investigate!

Goddammit, why is this a thing? How is a normal user supposed to know this? How can a user be expected to find out only through debug tools? I thought KSP was supposed to be out of beta?

I must have this!

Brilliant series! One should wish that tests like these are included in the standard KSP QA test run ...