[WIP] R.E.L Skylon C2. Alpha Released. FAR config broken. (08 Dec 2014)

[Climberfx]

One thing i wanna try is that mod to use one objet for bog sides of wings.

You remember what is the link for that Cpt. Kipard?

[CaptainKipard]

ModuleMirror? Adding this is far down on my to-do list, anyway if this happened after you added the FAR config then the problem must be FAR, or MM. It's pretty much out of my hands.

[Climberfx]

Yep. This one. I know. Gonna try out this clean install, then this ModuleMirror. If both don't work, i will try contact Ferram4 and see if he can give us a light!

[Voculus]

Are you on a Mac?

Are you using latest releases of everything?

BTW the real Skylon is even bigger than this. I had to scale it down for game purposes.

A Mac?! You wound me, sir! You wound me! Windows 7, FAR 14.4, and MM 2.5.1. I also installed the latest version of the Community Resource Pack before installing the Skylon.

[CaptainKipard]

well all I can suggest is to create a stock copy of the game somewhere and start with this mod and dependencies and start adding mods one by one to see what's causing the problem. Since I can't reproduce it on my computer I'm pretty sure nothing I did is causing the problem.

[Voculus]

Took the thoughts right outta my head. I'm really anxious to give this bad boy a whirl!

[Climberfx]

So, here goes.

Clean install, new KSP download from oficial site.

New Firespitter only dll, on the Firespitter plugin subfolder.

New FAR 14.4 from gibhub

New CRP last version

New KJR last version

Module Manager 2.5.1

Kipping from first post

And the cfg that you shared with us, to use with FAR/NEAR

So, i did a run, without this cfg for FAR, and that manner it works fine.

And then i put the FAR/NEAR cfg you shared. Boom!

Without the FAR/NEAR cfg by Climberfx, on Flickr

With the FAR/NEAR cfg by Climberfx, on Flickr

Here is the problem.

I believe that is because that cfg is based on a wing that rotates in "mirror" for both sides, the common way of kip handle symmetry, and Skylon wings don't do that, there are on wing for each side. But to be sure...

Now i gonna try implement the plugin Mirror symmetry so that way far will think is only a single wing on both sides.

I hope that works.

Post here the results as soon as i finish.

Cheers.

EDIT:

I saw Mirror Symmetry and his plugin do that when the two sides of object are exported as only one .mu from Unity. I'm asking him if will be possible to do with already exported separated .mu files from each side, but if not, i can't do any more, besides talk about this with Ferram4, to see if him give me a light.

Anyway, keeping in touch.

Edited December 7, 2014 by Climberfx

[White Owl]

Sorry I've been neglecting this thread for the last couple of days. Really, I'm sorry. This project is what I'm most interested to see work in KSP. But preview vids won't make themselves, ya know?

So I tried the FAR config file from the first post, with a fresh download of FAR 14.4. Applied it to the Skylon version I already edited to move mass forward and reduce overall fuel a little bit. It was very pleasing to see the CoL marker in the SPH was pretty much exactly where it was in stock aero! I didn't see whatever bug is plaguing Climberfx; my CoL is dead center.

Takeoff was very entertaining, since the beast won't rotate until airspeed is over 140-150 m/s. But the plane got off the ground before the end of the runway, just barely. Once airborne, you have to immediately retract the landing gear because the drag causes all kinds of hellish instability just when you can't afford it. I found it necessary to also cut the throttle to half or less, because going supersonic at sea level tends to make big airplanes fall apart.

In flight I saw exactly what I expected to see from an airplane with canards so far out in front: watch your angle of attack every second! Pitch back just half a degree too far and those canards will suddenly catch way too much air, the plane will violently pitch up, turn its belly into the relative wind, very bad things will happen to the airframe and you will not go to space today. But keep the plane at a safe angle of attack, and she flies beautifully and efficiently. A gradual climb at reduced power is the way to go. Save the throttle for high altitude.

Approaching 20km and about mach 3, the EAS drops down to more reasonable numbers (less than 200 m/s) at about the same time the engine thrust starts dropping off. I decided to lower the nose, go for a more gradual climb and firewall the throttles. At about 22km and mach 5, the intake air dropped below 0.1 so I switched to closed cycle mode. The rest of the ascent was a pretty standard rocket ascent to 300km orbit. I chose to limit myself to 3 Gs of acceleration. Now the plane is in orbit with 9787 hydrogen and 4068 oxygen in the tanks. That's probably too much again. LOL

I haven't tried reentry yet. It's past my bedtime.

So far, I don't see anything that needs changed in the FAR config. The plane is tricky to fly, that's true... but c'mon just look at this bird. It's supposed to be tricky to fly! Just be careful with your pitch, be patient with your climb, try to keep the EAS from running away, and Skylon will work great.

[CaptainKipard]

Thanks people.

I managed a reentry partially. I made it very shallow from a 71km orbit, so as slow as possible. I had to keep it steady even with SAS and lost balance at about 25km; the plane flipped and broke apart.

Here's some more FAR tweaks. Less resources, and nerfed jet engine. It should help on takeoff and keep the plane slower in the atmosphere.

@PART[KipEngSkylonWing*]:NEEDS[FerramAerospaceResearch|NEAR]

{

// zero out all stock values, remove stock module

@module = Part

@maximum_drag = 0

@minimum_drag = 0

@angularDrag = 0

@dragCoeff = 0

@deflectionLiftCoeff = 0

@ctrlSurfaceRange = 0

@ctrlSurfaceArea = 0

// add custom FAR values

MODULE

{

name = FARControllableSurface

MAC = 10.385

MidChordSweep = 17.165

b_2 = 4.02

TaperRatio = 0.56

e = 0.87

nonSideAttach = 0

maxdeflect = 15

ctrlSurfFrac = 0.12

}

}

@PART[KipEngSkylonCanard*]:NEEDS[FerramAerospaceResearch|NEAR]

{

// zero out all stock values, remove stock module

@module = Part

@maximum_drag = 0

@minimum_drag = 0

@angularDrag = 0

@dragCoeff = 0

@deflectionLiftCoeff = 0

@ctrlSurfaceRange = 0

@ctrlSurfaceArea = 0

// add custom FAR values

MODULE

{

name = FARControllableSurface

MAC = 1.985

MidChordSweep = 42.695

b_2 = 4.02

TaperRatio = 0.25

e = 0.87

nonSideAttach = 0

maxdeflect = 15

ctrlSurfFrac = 1

}

}

@PART[KipEngSkylonStabiliser]:NEEDS[FerramAerospaceResearch|NEAR]

{

// zero out all stock values, remove stock module

@module = Part

@maximum_drag = 0

@minimum_drag = 0

@angularDrag = 0

@dragCoeff = 0

@deflectionLiftCoeff = 0

@ctrlSurfaceRange = 0

@ctrlSurfaceArea = 0

// add custom FAR values

MODULE

{

name = FARControllableSurface

MAC = 3.27

MidChordSweep = 44.227

b_2 = 4.02

TaperRatio = 0.213

e = 0.87

nonSideAttach = 0

maxdeflect = 15

ctrlSurfFrac = 1

}

}

@PART[KipEngSkylonSabreEngine]:NEEDS[FerramAerospaceResearch]:AFTER[FerramAerospaceResearch]:NEEDS[!AJE]

{

@MODULE[ModuleEnginesFX],0

{

@maxThrust *= 1.3

}

}

@PART[KipEngSkylonPayloadBay]:NEEDS[FerramAerospaceResearch]

{

@RESOURCE[LiquidOxygen]

{

@amount = 11000

@maxAmount = 11000

}

}

@PART[KipEngSkylon*Fuel]:NEEDS[FerramAerospaceResearch]

{

@RESOURCE[LiquidHydrogen]

{

@amount = 12000

@maxAmount = 12000

}

}

White Owl you seem to be very efficient with your launches. Could you write a detailed bullet point list of your mission progress? I haven't been able to save that much fuel yet.

Or just record it.

What does EAS mean?

Edited December 8, 2014 by Cpt. Kipard

[Climberfx]

Man, i can be wrong, but i just update to the new FAR setting you post here Cpt, and the COL is back on his own place.

Let me test to be sure...

[nli2work]

EAS is Equivalent Airspeed (at Sea Level). better indication of how much aerodynamic control you can expect at a given indicated airspeed and atmosphere density.

Edited December 7, 2014 by nli2work

[Climberfx]

Nli2, here when i put this new cfg from Cpt Kipard, the COL got write. Was the only change i made here.

But i don't know why, because the new cfg is not so different.

The COL Arrow FAR removed it a long time ago.

Other thing i did was to build the ship from the parts, because my fuel tanks not updated with the new cfg file. So building from scratch make it with the new values for the tanks.

But that i did after it worked.

Uploading my flight so know you all can see the path to orbit and the limits of pitch in degrees and were you need to keep your eye.

This ship is made to be a computer flight, so, be it.

[nli2work]

new MM patch has small typo in "NEEDS[FerramAerospac(e)Research]" so the wings were still using stock lift modules. The CoL is still off center once the wings are properly patched. on the clean install with FAR 14.4.4; FS; and CRSPack.

[Climberfx]

You are absolutely write. So on stock it goes fine.

But when i fix that on cfg, will crash all again. Dam!

Wheel, here is the fake FAR Skylon Flying do.

Not using FAR for real, but is flying.

Edited December 7, 2014 by Climberfx

[CaptainKipard]

new MM patch has small typo in "NEEDS[FerramAerospac(e)Research]" so the wings were still using stock lift modules. The CoL is still off center once the wings are properly patched. on the clean install with FAR 14.4.4; FS; and CRSPack.

Ok so the reason I wasn't experiencing the problem was because I had the typos in my file.

[nli2work]

FAR's CoL indicator doesn't have an arrow. easy way to tell when something isn't quite right.

I tried adding "!MODULE[ModuleControlSurface]{}" after the block setting all the stock drag and lift values to 0. this should completely remove the stock ModuleControlSurface before adding FARControllableSurface module. no difference to CoL from what I saw.

I tried exporting the main Wing parts with the root Transform at the Wing's attach node. Looked like originally the Wings were cut from the full skylon model then exported, so the root transforms for those parts are at the middle of the wing instead of the base where they attach to the cargo section. That didn't appear to make any difference.

I also tried changing the main wings' lift module to FARAerodynamicModel instead of ControllableSurface. It meant the ailerons wouldn't function, but if that fixed the over all CoL, it was a step in the right direction. but I didn't have any luck there either.

I also build a smaller craft using same assembly methods, i.e. no symmetry at all, everything is individually attached, using RF and pWing parts, approximating the proportions as much as possible, and keeping part count as close as possible. The CoL is normal. that makes me thing it's something to do with the attach nodes (the NODE{} system?) and/or parts' root transforms.

if I think of something else in the next few days will post here

Edited December 8, 2014 by nli2work

[White Owl]

Yeah, I should've caught that it wasn't using the FAR aero module. Disregard everything I wrote earlier about how it flew in FAR.

If we get this working properly, I'll certainly make a video about it. I want people to know about this mod.

[ferram4]

So, poking at it, there are three things each FAR module needs:

The first is the standard node_attach = 0, 0, 0, 1, 0, 0 that most of the other wings have. Doesn't matter if the wings aren't allowed to surface attach, FAR uses it to orient where the wing root and wingtip are. That 1 should be positive for left wings, negative for right wings.

The second is the rootMidChordOffsetFromOrig vector; that find the point halfway down the root chord of the wing, and get the vector from the part origin to that; FAR will use that to orient where the wing actually is in space.

The third is a good look over the numbers, because I really, really doubt that the wing and the canard have the same exact semispan (b_2). They certainly don't look it; keep in mind that b_2 is to be measured from the root out to the tip, perpendicular to the chord; sweep is not counted in that. The wing MidChordSweep also looks a lot lower than 45 degrees, that looks more like the leading edge sweep. That angle needs to be measured using a line from the middle of the root chord to the middle of the tip chord.

Aside from that, the wing modules are probably fine.

Other problems: The intakes make an absurd amount of drag, probably because they're tuned differently than all the other intakes and have a huge area; that might need its own module, which, given the simplicity of the shape, should be doable by simply loading up the game with no intake module on the intake and exporting the FAR config it has in that case and then using that. Also, since it uses "Payload Bay" for the cargo bay, it is somehow being picked up as a payload fairing rather than a cargo bay; that can be fixed with a title change.

The only other thing that seems weird is the area-ruling on the payload bay. Proper area-ruling would have it extend past the back of the SABREs a little bit, but it isn't, I dunno if stopping it there is on the official diagrams or not, but it looks a little off; maybe worth a little research to see if it's as close to the official docs as possible.

[CaptainKipard]

I don't understand most of that. This is much harder than it should be.

All I can do for now is fix b_2

[IGNOBIL]

This is a beauty! Thank you.

[nli2work]

I don't understand most of that. This is much harder than it should be.

All I can do for now is fix b_2

FAR needs additional node for reference, node_attach 0,0,0,1,0,0. +X points at the center line of Skylon, so 1-X orientation for left wing node_attch, -1-X orientation for right wing node attach. then disable surfaceAttach in the attachment rules.

rootMidChordOffsetFromOrig i think can be taken care of by positioning the wing such that the middle point of the wing base is at 0,0,0. as in the image here

The Intake can use FARBasicDragModel module I think. if you export the part in the same orientation as stock parts, +Y forward in SPH, +Z down in SPH, the default values probably work. and tweak

S (surface area minus the base where it attaches to precooler.)

MajorMinotAxisRatio ( for cylindrical objects it's length/diameter)

taperCrossSectionAreaRatio (for cylinderical object it's (L*D)/S)

All that said, I think once you add node_attach to the left/right wings and canards. 90% of the CoL shift should be corrected. since without node_attach; it looked like FAR was using the root transform as reference. wing parts root transform had same orientation (+X right), so the CoL shifted to the left when both wings are attached. when only the right wing is attached, the CoL is center.

Edited December 8, 2014 by nli2work

[Climberfx]

i just put this line on the original cfg for each side wing and canard, respecting the +1 and -1 for each side like Ferram said. and it is working now with symmetry. I note that is not the perfect solution, but is flying with far now.

node_attach = 0, 0, 0, 1, 0, 0 for left side and node_attach = 0, 0, 0, -1, 0, 0 for right side.

[Iskierka]

In flight I saw exactly what I expected to see from an airplane with canards so far out in front: watch your angle of attack every second! Pitch back just half a degree too far and those canards will suddenly catch way too much air, the plane will violently pitch up, turn its belly into the relative wind, very bad things will happen to the airframe and you will not go to space today. But keep the plane at a safe angle of attack, and she flies beautifully and efficiently. A gradual climb at reduced power is the way to go. Save the throttle for high altitude.

So far, I don't see anything that needs changed in the FAR config. The plane is tricky to fly, that's true... but c'mon just look at this bird. It's supposed to be tricky to fly! Just be careful with your pitch, be patient with your climb, try to keep the EAS from running away, and Skylon will work great.

This should be fixable if you make use of FAR's AoA% setting on control surfaces - the real Skylon's canards are supposed to track airflow to remain in full control. To do this set AoA% to -100%, IIRC, and it should fly a lot more stable, and be a lot more stall-resistant and controllable at high AoA.

Visual reference for the behaviour:

They're not perfectly aligned, but the slight raise is a bit of trim to hold against the pitch load, they're still moved well beyond a normal control range and have additional range to handle anything extra required.

Unfortunately I've not had chance to play with this yet, I might try get things running on my desktop this week, hopefully it'll work nicely once I do.

[Climberfx]

You all guys came here with Wonderfull theories.

But the hole is a lot down there.

Try to fly with FAR and you will see what i'm talking about...

Still trying some configs here, no success yet, not near a stable flight. Not even a controllable flight, manual of Computer Assistive.

[CaptainKipard]

I think Climberfx is mostly right. With FAR you can try to keep a small AoA to give you some drag when entering but that's it.

Still trying some configs here, no success yet, not near a stable flight. Not even a controllable flight, manual of Computer Assistive.

Try to give yourself +10 SAS

rootMidChordOffsetFromOrig i think can be taken care of by positioning the wing such that the middle point of the wing base is at 0,0,0.

Does that mean the wing mesh origin, or the part origin, because I can't move the CoM all the way to the root; that's really hacky. I think he's saying I have to make the offset move somewhere. To the middle of the root?

The Intake can use FARBasicDragModel module I think. if you export the part in the same orientation as stock parts, +Y forward in SPH, +Z down in SPH, the default values probably work. and tweak

S (surface area minus the base where it attaches to precooler.)

MajorMinotAxisRatio ( for cylindrical objects it's length/diameter)

taperCrossSectionAreaRatio (for cylinderical object it's (L*D)/S)

Are you sure you mean surface area? Because that model is somewhat complex; it has a very large surface area, even without the base. The main mesh is like a pot, then there are a few concentric rings, and the pointy bit.

Edited December 9, 2014 by Cpt. Kipard