swjr-swis

G-force limits for kerbals and plasma blackout, yes - those add a bit of reasonably sensible constraints to deal with, and they work pretty much as one would expect. G-force limits and pressure limits for parts, no - because Squad never did anything with these for the stock parts, other than copy/paste the exact same silly placeholder values everywhere. It makes absolutely no sense that eg. a solid metal girder buckles as quickly as a fragile scientific instrument or an antenna. Or that a flat metal plate gets crushed under pressure as if it were an empty pizza box. If they ever decide to revisit these and fill in some half-decent values, we might get some use out of these features.

"Do NOT touch that button."

Load your craft in the SPH, turn on the CoM (yellow ball) and CoL (blue ball) indicators. Since it starts out flying great, I will assume the CoM is likely in front of the CoL, but close. Now empty all of the fuel tanks, and then look at the CoM position again. My guess is, it has now moved way to the front. This means most of your 'dry' weight is far in front of the CoL, so when you consume fuel during flight, the CoM starts to move to the front. If it moves enough, it will change your perfectly flying plane into a lawndart that is almost impossible to pitch up and only wants to dive into the water. There used to be a bug in the game a long time ago that actually caused planes (and orbital craft) to go haywire or even explode when passing right over the pole. For a minute I thought from your OP title that this might have resurfaced, but I haven't seen it happen in a very long time, and honestly, the above (CoM shift) is a much more likely cause. While this does indeed happen, the result of a drone-controlled plane with SAS losing connection is that it will maintain SAS hold; in effect, it will slowly keep pitching up as it doesn't follow the curvature of the planet anymore. That's the opposite behaviour of what the OP describes, so I suspect it's a CoM shift issue.

Well, they're not as good as radiators, but their (purposely) modified thermal parameters make them soak up heat and radiate it better than most other parts.

It's the cockpit control equivalent of a phone menu: "You have chosen option A.3.D - Deploy Control Surface. Specify craft type:" "If this cockpit is currently in a shuttle, turn to control panel 3B." "If this cockpit is currently in a spaceplane, turn to control panel 5C." "If this cockpit is currently in a cargo airliner, turn to control panel 2A." "If this cockpit is currently in an experimental contraption, pick any panel and flip the switch that you most fancy right now." "You have chosen option A.3.D.2 - Deploy Control Surface on a Spaceplane. Specify control surface to deploy:" "For flaps, flip switch 5C.1" "For airbrakes, flip switch 5C.2" "For ..."

This Picard quote seems relevant:

The BG rotors can't do enough RPM to produce significant prop power. Apparently it can still be done by using the rotors as free bearings, adding one or more regular reaction wheels, and using the RW torque to power the prop. I've seen some people post about putting rotors in series on each other, effectively adding their individual max RPM to each other - not sure if that has been successful yet. High-RPM rotors and single/minimal part-count stock props will remain on the wish list for now.

Use a "CH-J3 Fly-By-Wire Avionics Hub" - it will add full SAS to any probe core used, including the 'Target' mode. It's under the Command and Control part group (together with the reaction wheels and RCS thrusters) and looks and works very much like a small nose cone.

Whatever caused the issue, it wasn't the time. KSP can handle times well beyond 499 years. Below a screenshot of the moment KSP starts getting weird about time:

Because 15 more days to wait for the DLC...

Doesn't it? I still vaguely remember those quiet, almost innocent days of old, way back before they announced stock hinges and robotics parts...

I posted video links for two of the craft (the dropbox links). The other has extensive picture albums of flight linked on its KerbalX craft page. "Basic Atmospheric Rank" is quite alright.

Steam tells me I have played KSP 441 hours. The scary part? I've never actually played my Steam install. It's only ever used for quick try outs of the latest update, to see what's new... before I copy it to another folder from which I actually play they game. I don't really want to know how much time I've spent on it.

Does this one count? https://www.dropbox.com/home/KSP/113/video?preview=KSP113-FlyingBrickToo.mp4 https://kerbalx.com/swjr-swis/FlyingBrickToo Or this one https://www.dropbox.com/home/KSP/113/video?preview=KSP113-SpinAgain1.mp4 https://kerbalx.com/swjr-swis/SpinAgain2 Maybe this? https://kerbalx.com/swjr-swis/UFO-Mk2 Fair warning: they were all made several versions of KSP ago, so they may not work quite the way they did back then.

Another stock workaround: attach one or more launch clamps. It works even better than pre-deployable brakes, because craft on brakes will sometimes still bounce/skid from their starting position.

A mission builder that ties into Career Mode? Ah, but one can dream...

First of all, about the new suits: they look snazzy. Tron-like glowlines, my dudes. A recurring theme seems to be that DLC will come with new suits. I'm ok with that, it fits usual DLC policies of adding cosmetic stuff to a game. Less ok with adding DLC-only functionality, but I'm not gonna start on that; I consider that boat sailed. The part I'm hoping may still be up for ... adjustment ... is about the placement of that helmet cam. Kerbal heads are big all by themselves, ok? With helmets on, even bigger. And now they're gonna get implements sticking out of them, requiring even more space. It's already difficult to make a kerbal fit a 1.25m cross-section without their heads or helmets clipping into other stuff. Those head cams are going to make things worse. Any chance of reconsidering this and fitting the cam in another way? Maybe like the streamlined bumps for the helmet headlights? Or even inside the helmets... as big as their heads are, there's still a huge unused amount of space in there. Or if you insist on the external thing: how about on the side of the shoulder, below the helmet? If not for the aesthetics, think of the childr... I mean, think of the ergonomics. That cam is a snagging hazard, getting eternally stuck behind wires, handles, hatch rims, antennae, rock ledges, etc. Making regular movement through a crammed cockpit/station interior difficult, and emergency evacuations downright dangerous. Rethink this, please?

Just a FYI: this is not enough to replicate the UAL0232 situation. In KSP, turning off SAS only disables attitude hold assistance, but control surfaces will still react as normal to your inputs. You will need to: go into the tweakables of all control surfaces and disable pitch/roll/yaw control set authority to all control surfaces to 0 to also disable action group activation (since you can't edit action groups in flight) set authority to 0 on the Mk3 cockpit reaction wheels The A300 appears to have a symmetry issue, at least on my install: I had to lower the thrust limiter on the left/port engine to 97% to nullify the tendency to bank to right/starboard. It's not a fixed value though, it depends on airspeed and altitude. This asymmetry actually helps a bit in steering, because you can play with just that engine's limiter to either side of the equilibrium value to make the plane bank either way, and use the throttle purely for pitch and altitude hold. Like @vyznev mentions though, it's a slow way to steer the plane, and you have to account for the very slow spool down/up speed of the engine (iow the plane's attitude changes lag quite a bit to the input), so set up your approach from very far out. A method to bank a good bit faster is to shortly toggle the thrust reverser of the engine on the side you want to bank to, then toggle the other one when you want to level out. Downsides: it's a lot less accurate and you have to account for some altitude loss due to the sudden drop in net forward thrust, so spooling up and gaining a bit of pitch up before the maneuver is highly recommended. Pretty sure this is not an option in a real life plane. I tried flying the A300 'pre-crippled' as described above (including the limiter port-side), and it's actually not that hard to fly. Getting it properly aligned at enough distance to minimize the need for last-minute corrections is the hardest part, mostly because of the lack of good indicators/instruments in stock KSP. It reacts pretty benignly to thrust leveling. My only other problem was I couldn't get it up to 7000m in level flight this way. So for me to enter a valid attempt I'll need the starting altitude requirement to drop to 5500m.

I disagree. I still have a perfectly well performing install of KSP on a old tiny WinXP laptop that isn't much good for anything else. It's as close to a portable/mobile version as it has ever got, and it goes with me everywhere. Sure, I've also had a modded-to-heck 64-bit install on my full-fledged gaming laptop as well, but I wasn't lugging that thing anywhere with me unless I planned to spend more than a few nights somewhere. 32-bit version had, and still has, a good use case that is regrettably being ignored.

Laythe has a 0.6 atm sea level pressure - it's thinner than Kerbin's. The entries in this thread show that on a sufficiently optimized craft drag is no longer a factor, and the constraint becomes the Juno power envelope (Mach 2.31 @ ASL apparently being the best possible result before flame out). So on Laythe, like on Kerbin, on a drag-optimized craft the highest speeds will be achieved just above sea level (dictated by its atmCurve). Mach number is directly derived from the speed of sound, which mostly follows the same curve as air temperature. Air temperature within the Juno's altitude range is highest at ASL, and is lower than Kerbin's. Given all this, it's to be expected that the Juno will flame out at a lower air speed on Laythe than on Kerbin. A quick test dropping my JunoSpeeder-3c on Laythe only yielded a 772 m/s top speed at about 50 m over the ocean surface. The real top speed is probably a bit higher since I spent no effort optimizing (wing AoI and pitch trim made a difference on Kerbin), but flame out was happening around Mach 2.29 already, so it seemed a waste of time to dedicate much effort to this. Feel free to try though, and keep us posted on the results.

You should look into 'part welding'. It makes multiple parts work as a single one, which means physics are only calculated for a limited number of parts on your craft.

It sounds desirable, and given enough computing power it would certainly make things act more intuitive/realistically. But KSP is already heavily constrained by how much physics it has to calculate every frame. Calculating thrust the way you ask would add a lot of workload to that, potentially tanking the game for many players. Physics simulations, especially in games, tend to use simplifications and shortcuts exactly because of that, so a game remains fun to play. A stock way to do this currently is to take advantage of the fact that exhaust, regardless of the width of the visible graphics used, is calculated as a razor-thin line. Place wing sections or other useful parts strategically, leaving just the tiniest gap open, and thrust is no longer blocked. So it is already possible to build 'stealthed' exhaust ports. Just mind the gimbal range. A little more difficult to use in a practical manner: exhaust damage is only calculated up to a certain maximum distance. Anything placed beyond that distance has zero effect on thrust. Finally, with a little more handywork, the engine part cfg (or the craft file) can be edited to disable exhaustDamage entirely (this is how RCS, Ant/Spider, and the Dawn ion engine are excepted from exhaust blocking).

While true, I think we can safely skip it for this challenge. Whiplash, Swivel *and* Nerv? Contestants are going to have more trouble not overbuilding things than being short on power. Spoiler:

Yes, you can. You can edit the part cfg file, search for the following parameter (or add it if it's not there): explosionPotential = 0.1 A low value will give a 'poof' dust cloud, and higher values will yield bigger explosion effects.