Search the Community

URL: https://SpaceDock.info FAQ What we are working on now: We decided to split Spacedocks Frontend and backend. VITAS is working on the frontend (including UI rewrite) Darklight is working on the backend. VITAS is working on an improved cdn setup

Level: Intermediate/Advanced Craft used to illustrate this tutorial: BAK-52NS Version history: 1.2 - Updated with a note on 1.7.3 built-in rotor and propeller blades 1.1 - Updated with better rotors, thanks to a tip from @Hotel26 1.0 - Original version About this tutorial This tutorial is a basic primer on stock helicopters made with parts from the Breaking Ground DLC. It does not discuss pre-Breaking Ground stock rotary motors, nor helicopters made with mod parts. I have limited experience with both and it would expand the scope of the tutorial rather too much. I also do not claim to being the inventor of any of the construction techniques or principles discussed here; a quite a bit I have discovered on my own, and a quite a bit I have picked up around the forums. If you feel you ought to be credited, please say so and I'll add you. What's a helicopter? A helicopter is an aircraft that flies by producing lift from one or more powered rotary wings, or rotors. If the rotor is not powered it is not a helicopter, it is an autogyro; they are also very cool but out of scope of this tutorial. And if the rotor is not used to produce lift but for some other purpose -- thrust, for example -- then it is not a helicopter either. Helicopters can have other forms of propulsion as well: real-life choppers with jet engines bolted on exist and work well. If it's necessary to make the distinction, they are known as compound helicopters. This is a helicopter. It's the BAK-52NS. This variant uses hydraulically sprung and damped landing skids instead of wheels, making precision landings easy...ish. How is it different from an airplane? Airplanes fly by producing lift from airflow around wings. They need to be moving forward to do this and stay in the air. With helicopters, the spinning rotor moves the lifting surface through the air, producing lift. This allows them to hover. However, the big rotating propeller on top of the craft produces a whole set of complications, many of which are shared by kerbal helicopters and human ones; others however are specific to one or the other because kerbal physics aren't quite like real-life physics, and stock kerbals lack certain highly useful bits and pieces used to make human choppers more manageable. On the other hand, kerbals have some amazingly powerful components to build with. Cyclic and Collective Another obvious difference between a plane and a helicopter is how they're controlled. Planes are controlled by moving control surfaces -- rudder, ailerons, elevators, and canards -- which modify the lift produced by each lifting surface, applying forces to the plane and causing it to turn. Pull the stick back, and the control surfaces move to produce more lift near the nose and less lift near the tail, pitching the nose up; push it right, and port control surfaces move to produce more lift while starboard ones produce less, causing the plane to roll to the right. Since helicopters need to be controllable even when they're hovering, they work differently. The primary controls on a chopper are cyclic and collective. Cyclic means adjusting the pitch of the rotor blades differently depending where they are in the cycle of rotation. Imagine that your chopper sits in the middle of a clock face, nose pointing at 12 o'clock. Now, if you want to pitch up, you will want the blades to increase their pitch as they near the 12 o'clock position, and decrease their pitch as they near six o'clock, thereby producing more lift towards the front and less towards the back. You'll also want to adjust cyclic as you start going faster: if your rotor spins counterclockwise, the blades at three o'clock will have a faster airflow over them than the blades at 9 o'clock, because the airflow from your forward motion will get added to the airflow produced by the rotor's rotation. This means you'll want increased pitch around 9 o'clock and decreased pitch around 3 o'clock, or else your craft will roll to the left. This makes helicopters rather hard to fly in real life as well as on Kerbin. What's more, kerbals have no direct control over cyclic: instead, when you adjust the pitch, yaw, or roll, the magic control surfaces try to figure out what you want them to do. This works acceptably with regular aircraft; with helicopters, not so much. So cyclic control on Kerbin is crude at best and you will need partial or total workarounds for this. ~ * ~ UPDATE: FooFighter has built a working swash plate with collective and cyclic control. If you want to make a realistic helicopter that is controlled without reaction wheels, now it's possible! https://kerbalx.com/FooFighter/Swashplate ~ * ~ Collective is a much simpler proposition: it just means the average blade pitch on the rotor. Increase collective and the rotor produces more lift, causing you to gain altitude. Increase it more and your motor will run out of torque to spin the rotor: the RPM will drop and eventually the rotor won't be able to produce any more lift. You'll leap up and then drop down again. Increase it too much, and your rotor will stall, causing you to plummet rather precipitately. And conversely, decrease collective to descend and reduce the torque needed to spin the rotor, allowing it to rotate faster. Collective gives really fine control over hover, and makes a helicopter extremely responsive in vertical motion, comparable in KSP only to a wildly overpowered rocket-powered VTOL. Thankfully, it is possible to make a really nice collective in kerbal helicopters. Perhaps surprisingly, hover on a helicopter isn't actually controlled by throttle. The motor's job is just to keep the rotor spinning; collective and cyclic do the rest. Torque effects In addition to the asymmetrical aerodynamic effects described above, rotorcraft have one more issue to contend with: torque. Spinning up a rotor and, when flying, pushing against the air to produce lift requires torque. Because Sir Isaac Newton is no fun with his laws of motion, this torque will have to get transferred somewhere in an equal but opposing manner. If you don't want your helicopter to spin in the opposite direction of the rotor, you will have to find some way to balance out the torque produced by spinning the rotor. Most real-life helicopters do this with a tail rotor: the helicopter has a pretty long tail which works like a lever arm, and at the tip of the tail is a propeller producing thrust in the opposite direction of the main rotor's torque. The pilot controls the pitch of the tail rotor using yaw controls, and will in fact be continuously adjusting it in different flight conditions (unless he has a computer to do it for him). Sadly, this does not work all that well in KSP. It is possible to make a smallish single-rotor/tail-rotor that is somewhat controllable, but it is hard, it won't be all that easy to fly, and it will very likely require a lot of reaction wheels to paper things over. That's why we're going to discuss a different type of helicopter here: one that flies with twin coaxial contra-rotating rotors. This solution neatly balances out the asymmetrical torque and aerodynamic effects, making for a stable, neutral basis for your craft. By all means attempt to make a conventional main rotor/tail rotor helicopter. Just expect it to be quite hard! This has real-life counterparts as well, notably the Soviet/Russian Kamov Ka-50 and its relatives, and the solution is used there for the same reason it works for kerbals. It makes the craft stabler and easier to fly. By Dmitriy Pichugin - http://www.airliners.net/photo/Russia---Air/Kamov-Ka-50/0920728/L/, GFDL 1.2, https://commons.wikimedia.org/w/index.php?curid=5896037 The coaxial contra-rotating twin rotor powertrain The simplest kerbal rotorcraft powertrain uses a similar solution as in the Ka-50. Kerbals have the advantage of having incredibly powerful, yet compact electric motors that can be placed anywhere, so that's what we're going to do. The powertrain only consists of two parts: at the top a motor (the standard or heavy electric rotor work well for most craft), and below it, a flat servo with its motor disengaged (with no motor at all). The rotor blades attach to the motor above, and the freewheeling servo (or the bottom half of the motor) below. When you spin up the motor, the torque will be evenly split between the two rotors, which will start spinning in opposite directions. Note: this isn't the only way to make a contra-rotating powertrain; you can also use two electric motors surface-mounted to a base, then gizmoed into being coaxial; in this case, each motor will be spinning its own rotor. It has twice the power. For most purposes, the single-motor/freewheel solution is sufficient, however, and has the advantage of being simpler and stabler. Collective Since KSP 1.7.3, Breaking Ground includes propeller and rotor blades as parts. Clip them onto a motor, deploy them, and bind their authority limit to an axis group to control collective (e.g. up/down). Note that they come in clockwise and counterclockwise variants: if building a contra-rotating powertrain, be sure to use mirrored variants for each rotor so that the marking decals point the same way on each, and set the deploy direction on each of them so that adjusting collective up increases pitch on both of them. When building your own rotors (see below), mount an elevon on a servo as pictured above, limit the servo's angle to some relatively sane values, and bind it to an axis group as above. Rotor design The built-in rotor and propeller blades differ greatly in performance from ones made from elevons. They are much more powerful in the lower atmosphere, producing a great deal more thrust/lift. However, their performance drops off much more abruptly and their service ceiling is much lower. A craft powered with a rotor made from elevons can reach 20 km on Kerbin and operate easily on Duna. Therefore, for such special off-world uses, hand-built rotors still have a niche. With rotors, light weight is everything, so use the lightest components available for the job. Your rotor blades should be control surfaces -- FAT-455 for bigger rotors, elevons of various sizes for smaller ones. Here's the best way I know to make a rotor: Place servos onto the motor or the freewheel in radial symmetry. Small ones work most of the time; for very big rotors you might want to use larger sizes. Attach a control surface to the servo and rotate it to the correct orientation. Hold down the shift key and offset it outwards to your desired radius. Set the angle restrictions on the servo. Values of about 12 to about 35 degrees depending on rotor size work for me. If making a bigger rotor, add a second control surface and repeat step 3 for it. Optional: add a strut connector from the servo to the nearest control surface. It won't do anything much but it will make it look better. Copy the entire blade assembly onto your other power element and turn it upside down. Assign servo angle on both sets of servos to up/down, reversing one of them. Important: Disable yaw control on all the control surfaces on your rotor, leaving pitch and roll enabled. Powering it Rotorcraft require electricity to run the powertrain (and also operate collective). Small craft like the BAK-52NS "Kranefly" above could actually run just on a pair of the larger solar panels, or you could bring enough batteries to give you the endurance you want, but the all-around easiest solution is to use fuel cells as above: the golden tank contains enough fuel to fly the Kranefly for probably longer than you have patience, and it only needs a few cells to run. For the heavy rotors you pretty much have to use fuel cells; a pair of large fuel cell arrays is sufficient to power a single heavy electric motor. Controlling it You can set up whatever control scheme you like of course, but I have found the following to work for most things: Action group 1 Toggle fuel cells and engage motor(s) Main throttle[1] Adjust engine torque (you'll want this at maximum most of the time) Up/Down axis Adjust collective (K increases pitch, I decreases pitch -- this places them at the same positions on your right hand as pitch on your left) [1] Since 1.7.2, F/B in 1.7.0-1.7.1 Additionally, brake will apply brake on the motor driving the rotor. Because you have a freewheel between the rotors and the craft's body, this means you can stop the rotor very quickly by disengaging the motor (action group 1) and hitting the brakes -- both rotors will stop with the torque canceled out between them. The magic of reaction wheels Kerbals may not have cyclic but by the Kraken's tentacles they have reaction wheels. You can paper over minor misbehaviours in the craft by adding some reaction wheels... sometimes quite a lot really. Don't feel bad, it's a kerbal solution. Tuning it The powertrain described above is fairly docile and you can stick it on top of the centre of mass of pretty much any craft light enough for it to lift, and it will fly and hover. Getting it to fly well is a different kettle of fish altogether. If there is a science to tuning kerbal rotorcraft I haven't discovered it -- all of my tuning has been through trial and error. I suspect the unpredictability is due to the way KSP translates control inputs into control surface positions on the rotor, which is a bit on the flaky side: Change the number of rotor blades. I've had good results with rotors from 2 to 6 blades. More blades require more power but run smoother. Adjust blade length. Larger rotors are more efficient but less stable unless you feed them with more power. Move rotor forward/aft. Moving it forward and back changes the craft's tendency to pitch forward or back as you increase/decrease collective; it also changes its sensitivity to roll and yaw controls although I have no idea exactly why and how. Even tiny adjustments can make massive differences; less than a "click" of snap-to motion can completely change the handling characteristics of a chopper. I suspect this is due to the way the rotor blades respond to your control inputs. Move rotor up/down. Up tends to make the chopper more stable but less responsive to control inputs, down does the opposite. It's quite possible to make a really numb chopper that only goes up and down and barely even responds to pitch, roll, or yaw controls! Tilt rotor forward. It does something so it's worth a try. Adjust control authority. Less authority means less judder but less control; more does the opposite (and might cause blade stalls which is no fun at all). Adjust the craft's centre of mass. Generally speaking you will want a high centre of mass, close to the rotor: this is why the fuel tank is right below the powertrain in the BAK-52 above. Add or remove reaction wheels. Tip: Tune with SAS off. You might find that your chopper flies rather pleasantly without it in fact! Flying it To fly a helicopter, spin up the rotors with collective at zero, engines at maximum torque. Then increase collective until it takes off. Pitch to accelerate, slow down, or fly backwards; roll to fly sideways, yaw to spin around. When you're moving forward at a decent pace airplane-like aerodynamics start to enter the picture which is fun and different. Developing it further The basic Ka-50 style craft plan is just one possibility among many. Once you've got the power train figured out, you can make bigger ones and smaller ones, choppers powered by more than one set of rotors in a variety of configurations, tilt rotors with heavy servos making for an Osprey-style VTOL craft, and so on. You can stick on a jet or two just below the rotor assembly to make it go faster -- making fast choppers is a completely different and much harder challenge than making fast planes, since the limiting factor is stability rather than thrust to weight ratio; you will need to design rather different rotors for choppers that go very fast. You can also attempt different solutions altogether, like with non-coaxial contra-rotating rotors, or even attempting a main rotor/tail rotor style craft. There's a lot of room for tuning in rotor design as well, and if you feel the stock electrics don't quite produce the oomph you want, research turboprops and start breaking records (ht: @Azimech). You might have to get creative to find a practical use for helicopters in career missions but they are a lot of fun to build and, eventually, to fly. There are at least two helipads on the KSC just begging to be used, so go out and use them!

(WIP image) Shuttle Orbiter Construction Kit Today, being Yuri's Night and the anniversary of the first orbital mission of the Space Shuttle program, STS-1, felt like a good time to reveal what I've been working on lately: a pack of parts designed to replicate the US Space Shuttle Orbiter in a stockalike style. The stock mk3 parts, while excellent, are off in a number of ways in terms of proportions and performance when compared to the real space shuttle orbiters, and building a working space shuttle can be quite a challenge due to aerodynamics, thrust balance and a host of different reasons. This mod aims to do the following: Shuttle Orbiter System scaled to Kerbal sizes in a stockalike/restock-alike art style Payload bay sized for 2.5m payloads Performance appropriate for a shuttle in a 2.5x game (many mods, including reDIRECT and BDB, follow this principle) Easy construction with snap-together parts (all node-attached, no fiddling with surface attachment) Launcher agnostic (i.e. you can use parts from a number of mods or from stock in order to build the launch stack) Easy to fly with sensible aerodynamic properties Fully interactive, immersive IVA powered by 3rd party mods Low part count both in terms of editor clutter and in flight. Mirrored parts (such as wings) will be handled using mesh/texture switching Integration with reDIRECT launch vehicle parts (this will involve texture tweaks to the reDIRECT parts to bring them up to standard) So far, the shuttle is reasonably far along in texturing, but very far form functional in game. Many parts, such as landing gear, are not implemented at all yet, and others have very rudimentary textures or lack colliders, aerodynamics. This is by no means going to be an easy or quick task, so I wouldn't expect a release any time soon. To celebrate the anniversary of Columbia's first flight, please enjoy some of the screenshots below featuring a heavily WIP orbiter and parts from my reDIRECT mod. The shuttle features 15 switchable name slots, six based on the real flight-worthy orbiters, four based on test articles and mockups produced for the program, and five slots for custom names added by the user. In terms of size, the shuttle cockpit works out at slightly smaller but longer than the mk3 pod, and payload bay is longer but smaller in diameter. Happy to answer any questions you may have and take suggestions!

I've been watching a lot of Isaac Arthur's videos recently, and the man is absolutely obsessed with mega structures. O'neil cylinders, Launch Loops, Orbital Rings, Orbital Mirrors, the list goes on and on, and I wondered, what would it take to build these kinds of structures in KSP? Using both Extraplanetary Launchpads and USI Kolinization, there's practically no limit to the sort of stuff you can build, since you're not limited to having to launch stuff into orbit. However, constructing things in orbit takes Material Kits and Specialized Parts, both resources added by USI, and to build a mega structure you'd need a LOT of Material Kits. So how do you get all those material kits into orbit without having to make hundreds of landings with massive resource transporting ships? The answer, I thought, was a space elevator. But the question remains, is building a space elevator possible? Well, the answer is yes and no. When trying to research KSP space elevators I only found two examples of people successfully building one. The first was the one built by SWDennis, a man known for building ridiculously large objects in KSP. His space elevator appeared to be built using Kerbal Konstructs, rather than the elevator being an actual part. However, his design has an actual functioning crawler, or at least it functions until about 90 or so kilometers up, before clipping through the elevator. While this design was cool, it wasn’t really what I was looking for. The second example was by a guy called Tekist, who actually built a fully sized elevator going up to kerbin stationary orbit, and this one was a part too. Using both ubio part welder and tweak scale, he managed to build a tower 2924km high, and even launch a craft from the top! However, when he did the craft had a velocity of 0m/s and couldn’t activate its engine, so the craft wasn’t put into orbit like it should have been, were it a real space elevator. At first I thought this was definitive proof that a space elevator just wouldn’t work, at least not as intended, but something in the description of Tekist’s video caught my eye. “The tower is still affected by KSP's physics engine, resulting in it being very buggy because the engine isn't designed to handle such massive objects. This prevents a geosynchronous tower from being useful in any way. However, the low-Kerbin orbit tower is able to launch payloads.” So perhaps, the reason his elevator wasn’t working was because it was too high. But how high is too high? I decided I had to find out, and so I set out to build my own space elevator. The Goal My goal was this. If I could build a fully functional space elevator, I could dock a freighter to the top of it, and use USI’s planetary logistics system to fill that freighter with cargo, and then send it on its way. This way would mean I wouldn’t have to build a bunch of smaller ships capable of ferrying resources for the surface to orbit. When all was said and done, I wanted a planetary wide industry capable of producing 1 billion material kits a day, and I wanted to be able to transport those 1 billion material kits into orbit, again, every single day. It was a tall order for sure, but if I was able to build a fully functional space elevator, it would be as easy as just transferring the resources via tac fuel balancer. Issue #1: Height So if 2924km is too high, then where can we build a space elevator that’s shorter? Now in the Kerbol system, the answer would be Minmus. Synchronus orbit above Minmus is only 357km, meaning the elevator would only have to be that high. However, from the get go my plan was to build this elevator the legit method in a Real Solar System play through, so the question then became: what body in the solar system could we build the shortest space elevator? The answer, as far as I can tell, is Ceres, with the elevator only having to be 706km high, double that of the hypothetical Minmus space elevator. Issue #2: Physics Range A lot of people will tell you that space elevators are impossible because the physics range only extends 2.5km, so if you were at the top the object would just unload. This actually has the simplest solution, just using the Physics Range Extender mod. Since the elevator I planned on building was 706km, I decided to extend the range to 710km. Issue #3: Wobble This definitely ended up being the hardest thing to get around, as sometimes things would work while other times they wouldn’t. The obvious issue here is that loading in a 706km long object causes the game to freak out. It begins to wobble all over the place and eventually ends up spinning out of control. My solution to this was found within the USI mod. In that mod there is a module called the “Inertial Dampener” or ground tether. When activated, it fixes an object into place in relation to the ground. This would, in theory, keep the elevator stationary, as it should be. Construction My concept was to build an object with three parts: the base, the shaft, and the top. The base and the top were relatively easy, but the shaft proved difficult. In order to get the proper dimensions, I had to weld together a part that was 0.5m wide and 3530m tall. This took a lot of finagling in the space plane hanger but I managed. Then, I would have to use tweak scale to increase it to 200x its size, making the shaft 100m across and 706km long. I increased the size of both the top and base so that it would fit as well, and before I knew it I had my space elevator. It’s 1km across and 706km high, weighing in at 482 million tons. To build it with Extraplanetary launchpads it would cost 385 billion material kits, and in terms of funds, it costs 2.7 QUADRILLION. Truly an unholy beast of a craft, and the game absolutely did not like it existing. While sometimes the wobble wasn’t too bad, giving me time to activate the ground tether, other times physics would grab the thing by the neck and try to choke it to death. However, eventually I was able to toggle the ground tether and make the thing stationary. Then the question became this: if I uncouple something from the top of this thing, what will happen? Testing This was where things started to get messy. I placed a decoupler with a pod on it at the very top of the elevator and planned to decouple it after tethering the elevator, in a similar way to how Tekist did, to see if the physics engine would glitch out the same way. However I never got that far in testing. The moment the craft loaded in the wobbling became UNBEARABLE. It was so bad I couldn’t even click on the vessel to activate the tether because the camera was freaking out so much. When I uncoupled the pod without the ground tether being activate, it was flung off into space at three times the speed of light. This was incredibly disheartening, however I didn’t give up. After a few more tries using different techniques (this time I actually decided to extend the physics range), well it still didn’t work but something interesting happened. After the elevator loaded up the intense forces of the wobbling elevator broke the connection to the pod and flung it off into space, however instead of being flung at super luminal speeds, it ended up in a sub orbital trajectory. This, I thought, was very promising. It could mean that the game was actually properly calculating the orbital speed of the vessel, or perhaps the speed was being generated entirely by the flinging. I had to find out. So I decided to change my approach. Instead of putting something on the top of the elevator and uncoupling it, I would load in the regular elevator and tether it to the ground, build a ship with a grabber claw on it, fly it all the way to the top, and forcefully dock with it. Then, I would undock to see what would happen. I built something small, turned on infinite fuel, and began to fly up. It took me about three days to get to this point, and I was incredibly excited. The elevator was stable, stationary, and as I flew up it continued to stay that way. I knew by using the camera tools mod that the top of the elevator did in fact exist, although it did flicker quite a bit, so I knew there was actually something to get to. My only worry at this point was that at that distance the physics engine would break down and the ship would phase right through the shaft. Still I had to try. Then, at around 150-200km up, the elevator disappeared. I was dumbfounded. It didn’t make any sense. The physics range extender was working just fine. I went back to the tracking station and indeed, the elevator was still there. I switched back to the elevator, then switched back to the ship, and then bam, it was gone again. It was only after using cameratools to inspect the surface that I figured out what was going on. The ground itself was disappearing after a certain distance, and because the elevators base was tethered to it, the elevator disappeared along with it. And that was it, definitive proof that a fully practical space elevator in KSP is impossible, something that still bothers because it appears to directly contradict with Tekist’s video, where his elevator stayed rendered after undocking from it. How he managed this, and how he managed to build an elevator without wobble in the first place, I may never know. Faux Practical Okay, so the elevator can’t be docked with, that point I’ve conceded. However, just because it can’t be fully practical, doesn’t mean it can’t be faux practical. Essentially, all I need is a device capable of getting things into orbit on the cheap, and USI’s orbital logistics module gives me some room for that possibility. The plan now became to lower the physics range back down to normal, then build a space station directly above the elevator in the orbit it would supposed to be in. This way, I could use USI orbital logistics to transport resources to that space station, then have ships dock with that station to retrieve resources from it. I could even have a shaft extend 10km down from the station to make it look somewhat more realistic. Now the orbital logistics module requires the use of transport credits in order to make a transfer, but I could just use cheats to give the elevator an absurd amount of transport credits. So I attempted to put this theory into practice, and again, ran into a problem. Remember that my goal was to be able to put 1 billion material kits into orbit every day. Well, using USI’s orbital logistics, even with infinite transport credits, it would take four YEARS to get 1 billion Material Kits into orbit. I wasn’t able to find any setting in the mod to be able to edit this amount of time, not even in my save file. Or at least that was what I thought until just this very moment. Turns out you absolutely can edit the amount of time it takes for a transfer, which means I can turn those 4 years into 1 second. So, in short, I now have a totally practical space elevator, capable of transporting millions of tons into orbit for free. It took a lot of cheating and mods, but still, it can be done. The end result A few things. First, in order for maximum stability, I turned the shaft into a physicsless object. This means when you load in the elevator the camera will jump down to the base. However, this also causes the base of the elevator to jitter, even when tethered to the ground. I found the only way to prevent this was to load up another craft on the Launchpad. Then, for whatever reason, the elevator becomes completely stable and stationary. What you’re left with is a really cool looking thing that kind of, sort of does what a space elevator is meant to do, hence the answer to whether you can build a space elevator in KSP being both yes and no. Keep in mind this was made for Ceres in RSS, but I never actually tested it there, as this whole affair had already become enough of a pain. So maybe this thing wouldn’t even work on Ceres, who knows. Maybe a shorter one built for Minmus would work better. All questions I am not currently prepared to answer. I’m just glad I was able to build something cool. By the way, in case you couldn’t tell the elevators base was based on this artwork. Anyway, if you have any questions or want the craft file and save file, let me know, but really the main point of this was to put my findings out there on building a functional space elevator, so that some other poor sap won’t have to go through the same trials and tribulations I did. So is it possible to build a space elevator in KSP? Yes, absolutely.

I think I finally got this working reasonably well. There are some odd bugs. If you timewarp, the program rearranges his eyeballs, and for some reason the mouth is positioned properly in the SPH but a bit off when loading. Oh, well.. minor stuff. Despite the fact I actually am not at all a fan of Twitter, it was still quite cool to have the KSP folk post both this and my Milo plane. Thanks for the support you all! The frog is up on KerbalX here: https://kerbalx.com/Klapaucius/Aristophanes-the-Frog