1.1 - New ModuleEngines Features Examples and Discussion

[Shadowmage]

Would like to open a general discussion regarding the new features added to ModuleEngines with 1.1:
(Will attempt to keep OP updated with as new information is added/discovered)

 

1.) Resource-based thrust curves -- obvious application is for SRB thrust curves.
Implementation:  Looks as though you need to add a new float-curve to your engine module with the node name of 'thrustCurve' and set 'useThrustCurve' to true.  By default it is the average of all propellants levels.  Individual propellants can be excluded by adding 'ignoreForThrustCurve = true' in the PROPELLANT node.

Example: (WIP)

 

2.) Per-thrust-transform thrust multipliers -- known application is for vernier nozzles on engines while using a single ModuleEngines module in the part
Implementation: add a new config node to the engine module with the transform multipliers; see example below.

Example: Added in the ModuleEngines config, as a node similar to propellant/cuves/etc.

transformMultipliers
{
    trf0 = 0.4
    trf1 = 0.4
    trf2 = 0.1
	trf3 = 0.1
} 

3.) ModuleGimbal - per-axis range limitations.  Usefull for many custom parts and engine setups.  Can limit a gimbal to only respond on a single axis, or have different ranges per-axis

Example:

MODULE
{
	name = ModuleGimbal
	gimbalTransformName = RD-108A-Vernier
	gimbalRange = 5
	useGimbalResponseSpeed = false
	gimbalRangeYP = 0
	gimbalRangeYN = 0
	gimbalRangeXP = 5
	gimbalRangeXN = 5
}

 

 

Any other new features that I missed?

 

Anyone have any additional information or details on these points they would like to add? 

 

Edit: Updated to add examples for 2, & 3
Edit: Add slightly more info for #1 regarding propellant setup (example still todo)

Edited April 7, 2016 by Shadowmage

[heliobyte]

I just want to chime in and say that I am extremely happy that they basically implemented ETC and KM_Gimbal into ModuleEngines. Stock SRBs has desperately needed thrust curves for the longest time. Both these features will open up quite a few new ways of designing your craft, which is always nice.

[NathanKell]

1. Yup. By default it uses the min ratio of (total amount / total capacity) across all propellants. Propellants can be ignored by adding ignoreForThrustCurve = true in the PROPELLANT node.

2. Used like this. In the module, add:

transformMultipliers

{

trf0 = ratio_for_first_transform

trf1 = ratio_for_second_trasnform

...etc.

}

The ratios must add up to 1; in fact for an engine with n+1 trasnforms, trf(n) is ignored and is calculated by doing 1 - (sum of other trf valuse).

So you'd do, for the Mammoth:

transformMultipliers

{

trf0 = 0.2

trf1 = 0.2

trf2 = 0.3

}

and the 4th transform (trf3) can even be left out; it will be 1 - (0.2 + 0.2 + 0.3).

 

3. ModuleGimbal requires gimbal transforms to align Z with the thrust axis. An engine will rotate its gimbal a maximum of gimbalRangeXP degrees forward around X, gimbalRangeXN degrees backwards around X, and same for YP and YN. You can just specify gimbalRangeXP and gimbalRangeYP if the ranges are symmetric, or just gimbalRange if they are equal across XP, XN, YP, and YN.

[nli2work]

7 hours ago, NathanKell said:

The ratios must add up to 1; in fact for an engine with n+1 trasnforms, trf(n) is ignored and is calculated by doing 1 - (sum of other trf valuse).

So

So it's impossible to get ludicrous thrust by stacking multiple thrustTransform and setting them all to ratio of 1... and engines can have 0-thrust FX-only transforms. Sounds about right?

[martinezfg11]

I wonder if the new gimbal limits will make KM_GIMBAL redundant.. I'll have to this out on my engine.

[InsaneDruid]

It does. Maybe besides responseSpeed, which doesnt seem to be supported by the stock gimbal. I replaced KM with stock though.

[sarbian]

1 hour ago, martinezfg11 said:

I wonder if the new gimbal limits will make KM_GIMBAL redundant.. I'll have to this out on my engine.

KM_GIMBAL will be gone in 1.1. I will add a module that does the Gimbal Trim but it will use the stock gimbal module.

[Padishar]

13 hours ago, NathanKell said:

1. Yup. By default it uses the min ratio of (total amount / total capacity) across all propellants. Propellants can be ignored by adding ignoreForThrustCurve = true in the PROPELLANT node.

I'm sorry, could you possibly explain this in more detail?  Do you mean the input to the FloatCurve is the current amount of resource (well, ratio current:full)?  Is this the ratio of all the resource accessible to the engine?  Does the fuel flow rate change or does that stay constant and the effective Isp change?  Does this take into account partially filled tanks or just assume that means a different starting thrust?  It sounds like this is going to complicate the calculation of TWR...

[sarbian]

1 hour ago, Padishar said:

It sounds like this is going to complicate the calculation of TWR...

Indeed. I had a look and I am not sure I will add support for that curve.

[NathanKell]

I would suggest that you may well not want to support it, and that engine makers should use the average thrust (total impulse divided by time) as the 'maxThrust' of their engine so info-mod burn times will be correct.

 

@Padishar The algorithm is basically this:

ratio = 1

for each propellant:

if propellant has ignoreForThrustCurve, then skip

else ratio = min(ratio, propellant.totalAmount / propellant.totalCapacity)

 

flow multiplier *= thrustCurve.Evaluate(ratio)

 

And yes, if you tweak an SRB to have < full resource, the thrust curve will start out at say key .5; I'm open to suggestions if you'd rather I take a different approach.

10 hours ago, InsaneDruid said:

It does. Maybe besides responseSpeed, which doesnt seem to be supported by the stock gimbal. I replaced KM with stock though.

useGimbalResponseSpeed = true

gimbalResponseSpeed = (whatever)

the speed is used in a lerp(existing, desired, speed * fixedDeltaTime)

[Shadowmage]

Regarding the gimbal;

I'm having some issues getting it working with my engine cluster module and parts.  It works fine with a single engine, but as soon as I add another engine model, it only responds properly to roll input. 

I am re-initializing the gimbal after the model changes by calling its OnStart() method; and I can tell that it has the transforms are referenced properly, as all of the engines respond to roll input; but for pitch or yaw input they merely twitch a little bit.

The gimbal transform is the engine bell mesh, which is aligned with the thrust transform.  It gimbals properly in a single engine setup; multi-engine setups worked fine in 1.05 with reloading the gimbal module.

First image is hierarchy; second image is gimbal centered; third image is gimbal full deflection; fourth image is single-engine centered; fifth image is single engine full deflection

 

Edit:

Am going to manually build a part through MODEL nodes with multiple models to make sure it is nothing in my plugin/code that is causing the issue.  Will update with more info when I have it

Further Edit:
Gimbal behaves properly when part is built with individual models through MODEL nodes in the part config.  Which means that there is something in the updating code that I'm not updating or resetting properly.  Any clues on how to do run-time re-init of the gimbal module (update transform lists, etc)?

 

More Edit:
If I take that same test-part built with MODEL nodes, but rotate the models in the node, the gimbal stops working.  The exact same config without the rotation= in the model node definitions works properly.
 

PART
{
module = Part
name = SSTU-SC-ENG-J-2-Test
author = Shadowmage

TechRequired = fuelSystems
entryCost = 22000
cost = 5500
category = Engine
subcategory = 0
title = SSTU - SC-ENG - J-2
manufacturer = SSTU
description = SSTU - ShipCore: Engines - J-2.  When the mission planners at SSTU were unimpressed with the thrust output of the RL10 series of engines, they tasked the engineering team with coming up with a viable restartable second-stage motor for larger payloads.  The J-2 is the result of over two years of development, three exploded hangars, and twelve and a half tons of melted prototype engines.  Intended to be used solely as an upper-stage engine, its sea-level thrust and efficiency are quite poor, but generally compensated for by its above-average vacuum performance.

MODEL
{
	model = SSTU/Assets/SC-ENG-J-2
	position = 1, 0, 0
	rotation = 0, -90, 0
}
MODEL
{
	model = SSTU/Assets/SC-ENG-J-2
	position = -1, 0, 0
	rotation = 0, 90, 0
}
rescaleFactor = 1

// nodes/attachment 
// node position specification: posX,posY,posZ,axisX,axisY,axisZ,size
// attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision
node_stack_top = 0,0,0,0,1,0,2
node_stack_bottom = 0,-2.0833,0,0,-1,0,2
node_attach = 0, 1.2, 0, 0, 1, 0, 2
attachRules = 1,1,1,1,0

mass = 2.93
crashTolerance = 6
maxTemp = 2000
fuelCrossFeed = True
breakingForce = 200
breakingTorque = 200

//FX
EFFECTS
{
	running_closed
	{
		AUDIO
		{
			channel = Ship
			clip = sound_rocket_spurts
			volume = 0.0 0.0
			volume = 1.0 1.0
			pitch = 0.0 0.2
			pitch = 1.0 1.0
			loop = true
		}
		PREFAB_PARTICLE
		{
			prefabName = fx_smokeTrail_veryLarge
			transformName = J-2-ThrustTransform	
			emission = 0.0 0.0
			emission = 0.05 0.0
			emission = 0.075 0.25
			emission = 1.0 1.25
			speed = 0.0 0.25
			speed = 1.0 1.0
			localOffset = 0, 0, 3
		}
		MODEL_MULTI_PARTICLE
		{
			modelName = Squad/FX/ks1_Exhaust
			transformName = J-2-ThrustTransform			
			emission = 0.0 0.0
			emission = 0.05 0.0
			emission = 0.075 0.25
			emission = 1.0 1.25
			speed = 0.0 0.5
			speed = 1.0 1.2
			localPosition = 0, 0, 2
		}
	}
	engage
	{
		AUDIO
		{
			channel = Ship
			clip = sound_vent_soft
			volume = 1.0
			pitch = 2.0
			loop = false
		}
	}
	flameout
	{
		PREFAB_PARTICLE
		{
			prefabName = fx_exhaustSparks_flameout_2
			transformName = J-2-ThrustTransform
			oneShot = true
		}
		AUDIO
		{
			channel = Ship
			clip = sound_explosion_low
			volume = 1.0
			pitch = 2.0
			loop = false
		}
	}
}

MODULE
{
	name = ModuleEnginesFX
	engineID = SSTU-J-2
	runningEffectName = running_closed
	thrustVectorTransformName = J-2-ThrustTransform
	exhaustDamage = True
	ignitionThreshold = 0.1
	minThrust = 0
	maxThrust = 423
	heatProduction = 250
	fxOffset = 0, 0, 2.3
	PROPELLANT
	{
		name = LqdHydrogen
		ratio = 15
		DrawGauge = True
	}
	PROPELLANT
	{
		name = Oxidizer
		ratio = 1
	}
	atmosphereCurve
 	{
		key = 0 421
		key = 1 200
 	}
}
MODULE
{
	name = ModuleGimbal
	gimbalTransformName = J-2-Bell
	gimbalRange = 5
	useGimbalResponseSpeed = true
}
MODULE
{
	name = ModuleSurfaceFX
	thrustProviderModuleIndex = 1
	fxMax = 1
	maxDistance = 120
	falloff = 2
	thrustTransformName = J-2-ThrustTransform
}
}

 

Even more edit:
Merely rotating the model in the MODEL node for a single engine also results in.... improper gimbal setups depending upon how far rotated it is.  Rotating 90' results in the engine gimbaling on the pitch axis for roll input (single engine should not respond to roll input...)
 

Rotating the models in stock parts will also make them exhibit this problem.

 -- modified mammoth engine cluster exhibits gimbal problems
	// mesh = Size3EngineCluster.mu
	MODEL
	{
		model = Squad/Parts/Engine/Size3EngineCluster/Size3EngineCluster
		rotation = 0, 90, 0
	}

 

Going to file a bug report as soon as I gather more info.

 

Edit:  Bug report opened:   http://bugs.kerbalspaceprogram.com/issues/8345

Edited April 4, 2016 by Shadowmage

[Skalou]

On 03/04/2016 at 8:31 AM, NathanKell said:

I would suggest that you may well not want to support it, and that engine makers should use the average thrust (total impulse divided by time) as the 'maxThrust' of their engine so info-mod burn times will be correct.

@Padishar The algorithm is basically this:

ratio = 1

for each propellant:

if propellant has ignoreForThrustCurve, then skip

else ratio = min(ratio, propellant.totalAmount / propellant.totalCapacity)

 

flow multiplier *= thrustCurve.Evaluate(ratio)

 

And yes, if you tweak an SRB to have < full resource, the thrust curve will start out at say key .5; I'm open to suggestions if you'd rather I take a different approach.

Hi @NathanKell , it was a really awaited feature for me!

by reading the changelog in the Part Modules  section we can read:

Quote

Part Modules

...

Allow ModuleAblator to create a resource as it consumes the ablator (i.e. cracked ablator).

...

 

Spoiler

out of thread: i thought it will be used for the blackish texture when reentry, but i didn't change anything in actual 1.1, did i missed something?

1.1:

1.0.5:

 

So maybe why not using this same trick for the SRB to know the amount of solide fuel set in the VAB? lets say a booster create a new ressource called "BurntSF" when burning SolidFuel.

So at all time you know that BurntSF + available Solid fuel = total of solid fuel set in the VAB,

and then use it to define the thrust curve instead, to avoid it starting offset of X frames when a SRB is not full at ignition.

i have really hope to see this in stock KSP:

https://www.reddit.com/r/KerbalSpaceProgram/comments/2jwc28/mod_idea_solid_fuel_thrust_profiles/

as you stated the mod Engine thrust control allowed this, it's really good for a fixed curve ( for reproduction in RSS for exemple) but it is impossible to tune it in the VAB:

Spoiler

this simpler mod however has a nearly perfect gameplay implementation IMO ( just need to define points as above instead of constant thrust segments and show the curve: time/thrust)

keep up the good work team!

Edited April 4, 2016 by Skalou

[NathanKell]

@Shadowmage you ever post that issue?

[Shadowmage]

5 minutes ago, NathanKell said:

@Shadowmage you ever post that issue?

 

Indeed: http://bugs.kerbalspaceprogram.com/issues/8345

I'm still working on tracking down the specifics and more debugging(read: random testing) on it; but the general details are in the issue ticket.

Edited April 5, 2016 by Shadowmage

[Shadowmage]

Double posting to tag @NathanKell because I'm a noob and didn't hit the quote button on the last post...

[NathanKell]

@Shadowmage It worked just fine--quotes / tags edited in later still pop as notifys.

(As I just proved by forgetting to tag you at first )

[Shadowmage]

Lol, thanks, and noted.  Sorry for the spam

Please let me know if there is any further information that I can provide, test to do, or whatever

 

[Bonus Eventus]

On 4/2/2016 at 11:22 PM, NathanKell said:

1. Yup. By default it uses the min ratio of (total amount / total capacity) across all propellants. Propellants can be ignored by adding ignoreForThrustCurve = true in the PROPELLANT node.

2. Used like this. In the module, add:

transformMultipliers

{

trf0 = ratio_for_first_transform

trf1 = ratio_for_second_trasnform

...etc.

}

The ratios must add up to 1; in fact for an engine with n+1 trasnforms, trf(n) is ignored and is calculated by doing 1 - (sum of other trf valuse).

So you'd do, for the Mammoth:

transformMultipliers

{

trf0 = 0.2

trf1 = 0.2

trf2 = 0.3

}

and the 4th transform (trf3) can even be left out; it will be 1 - (0.2 + 0.2 + 0.3).

 

3. ModuleGimbal requires gimbal transforms to align Z with the thrust axis. An engine will rotate its gimbal a maximum of gimbalRangeXP degrees forward around X, gimbalRangeXN degrees backwards around X, and same for YP and YN. You can just specify gimbalRangeXP and gimbalRangeYP if the ranges are symmetric, or just gimbalRange if they are equal across XP, XN, YP, and YN.

Thanks so much @NathanKell, I was completely stumped last night trying to figure out why gimballing wasn't working in 1.1 pre-release on a 9 nozzle engine. Now it works great. All I had to do to fix it was (for anyone interested) make a new gimbal transform in unity with x = 90. I then switched the children of the old gimbal transform to the new gimbal transform, and since unity has child compensation, everything ended up in the right place. Just know that prior to 1.1 you could have your gimbal transform in unity oriented to Y and now it must be oriented to z like thrustTransform as Nathan pointed out.

[Eskandare]

Would this be correct?

	MODULE
	{
		name = FXModuleAnimateThrottle
		ThrustAnimationName = masamuneThrust
		dependOnEngineState = True
		dependOnThrottle = True
		responseSpeed = 0.007
		preferMultiMode = True // bind to the parent multimode module, not the actual engines.
	}
	
	MODULE
	{
		name = ModuleGimbal
		gimbalTransformName = Gimbal
		gimbalRange = 10
	}
	
	MODULE
    {
	    name = ModuleGimbal
	    gimbalTransformName = vaneMover1
	    gimbalRange = 10
	    useGimbalResponseSpeed = true
		gimbalResponseSpeed = 5
	    gimbalRangeYP = 0
	    gimbalRangeYN = 0
	    gimbalRangeXP = 10
	    gimbalRangeXN = 10
    }
	
		MODULE
    {
	    name = ModuleGimbal
	    gimbalTransformName = vaneMover2
	    gimbalRange = 10
	    useGimbalResponseSpeed = true
		gimbalResponseSpeed = 5
	    gimbalRangeYP = 0
	    gimbalRangeYN = 0
	    gimbalRangeXP = 10
	    gimbalRangeXN = 10
    }
	
		MODULE
    {
	    name = ModuleGimbal
	    gimbalTransformName = vaneMover3
	    gimbalRange = 10
	    useGimbalResponseSpeed = true
		gimbalResponseSpeed = 5
	    gimbalRangeYP = 0
	    gimbalRangeYN = 0
	    gimbalRangeXP = 10
	    gimbalRangeXN = 10
    }
	
		MODULE
    {
	    name = ModuleGimbal
	    gimbalTransformName = vaneMover4
	    gimbalRange = 10
	    useGimbalResponseSpeed = true
		gimbalResponseSpeed = 5
	    gimbalRangeYP = 0
	    gimbalRangeYN = 0
	    gimbalRangeXP = 10
	    gimbalRangeXN = 10
    }
		
	MODULE
	{
		name = ModuleSurfaceFX
		thrustProviderModuleIndex = 1
		fxMax = 0.6
		maxDistance = 25
		falloff = 2
		thrustTransformName = thrustTransform
	}

 

Edited April 5, 2016 by Eskandare

[blowfish]

@Eskandare You don't need to specify all the range parameters.  In your case setting (gimbalRange = 0, gimbalRangeXP = 10) or (gimbalRangeYP = 0, gimbalRangeXP = 10) would be sufficient - the positive range updates from the regular range if it's not set, and the negative range updates from the positive range if not set.

[Eskandare]

I take it we are still limited to one FXModuleAnimateThrottle animation? I noticed it still doesn't like to animate across gimbals.

[blowfish]

8 minutes ago, Eskandare said:

I take it we are still limited to one FXModuleAnimateThrottle animation? I noticed it still doesn't like to animate across gimbals.

I think it works (see stock Panther), but maybe all of the animations have to be on the same component?  I forget exactly what the limitation is.

[Eskandare]

1 hour ago, blowfish said:

I think it works (see stock Panther), but maybe all of the animations have to be on the same component?  I forget exactly what the limitation is.

Can't put it on the same component, either I have the animation and the gimbals don't work or I have gimbals but no animation. I feel like I have tried every configuration imaginable including separate animations for each vector fin. I still can't get it to work.

Edit: each vector fin has it's own gimbal.

Edited April 6, 2016 by Eskandare

[nli2work]

The old gimbal pivoted around the Z just like thrustTransform. You could assign thrustTransform for both gimbal and thrust if you wanted to. The only one that used Y axis was the smoke trail transform.

@Eskandare, if you haven't tried it already... I think you'll get better results combining the vector paddles into single mesh and using Skinned mesh. Child the end joint to the gimbal transform, and you can animate the end joint in/out the exhaust, or just scale it, to close/open the nozzle. 
 

[Eskandare]

What defines layer, for example: layer = 1

Edit: ...and what is it used for?

Context:

	MODULE
	{
		name = FXModuleAnimateThrottle
		animationName = TurboJetNozzleDry
		responseSpeed = 0.05
		layer = 1
		dependOnEngineState = True
		dependOnThrottle = True
		engineName = Dry
		weightOnOperational = True
	}
	MODULE
	{
		name = FXModuleAnimateThrottle
		animationName = TurboJetNozzleWet
		responseSpeed = 0.08
		layer = 2
		dependOnEngineState = True
		dependOnThrottle = True
		engineName = Wet
		weightOnOperational = True
	}
	MODULE
	{
		name = FXModuleAnimateThrottle
		animationName = TurboJetHeat
		responseSpeed = 0.0005
		layer = 3
		dependOnEngineState = True
		engineName = Wet
	}

 

Edited April 6, 2016 by Eskandare