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

[CaptainKipard]

Yeah. Now that I've done the hardest part of the asset side of things, importing will pick up quickly.

My next biggest issue is configuring all the parts. It's going to be really difficult getting all the variables right, so I could use some help with that. One of the most important variables is mass. I need to somehow balance all the masses so that the whole thing flies well with the engines pointing where they're pointing.

[OrbitusII]

Ah, yes. The joys of balancing unconventionally-designed aircraft! I can't offer my time as a tester to try and figure out some good values for this, but I do have a passenger jet made with B9 aerospace that might be a good starting point for figuring out the ideal setup if you'd like a craft file.

Yes, all of the engines are below the wings and significantly below the center of mass. It's not a perfect comparison to the Skylon but I'm sure it could help you get some of the balancing methods down.

[nli2work]

let me know if you need help setting up FX for engines

[CaptainKipard]

but I do have a passenger jet made with B9 aerospace that might be a good starting point for figuring out the ideal setup if you'd like a craft file.

I'll take it. It'll at least give me a starting point, as long as B9 parts are realistically weighted themselves. Thanks

let me know if you need help setting up FX for engines

Ok, thanks. I saw a request or a wip somewhere of a different mesh-based take on engine FX, but I can't find it right now. That's something I'd like, but if that's not possible I'll go with stock. It's not a big issue right now.

[nli2work]

Ok, thanks. I saw a request or a wip somewhere of a different mesh-based take on engine FX, but I can't find it right now. That's something I'd like, but if that's not possible I'll go with stock. It's not a big issue right now.

SmokeScreen can handle all of it. and even if only stock, you can still have something like Hotrockets which is pretty nice too.

Edited October 2, 2014 by nli2work

[CardBoardBoxProcessor]

what i was saying is I tried making a single part space plane and it works but not super fine. (mostly because my code stinks) so I applude the seperated parts you have the

[CaptainKipard]

I added the aft engine in without any issues. I just used the default FX for now.

I'm also trying to set up the wings for FAR compatibility. If anyone has any experience please visit this post and share.

what i was saying is I tried making a single part space plane and it works but not super fine. (mostly because my code stinks) so I applude the seperated parts you have the

Ok I just thought that you were doing it without any plugins.

[CaptainKipard]

Things are really picking up now. I have the whole fuselage exported and mostly configured now.

One thing that's been confusing me is the orientations. Up Unity is Up in the VAB and Forward in the SPH is that correct? And Up in Blender is Down in the SPH and North on the Launch Pad?

EDIT

Here's another weird thing I noticed. I was following this post when creating my aileron and it looks like you really have to orient the aileron mesh object and name the object itself "obj_ctrlSrf". You can't name a transform obj_ctrlSrf and child the mesh to it, because even though the transform is called obj_ctrlSrf and has the x axis along the axis of rotation, it will still be the child mesh that gets rotated around its own X axis.

Edited October 4, 2014 by Cpt. Kipard

[Justin Kerbice]

It's bad to think of up, down, etc, better +z, -z, +y, -y, as these are rock solid (up/down and others are just a view of the reality).

Using North is even worth as it depends of magnetic pole .

+z if forward in SPH, +y is up there (also in VAB).

And for CS, funny, I start messing with it today and I noticed "weird" behaviour. Usually only unity transforms matter, what you do with a modelling tool is mostly irrelevant (especially pivot point), but for this, it looks like not !

I've made a simple CS made with a fixed part (surface attached to something) and a moving part which do the job of controlling.

This moving part have its pivot point set to where it should rotate and, fortunately for me, x axis is the axis around which the part rotate, and in unity, I just made a simple GO with partools exporter, add the tool objects as children, didn't care at all about the transforms of all three and... tried in KSP and it works as expected !

(I used 3dsmax 2015, FBX export format, set to y up, size in meters, imported in unity with set size to 1 instead of 1/100).

This is one of the only counter example I know where it behave like this.

Another inconsistency is ModuleControlSurface is used with a Part, whereas wings need Winglet, but both create lift.

[nli2work]

orientation reference for VAB and SPH

and for FAR compatible ctrl surfaces; take a look at the pWing example FBX.

Unity setup

and Config; for standard control surface just make static mesh instead of skinned mesh with armature. obj_ctrlSrf transform is hardcoded into Squad and FAR's control surface module and is required.

PART:NEEDS[ProceduralDynamics]
{

// --- general parameters ---
name = rFpCtrlSrf
module = Part

MODULE  // stock control module
{
	name = ModuleControlSurface
	dragCoeff = 0.5
	deflectionLiftCoeff = 0.5
	ctrlSurfaceRange = 20
	ctrlSurfaceArea = 0.95
}

MODULE  //pWing stuff. remove this and it will just be a standard control surface.
{
    name = WingManipulator
    keyRootScale = r
    keyTipScale = t
    keyTranslation = g // It should be "g" if someone tells you otherwise give em slap!
	modelChordLenght = 1
	symmetricMovement = true   
    doNotParticipateInParentSnapping = true
	isWing = false
	isCtrlSrf = true
}

MODULE  //This makes it work in FAR; just duplicated from pWing. Works in game, can't vouch for realism.
{
    name = FARControllableSurface
    MAC = 1.6
    e = 0.9
    MidChordSweep = 0
    ctrlaxis = roll
    maxdeflect = 15
    nonSideAttach = 1
    b_2 = 3.95
    TaperRatio = 0.98
}
}

Edited October 4, 2014 by nli2work

[CaptainKipard]

WRT orientations: It looks like spaceplanes have to be modeled upside-down in Blender.

WRT obj_ctrlSrf: are you sure you understood what I said there? The example you gave is of a control surface that's already aligned to the global X axis. The aileron on my wing is at an angle. It's the only reason I noticed that it's the mesh that's rotated, and not the transform. That pWing example would work just fine for the same reason that my aileron is rotating incorrectly

It's not a problem, it's just an observation.

Edited October 4, 2014 by Cpt. Kipard

[nli2work]

no, doesn't need to be modeled upside down in blender. the orientation of the root object, the one with PartTools is what counts. Root object is zeroed out and aligned to world XYZ during export

regarding aileron, the axis of rotation is local X of obj_ctrlSrf. the mesh around it doesn't matter, they are just visuals, can be aligned however you need it to look like. you can see in the image the obj_ctrlSrf transform is moving the visible mesh just like one would expect

http://i.imgur.com/m4fEhDZ.jpg

looking at the skylon plan drawings, the aileron's axis of rotation appears to be aligned to the X; not slanted like in Tiberion's example.

Edited October 4, 2014 by nli2work

[CaptainKipard]

regarding aileron, the axis of rotation is local X of obj_ctrlSrf.

Is that a mesh object or a transform with a childed mesh?

looking at the skylon plan drawings, the aileron's axis of rotation appears to be aligned to the X; not slanted like in Tiberion's example.

damnit....

Actually it's just parallel to the vertical plane. Still, I'll need to remodel and retexture it.

[nli2work]

Is that a mesh object or a transform with a childed mesh?

transform with childed mesh; the left image shows the heirarchy setup. obj_ctrlSrf is just a transform; aileron mesh and the red rod is childed to it. the red rod just indicates the X-Axis of obj_ctrlSrf in game, axis of rotation

[CaptainKipard]

I have my wing/aileron combo set up the same way and it doesn't rotate around the the obj_ctrlSrf transform X axis.

EDIT

Screw it. I'm taking a break from this.

I need to refresh my mind a bit, so I'm going to model the SKYLON Personnel & Logistics Module

Edited October 5, 2014 by Cpt. Kipard

[nli2work]

is there a line like this in the config?

mirrorRefAxis = 0, 0, -1

if so, try removing it.

[CaptainKipard]

It's not there.

[nli2work]

is the Part type Part and not Winglet? I don't think they mix well. I'll upload the unity and part files for the ctrlSrf in a few min

[CaptainKipard]

is the Part type Part and not Winglet? I don't think they mix well. I'll upload the unity and part files for the ctrlSrf in a few min

It's a part just like the stock winglet3. I'm putting this off for the moment. There's no rush. Skylon needs a passenger compartment for its initial release anyway.

[nli2work]

It's a part just like the stock winglet3. I'm putting this off for the moment. There's no rush. Skylon needs a passenger compartment for its initial release anyway.

basic control surface for FAr and stock Aero.

http://www./download/1ptsytr7ol3lgf1/ctrlSrf.zip

[nli2work]

looks like KineTechAnimation has AnimateIntakeAir module that can take care of your engine intake.

MODULE
{
	name = KModuleAnimateIntakeAir

	//When True, the animation will only be evaluated when the Intake on this part is open.
	//When open and the player closes the intake it will be interpolated to 0 value.
	//If set to False, animation will be evaluated regardless of intake state.
	IntakeMustBeOpen = True

	//The minimum value at which the animation will begin interpolating.
	MinValue = 0

	//The value at which the animation will complete its interpolation.
	MaxValue = 1

	//When set to False, once the animation has reached the maximum
	//value it becomes locked.
	CanDescendAfterMax = True

	//The name of the animation to be played with this module.
	AnimationName = nameOfAnimation

	//When True the animation will be played in reverse.
	PlayInReverse = False

	//When TRUE, the animation will not be updated.
	IsLocked = False

	//When TRUE, the Normalized Animation Time of the module is
	//interpolated between frames based on the 'LerpDampening'
	//value.
	UseInterpolation = True

	//The coefficient applied to Time.deltaTime that dictates
	//the speed our animation is played when interpolating, 
	//as large changes in the normalized time could result in
	//undesired playback.
	LerpDampening = 1

}

[CaptainKipard]

Interesting.

I don't see anything that tells it what to use as the basis for the interpolation. I guess it's just based on air speed like IRL. I wonder how it works with hybrid engines. Is that what IntakeMustBeOpen is for?

Also I wonder if PlayInReverse also flips the open and closed states.

Edited October 8, 2014 by Cpt. Kipard

[nli2work]

this particular module runs animation clip based on air intake amount. KineTech has many other modules that run animation based on different input conditions like airspeed; static pressure; altitude. etc. The full list of modules and documentations are in the B9/GameData/KineTechAnimation/Documentation. docs also explains what module are required in the part for for it to work. e.g. AnimateIntakeAir requires ModuleResourceIntake on the same part part

Haven't tried a part using these modules; but from the documentation I'm guess your setting would probably be something like this

MODULE
{
	name = KModuleAnimateIntakeAir
	IntakeMustBeOpen = True  //if player closes Intake; animation will go to last frame

	MinValue = 0      //min Intake Amount where Intake is closed; can set this so it closes when the engine automatically switches to closed cycle
	MaxValue = 0.01 //min Intake Amount where Intake begins to close

	CanDescendAfterMax = True  //allow Intake to reopen during descent

	AnimationName = IntakeClosing

	PlayInReverse = False  // flip this if in game the process appears reversed

        UseInterpolation = True  //smooths closing animation

	LerpDampening = 1  //experiment to get right speed

}

Edited October 8, 2014 by nli2work

[CaptainKipard]

I'm looking at Sabre's stats and the manual gives its Isp as 4562 N sec/kg.

What does that means and how does that relate to KSP values? The number is an order of magnitude larger than anything in KSP. Should I just divide it by 10?

[Master Tao]

It's a different way of reporting the same value (by mass instead of KSP's by weight). The SABRE's reported Isp is multiplied by standard gravity (9.8 m/s²), so you can divide by that number to get 465s. For the stock size Kerbin system, specific impulses are nerfed a little, so that translates to an Isp of about 400s (B9's SABRE is 390s). The SSME had a vacuum Isp of about 450s, which is better than any chemical rocket in the game and comparable to the LV-909 or Poodle.