swjr-swis

A few years ago, during a Squad dev meeting: "KSP players clearly require protection and guidance, we can't leave important decisions to them. Let's instead have an algorithm decide when parts can perform their main functions or not. Let's also make this non-optional. I mean, what could possibly go wrong..." . . . . Present day, at the worst possible moments during play: CANNOT DEPLOY WHILE STOWED

Travelers can no longer complain about lack of space between the seats...

A few longer versions of the octagonal and cubic struts have always seemed like a logical addition. The heavy girders and I-beams make sense for ground construction, but are rather ridiculous for space and air craft design. And considering KSP's heavy penalty on high part counts, it's hardly ever practical to create lightweight structure out of the tiny struts.

Based on the semi-official statement that Squad has "focused on full-time game development since the release of KSP", it would make business sense to already be working on a new project. T2 might still throw Squad some regular work on further KSP developments, it might even have been part of the deal, but it seems a risk to gamble a company's future on just one product. It makes sense to have more projects in the pipeline to secure a revenue stream and I wouldn't fault them for that. So, I expect they have something more up their sleeve, and we'll hear about it in time. I just don't expect them to be very forthcoming with details until it's practically ready for release, given the tighter reigns/NDA they're operating under now. My only hope is that they find the latitude to at least 'finish' KSP - still waiting for that definitive polished version mostly free of bugs and annoyances. Hey, I can dream.

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...

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.