swjr-swis

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.

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.

'Obvious' things tend to be obvious only after we're shown how it works. Nothing was wasted if it helped you progress on your mission. Asking questions and getting help is what this forum is for.

Probably the only change you need is how you fly it. You're probably trying to fly it like a spaceplane, when it's really built more like a horizontally launched rocket. There's a number of things that are 'wrong' on it for a spaceplane, but it also carries enough engine power and fuel to make it to orbit despite the design errors. Try this: Full throttle until it rolls off the runway (with the main gear so far back you won't be able to pitch up before that anyway). Then pitch up to 10-15 degrees and hold there. Don't try to adapt pitch from here on, it will only make the nose dip down. Stage Nerv when you stop accelerating. Let the rapiers auto-switch to closed cycle, or manually switch if you have set an action group for it. At this point adjust pitch slowly to prograde and set SAS to follow prograde. Cut throttle when you reach 80km apoapsis. Circularize at apoapsis. After flying a rebuilt copy of your plane like this, I still had enough fuel in orbit to do a Mun flyby, return to Kerbin and land - although the last part was very slow on just the Nerv. As for making this more into a 'real' spaceplane: CoL is too far behind CoM. This is the main cause of the problem you describe where it dips down and it takes too much effort to pitch up again. There's a lot of wing at the very back of the plane which causes this. There has to be wing sections clipped into the back end of the body too that we can't see on the images, to make the CoL so far back. Remove those, and add some more wing towards the front end. Your goal should be to get the CoL very close behind the CoM. Wings have no angle of incidence. The wings have been attached 'straight', which means they don't provide any lift when flying prograde. They need to be angled up a bit, so they generate lift while the plane's draggy body keeps pointing prograde. You can use the rotate tool, while holding shift for fine adjustment, and a single 'tick' will add a 5 degree angle. This may not be optimal but it's close enough for your first attempts. It will make the CoL drop even farther back though, so they wings will need to be ofset a bit towards the front. I count three Mk2 monoprop tanks in that fuselage. That's really two and a half too many, in a tank type that is less than optimal. Cut them out entirely, or exchange them for regular fuel, and add two FL-R25 mono tanks on one of the engine pod sets instead. Better yet, exchange them for a long Mk2 cargo bay, and now your plane can carry stuff up. Two small mono tanks can go in the cargo bay, and are plenty for any orbital maneuvers. The engines look to be 'uncapped' - they have no nose cones on the back node. Due to how KSP calculates drag, this adds unnecessary drag. Add some nose cones on their back, then offset them into the engines so they don't block the exhaust. Drag is a key factor in being able to make orbit for a spaceplane, so it's important to optimize for it. The fuel is unbalanced. Always build your spaceplanes with empty tanks first, and then place/fill tanks in such a way that the CoM stays mostly in the same place. That way the handling of your plane remains predictable regardless of how much fuel you have left. RCS/vernor thuster placing is... chaotic. It looks to have been placed for looks instead of for function, and it will likely not work correctly when you need it in orbit. Also, they add drag, so you need to ask yourself if you really need them, and if so, how to use as few of them as possible. This size/weight craft (~50t) should not need 4 rapiers to get to orbit, especially if you remove the excess monoprop. The single Nerv on the other hand makes for very slow orbital acceleration. Two and two would probably make a better mix.

I can think of several ways to do this in stock: Use a 1.25m fairing base at the end that attaches to the lab. Build the arm wit the panels and the antenna on the fairing base node. Enable the interstage nodes on the fairing. Pre-dock a small monoprop tug with probe core to the top interstage node, so you can use it to fly it out and dock it to the lab (you may need to offset the tug a bit up to be free from the antenna end, but it will work as if firmly attached). Once the arm is docked to the lab, undock your tug and it will look like your first pic. Build the tug into the antenna arm. In other words, add a small monoprop tank, a probe core and RCS thrusters to the antenna arm, so it can dock itself. Turn the antenna 90 degrees so you can add a Jr docking port to that end of the arm and dock a tug there. The last two methods are illustrated in two versions of my recreation of the Hubble telescope, HLST-1c (method 3, the antenna arms, with tugs pre-docked) and HLST-1a (the solar array arms, with built-in RCS). I don't have a quick illustration at hand for the first method, but I hope the explanation is clear.

This thread has a screenshot and even detailed info on what caused the bug:

An SAS that doesn't try to kill our kerbals would be nice. It went all HAL on us a couple of major versions ago and needs to become usable again.

Kerbal cloning by merely exiting a pod. Kerbal launching by merely exiting a pod. Synchronized space swimming: SAS of a nearby craft in space that would mirror/mimic your every attitude adjustment. Camera that would suddenly start to zoom away from the craft in the middle of flight because the game was tracking a 'ghost' center of mass instead of the actual one. I think due to separating a shroud or fairing? Floating dentures: used to be we could zoom in enough to see our EVA kerbal's teeth. Asteroid teleportation: certain scene switches used to cause the flight view camera to focus on a random uncontrolled/unrendezvoused asteroid. Valentina's miraculous space-resistance: she used to have no visible glass in her helmet, while floating in the game menu. Darkness of the Deep: getting below a certain threshold depth in the seas would drop us into complete darkness. I don't have the opportunity at the moment to match the above with footage or version numbers... work is beckoning in only 3.5 hours more and I need to fit in a bit of sleep in there somewhere. But maybe others can fill in for my lapse.