ferram4

The Mun visibility issue Visari was talking about is caused by the game shifting from the scaled space model of the Mun (which looks very rocky and uneven) to the PQS terrain Mun (which has been changed to be a lot flatter). Basically, rocky Mun fades away and is replaced by perfectly spherical gray blob. Solutions I can think of are either trying to rebuild the scaled space model from PQS (if that is even what's done) or scale up the Mun PQS height values so that the hills have the same scale with respect to the radius. Re: wobble plugin: I have a simple version working, similar to the old KIS Connect that essentially makes all the parts flex as if they were automatically connected with struts, but I'm not satisfied with this. It looks like the main source of the problem is the physics dT value and the number of solver iterations used; decreasing dT and increasing the iterations should fix the issue, but that will make lagging worse. I'll continue working on it and see what can be done.

@Spanier: If you mean that the wings flex on the plane under control inputs, then that is actually to be expected (most planes are designed with this in mind, even if it isn't desired behavior); if you really want to fight it, use struts. If you mean that the plane pitches up / down with roll inputs, that actually might make sense. I'd guess that it tends to pitch down; when control surfaces deflect, the wing makes more / left lift, causing it to make more / less drag. Since the wings are below the CoM of the plane, more drag would cause it to pitch down. @Ciber: Quicksave, try a path, quickload if unsatisfied. Honestly, you wouldn't be happy with any aerobraking calculator for this mod; the resulting orbit is so dependent on slight changes to the orientation and path taken that your resulting orbit would always be very far off of the predicted path. You'd find that the calculator would be less useful than learning from experience and making an educated guess. @smarkey: Aware of it, looking into a fix. Thanks for the log and config files (most people don't remember to upload those), but for other reports would you be kind enough to upload the output_log.txt in the KSP_Data folder rather than KSP.log? The output log includes stack traces for exceptions, which are useful for finding where an issue starts.

I would advise KW Rocketry or Procedural Fairings.

@Razorcane: Ummm... no. I don't have HyperEdit installed. This is a bug report for this plugin that moves the Mun to the appropriate orbit but doesn't update the period. @NathanKell: Nothing updates orbit.period in the current source... the rotation period is set to equal orbit.period if the body is tidally locked, but unless the current source on github / what's included in the zip isn't up-to-date then there's nothing that modifies the orbital period.

Wing pieces that don't have FAR modules defined will behave exactly as they do in stock. This means that lift will be proportional to velocity, rather than velocity squared (so don't trust them to keep your vehicle pointed the right way). The CoL indicator is calculated differently for the stock wing pieces than for FAR wing pieces, so combining them on a rocket or plane will make the CoL indicator absolutely worthless.

Bug report, and an interesting one: It looks like the manual orbit changes you've done don't automatically cause the orbital period to update. This means that the Mun's orbital period is still a little over a day rather than the ~27 days it should be; this is quite noticeable when on a transfer orbit, where the Mun completes multiple orbits when it should not. The reported orbital velocity numbers are wrong, it's moving much faster.

I've noticed that part wobble is only truly bad for very large parts; I've never had a 1.25m diameter rocket break on the pad with this. I'm thinking that I might have a go at making a plugin to fix the joints between parts so they behave more realistic / sane and see if that helps. I've looked into trying to get Kerbin tilted, but no success on my end.

@Miller: If the pod gets too far off of retrograde it will flip around due to the way that drag is worked out on it. Another possibility is that a lot of stuff is attached to the top of the pod, shifting the CoM further back and making it less stable in a traditional reentry configuration. @Barb0: Struts. Lots of struts, like Softweir said. The same problem occurs if you create any large-span wing and look at where it attaches to the fuselage.

@Surefoot: Composite wings will be treated as essentially one wing. The method isn't perfect, but it is close. Leading edge slats / flaps are accounted for. No, those aren't the types of nodes I was talking about. I don't know of any wing part that includes the teal sphere stack node on it. And anyway, the wing aero model doesn't account for those at all. I don't model flow separation at transonic speeds (mostly because the wing model isn't sophisticated enough to handle it), but I do shift the CoL forward a bit at those speeds. Reentry effects aren't changed by FAR and are just pretty effects, just like in stock. @softweir: I've looked at not dumping things to the log, and that seems to make things a lot smoother.

Put a link to the source and dll in the first post for everyone's convenience. It'll certainly help anyone interested in getting into it initially since they won't have to search as much. I don't know what could be messing with the barometer or the chutes, since all FAR does is grab "vessel.atmDensity" for density. I know that there are AtmosphereFromGround and AtmosphereFromSpace classes that might have something to do with the atmospheric stuff, but trying to get an array of all of them results in an empty array. There might be some use in looking at the ones under "SGT_[...]" which might get used.

Playing around with things more, I've discovered some... interesting things. The orbital period of orbital bodies needs to be set manually. The Mun was at the Moon's orbital distance but was completing an orbit in one day rather than ~27 days. The Mun's scaled space representation wasn't set. Further, trying to adapt the scaling used for Kerbin didn't work; I settled for multiplying the current scaling by the ratio of Moon radius / Mun radius, which worked out. The scaled space representation is based on something other than the standard PQS. This means that when coming in close to the Mun you see it fade from a somewhat a-spherical scaled space version to the much more spherical rescaled PQS. We may need to maintain a constant ratio between body radius and the heights on the PQS to make things look proper. I think the twitchiness on the pad is due to the launch clamps. I'll look into designing rockets that don't need the clamps to launch / building effective clamps using parts and see if that changes things. We might need to recode those to make it work. In rare occasions, parachutes will open fully within 100m of the ocean. Never seen it happen on land though.

@NathanKell: The current source doesn't have any changes to the SOIs, which puts the Mun's SOI within a few kilometers of the surface and the Mun's orbit outside Kerbin's SOI. If we're gonna use real-life values, Kerbin's should be 925,000 km, while the Mun's should be 66,100 km. For reference, it can be calculated from this: rSOI = a * (m / M)2/5 rSOI: SOI radius from planet center a: semi-major axis of body's orbit m: mass of body M: mass of the body that is being orbited; for Kerbin this is the Sun, for the Mun it is Kerbin As for what you were saying, I don't see why we can't do that. I've also been thinking about hijacking the stock aero effects the way that Deadly Reentry does so that things look a bit better. I have to admit that it certainly looks better coming down from a real-life-sized orbit. @Dragon01: Well, if we're all running FAR with this, there's no reason I can't scale up the surface areas. All that would need is a scalar after I calculate the surface areas from the model.

@Suzie's Brother Max: The current changelog is in the readme included with the download. Here's a non-exhaustive list of things modeled in FAR right now; most of this is using approximations rather than exact solutions since the latter would be painful for the processor: Wings Effects of aspect ratio, taper ratio, wing sweep, camber (not intrinsic to any piece; must camber wing with multiple wing pieces placed at angles), and flaps accounted for. Subsonic flow based off Prandtl lifting line theory, with stall above a given angle of attack. Supersonic flow based off a combination of linear approximations for wings and shock-expansion theory for airfoils (using 10% thick diamond airfoils). Transonic flow approximated as a smooth blending of the above. Drag is a combination of the induced and wave drag factors predicted by the above, along with a simple approximation to account for transonic wave drag and a constant base friction drag. Bodies Effects of taper ratio and fineness ratio are considered. Sudden changes in cross-sectional area produce more pressure drag. All flow regimes are approximated using simple potential and viscous flow calculations. Extra drag added for unused attach nodes, which indicate a very un-aerodynamic surface exposed to the airflow; nodes facing the flow are assumed to have a stagnation pressure coefficient across the entire surface while nodes facing away from the flow are assumed to have half of the minimum pressure coefficient in that flow. Most of the above stuff is based off of the 1965 Stability DATCOM that I managed to get my hands on. Not all of it is completely exact, but it does seem to provide a decent flight model. Other stuff [*]Payload fairings and cargo bays will properly detect parts inside them and shield them from the airflow, making them useful for decreasing drag. Hope that was helpful! @Taverius: Hmm... I'll look into that then.

I don't have RemoteTech installed, so I don't know what it could be. BreakingForce and BreakingTorque do seem to have some effects if they are set high enough. I wish there were a way to set the springiness of the joints independently of the joint strength, since that is really what we need.

I actually think a slightly more critical thing might be a plugin that locks all the part joints or makes all of them stronger; I've had a lot of rockets explode on the pad due to physics starting up. Even if the final version doesn't include something like that it might be useful just for testing purposes. Also, I too have suffered the "parachutes visually deploy but don't do anything bug." It killed Jebediah. This thing is totally awesome.

Then copy the current core and set them as a pair of boosters and use a smaller engine for the new core. We might need to try making the VAB bigger too... oops.

@asmi: Make the central core a little taller and use the same engine type to make a pair of liquid boosters that are half as tall as your current core stage is. No fuel cross feed. That should provide enough dV for you to get there. I must try this myself.

It could be the debug log, which is somewhat resource intensive. It could also be all of the calculations necessary to figure out the aerodynamic properties of the vehicle. I can try things on my end and see if I can make things better.

No, I meant keep the scale height where it is at 7.5km, but set the maxAtmosphereAltitude to ~135km. What you're doing keeps the same issue I was trying to solve, but causes it at a higher altitude. Also, the proper average radius is 6371km, not 6137km; minor, but important detail.

Okay, version 0.9.7 is out, fixing the roll control surface silliness, some non-wing drag issues, and fixing some issues where mod parts would not have their proper orientations determined (thanks to a.g. for that one). @NWM: Any craft created in a save with FAR will be properly loaded in a stock save, using the proper stock behavior. Or do you mean a switch to turn FAR on and off at will in a save?

Thinking about it more, I'd actually advise making the atmosphere taller than 105km; here's why: We should set the cutoff so that dynamic pressure (0.5f * air_density * velocity2) is about the same between stock Kerbin and real Kerbin. Dynamic pressure at the top of stock Kerbin's atmosphere (at orbital velocities) tends to be ~2-5 Pa. At the top of this atmosphere, assuming a circular orbit, we get a velocity of 7.836 km/s. Converting to rotating frame: sidereal day: 86164s angular rate: 1.1606 1/s velocity of the frame at the top of the atmosphere: 0.0751 km/s So we're looking at a velocity in atmosphere of ~7.761 km/s Air density at 105km: 1.0186 * 10-6 kg/m3 Dyn pressure = 30.677 Pa This means that the aerodynamic forces are about ten times as high for this Kerbin's atmospheric cutoff than for the stock Kerbin atmospheric cutoff. Looking at the math for it, rather than having the cutoff at 14 scale heights (105km), increasing it to 17-18 scale heights (127.5km - 135km) will set the cutoff dynamic pressure slightly below what is experienced in stock KSP. It would also make going into the atmosphere a lot less abrupt in terms of forces applied.

@a.g.: To figure it out properly you'd need to integrate along the launch profile to figure out the total dV, accounting for changes in Isp due to air pressure changes and adjust the atm and vac multipliers until the proper dV numbers come out. I would guess that the proper numbers in your example would be closer to 0.9 vac, 0.55 atm, but that's just me making an educated guess. To be honest, I figured out the atmo-only preset using the method of "Launch a Kerbal X with the universal preset; then launch another one with the atmo-only preset; adjust the atmo-only preset until they had the same fuel in the same orbit." Very ad hoc, but it worked fairly well. The thrust scaling feature should probably make using the atmo-only preset silly; consider that any atm-rated engines would produce a ton of thrust in vacuum, while vac-rated engines would make no thrust in atmo. Probably not a good idea to use both. @Camacha: Consider that the real-life Soyuz rocket burns ~95% of its mass to put its payload into orbit, which is very similar to what had to be done on my mission. If the separate orbital module with the hitchhiker, docking port, lights, batteries and adapters were removed the payload would have been reduced enough that a decent chunk of the launch vehicle would become superfluous, I think. The "adjusted" settings are designed to try and account for the higher dry masses of fuel tanks and the larger masses of engines.

A proper way to penalize asparagus staging in KSP, though one that would probably be somewhat complicated to model, would be to conserve the momentum of the fuel as it drains. As the fuel drains counterclockwise out of each liquid booster, the rocket will pick up clockwise spin to conserve momentum in the system. Then the primary issue with an asparagus monster isn't drag (though it is a fairly big factor), but the fact that your rocket is spinning like mad as you try to pilot it into orbit; this would make gravity turns particularly nasty, since it could lead to the rocket's roll combining with the pitch-over movement to send it off course. Of course, this is one of the larger problems in real life.

I think sending Minmus to Duna won't really make sense, particularly since this is a different solar system. It's not too difficult to justify bringing all the planets up to realistic sizes, but I do think it might be difficult to justify making Kerbin into "Earth-but-doesn't-look-like-Earth" and Duna into "Mars-but-doesn't-look-like-Mars." I'd just cut the knot with the angular velocity / rotational period problem and set both at the same time; it certainly avoids the worst-case-scenario of strange things happening because the two aren't consistent and there are no sanity checks between them.

I am terrified and intrigued. The only other thing that needs to be done for the planet scaling is to have the atmosphere's scale height increased to 7.5km from the current 5km and have it end ~100km - 120km up. How does the terrain look after this mess? Also, a rotational period of 23hr, 56min and 4.1s, so that you have a proper sidereal day. I guess KIDS will get two uses: making things harder for people who don't want realistic-sized planets (and any issues with those) and those who need an easing-in type of plugin for getting used to realistic-sized planets.