Jump to content

[0.90] TweakScale - Rescale Everything! (v1.50 - 2014-12-24 10:40 UTC)


Recommended Posts

The problem seems to be with RF. With RF6+TweakSable1.19, When I start a vessel with a part with RF, I can tweak it, save it, but cannot load it correctly. When it's loaded KSP doesn't know which is root part and the title becomes "vessel name". Cannot fly it either, as it starts somewhere in the space instead of on the ground.

When I start with a vessel without any part with RF, it seems fine. Reverting to 1.9 everything's fine too.

Still having the same problem, deleting the two "RF support" dlls fixed it.

Link to post
Share on other sites
Quick question - is there any documentation for the massFactors values used especially in things like scaletypes? Is 0 0 1 for volume, and 0 1 0 for surface area, or 1 0 0? What do the values correspond to? I'm attempting to rewrite things like LLL and B9 scales and create a scaletype for cargo bays (and other hollow parts) so they aren't ginormously heavy when scaled up. Couldn't find much of anything except 0 0 1 massFactors in the many cfgs I perused.

0, 0, 1 is volume, 0, 1, 0 is surface, and 1, 0, 0 is... I don't know, for when something scales only with the length of a part. You can also combine them, so a part whose mass is defined by both its surface area and its volume could be 0, 0.5, 0.5, for instance. I've not tested how that works in practice, so... good luck, i guess.

The values correspond to the coefficients of a polynomial - given massFactors = a, b, c, the mass will be scaled by the function M*(ax + bx^2 + cx^3), where M is the initial mass, and x is the scale.

If you really want to, there's no actual limit to the number of factors you can put there - massFactors = 0, 0, 0, 0, 0, 1 works just as fine, but gives some ridiculous weight after scaling up.

Edited by Biotronic
Link to post
Share on other sites
Still having the same problem, deleting the two "RF support" dlls fixed it.

I'd love to help, but I'm going away on vacation until next sunday. :(

I'm guessing the problem might be that it's RF6. I haven't updated the support module to that version. In the meanwhile, you can try this beta. If it works, whoo! If it doesn't, you'll either need to download and recompile TweakScale yourself, or just wait for next sunday. (of course, anyone else who wants to is also welcome to look at the code and try and fix this - please post pull requests!)

Link to post
Share on other sites
0, 0, 1 is volume, 0, 1, 0 is surface, and 1, 0, 0 is... I don't know, for when something scales only with the length of a part. You can also combine them, so a part whose mass is defined by both its surface area and its volume could be 0, 0.5, 0.5, for instance. I've not tested how that works in practice, so... good luck, i guess.

The values correspond to the coefficients of a polynomial - given massFactors = a, b, c, the mass will be scaled by the function M*(ax + bx^2 + cx^3), where M is the initial mass, and x is the scale.

If you really want to, there's no actual limit to the number of factors you can put there - massFactors = 0, 0, 0, 0, 0, 1 works just as fine, but gives some ridiculous weight after scaling up.

Awesome, thanks! Cargo bay chunkiness solved. :)

Link to post
Share on other sites
Any plans to add scaling functionality to rover wheels? The stock wheels are all either too big or too small. I want something in-between!

Follow the examples in the first post and you can do this yourself. I did it with AIES parts pack.

Link to post
Share on other sites

A few more Options on the tiny end of the spectrum would be useful. To make this little Plane, I gave the engine a 'free' scaling type. At 25%, it has about 3kN of Thrust, still almost 10 times what the plane needs to stay in the air. What do you think about the following proposals:

* introduce a 0.31m scale to stack parts, i.e. half of the current minimum, and set the minimum free scale to something like 10%. Or even less, I really like how the length for procedural parts starts at 10mm, have used this several times to align or balance things.

* allow continuous scaling for all scale types, like it is done in procedural parts. So there are arrow buttons for quick selection of standard sizes, and the bar inbetween allows free scaling. Why forbid odd-sized rockets if both the code and the user interface would easily allow it? Also, stack parts are often used other than flush on a stack part of the same size.

toyplane.png

Link to post
Share on other sites

I just wanted to say: Wow! :D Outstanding job taking my little hack and turning it into something great!

Sorry, forgot about that. It's CC BY-NC-SA. I want to make it WTFPL (my favorite licence), but I've asked Gaius for permission to do that and haven't yet received an answer. (I'm not holding that against him, just clarifying)

I was originally going to quibble (I tend to be on the GPL side of the "license wars"), but at this point I think it's fair to say it's more your mod than mine. Feel free to re-license it as you prefer with my blessing.

Edited by Gaius
Link to post
Share on other sites

Hi, I did a search but couldn't find a mention so I'll ask, is it possible to apply this mod to an object that uses the Scale = X, Y, Z functionality of;

MODEL

{

model = JonzCo/JonzCo_Bullet_RamJet/Models/JonzCo_Bullet_RamJet

scale = 0.5, 0.5, 0.5

texture = BulletJet_Diff , JonzCo/JonzCo_Bullet_RamJet/Textures/BulletJet_Diff_4

texture = BulletJet_Emm , JonzCo/JonzCo_Bullet_RamJet/Textures/BulletJet_Emm

}

I don't need it to scale them seperately just to treat the xyz as one overall scale? (Sorry for the overly direct example)

Link to post
Share on other sites
Hi, I did a search but couldn't find a mention so I'll ask, is it possible to apply this mod to an object that uses the Scale = X, Y, Z functionality of;

MODEL

{

model = JonzCo/JonzCo_Bullet_RamJet/Models/JonzCo_Bullet_RamJet

scale = 0.5, 0.5, 0.5

texture = BulletJet_Diff , JonzCo/JonzCo_Bullet_RamJet/Textures/BulletJet_Diff_4

texture = BulletJet_Emm , JonzCo/JonzCo_Bullet_RamJet/Textures/BulletJet_Emm

}

I don't need it to scale them seperately just to treat the xyz as one overall scale? (Sorry for the overly direct example)

That should work, yes. It was a problem as described in post 123, and fixed in version 1.10. As we're currently on 1.20, it shouldn't be a problem. Please do inform me if things don't work as you want it to.

Link to post
Share on other sites
Not sure if this is intended, however, from my brief experience with this mod, it appears that drag is being scaled incorrectly. For example, the terminal velocity of a craft with a MK1 command pod 1 jumbo X64 Orange fuel tank and a default sized Mainsail is ~ 100 m/s @ launch altitude. Scaling tank and engine up to 5 meters is ~ 60 m/s. This causes acceleration to peak quickly and drop down to ~1.06 G even with a TWR being significantly higher.

Installed version 1.19

This might be what i ran into when testing the 64bit ksp hack. Airplanes become impossible to get to take off, rockets require almost double delta-v to get into orbit (not always though). If the cause is indeed a tweakscale bug, it's still there in v1.2.

Link to post
Share on other sites
This might be what i ran into when testing the 64bit ksp hack. Airplanes become impossible to get to take off, rockets require almost double delta-v to get into orbit (not always though). If the cause is indeed a tweakscale bug, it's still there in v1.2.

I poked a little into the ScaleExponents.cfg file. After setting the angularDrag, maximum_drag , and minimum_drag to 0 I started getting consistent drag modeling again. I don't know if all of these need to be set, and what each of them do. I was hoping Biotronic might be able to take a look.

Link to post
Share on other sites
I poked a little into the ScaleExponents.cfg file. After setting the angularDrag, maximum_drag , and minimum_drag to 0 I started getting consistent drag modeling again. I don't know if all of these need to be set, and what each of them do. I was hoping Biotronic might be able to take a look.

I'm not entirely sure but the maximum and minimum drag number in ScaleExponents.cfg look just wrong, might be off by a factor 10. In stock ksp those are much lower and independent of part size and mass. As far as i know they are drag coefficient numbers and the actual drag is calculated based on part mass. So for all i know TweakScale does not need to/should not scale the cfg drag numbers at all.

Setting maximum and minimum drag in ScaleExponents.cfg to 0.2 and 0.3 respectively might just be the fix it needs. On second thought: obviously not. Should perhaps both be 1, as should angularDrag.

After testing: "0" seems to work much more like "do not scale" than 1, so 0 it is.


ScaleExponents.cfg:

TWEAKSCALEEXPONENTS
{
angularDrag = 2
maximum_drag = 2
minimum_drag = 2
}


stock:

title = Rockomax Jumbo-64 Fuel Tank
mass = 4

maximum_drag = 0.2
minimum_drag = 0.3
angularDrag = 2


title = PB-X150 Xenon Container
mass = 0.05

dragModelType = default
maximum_drag = 0.2
minimum_drag = 0.3
angularDrag = 2

Edited by rkman
Link to post
Share on other sites
Does this work with RADIAL-attached parts like the little mono-propellant tanks?

Best that you try it yourself on the parts you're interested in. Concerning the Mono-prop tanks; yes, it does work. Even works on the RCS jets as well. If a part is stock and it's logical to tweakscale it, then the mod-maker has probably added the functionality. You can add the functionality yourself; just follow the instructions in the orig post. I did so with the AIES parts pack.

Edited by Apollo13
Link to post
Share on other sites

...So I want to make the construction pack from NearFuture scale too.


@PART[trusslrg] // Modular Octo-Girder XL
{
MODULE
{
name = TweakScale
type = stack
defaultScale = 2.5
}
}

It's not working and I get a very interesting error message in the logs:



InvalidOperationException: Operation is not valid due to the current state of the object
at System.Linq.Enumerable.Single[ConfigNode] (IEnumerable`1 source, System.Func`2 predicate, Fallback fallback) [0x00000] in <filename unknown>:0

at System.Linq.Enumerable.Single[ConfigNode] (IEnumerable`1 source, System.Func`2 predicate) [0x00000] in <filename unknown>:0

at TweakScale.TweakScale.get_moduleNode () [0x00000] in <filename unknown>:0

at TweakScale.TSGenericUpdater..ctor (.Part part) [0x00000] in <filename unknown>:0

at TweakScale.TweakScaleUpdater+<createUpdaters>d__4.MoveNext () [0x00000] in <filename unknown>:0

at System.Collections.Generic.List`1[TweakScale.IRescalable].AddEnumerable (IEnumerable`1 enumerable) [0x00000] in <filename unknown>:0

at System.Collections.Generic.List`1[TweakScale.IRescalable]..ctor (IEnumerable`1 collection) [0x00000] in <filename unknown>:0

at System.Linq.Enumerable.ToArray[IRescalable] (IEnumerable`1 source) [0x00000] in <filename unknown>:0

at TweakScale.TweakScale.Setup () [0x00000] in <filename unknown>:0

at TweakScale.TweakScale.OnStart (StartState state) [0x00000] in <filename unknown>:0

at Part.ModulesOnStart () [0x00000] in <filename unknown>:0

at Part+ .MoveNext () [0x00000] in <filename unknown>:0

(Filename: Line: -1)

Is that a bug or am I configuring something wrong?

EDIT: Disregard that, they were already scalable and I was mistakenly under impression that they weren't.

Still, you should probably account for mistakes like multiple copies of the module on a part. :)

Edited by Mihara
Link to post
Share on other sites
Engine thrust scales by cross-section surface area, with a small ISP bonus/penalty as you shrink/enlarge. Mass also does so, regardless of how it would be IRL, with the same bonus/penalty. I've never actually curve-fitted it, but it seems to be about 5% penalty in both ISP and TWR when going from 1.25m to 2.5m.

Just a thought, but IRL, shouldn't ISP and TWR *INCREASE* when going to a larger diameter, regardless of what they do in-game?

This would seem intuitive, since the amount of mass to make some parts of a rocket engine, such as the rocket nozzle, would decrease relative to the mass of the rocket engine when going to a larger size (a 2 meter circle has only twice the circumference of a 1 meter circle, but encloses 4 times the area), and the exhaust column of a wider rocket nozzle should be less subject to pinching or pluming compared to that of a smaller nozzle (see this article for a simple explanation of what I'm talking about), once again due to its better ratio of cross-sectional area to circumference...

Regards,

Northstar

Link to post
Share on other sites

Well, as always, the truth is more complex than I initially anticipated. Here's what I found after doing some research: it might be interesting to this mod:

It turns out that, in vacuum and high-altitude flight, you want a LARGER nozzle cone relative to the enclosed area of the rocket nozzle and the size of the engine. To the point that there are actually patents for "extendable rocket nozzles" specifically designed to enlarge rocket nozzles as a rocket climbs in altitude...

However, at lower altitude, a SMALLER nozzle is desirable, so as to prevent atmospheric pinching of the exhaust column.

Aerospike engines use shock waves rather than changes in nozzle size to obtain optimal ISP throughout an ascent.

What all this means for rescaling engines:

Larger rocket engines of the same nozzle design have relatively smaller nozzles (as area of a circle = pi * radius^2, whereas circumference = 2 * pi * radius), and thus should obtain better ISP near sea-level, but inferior ISP at altitude.

Smaller rocket engines of the same nozzle design have relatively larger nozzles, and thus should obtain better ISP in vacuum, but inferior ISP near sea-level.

IN SUMMARY: What seems most appropriate (accurate/realistic) is not to blanket-cut ISP across-the-board for scaled-up rocket engines, but rather to shift their ISP curves slightly so they perform relatively better at sea-level and relatively worse in vacuum.

As it so happens, that also corresponds best to how players will normally use larger rocket engines- for lower stages of atmospheric launches. Isn't it nice when things just work out the way they should? :)

Tough luck for people looking to use a mod like this to scale up engines for reusable rockets in vacuum conditions, like I am for my planned Mun base, though. :(

Regards,

Northstar

P.S. For those of you who didn't catch it, there following link was embedded in the post: http://www.google.com/patents/US4787559

Edited by Northstar1989
Link to post
Share on other sites

How is compatibility with Realism Overhaul? Is there a DefaultScales.cfg available for the 0.5m/1m/2m/etc scaling? If so, could we get it mentioned in the OP?

EDIT: Well, here's one I think is right... One question though, it looks like the "surface" type isn't showing the additional scale factors I added, does it even support more than the default?


SCALETYPE
{
name = stack
freeScale = false
scaleFactors = 0.5, 1, 2, 3, 4, 5
scaleNames = 0.5m, 1m, 2m, 3m, 4m, 5m
massFactors = 0.0, 0.0, 1.0
defaultScale = 1
}

SCALETYPE
{
name = surface
freeScale = false
scaleFactors = 0.25, 0.5, 0.75, 1.0, 1.25, 1.5, 1.75, 2.0, 2.5, 3, 4,
scaleNames = 25%, 50%, 75%, 100%, 125%, 150%, 175%, 200%, 250%, 300%, 400%
massFactors = 0.0, 0.0, 1.0
defaultScale = 1.0
}

SCALETYPE
{
name = free
freeScale = true
massFactors = 0.0, 0.0, 1.0
minScale = 25
maxScale = 400
defaultScale = 100
suffix = %
}

SCALETYPE
{
name = adapter_2_1
freeScale = false
scaleFactors = 1, 2, 4
scaleNames = 1m to 0.5m, 2m to 1m, 4m to 2m
defaultScale = 1
}

SCALETYPE
{
name = adapter_4_1
freeScale = false
scaleFactors = 2, 4
scaleNames = 2m to 0.5m, 4m to 1m
defaultScale = 2
}

Also, RO makes so many MM changes that it looks like the tweakscale module gets stripped out of most new parts, so not many actually end up scalable in-game. I'm hoping Nathan ends up supporting this plugin in earnest to reduce part count.

Edited by curiousepic
Link to post
Share on other sites

I have been testing this mod and so far it has been working quite excellently! I have noticed one small typo. In your config for Interstellar, you have the default size of the anti-matter collector set as 1.25 when it should be 2.5.

Link to post
Share on other sites

Noticing something strange - maybe - wondering if anyone else has this issue: some engines just won't scale (meaning the option to TweakScale at all doesn't appear when right clicking), where others from the same pack will. I cannot for the life of me figure out why. TweakScale 1.20.

Here is the code I'm using for the Klockheed OMS engine - this first one will not scale in the VAB:

@PART[km_se0-oms]

{

MODULE {

name = TweakScale

type = stack

defaultScale = 0.625

}}

In the exact same cfg file, here's the code I'm using for the klockheed linear aerospike:

@PART[km_se4L]

{

MODULE

{

name = TweakScale

type = stack

defaultScale = 2.5

}}

This is on a clean install of KSP, clean TweakScale, clean Klockheed. WTF am I doing wrong?

Config file for the non-scaling OMS:

PART
{
// Kerbal Space Program - Part Config
// Shuttle Engine
//

// --- general parameters ---
name = km_se0-oms
module = Part
author = dtobi

// --- asset parameters ---
mesh = x0-oms.mu
scale = 1.0
rescaleFactor = 0.75




// --- FX definitions ---

//fx_exhaustFlame_blue_small = 0.0, -3.0, 0.0, 0.0, 1.0, 0.0, running
//fx_exhaustLight_blue = 0.0, 1.0, 0.0, 0.0, 0.0, 1.0, running
//fx_smokeTrail_light = 0.0, 4.0, 0.0, 0.0, 1.0, 0.0, running
//fx_exhaustSparks_flameout = 0.0, 4.0, 0.0, 0.0, 1.0, 0.0, flameout

// --- Sound FX definition ---

sound_vent_medium = engage
sound_rocket_hard = running
sound_vent_soft = disengage
sound_explosion_low = flameout

// --- editor parameters ---
TechRequired = precisionEngineering
entryCost = 4200
cost = 620
category = Propulsion
subcategory = 0
title = FSX0-OMS Micro Shuttle Engine
manufacturer = Klockheed Martian
description = Initially a shuttle engine. Now an OMS.

// attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision
attachRules = 1,0,1,0,1
node_stack_top = 0.0, 0.31, 0.0, 0.0, -1.0, 0.0, 0
node_stack_bottom = 0.0, -0.47, 0.0, 0.0, -1.0, 0.0, 0

// --- standard part parameters ---
mass = 0.40
dragModelType = default
maximum_drag = 0.2
minimum_drag = 0.2
angularDrag = 2
crashTolerance = 7
maxTemp = 2400

stagingIcon = LIQUID_ENGINE


EFFECTS
{
powerflame
{
MODEL_MULTI_PARTICLE
{
name = flamethrust
modelName = Klockheed_Martian/FX/engine/x0OMSflame
transformName = exhaust
emission = 0.0 0.1
emission = 0.5 0.25
emission = 0.75 0.75
emission = 1.0 1.0
speed = 0.0 0.40
speed = 1.0 1.0
size = 0.0 0.3
size = 1.0 0.7
localOffset = 0, 0, -3
}
AUDIO
{
channel = Ship
clip = sound_rocket_hard
volume = 0.0 0.0
volume = 1.0 1.0
pitch = 0.0 0.2
pitch = 1.0 1.0
loop = true
}
}
powersmoke
{
PREFAB_PARTICLE
{
name = flamethrust2
prefabName = fx_smokeTrail_light
transformName = smokePoint
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, 0
}
}
engage
{
AUDIO
{
channel = Ship
clip = sound_vent_medium
volume = 1.0
pitch = 2.0
loop = false
}
}
disengage
{
AUDIO
{
channel = Ship
clip = sound_vent_soft
volume = 1.0
pitch = 2.0
loop = false
}
}
flameout
{
AUDIO
{
channel = Ship
clip = sound_explosion_low
volume = 1.0
pitch = 2.0
loop = false
}
}
}
MODULE
{
name = ModuleEnginesFX
//engineID = rocketengine
runningEffectName = powersmoke
directThrottleEffectName = powerflame
thrustVectorTransformName = exhaust
exhaustDamage = True
ignitionThreshold = 0.1
minThrust = 0
maxThrust = 85
heatProduction = 360
fxOffset = 0, 0, 0
PROPELLANT
{
name = LiquidFuel
ratio = 0.9
DrawGauge = True
}
PROPELLANT
{
name = Oxidizer
ratio = 1.1
}
atmosphereCurve
{
key = 0 380
key = 1 330
}

}

MODULE
{
name = KM_PreLaunchEffect
effectName = PreLaunchEffectEngine0
isActive = false
}

MODULE
{
name = KM_Gimbal
gimbalTransformName = gimbal
debug = true
yawGimbalRange = 5
pitchGimbalRange = 5
}

MODULE
{
name = ModuleAlternator
RESOURCE
{
name = ElectricCharge
rate = 4.0
}
}
MODULE
{
name = ModuleAnimateHeat
ThermalAnim = x0-heat
}

RESOURCE
{
name = ElectricCharge
amount = 0
maxAmount = 0
isTweakable = false
hideFlow = true
}
MODULE
{
name = ModuleJettison
jettisonName = fairing
bottomNodeName = bottom
isFairing = True
jettisonedObjectMass = 0.1
jettisonForce = 5
jettisonDirection = 0 0 1

}
}

Config for the yes-scaling spike:

PART
{
// Kerbal Space Program - Part Config
// Shuttle Engine
//

// --- general parameters ---
name = km_se4L
module = Part
author = dtobi

// --- asset parameters ---
mesh = x4l.mu
scale = 1.0
rescaleFactor = 1.25



// --- FX definitions ---

//fx_exhaustFlame_yellow_small = 0.0, -10.0, 0.0, 0.0, 1.0, 0.0, running
//fx_exhaustFlame_blue_small = 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, running
//fx_exhaustLight_yellow = 0.0, 4.0, 0.0, 0.0, 0.0, 1.0, running
//fx_smokeTrail_light = 0.0, 4.0, 0.0, 0.0, 1.0, 0.0, running
//fx_exhaustSparks_flameout = 0.0, 4.0, 0.0, 0.0, 1.0, 0.0, flameout

// --- Sound FX definition ---

sound_vent_medium = engage
sound_rocket_hard = running
sound_vent_soft = disengage
sound_explosion_low = flameout

// --- editor parameters ---
TechRequired = veryHeavyRocketry
entryCost = 24000
cost = 2320
category = Propulsion
subcategory = 0
title = FSX4L Linear Aerospike
manufacturer = Klockheed Martian
description = The epitome of kerbal rocket engineering. This wonder of technology can power shuttles of any color. Has an extreme gimbal range and is very efficient.

// attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision
attachRules = 1,0,1,0,1
//node_stack_top = 0.0, 0.47, 0.0, 0.0, -1.0, 0.0, 0

// --- standard part parameters ---
mass = 6
dragModelType = default
maximum_drag = 0.2
minimum_drag = 0.2
angularDrag = 2
crashTolerance = 12
maxTemp = 3600
breakingForce = 200
breakingTorque = 200

stagingIcon = LIQUID_ENGINE

NODE
{
name = top
transform = node_top
}


//MODULE
//{
// name = ModuleEngines
// thrustVectorTransformName = exhaust
EFFECTS
{
powerflamel
{
MODEL_MULTI_PARTICLE
{
name = flamethrustl
modelName = Klockheed_Martian/FX/engine/airflamel
transformName = exhaustl
emission = 0.0 0.1
emission = 0.5 0.25
emission = 0.75 0.75
emission = 1.0 1.0
speed = 0.0 0.40
speed = 1.0 1.0
size = 0.0 0.1
size = 1.0 0.25
localOffset = 0, 0, 0
}
AUDIO
{
channel = Ship
clip = sound_rocket_hard
volume = 0.0 0.0
volume = 1.0 1.0
pitch = 0.0 0.2
pitch = 1.0 1.0
loop = true
}
}
powersmokel
{
PREFAB_PARTICLE
{
name = flamethrust2
prefabName = fx_smokeTrail_light
transformName = smokePoint
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, 1
}
}
engage
{
AUDIO
{
channel = Ship
clip = sound_vent_medium
volume = 1.0
pitch = 2.0
loop = false
}
}
disengage
{
AUDIO
{
channel = Ship
clip = sound_vent_soft
volume = 1.0
pitch = 2.0
loop = false
}
}
flameout
{
AUDIO
{
channel = Ship
clip = sound_explosion_low
volume = 1.0
pitch = 2.0
loop = false
}
}
}
MODULE
{
name = ModuleEnginesFX
//engineID = rocketengine
runningEffectName = powersmokel
directThrottleEffectName = powerflamel
thrustVectorTransformName = exhaustl
exhaustDamage = True
ignitionThreshold = 0.1
minThrust = 0
maxThrust = 775
heatProduction = 275
fxOffset = 0, 0, 0.0
PROPELLANT
{
name = LiquidFuel
ratio = 0.9
DrawGauge = True
}
PROPELLANT
{
name = Oxidizer
ratio = 1.1
}
atmosphereCurve
{
key = 0 390
key = 1 385
}

}

EFFECTS
{
powerflamer
{
MODEL_MULTI_PARTICLE
{
name = flamethrustr
modelName = Klockheed_Martian/FX/engine/airflamer
transformName = exhaustr
emission = 0.0 0.1
emission = 0.5 0.25
emission = 0.75 0.75
emission = 1.0 1.0
speed = 0.0 0.40
speed = 1.0 1.0
size = 0.0 0.1
size = 1.0 0.25
localOffset = 0, 0, 0
}
AUDIO
{
channel = Ship
clip = sound_rocket_hard
volume = 0.0 0.0
volume = 1.0 1.0
pitch = 0.0 0.2
pitch = 1.0 1.0
loop = true
}
}
powersmoke
{
PREFAB_PARTICLE
{
name = flamethrust2
prefabName = fx_smokeTrail_light
transformName = smokePoint
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, 1
}
}
engage
{
AUDIO
{
channel = Ship
clip = sound_vent_medium
volume = 1.0
pitch = 2.0
loop = false
}
}
disengage
{
AUDIO
{
channel = Ship
clip = sound_vent_soft
volume = 1.0
pitch = 2.0
loop = false
}
}
flameout
{
AUDIO
{
channel = Ship
clip = sound_explosion_low
volume = 1.0
pitch = 2.0
loop = false
}
}
}
MODULE
{
name = ModuleEnginesFX
//engineID = rocketengine
runningEffectName = powersmoker
directThrottleEffectName = powerflamer
thrustVectorTransformName = exhaustr
exhaustDamage = True
ignitionThreshold = 0.1
minThrust = 0
maxThrust = 775
heatProduction = 275
fxOffset = 0, 0, 0.0
PROPELLANT
{
name = LiquidFuel
ratio = 0.9
DrawGauge = True
}
PROPELLANT
{
name = Oxidizer
ratio = 1.1
}
atmosphereCurve
{
key = 0 390
key = 1 385
}

}


MODULE
{
name = KM_Gimbal
gimbalTransformName = gimbal
yawGimbalRange = 1
pitchGimbalRange = 30
responseSpeed = 50
}

MODULE
{
name = KM_PreLaunchEffect
effectName = PreLaunchEffectEngine
}

MODULE
{
name = ModuleAlternator
RESOURCE
{
name = ElectricCharge
rate = 14.0
}
}
MODULE
{
name = ModuleAnimateHeat
ThermalAnim = x0-heat
}

RESOURCE
{
name = ElectricCharge
amount = 0
maxAmount = 0
isTweakable = false
hideFlow = true
}
}

Edited by AccidentalDisassembly
Link to post
Share on other sites

Second weird thing - it seems that the exponents in ScaleExponents.cfg only apply to Squad parts - I modified it (separately from last post) so that the ModuleEngines bit was 2.5 instead of 2. This ended up making Squad parts more than 4x as powerful when they doubled in radius, but other parts (like the one Klockheed engine that would scale) remained at 4x...

Link to post
Share on other sites

Third bizarre thing happening that I can't figure out how to duplicate: sometimes on loading in the vab, tweakscaled parts placed in symmetry (doesn't seem to happen with non-symmetrical parts) have a huge amount more mass than they ought. I can (sometimes) get this to happen too by placing a part in symmetry in the VAB, then scaling it, then simply removing it from the ship and re-placing it right back where it was. Only happens on parts that have been scaled. Upon re-placing the part, it gains a lot of mass. Sometimes it gained mass every time I picked up the part off the ship and put it back on - ultimately up to millions of tons for something like a landing leg.

Can't figure out the circumstances it happens under though...

EDIT: After a godawful process of elimination, I think (probably?) the problem stems from Infernal Robotics + TweakScale combination. Infernal robotics installed: problem. Removing MSI's scale.dll seems to resolve some of it for some parts, not others...

EDIT 2: Crazy theory posted in MSI thread too: Even with MSI folder removed from GameData the shifty mass problem (more mass on re-placement or on load/launch) occurs, but seems maybe less severe. I think it MIGHT have something to do with parts not scaled using massFactors = 0.0, 0.0, 1.0. I had set custom scales for certain parts to scale based on surface area or whatever - this also is the case with the trusses etc. from the IR rework structural pack (I think). Perhaps therefore a general problem in all scale.dll files, somehow made worse when there are 2 of them in gamedata? No clue. Wish I could be more helpful. I am to take a wild flailing guess that having 2 scale.dll files somehow applies the polynomial massFactors function you mentioned before, but twice; though errors occur with only one copy too. Not sure how to confirm math on that.

Edited by AccidentalDisassembly
Link to post
Share on other sites
Guest
This topic is now closed to further replies.
×
×
  • Create New...