[1.3.1] Ferram Aerospace Research: v0.15.9.1 "Liepmann" 4/2/18

[Frederf]

You use less dV because you've got all the dV you spend in stock overcoming drag losses back all of a sudden ( which is realistic - Earth rockets lose 1-200 generally, I think Saturn V losses were about 40m/s ), there's nothing else going on. Parts are tuned for stock aero, mebbe we need FAR nerfs for rocket engines like the jets have been.

Wow really? I had no idea. That's miniscule. No wonder they wanted maximum TWRs.

[Weatherman159]

I don't think it's feasible for Squad to add anything like FAR to the stock game. All the people who fly bricks to space would go nuts, and that's a good percentage of players.

[nhnifong]

I don't think it's feasible for Squad to add anything like FAR to the stock game. All the people who fly bricks to space would go nuts, and that's a good percentage of players.

Fairings FTW! Streamline coalition unite!

[taniwha]

Weatherman159: actually, it's still possible to get bricks into space using FAR, and still for less delta-v than stock. It's just a little more challenging because you need more fins.

[ferram4]

@wased89: If the drag is being influenced by mass, then FAR isn't installed properly. With FAR installed, drag will be completely independent of the actual mass of the vehicle and will only be dependent on the vehicle geometry.

@GrizzlyJones: I don't believe that it would be possible to set up the control surface assignment code with the stock aerodynamics. I'd have to either try to extend the ControlSurface class to replace the stock control input algorithm with mine or I would have to rebuild the class completely and try to recode whatever wonky algorithm they're using for lift. Honestly, neither of those options are very appealing to me, particularly because I wouldn't make any use of the code myself.

@NathanKell: I guess I can add that to the next release... I'll see what I can do.

@Weatherman159: People complained when liquid engines got nerfed during the initial introduction of part modules; they originally got something like 500 Isp regardless of atmospheric pressure. Now no one complains about the ~350 Isp engines. People will complain when reentry heat is added, because they won't be able to be as careless with aerobraking and reentry as they are now. They will complain when life support requirements are added. They will complain when maximum g-forces for Kerbals and (possibly) parts are added. They will complain about the inevitable change in the fuel required for the NTR, when they won't be able to run it off of the same fuel mixture as a mainsail. They will complain when intakes are recoded so that intake spamming can't be done anymore. Just as they will complain about these changes, they will complain about the addition of proper aerodynamics.

All of these complaints will stem from one place: the introduction of constraints. KSP is a sandbox, and as players, we don't like feeling like we're being told what to do in our sandbox and the introduction of a new constraint feels like that. Of course, no one complains about the already existing constraints; we're barely aware they exist. We easily forget that the game already places constraints on what we can do through the behavior of gravity, the existence of atmospheres, where parts are spawned and how the physics simulation runs. Within a week after those new features are added the complaints will stop as the focus turns to designing a way around the problem, just as we do now. People will adapt and learning to design aerodynamic rockets will be part of the things that a player must learn, just as they must learn how to design staging properly, how to reinforce their rockets with struts, how to keep their vehicle powered in space and orbital maneuvers. And then, in the next update or so, people will look back fondly on the time when they didn't need to worry about whether their rocket would do backflips during launch, just as we look back at the time when Kerbin's atmosphere was a constant density shell that ended at ~35km and when landing on the Mun meant landing on an engine bell or on fins.

[Burninate]

@Weatherman159: People complained when liquid engines got nerfed during the initial introduction of part modules; they originally got something like 500 Isp regardless of atmospheric pressure. Now no one complains about the ~350 Isp engines. People will complain when reentry heat is added, because they won't be able to be as careless with aerobraking and reentry as they are now. They will complain when life support requirements are added. They will complain when maximum g-forces for Kerbals and (possibly) parts are added. They will complain about the inevitable change in the fuel required for the NTR, when they won't be able to run it off of the same fuel mixture as a mainsail. They will complain when intakes are recoded so that intake spamming can't be done anymore. Just as they will complain about these changes, they will complain about the addition of proper aerodynamics.

All of these complaints will stem from one place: the introduction of constraints. KSP is a sandbox, and as players, we don't like feeling like we're being told what to do in our sandbox and the introduction of a new constraint feels like that. Of course, no one complains about the already existing constraints; we're barely aware they exist. We easily forget that the game already places constraints on what we can do through the behavior of gravity, the existence of atmospheres, where parts are spawned and how the physics simulation runs. Within a week after those new features are added the complaints will stop as the focus turns to designing a way around the problem, just as we do now. People will adapt and learning to design aerodynamic rockets will be part of the things that a player must learn, just as they must learn how to design staging properly, how to reinforce their rockets with struts, how to keep their vehicle powered in space and orbital maneuvers. And then, in the next update or so, people will look back fondly on the time when they didn't need to worry about whether their rocket would do backflips during launch, just as we look back at the time when Kerbin's atmosphere was a constant density shell that ended at ~35km and when landing on the Mun meant landing on an engine bell or on fins.

I think this is an extremely cogent point.

One wonders if maybe there's room for an in-GUI 'old versions' functionality, so I, a recent devotee of KSP, can see how you all managed in 0.17 and load old crafts.

[Frederf]

The average user is like a child deciding what to have for dinner. Generally the answer is "candy" with no concern for the stomach ache later. Game design should be informed by the user's enjoyment, not their wishes. The user has a one-track mind preoccupied with maximizing their performance against the challenges of the game. It is the challenges and limitations that define the gamespace the user navigates. Generally the user will ask for more, faster, better even if that doesn't make an enjoyable gamespace.

The difficulty in changing the gamespace is that users very readily calibrate themselves to one set of rules. Changes, especially "backwards" from the user performance point of view are often met with harsh and unconsidered backlash. If one runs the experiment where the game is introduced one way to a group and then changed and this is compared to a second group that is introduced only to the later version you will see that a lot of the "problems" are had by the first group. The second group won't find certain features "broken" "unplayable" "unfair" because they aren't.

[jrandom]

The Red Dwarf book "Better than Life" paints a pretty interesting picture of why giving people what they think they want generally doesn't work out very well. If you get all the easy stuff you ask for, suddenly everything is quite dull.

Of course, I'm one of those insane people that adds mods specifically to makes things harder through better realism.

[foamyesque]

All this talk about game theory is a bit heavy from me. I prefer pretty pictures.

3.21km/s dV to 100x100, baby.

I love FAR.

[taniwha]

foamyesque: yeah, high TWR starts to chew into the gravity-losses, too (and the gentler drag-losses means high TWR isn't such a bad thing).

[foamyesque]

Um. Is this correct?

It doesn't seem like it should be correct. No stalling?

[ferram4]

That is partly because supersonic flow is weird and partly because I don't have too much data for that flight regime. Assuming that there aren't any viscous effects in the flow, the airflow should be able to stick to the wing up to ~50 degrees angle of attack at Mach 5.5. I haven't attempted to add any "supersonic viscous stall" function since I haven't been able to dig up any papers on variation of stall angle and stall severity at supersonic speeds. I'd prefer not to add something that has no basis in reality just because I look at what's already modeled and say, "that seems wrong," especially since this is supersonic flow, where fluids behave a lot differently than at the subsonic speeds we're used to.

[jrandom]

Are there any good guides out there on how to place lifting surfaces and control surfaces for decent pitch control past mach-1? This seems to be the only thing I can't figure out by trial and error. Most of my planes have trouble at high speeds (I have a hell of a time changing pitch upwards), and some work great but I have no idea why they work great. Roll stability is good, pitch control at lower speeds and altitudes is good, CoL works over a high range of full->empty fuel tanks... I just need to nail down high-velocity performance.

[asmi]

Are there any good guides out there on how to place lifting surfaces and control surfaces for decent pitch control past mach-1? This seems to be the only thing I can't figure out by trial and error. Most of my planes have trouble at high speeds (I have a hell of a time changing pitch upwards), and some work great but I have no idea why they work great. Roll stability is good, pitch control at lower speeds and altitudes is good, CoL works over a high range of full->empty fuel tanks... I just need to nail down high-velocity performance.

The general rule that I follow is putting elevators as far back as possible, and/or making them as large as it's practical.

[jrandom]

The general rule that I follow is putting elevators as far back as possible, and/or making them as large as it's practical.

I've been using canards at both the extreme back and front ends for pitch control, so I assume those are just too small for anything but tiny SSTO's?

[LMA]

Just tried this mod on a simple rocket with just a fuel tank and engine, with mechjeb object under the nose cone.

At 4Km Mechjeb 2.0.9 starts the turn then when it tries to point more up it does a backflip but then manages to regain control.

Any Ideas what this is, is it normal?

Edited August 8, 2013 by LMA

[Read have Read]

Just tried this mod on a simple rocket with just a fuel tank and engine, with mechjeb object under the nose cone.

At 4Km Mechjeb 2.0.9 starts the turn then when it tries to point more up it does a backflip but then manages to regain control.

Any Ideas what this is, is it normal?

let me guess your TWR is around 3? What kind of vertical speed and where is your COM at that point?

You want to start your gravity turn as soon as you are off the pad. I found 1km to be ideal, but I used .5km before.

I aim for a TWR of around 1.7, add in fairings and I have pretty decent 3500 dv ascents.

[LMA]

TWR was at around 2 at launch. Setting mj to start turn at 1km fixes my problem very smooth ride thanks for the help.

[NathanKell]

...I wish MJ would start turn by velocity, not altitude. Make my life so much easier.

I find 100m/s is about right, btw--what do you all find?

[ferram4]

@jrandom: Canards at the extreme front and back would be enough if you keep the CoL very, very close to the CoM. Keep in mind that if you want your vehicle to have good supersonic stability and control you should design it to be only slightly stable at subsonic speeds.

I would suggest reducing the max deflection of your forward canard as well; at large angles of attack at low supersonic Mach numbers the wings might not make as much lift as you would hope, but will create large amounts of drag due to the shocks detaching from the leading edge of the wing and sitting as a bow shock in front of it. Reducing the max deflection will allow you to make full use of your rearward pitch control surfaces without detrimental effects on the forward ones.

@LMA: What it sounds like happened was that MechJeb decided to start the "gravity turn"^* with its characteristic "grace" and the sudden change in the rocket's angle of attack caused it to become slightly aerodynamically unstable. You'll probably want a lower TWR, an earlier start to the "gravity turn" and a less dramatic switch from vertical flight to "gravity turn."

_{*Quote marks used to take note of the fact that MechJeb does not fly an actual gravity turn trajectory; that would be pointing the rocket towards surface-prograde the entire launch and is chosen due to it being the optimal launch trajectory with respect to dV when there is not atmosphere and the optimal trajectory with respect to reducing lateral aerodynamic forces in an atmosphere.}

@NathanKell: I've tended towards starting at about 60 m/s, but it really depends on how severe the initial pitch over maneuver is as well as the launch TWR. TWRs higher than ~2 you have to start pitching over right at launch and any higher and you might as well just start the rocket angled 5 degrees or so on the pad.

[NathanKell]

Fair. I try for TWR-Max of 1.5-2.5 for my booster stage, so 100 works about right. I find things get a bit squirrely if I pitch over at 60, because my TWR isn't so high.

(Though--I do a very gentle pitchover, however, at the start, and try for a real gravity turn. Which you _can_ simulate in MJ2, just takes tweaking of the ascent path.)

[loknar]

I am a vanilla man but your mod is simply unavoidable.

Thank you.

What will you do if future updates start improving aerodynamics?

[jrandom]

Ferram, that's exactly the kind of advice I was looking for! Thank you.

[ferram4]

@loknar: I'd probably have to try and find out as much as I can from the devs about what aerodynamics have changed so I can see if it's possible for me to add any improvements to that system. Odds are that I'd switch from being focused on trying to balance the competing aspects of realism, gameplay and computational load and switch towards as much realism as possible. It wouldn't necessarily be for most of the current FAR users at that point, but for the people who say that they need even more realism, they'd get what they want.

[jrandom]

The more realism, the better. Succeeding in the face of greater odds is so much more satisfying.

In the meantime, would it be possible to add multithreading to FAR so it can do more calculations per frame? Maybe a user-configurable number of thread pools that asynchronously and constantly update all the parameters?