swjr-swis

A bit of roll during ascent doesn't have to be an issue, as long as the rocket keeps following the correct trajectory. In a proper gravity turn, you really shouldn't need to steer at all - at most, just the very initial nudge a few moments after lift off, to initiate the turn. KSP doesn't model weather or wind, so there's no unpredictable forces during ascent that require us to be 'on the stick'. Gravity and aerodynamic forces should keep the rocket on track. A tiny bit of gimbal from the engines and SAS set to follow prograde take care of any corrections. In fact, the less you try to steer manually, the better. It's very hard to be precise in either timing or force, and you end up causing more deviation than you correct. Which then needs more correction, etc etc. All that said, it is annoying when the rocket starts rolling when it's not supposed to. A few common causes: Asymmetry: this should be easy to spot and avoid, just try to keep your rocket symmetrical around its long axis. Joints: generally, try to use the biggest diameter connections available between parts/sections of your rockets. The smaller a joint, the more flexible it is. Any form of steering input can cause the rocket to wobble around a 'bendy' joint, and this wobble can veer the rocket off course. If you can't avoid narrow sections, try adding some struts. Fins: if you use fins at the bottom, and SAS (usually you'll want to), those can be the cause. The current SAS code sometimes does a very regular 'flutter' of control surfaces, small enough that it's only visible when zooming in, but enough to cause an ongoing deviation.... which we experience as a tendency to slowly roll/yaw/pitch in one direction. This is more noticeable in planes than rockets, but it can cause this unwanted roll. Rockets can be flown without fins, so I highly recommend trying to do without them to avoid this issue. If you absolutely need fins to add drag to the bottom, try lowering their control authority to minimize the effect, or use fixed fins. Gimbal: almost all rocket engines have a bit of gimbal capability, often more than is really needed. To a lesser degree than fins, they too can be affected by the SAS flutter, so try to tune them down to lessen the effect.

"Uhm, KSC Coast Guard, this is Duckboat... we are now airborne." . . . "Come again?"

I think it's the cubic octagonal struts, which appear to be abundantly used in these stations. I recreated a similar space station with a 2.5m core and two of the above modules attached by Jr docking ports, and spent a good 15 mins swinging the hinged solar panels and RCS thrusters back and forth, locking and unlocking, enabling and disabling SAS and doing barrel rolls and pirouettes, then undocking the attached vessel and flying it back and forth around the station, docking and undocking and getting some distance away and flying near again. Nothing at all happened. Then on the last flyby, the console suddenly got spammed with the following messages: Warning: BoxColliders does not support negative scale or size. The effective box size has been forced positive and is likely to give unexpected collision geometry. If you absolutely need to use negative scaling you can use the convex MeshCollider. Scene hierarchy path "strutCube/model/cubestrut" And the station got an epileptic seizure and shook itself apart. Station craft file, for error reproduction tests: https://www.dropbox.com/s/kpw31nb76kuaeu0/0test0.craft?dl=0

They did, but not in the way you may expect: what they changed is how much drag kerbals suffer, I think in 1.3.0. Drone planes (or with shielded kerbals) will perform much the same, but any kerbal exposed to airflow will kill much of the performance you knew from 1.2.2 or earlier. I had a blast in 1.0.5 - 1.2.2 with tiny Juno-based planes with EAS-seated kerbals. None of those are very good anymore. https://imgur.com/a/5Yh9e https://imgur.com/a/spp1N https://imgur.com/gallery/hvwwi

Yep that's the struts at work - one of those two separators isn't actually attached. Grab some random part and zoom inside the split tank. You'll see that one of the nodes is still showing the green 'attach here' orb, indicating an unused node. It looks pretty solid and neat. But as far as KSP physics is concerned, it's only attached on one of the sides. On a heavy assembly subjected to lots of drag and thrust, this will be a very asymmetric bendy point, and make the craft very hard to control.

Hmm, it's hard to tell from these angles, but I wonder how you attached the Peryton to the rest. I hope you're not trying to directly stack attach from the dual RAPIERs. Due to how KSP works, only one of them will be actually attached, leaving the other to bend freely. I could see that causing all kinds of problems during ascent! Personally, I'd go for a mirrored booster set for the Peryton. it could still be attached primarily from the aft node on the RAPIERs, further strutted to enhance stability . Or just forget about those RAPIER nodes entirely and use hardpoints/pylons - with the additional issue of having to manage off-axis thrust (gimbals!). Could still work if you want to include the additional orbiter in the same launch, but you'd need to find a different way of attaching that too. If you're really dead set on mounting it on top of a single booster assembly, I'd strongly suggest using one of the open nodes inside the Peryton cargo bay as the attachment point, then offset down to make it visually be in the right place. It'll still be a bit bendy and need some extra strutting, but at least the one joint will be centered on the thrust axis.

Meh... we didn't need that rocket anyway.

Hark! The voices calleth me! Summoning @The Space Man, for old forum fart's sake.

Y'know, when I voluntarily visit a thread about negative things, I'm not waiting for fluffy rainbowey glittery happy positive helpful messages. Get off my lawn, you hippie. <grumble> . . . . <while puttering around in Sketchup>

To answer the original question: On planes I do omit them most of the time. Drag is a prime consideration in most planes, and the excessive ladder drag is simply incompatible. When I do feel a ladder is absolutely required, I actually add them mirrored, to counter the otherwise unbalanced forces causing constant 'phantom' roll or yaw. So even when deemed required, it's a very mindful decision due to the double-drag punishment. On rockets, even though the drag tends to be even worse (they end up facing their biggest surface into the airstream), they tend to be required to make hatches accessible on higher gravity worlds, so I add them anyway. Due to the vertical take off, drag quickly tapers down to where it is of little influence on the gravity turn anyway. Here too though, I am always keenly aware of where I place them, as there is a certain amount of unbalanced forces added to the rocket (more even than its excessive weight, this is one of the reasons I hardly ever use the Mk1-2 command pod - there's no good way to place a continuation ladder without unbalanced force effects). On landers, surface base, or other constructs, since they tend to be shielded during ascent, hatch accessibility is the only real consideration, so ladders are added if required with no second thought. I do this too, for that same reason, although it's often the much less draggy Pegasus I rungs. Also do this on some station modules, for additional or more accessible 'grab-on' area to aim for when returning from EVA. I saw someone else post recently about how structural trusses really should allow grabbing onto and climbing like ladders, which I very much agree with. It would be a better alternative in many situations that now force the addition of ladders parts.

I somehow missed thanking you for those when you first posted them. Belatedly: thank you (and @Hotel26 too, for this reminder). I have been aware, and archived them for later use, together with a whole list of other fixes the stock game still needs and the community has come up with over time. When the announcement comes we've seen the last update to the game, i'll evaluate which of those are still required, and they'll get permanently added to my installs. For now, I'm still stubbornly playing the stock game though, even down to these things. Hence I still mutter about such matters. I guess I still hope they may fix things in the stock game.

Laythe may work nicely, having very similar atmosphere to Kerbin, but Duna (too rare) or Eve (too dense) could be problematic. To have any chance at working on Duna, and for better fuel efficiency on Kerbin/Laythe, giving those wings a bit of AoI will make a big difference. Eve... I think atmosphere pressure and heating, not to mention sheer size, may preclude this from working. Either way, always good to witness the design progression of concepts. Keep us informed!

A small kerballed supersonic plane on a single Juno and with an actual cockpit: https://kerbalx.com/swjr-swis/LT-Supersonic-II 1.68t wet weight, 4400 funds, only 68 science points to spend on the tech tree. Flies 1 kerbal at mach 1.6 @ 11 km using 0.02 LF/s, cruise range upwards of 800km. Lands horizontally, chute for braking (the smallest low tech gear have no brakes of their own). Does it count?

Hint: you only really need a single wheel for a 'rover'. (reaction wheels are awesome)

Why not? Coding such a thing could practically be 'natural', and mathematically/physically... well, we're still not sure of the nature of our universe. It may indeed wrap in on itself, just well beyond our observation horizon. I'm kinda partial to the Asteroids solution.

Considering the forced stock use of autostruts on wheels and anything stack attached under engine plates, and how the game goes haywire the moment they're not used (try attach landing gear on anything past a robotics part, and 'unlock' it)... I think we're long past considering them 'evil'. A necessary evil perhaps, and one people need to learn when (not) to use . At least this Stearwing is teaching people to use 'grandparent' as the target when the craft is meant to dock. But yes, all good points. Some personal preferences are inevitable in the design choices, and we use craft differently too (I use no mods -no autopilots- and use standard keyboard and mouse as inputs), which makes other considerations paramount for each of us. I don't really see that as a problem, rather as an opportunity to learn different ways to get things done. Besides, I feel that if the craft design is such that a few simple tweaks transform it to a different personal preference... I'd say that's a better base to start from as stock example - rather than a craft that requires to be fixed to be used at all. Perhaps two or three of each main category, with an explicit choice to make each included example show a different design solution for key elements? It would showcase the flexibility and potential of the KSP build system, and allow players to explore different schools of design and control. I would suggest a requirement should be to add enough of an explanation/description to highlight the design choices made and the intended usage. We shouldn't just slap something together and hope someone can figure out our thinking on their own. That Stearwing is clearly missing some usage instructions. And I wouldn't expect mine to make it to the list just for being the first entry offered - that's what the community challenge would be for. I'd like to add for consideration: Rover Land and return vehicle (with and without kerbals) Vertical launch/return SSTO At least one shuttle-like A more defined split of aircraft into basic categories of their own: I'd say at least a passenger, a cargo, a science/surveyor plane, and a supersonic plane. A few subassemblies/payloads, which would help players familiarize themselves with modular design, the reuse of modules (eg. 'merge') in VAB/SPH, and the general concept of matching lift vehicle to payload and/or vice versa: eg. a satellite, a transfer stage, an Eve aerobrake/delivery stage Space station Surface base Some craft/assemblies demonstrating ore scanning/mining/refining Somewhat more controversial, I expect, but I really would like to see at least one or two examples of constructs that have no real use case for an aerospace program as such, but which at least show the potential for alternative activities/objectives in this sandbox. A working Rubik's cube... a train... a Mech... a working piston engine. There's been some amazing creations, let's showcase a few and spark people's imaginations.

That may be the answer: it looks almost as if the normal of that face is inverted, tricking the graphics into thinking it's in full sunlight. Interesting find. Did you take a scoop of it to sample if it tastes any less (or more) minty, compared to the unlit surface?

@Stone Blue filed a suggestion to renew/refresh the list of stock craft in KSP in an upcoming update, by means of a community contest. He mentioned that the stock craft always required... well, some work, to get them to actually work well. Which prompted some long-repressed erhm, fond memories of hours and hours spent tweaking stock craft. Result: The Stearwing D45-C, a resurrected and fixed-to-work in KSP v1.3.1+ version of the stock D45 that was dropped from the game since v1.1. Lots of changes and fixes needed, but I tried to stick as much as possible to the original concept and its operating paradigm. And it works! All the way to orbit. I hope others like the idea of adding community(-created or -fixed) craft to stock. Could be a really fun event to fill time until KSP2 hits.

I really like this idea. The list of stock craft can definitely be improved and/or expanded on. The only problem will be, there's potentially so many to choose from! They might need to limit entries by specifying categories with specific requirements, modeled a bit like the forum challenges. Would be nice to see a few really random/outrageous designs too though, so I hope they include for at least a couple 'free-form most impressive/useful/crazy craft' or some such. I would really prefer the stock craft to be functional as is though. I get that one of the underpinning thoughts was to give people something to tinker with, but I think that is better left to the scenarios. This is the same excuse they used to disappear the Stearwing D45. <sob> Why can't we just fix them to work within the latest version? In fact, here's my first entry in that spirit: the Stearwing D45-C, a resurrected Stearwing D45 that has its many... peculiarities, yes let's call it that... fixed and made to work again in the current versions, and perform well at it too. Craft file: https://kerbalx.com/swjr-swis/Stearwing-D45-C And some teasers (full album here):

I'm curious too. So I decided to test the apparently abandoned option (always had a weakness for the underdog ) so we have some comparisson. Just before take off. 540 units of LF in the tanks. Wet weight 9.9t. Flying over the KSC, 49 minutes after take off, after a non-stop full circumnavigation. A little hotter, and 435 units LF lighter.

Oh hell, Roger, it's easy. All you gotta do is tap the brakes a lil' bit, put 'er into a stall, then drop the nose. Tell Elon that Hawk and Frank can tell him all about it over a jar of baby food.

Not sure one can grow any potatoes in that time...

{three four long posts about how to mitigate Steam's brain-dead 'cloud' auto-update process causing issues with KSP, with many elaborate steps] Orrrr.... just don't ever play KSP from the original install location Steam picks if you wish to play with mods *and* keep your sanity. Instead, copy the entire folder to a different location, and run it from there. Steam will never ever, ever, update or change a game that is not running from its configured install folder. You wish to keep a cloud copy of your game to use on other computers? Use an actual cloud service, and add the KSP install folder to it (Dropbox, Google Drive, etc etc). Or better yet, take a few moments to learn how github can do this for you, including keeping a history you can return to. Any of those will actually give you full control on when and how your local copy gets updated, if at all. P.S.: not to minimize @adsii1970's great work to prepare and document this. If for any reason you still want to put your trust in Steam, be sure to follow those instructions.

I saved another smidge of weight (and funds) by sending her up without a jetpack (or a chute, for that matter). The pack adds its own 600 m/s once out of the seat, with full translation and rotation capabilities. That's 2-3 times more than most orbital craft get to do their rendezvous with. But it's 45kg more to get all the way up there, which means I'll have to add at least one extra tank... more parts and weight and cost. Defeats the purpose of that tiny lil thing. She could just suicide burn into the nearest hatch, I guess. She did get up there with 201 m/s to spare. On the other hand, this could be the long sough-after explanation of how so many kerbals get themselves stranded in low orbit. It's not rookies, exactly the opposite: they're trained instructors risking life and limb to provide rookie pilots with training hours doing rendezvous and rescue missions.

I picked up one of my many half-finished projects: creating a minimalistic orbiter that could compete with Whoop_whoop_pull_up's ChairSat S2b on launch cost, weight, and/or part count. Whoop_whoop_pull_up got to this end result after quickly iterating through cost-saving alternatives, ending with an SRB-based lifter and a chair-tank-spider upper stage. Watching the design progress was an entertaining experience. I was left with the question whether this would indeed be the cheapest possible solution, or if it would be possible to shave off any more funds, parts or launch weight. Today I set myself to the task of finding out. The result: the CheapOrbiter1, transfering one kerbal to low Kerbin orbit at the cost of 1.1t, 8 parts, and 1243 funds. Craft file: https://kerbalx.com/swjr-swis/CheapOrbiter1 More pics: https://imgur.com/a/tNxtuVj With thanks to Whoop_whoop_pull_up for the incentive and the design of the tiny upper stage.