GoSlash27

RIC, The way I see it, the second Kerbin encounter is actually correcting the inefficiency of the first Kerbin encounter. I understand why it would have to be done that way in order to to sync the encounters with the bodies (no sense in boosting for Jool when Jool isn't there yet), but he would've entered the same exact orbit had he left the first Kerbin flyby tangent... right? So in that sense, the second flyby didn't "gain" anything, it just restored what could've been gained in the first pass, but wasn't. Or am I missing something? Best, -Slashy

I've been trying to wrap my head around how this is working, and I'm stumped. My understanding of gravity assists: The most velocity I would expect to see from overrunning a body is exactly the same as when you started (as if it never happened). Anything else gives a radial change and a reduction in total velocity. My understanding is that you have to come in from the front or side to actually see a velocity boost. Paging @OhioBob ... What am I missing here? I can see how if you came in a little crooked and left precisely prograde how you could get a *very* minor boost, but other than that...? Best, -Slashy *edit* Yeah, that's consistent with my understanding. So for a Kerbin/ Kerbin slingshot, I would expect the ship to arrive precisely tangent (because it left precisely tangent), and thus only a velocity reduction is possible. So how are people gaining velocity from a single body in multiple passes?

Bedwyr, You should be able to reduce the spring rate with the slider to eliminate the bouncing. The setting in the tweak is a compromise between hitting the stops in normal use and invoking the kraken. Depending on the load, there may be some leeway there. Other than that, yeah... nothing I can really do about it. The suspension travel of fixed gear (especially the nose gear) is extremely limited, and this requires extremely high spring ratios to keep from crashing the wheel into the strut in normal use. Those high spring rates cause an oscillation frequency that's too high for Unity to track smoothly, and creates a phantom force. I don't know how to render the gear completely indestructible, due to the instantaneous speeds it gets on impact and bouncing. Best I can recommend is to treat the basic gear as too weak for off- roading or impact absorbers. They're okay for airplanes (even out in the boonies), science carts/ trailers... stuff that doesn't need to be rugged. Best, -Slashy Alshain, Yeah, nothing more I can do about that, unfortunately. Make sure you attach the gear using global alignment instead of local. The gear will create some imbalanced forces no matter how they're adjusted, so the best I can do is choose how the imbalanced forces affect the aircraft in the most gentle way, which is veering. Best, -Slashy

eddiew, I'd recommend doing it from low Munar orbit. The Mun can be an analogue for Kerbin and Kerbin an analogue for the sun. It'd take a lot less time and effort. Best, -Slashy

eddiew, Unfortunately, it will give you a velocity change, but not the kind you want. It would *reduce* your speed in the inertial plane, bringing your Pe closer to the sun. Think of it like bouncing a tennis ball off the back of a truck that's moving away from you. If you could get another encounter after that, it would have the opposite effect (like tossing a tennis ball out in front of a truck), but that would only return you to where you started. Unless you pinball off of other planets, you've already got all of the velocity you can get from Kerbin. Best, -Slashy

Or as we called it, the "tree- bucket" A few years back, squirrel launcher videos were all the rage. I got the idea to build the ultimate squirrel launcher (don't worry, no *actual* squirrels were harmed in the process). I designed and (with the aid of a few friends and copious amounts of beer) built the "tree- bucket"; a floating axle trebuchet that used a bucket to fling the critters into a tree down the block. There's a series of videos on Facebook covering the design, assembly, and testing, but no way to share it here. Good times... It ended up being horrifying how far the thing would fling a "squirrel simulant", so we wisely decided to scrap the project. *edit* Here's some really crappy frame stills from one of the videos: http://s52.photobucket.com/user/GoSlash27/slideshow/Tree-%20bucket?sort=9 Here's a video of a floating arm trebuchet in action. Food for thought? Best, -Slashy

Higher spring strength will reduce the suspension travel in response to bumps, but will increase the oscillating frequency of the suspension. If this frequency gets too high, you will experience phantom forces. If spring strength is too low, you will experience suspension bottoming out against the stops, making very erratic behavior. You want to set springs as high as you can without causing the kraken to appear. Dampers are trickier. 0 is completely undamped. .5 is underdamped, the suspension will overswing exactly once in response to a bump. 1 is critically damped. It is the weakest setting that will not experience an excursion in response to a bump. Above 1 is overdamped. It will take longer to return to normal ride height. If your damper is too loose, you will experience excessive body bounce and wallow in response to uneven terrain. You may experience the suspension crashing against the stops. If your damper is too tight, you will experience the wheels bouncing and skittering off the ground in rough terrain. If your dampers are *way* too tight, you will experience "suspension jacking" in rough terrain; the suspension will get lower and lower until it hits the stop and goes rigid because it doesn't have enough time to return to static ride height. Damper adjustments are a balance between keeping the vehicle body stable and keeping the wheels in contact with the surface. I recommend .6 for aircraft and .3 for rovers. Best, -Slashy

Day 3: Houston, we've had a problem. I collected the data on my flyby probes without a hitch and my lander's on track, but the Mun ejected my flyby probes into the downward leg of a 6Mx27Mm orbit. I don't have the DV to get an interface from here and waiting for Ap will take *way* too long. It'd be quicker to send another couple probes. I'm going to have to figure out how to set up a free return trajectory on level 1 tracking. Should be fun... -Slashy

End of speed run, day 2. Day 2: Science workups for first orbit, low space and high. Both remote probes were recovered. I also sent the rover around KSC to collect pressure readings from the KSC biomes. I have 3 probes enroute the Mun. The first 2 are recoverable flyby probes, and the third is a remote transmitting lander. I don't expect to need the lander to fill in the tree, it's just an insurance policy. I feel a little guilty about how I tackled this. It's called "Kerbal Space Program", but I haven't actually put any Kerbals in space... Best, -Slashy

herbal space program, I have a fix for the entry level landing gear here: http://forum.kerbalspaceprogram.com/index.php?/topic/138567-112-basic-landing-gear-fixer/#comment-2550993 Best, -Slashy

MoeslyArmlis, The little one cruises at 4km, and the big one cruises at 9-10km. Both cruise at 200 m/sec. Best, -Slashy

bewing, It might be that 1.1 has changed things, or it could be that your design relies on thrust instead of minimal drag. I really couldn't say without pics. Best, -Slashy

Starting my Caveman challenge for 1.1.2 as a speed run. Here's where I am at the end of the first day: A couple new plane designs that were helpful: Takes off and lands from anywhere. Reaches most biomes. Super low takeoff and landing speeds, but still decently fast cruise. Reaches any spot on the globe. Best, -Slashy

I'd recommend dampers be set to .6 on all occasions. Springs should be max where 2 gear are handling the load and reduced for situations where 4 or more gear are sharing the load. You want to balance between sponginess and the Kraken. Best, -Slashy

Well... Unity5 caught everybody off guard. It's wheel collider system is a dumpster fire. The first iteration was set up to try to mimic the 1.05 gear, but it's really bad at aircraft landing gear and our tendency to use landing gear as wheels aggravated it. The devs missed the kraken bait, which is understandable. When you get wrapped up in tweaking parts, you don't really have a chance to use them as they are used in normal game play. I crutched the parts to deal with the problems in 1.1, but the loose mounting (and a poor choice of design points on my part) made a wheel that wouldn't act as kraken bait under any circumstances, but was way too sloppy to be useful as an airplane landing gear. The devs folded my adjustments into 1.1.1, so you can blame me for that. After that, they added auto- strutting to shore up the mounting points, so I had another go at rebalancing the parts. It was pretty much what you see here, but the 1.1.2 patch came out so quickly that I didn't have time to get it incorporated. So now they're on vacation for 2 weeks. I'll try to get this in 1.1.3 when they come back. This won't be truly sorted out until Unity fixes their wheel system. Best, -Slashy

I'm fully on board the hype train for this.

Entry level planes are tricky now because there's no action group for flaps and spoilers. Clean designs are difficult to force to bleed off airspeed. What I do is run a normal pattern, but then s-turn on final to bleed off any excess energy. With a little practice, I'm able to drop my plane into very tight spots. I occasionally screw it up, but it's usually not the gear that does me in. They're actually pretty forgiving with this adjustment. Try this little puddle jumper. Extremely docile and easy to fly with good rough field capabilities. http://wikisend.com/download/311698/Kondor1.craft

All, I have a new fix for the landing gear in 1.1.2 here: http://forum.kerbalspaceprogram.com/index.php?/topic/138567-112-basic-landing-gear-fixer/#comment-2550993 Best, -Slashy 1.0.5? I don't know what to tell you there. We're several iterations beyond that now. Did you originally have 1.1 and then revert back? If so, perhaps your .cfg files got screwed up. I have copies of the 1.0.5 .cfg files if you need them. Best, -Slashy

Starhawk, Thanks for the kudos, but the original batch of adjustments for 1.1.1 was a terrible kludge IMO. I loosened the suspensions way too much in the process, turning early planes into lumberwagons. Now that we have more rigid mountings, I was able to return to near- 1.0 suspension stiffness without jittering. Best, -Slashy

This is what I've worked out/ learned from debugging the stock parts and researching Unity5 wheel collider. Some of it may be incorrect and some of it is a mystery to me, so please help fill in the gaps! moduleWheelBase radius:(x) the radius of the collider wheel in meters center: (x,y,z) The cartesian offset of the forces imparted to the wheel from the bottom of the wheel in meters. Set by default to 0,0,0; the bottom center of the wheel. mass: (x) I'm not sure about this one, but I believe it's the sprung mass of the suspension before KSP scales it to real life. Increasing this allows you to use higher spring rates without jittering. groundHeightOffset: (x) I'm not sure what this is about, but I think it's the offset between physics enabled ground height vs physics disabled (such as during time warp or gear retraction). I've had no luck so far playing with it. frictionSharpness: I *think* this is how far the grip falls off from peak once maximum cornering is exceeded. Not really sure, though. moduleWheelSuspension: suspensionDistance: (x), meters. the travel distance of the suspension from fully extended to fully compressed. Altering this must be compensated for by suspensionOffset. Small suspension distances will require very high spring ratios, which may lead to skittering and oscillations. suspensionOffset: (x), meters. An adjustment between the visual wheel and collision wheel. Negative raises the visual wheel. targetPosition: (0-1). The amount of compression (0 fully extended, 1 fully compressed) of the suspension *as drawn*. This allows you to adjust where the suspensionDistance lives. Changing this will have to be compensated for with suspensionOffset. springRatio: (x). Units unknown, but I suspect it's the ratio of the spring force in N/m to the mass provided in moduleWheelBase. High spring ratio tightens the suspension and increases the resonant frequency of the spring/mass system. Too high spring ratio causes terrain collisions and skittering, especially when lightly loaded. damperRatio: (0-1) The ratio of drag imparted by the damper to the velocity of displacement. 0 is completely undamped, while 1 is critically damped. Exceeding 1 will cause forces greater than the original displacing force, leading to oscillations and bizarre behavior. I like to use .6. It's just high enough to damp out oscillations, and low enough to allow the spring to absorb impacts smoothly. boostRatio: I dunno, and I'd really like to. This affects the suspension. I've had good luck with simply commenting it out... So... Unity takes all of this info, and figures out a spring rate and damper that will fulfill these requirements. Then KSP takes that and scales it appropriately to the load of the actual vehicle. The end result is that struts and landing gear will ride at the same height regardless of load... but they will not act the same. light loads and tight springs is a recipe for Kraken bait. One other thing. For struts: ModuleWheelDeployment TsubSys (0-1) : when the wheelCollider becomes active during wheel/leg deployment. 0 is start of deploy animation; 1 is end. So that's all I've got at the moment. Please help fill in the gaps and correct anything I've got wrong! Best, -Slashy

Wow, you were in college in '79? In that case, I'll get off your lawn! Best, -Slashy

Sure, here ya go No actual asymmetric drag. Best, -Slashy

The aero overlay appears to show imbalanced drag from the starboard gear, but the "drag" doesn't affect the aircraft, even at high speeds. It's a bug in the display, not the actual physics. Best, -Slashy

Jetski, Aye, but it *does* appear. The arrow appearing on only one side is an optical illusion, not an indication of any actual imbalanced forces. There *is* an imbalanced force when taxiing at high speed, but it's not aerodynamic, it's due to a combination of problems with surface interactions. If it were aerodynamic, you'd see a tendency to yaw and roll-couple right at high speed. Also remember, gear are "physicsless" parts. Their drag manifests at the Cog of their parent part, not the gear themselves. Best, -Slashy

Yes, but the apparent drag is dependent on which angle you look at it from. If you look from forward on the port side, the arrow switches sides. The uneven pull during takeoff is actually due to terrain collision and imperfect placement of the nose gear in the SPH. "Local" reference snap vs. "global". Best, -Slashy