ferram4

Yes, and all of that data is very, very easy to find. The problem is determining the proper geometry to apply it to, and making sure that the model works for everything at every Mach number and most importantly, that it's not impossible to build a working rocket with it. It needs to work for slender rockets, fat rockets, slender planes, wide planes, rovers, flying boxes, space stations, crazy motherships, probes and anything that Whackjob might come up with. I'd go with the USAF Stability and Control DATCOM myself; it's a lot more direct in trying to apply the physics to the shapes rather than using the flow equations directly. It reduces the calculations a lot to do things that way.

Given the way that water currently works in KSP (at least based on my knowledge of it) I don't think that anything can really be done on my end to fix it. Also, fluid interfaces can be really, really nasty to work with, so that's an entire new bit of code to try and handle the switch from atmosphere to ocean. @Imca: Fewer control surfaces. Reduce deflection of all control surfaces. As I've said time and time again (stuff that should come up in this thread if you search for it), SAS is not designed to deal with lots of control authority. It's simply not good as a controller for planes, and it never seemed to be designed for them anyway. If you can't design the plane to work around SAS, you'll have to just not use it.

FAR already does most of what this particular model does at very high speeds, but at a much lower cost to performance. Further, the raycast model would still drop completely bogus values for wings into the physics due to the way that it functions with colliders; wings won't be modeled as very thin flat plates like they should, they'll be modeled as barn doors due to the fact that any raycast that hits the edge of the wing will add a lot more drag to the wing than it should actually get. This model is a lot more flawed than people want to accept; it will never function as a proper aerodynamic model due to its drawbacks. If you try to merge it with another aerodynamic model the raycast model will simply make the combined model less accurate and more expensive to run.

Oh, I'm sure if everything could be pushed to the GPU things could go quite well. (Wow this topic is old; I need to get this old thing back to functioning.) The problem is that as for me, I'm actually GPU limited in KSP more than CPU limited (mobile GPUs are the best!), so I have very little incentive to actually try to make it work on that. Also, given how much CPU power doesn't get used in KSP, it makes more logical sense to work towards CPU-based multithreading than trying to rope the GPU into things (at least from my perspective). But there's still the problem that no matter how much power you throw at it, this particular drag model is highly flawed in that it treats air as a stream of particles that don't interact with each other until the hit and then slide along the vehicle, rather than as air. If a better aerodynamic model were set up using a more-advanced-than-FAR model the problem would inevitably devolve into trying to make the simulation robust and not want to explode in the face of whatever crazy thing a particular player comes up with. And at that point, the calculations you're doing to prevent that will end up slowing things down no matter how good the GPU ends up being.

Supernova already hit my mind, it's just too... bland. I want something that fits its looks and conveys the amount of damage to the space center following the launch, including the transformation of the launchpad into a crater. I'm tempted to just go with Gargantua and call it a day.

Not sure why it would make it weaker in 1.7, but in 2.0 the inertia tensor fix would make any amount of angular motion require much more torque to stop. That would lead to a greater torque being applied to the decoupler than before, and a lot of that torque would also have to be balanced by a force on the end of a moment arm, which is probably what's going on, though I'd have to work out a free body diagram and run the numbers to be sure.

I'd actually like some feedback from you guys here. I need a name for a rocket. Riddle me this: What do you name a rocket that fills the VAB with its boosters and first stage, creates 1.6 GN of thrust at launch, outweighs a Nimitz-class carrier, and lifts 5000 tonnes to orbit?

What I meant was that it sounds like some other plugin-based mod you're using broke and caused the issue; that or you found a bug in the stock game. Since SpaceX doesn't have any plugins in it, that means that it is not the cause of the issue.

It sounds like you've got some kind of engine config conflict going on. The RD-170 makes more thrust than the F-1 does (with better Isp too) at the cost of a lower TWR. Make sure you're using the most up-to-date versions of SFJackBauer's RealEngines and RealFuels and that you don't have the RftS engines in there (or keep RftS engines but get rid of RealEngines; they conflict).

Whoops. Didn't notice you edited the post to include it. After playing around with it (and removing a lot of unnecessary even in stock struts), the issue isn't the TT-70s; it's the extended rockomaxes that they're connected to. Basically, the fact that it's made up of many attached meshes confuses KJR on how strong the connection should be, since KJR thinks the part is much smaller than it actually is; I'm going to have to look into a fix for that. Until then, use pairs of the stock orange tanks and it should be fine. Edit: Wait... I don't think that's the issue. I think the decoupler just gives it too little connection area for the moment arm. Try boosting the decoupler's breakingForce and see if that fixes it. I think I'm going to increase the breakForceMultiplier to 1.5 for KJR 2.1 to see if that helps, since the stock breakForces aren't quite enough once you're dealing with proper inertial tensors.

@NeoMorph: That sounds like a plugin breaking horribly, which shouldn't affect the SpaceX pack. Check out the other plugins you're using to see if there are any reported issues similar to taht and make sure they're all up-to-date. @Galane: The TT-70 is just as strong as the TT-38. The only difference is that it's longer reach gives the mass on the end a greater moment arm to work with. Whatever issues you're having (that I haven't been able to reproduce) I think simply come down to design errors.

@rosenkranz: They'll have the stages enter the atmosphere in exactly the right orientation and will use RCS to keep the things pointed the correct way. The inaccuracy in KSP will end up mostly being due to players not putting the craft in the exact correct stable configuration at first and the initial transient effects will cause enough of an initial deviation that the trajectory will be changed a lot. Especially if the craft's drag changes significantly as it oscillates around the stable orientation. The difference is that SpaceX will set things up so that the stage comes in matching the model as much as possible, fully knowing that the wrong initial conditions will completely invalidate the model, while KSP players don't think in such terms and will instead expect absolute accuracy regardless of what they throw at it. Because they've had that so far with MJ and now they're used to it. @K^2: Yeah, but that's limited by the size of the heat shield, as it should be. It's noticeable (it's needed to make even the mk1 pod stable enough) but it's not enough to make some people's designs stable.

That sounds like something else is forcing the station and your vessel to go on rails and screws up the orbit. KJR doesn't affect when things go on / off rails, it just does things when they come off rails, so it shouldn't be able to cause that issue. Fortunately, since you know that it's something that affects on / off rails behavior that should help you figure out which mod is causing the issue.

Perhaps it's due to some strange plugin-caused thing involving particular parts? If you're using the welding plugin that might be causing some issues as well since that might interfere with disabling collisions; as I understand collisions need to be disabled for each collider and if a part has multiple colliders that could be the issue.

Parts on the same vessel don't have collision enabled. However, if the part breaks off, then all of a sudden collision activates, and the vessel telefrags itself. Basically, it would break either way since the part already has to break off for that to happen; there's not much you can do besides building a better design.

That is due to the fact that FAR prefers to use the surface area of wing parts for calculating Cl / Cd rather than total surface area. The main reason is that planes use the wing area for its Cl and Cd output, so FAR tries to be consistent with that. When you don't have any wing parts attached it has to use some other reference area, and the best choice is total surface area. FAR never uses cross-sectional area except for pre-calculating the aerodynamic properties of parts before converting the numbers over to use surface area. It just works out that accounting for skin friction drag (approx. Cd 0.005) is much easier and cheaper if I use surface area instead. As for trying to calculate aerobraking and landing with FAR, it's never going to be as accurate as people have gotten used to with MJ; unfortunately the simplicity of the stock drag model allows MJ to make very good predictions for that, since the orientation of the vehicle largely doesn't matter, but people have gotten so used to that that they'll forever complain about the inaccuracy of the predictions (especially for the not-so-stable craft).

If you made the heat shield a little more round and less like a flat plate it should help make it more stable. Fins would help, but that's only because FAR doesn't simulate local changes in velocity and dynamic pressure (yet) which in real life would create a pure vacuum behind the heat shield. For that thing, the best solution would be to make it flatter to ensure that it's stable (with a correspondingly larger heat shield) and to give it spin stabilization as well. For that particular one all the fuel and heavy nuke engines at the front should make it stable unless there's something I'm missing.

Laythe can be a little weird, since the speed of sound is slightly lower there (it's simulated as having an atmosphere with lots of CO2 and SO2 from volcanism, which decreases the speed of sound; on the other hand, this pushes up the density a bit). Overall, the aerodynamics are the same, but compressibility effects (supersonic stuff, the speed of sound) will happen at slightly different temperatures and magnitudes. The only place where it's really different is Jool, where a primarily hydrogen atmosphere pushes the speed of sound really high and the density down a lot. Don't go airhogging with FAR. One intake per engine is often more than enough, so don't add more and end up with lots of drag to deal with. Also, make sure to test your spaceplane after fuel drains, since that can mess with the CoM a lot. Vertical landings on atmospheric bodies need to account for the fact that the craft has to be able to change which direction it's stable in; this means separate landing and ascent stages or some type of special aerodynamic sections that are intended to make it stable during reentry. This is ignoring parachutes, since you can deploy those in the upper atmosphere without risking them burning up (assuming DRE) or not doing anything until the vehicle is tumbling (which probably results in it breaking apart). I still have to attempt a sea level landing and return from Eve with FAR; AFAIK, no one has attempted that yet. The dV requirements should be much lower than stock, but trying to land the ascent vehicle will be the real challenge.

Hunh, yeah I guess that makes more sense. I'm just used to FAR being the subject of "it's aerodynamics are crap," and in the context of complaining about aerodynamics with FAR installed that's the first thing I think. OP, sorry if that's the meaning you intended, I'm just defensive about my pet project.

There's a spaceplane that can take you to Laythe included with FAR; it's the Velocitas. I've landed it on Laythe and returned it to Kerbin a few times, though a non-optimal Kerbin return trajectory generally leads to it being torn apart on atmospheric entry. Honestly, it just sounds like you're trying to build vehicles without thinking through the aerodynamics or you're over-relying on MJ (which is far from perfect) to get things done. Oh, and as for FAR's aerodynamics being crap, take it up with the USAF; the aerodynamics are heavily based on the USAF Stability and Control DATCOM, with a few small changes to reduce computational overhead. Basically, it's using the aerodynamic models used for the first pass in designing real life aircraft and missiles. Although I have to admit I've been wondering when the next, "FAR's aerodynamics are crap (read: I don't know what I'm doing so I'll blame the mod)," post / thread would crop up; it's been about a month (by my estimate) since someone ranted about this, which makes it about two weeks overdue.

@Luckfish: I'm gonna say that Nathan's right on this one. There should only be one set of tweakables there, which means that something broke. Be more careful when dealing with mods next time. @Mystique: Things don't necessarily enter pointy-end first; after all, on most manned reentry capsules the pointy end is at the back and it enters blunt-end first. Odds are what's happening is that the nose is too light for how big it is and the back of the vehicle is too heavy. You might benefit from just using a smaller nosecone. @camlost: That's because of the node on the back, and the drag on it is high (just like on all the other engines with nodes on the bottom) to deal with stability issues. Nothing I can do about it unless rockets flipping like crazy again is on the table.

The first deflection setting is for total deflection under standard controls (pitch, yaw, roll) and the second is only for deflection when using flaps or spoilers. So what's happening is you're setting the flap / spoiler setting and it's not having any effect since you don't have the control surface set up as a flap or spoiler (and it doesn't seem like you want to do that). So unfortunately, you're either going to need separate control surfaces if you need different amounts of pitch and roll control or you're going to have to try and find a happy medium with that control surface. Max deflection is for total control and can't be set for each control axis.

That's the stock infiniglider bug; control surfaces produce thrust when deflected. If you flap them around you can achieve any change in velocity you want.

If he adds that wing code everything will act really, really funky. Body lift is a lot less than wing lift and he's basically setting things up so that the cockpit is only capable of being at the back of the plane; besides that the lack of setting nonSideAttach = 1 in that will also cause the CoL to be offset, causing fun rolling issues. If he leaves it set with a stock winglet lift factor FAR will simply ignore it when working out standard body lift / drag, so if he wants it to function properly with FAR that has to go as well. Body lift in stock isn't really a good thing to have anyway since it'll just make things less stable and there's less ability to control how things are set up.

Yes, the gases would reduce the drag a bit, but trying to figure that out is a nightmare since you're dealing with a supersonic jet in subsonic / supersonic flow. Overall, most of the drag that's added there is actually just a kludge fix for the huge weight of stock KSP engines, the fact that rockets tend to become unstable as the fuel drains due to the lack of a need for large series staging and the fact that there's no simple way to make rockets aerodynamically stable by adding a quick little skirt at the bottom that widens a bit. The drag on them is 50 times what it should be at Mach 0 and 20 times what it should be at Mach 1 (and realistically equal to 0 at Mach infinity) to try and deal with the problem, since there's not much that can be done to design around it. The B9 VTOL thing isn't something I can fix though; it probably just makes more sense to get rid of that node. I wasn't aware of the graph texture code causing memory issues. I'll play around with that and see if I can force the assets to be released.