[WIP] TweakScale - Development Thread

[pellinor]

do you need any testing done on the mac client? If so, I will be willing to help. If not I understand.

I would not expect differences between operating systems. But if you are interested in testing some scaled wings I'd be grateful. Control surfaces look unchanged but wings moved to a proper partModule and the exponents are pretty much guesswork so far.

EDIT: lift, mass and (dry)cost is supposed to go with scale^2.

[Verios44]

I would not expect differences between operating systems. But if you are interested in testing some scaled wings I'd be grateful. Control surfaces look unchanged but wings moved to a proper partModule and the exponents are pretty much guesswork so far.

EDIT: lift, mass and (dry)cost is supposed to go with scale^2.

ok, a few questions first. By wings you mean the wing segments I presume, ones not fitted with stabilizers, etc? What sort of proportion should I expect to see from different sizes? Or do I use the base size and use percentage adjustment for down or up scaling? Finally, do you want stock wings only or include modded items?

[pellinor]

ok, a few questions first. By wings you mean the wing segments I presume, ones not fitted with stabilizers, etc? What sort of proportion should I expect to see from different sizes? Or do I use the base size and use percentage adjustment for down or up scaling? Finally, do you want stock wings only or include modded items?

Basically just play the game using some scaled parts and be a bit skeptical about their behavior. So a double size wing should give 4 times the lift. What might happen is that this factor is 1x or 16x instead. If you notice something that does not look right, try to boil it down to a simple case, like a small craft with only stock parts that behaves obviously wrong. So testing does not need to be boring work, I think the most important part is that you examine and discuss strange behavior instead of just strutting and duct-taping your ships arount the problems.

Lift, mass and (dry)cost of wings is supposed to go with scale^2. So the same area should give the same lift, regardless if it is one big part or multiple small ones.

EDIT: I flew my first plane in 1.0! First impression is that 1xnormal wing and 4x50% wing behave about the same. Nice and stable little plane, flying is nice but slowing down on the runway is a lot more difficult now.

Edited April 30, 2015 by pellinor

[pellinor]

Update: the release is out!

[DaniDE]

Heyyy nice

Grats on releasing 2.0

How did you go with the engine scaling for release? Is the heat still a problem?

Edited April 30, 2015 by DaniDE

[pellinor]

Heyyy nice

Grats on releasing 2.0

How did you go with the engine scaling for release? Is the heat still a problem?

See here: It seems like the overheating is consistent with the new heat system. Scaled engines should heat up at the same rate. Once some temperature difference is built up, small engines can radiate their heat better so they stay cooler.

- - - Updated - - -

Small dev update:

* restored maxThrust exponent to fix the editor CoT display

* added patch for new KIS container

[pellinor]

Small Dev update:

* surviving mistyped scaletypes

[pellinor]

KSP 1.0.1: same procedure as everytime, waiting for KAE and moduleManager to update...

EDIT: new Version is up! KAE is updated and MM seems still to work.

Edited May 2, 2015 by pellinor

[DaniDE]

KSP 1.0.1: same procedure as everytime, waiting for KAE and moduleManager to update...

EDIT: new Version is up! KAE is updated and MM seems still to work.

Thank you

[Kolago]

In the game log are several entrys like this:

(Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

PartLoader: Compiling Part 'Squad/Parts/Command/cupola/cupola/cupola'

(Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

PartLoader Warning: Variable removeTweakScale not found in Part

I think there is something wrong in the ScaleExponents.cfg

// ** Settings to switch scaling ability **
TWEAKSCALESETTINGS
{
    noScaledCrewPods = 1     // set to 0 for scaleable pods
}
@PART[*]:HAS[@MODULE[TweakScale],#CrewCapacity[*],~CrewCapacity[0]]:FOR[TweakScale]
{
    removeTweakScale = #$@TWEAKSCALESETTINGS/noScaledCrewPods$
}
@PART[*]:HAS[@MODULE[TweakScale],#removeTweakScale[1]]:FOR[TweakScale]
{
    !MODULE[TweakScale] {}
    !removeTweakScale
}

[pellinor]

In the game log are several entrys like this:

I think there is something wrong in the ScaleExponents.cfg

Since the HAS statement seems not to work with a full path, I put a variable into the part config. Added a patch to clean up those variables before the part is loaded by KSP.

[pellinor]

I found an interesting explanation about overheating of engines:

Objects absorb heat based on their specific heat, which is the number of Joules (or kilojoules) to raise the temperature of 1 gram (or kilogram) 1 degree C (or K, doesn't matter which). IOW, the more massive an object, the more energy it takes to heat it up. This means that when exposed to a heat source producing a given number of Joules, the more massive object will heat up slower than a less massive object. Everybody has seen this phenomenon in action. This is why it takes some time for the big logs in your campfire to get burning when you toss them onto a pile of burning kindling that you lit very quickly. It's also why heatsinks tend to be massive compared to what they're drawing heat from.

Of course, this works hand-in-hand with the ratio of surface area to mass. The higher this number, the more of the mass is exposed on the object's surface to the heat source, so can absorb heat simultaneously. This is why it's easier to ignite a board vs. a cubic block of the same mass of wood. But when objects are roughly the same size, such as rocket engines, the one with the higher mass has the lower surface-to-mass ratio, so will heat up slower.

So if a scaled engine burns at the same temperatures, the thermal energy conducted to the part should go with scale^2, just like the thermal energy the part radiates. Then scaled engines should have the same asymptotic overheating behavior (small ones will converge faster because mass goes with scale^2.5). To achieve this I think I'd need to scale heatProduction with an exponent of -0.5 (since it is normed to thrust and thrust goes with scale^2.5). Now the only problem left is that KSP ignores the manipulation of heatProduction...

Edited May 3, 2015 by pellinor

[ManuxKerb]

Hi

Please see my bugreport (parts do not node attach) here, this is caused by Tweakscale: http://forum.kerbalspaceprogram.com/...79#post1905379

Logs and pics are in the support thread :-)

Thanks!

Edited May 5, 2015 by ManuxKerb

[DaniDE]

Hi

Any ideas what causes Tweakscale to stop scaling the amount of fuel inside a tank that scales nicely otherwise? I´m lost :/

Edit: further tests show it happens when EPL (updated today) is installed, and/or when MFT is installed. Maybe also insterstellar fuel switch bundled with the cryo engine mod.

I already asked taniwha who was online in the chat:

<taniwha> that makes no sense

<taniwha> EL should not be affecting any such thing

Edited May 6, 2015 by DaniDE

[pellinor]

Hi

Any ideas what causes Tweakscale to stop scaling the amount of fuel inside a tank that scales nicely otherwise? I´m lost :/

Edit: further tests show it happens when EPL (updated today) is installed, and/or when MFT is installed. Maybe also insterstellar fuel switch bundled with the cryo engine mod.

I already asked taniwha who was online in the chat:

<taniwha> that makes no sense

<taniwha> EL should not be affecting any such thing

My bet is the fuelswitch (if the part is switchable). It completely overwrites resource nodes and keeps the scale as an internal variable instead. However it should work together with TweakScale.

[4plains]

Greeting to the developer of TweakScale.

My TweakScale behaves wierdly together with nuFAR (VoxelAeroPort). I'm not sure it's because I use the development version of FAR, the voxelAeroPort, or it's TweakScale itself. Or because I have an incorrect/incomplete install of TweakScale (What's it dependent on if it is?).

When I rescale parts, their ingame stats are changed, but nuFAR seems to get confused over the size/hitbox/mesh of the part I use. Since nuFAR ignores any kind of aerodynamicly relevant stats of parts and goes by a voxelized approximation of the Aircraft's or Rocket's shape this posts quite the problem.

Steps to reproduce:

1. Place a small wing (Standard Canard, Tail Fin, ...)

2. Scale up

3. Move it and other parts with the Offset building mode

4. Sweep AoA with the nuFAR build helper

5. Rescale

6. Repeat 1. - 4.; 1. and 2. not required; (Graphs don't really change, and sometimes the game thinks my part is at 100% scale)#

7. Launch, Revert/Recover craft

8. Graphs updated and part now seems to work (as it should)

or: Graphs update but parts are now treated by nuFAR as being at 100% scale and therefore producing not the results desired.

As of yet I have been able to repoduce this bug with the Standard Canard, the Tail Fin, The AR-68 Winglet, and the standard winglet. The new Big-S and FAT-455 parts seem to be immute to this as well as the Elevons.

Thank you for looking into this. I'll post a similar post at the FAR Thread.

Greets 4plains

[pellinor]

My TweakScale behaves wierdly together with nuFAR (VoxelAeroPort). When I rescale parts, their ingame stats are changed, but nuFAR seems to get confused over the size/hitbox/mesh of the part I use.

nuFar is still in development, and I am not familiar with it at all, so I don't think I can give any useful support at the moment. Until release I consider it a sack of bees that might change its behavior or interfaces at any moment, so compatibility efforts are better spent once it reached some stability.

From tweakScale's side, all visual models are scaled by writing the variable part.transform.GetChild(0).localScale, no special treatment for any part.

Maybe the similarity between the problem parts is that they are split into a fixed mesh and a moving one?

[pellinor]

Hi

Any ideas what causes Tweakscale to stop scaling the amount of fuel inside a tank that scales nicely otherwise? I´m lost :/

Edit: further tests show it happens when EPL (updated today) is installed, and/or when MFT is installed. Maybe also insterstellar fuel switch bundled with the cryo engine mod.

I changed my mind: if there is an MFT module on the part then this is the cause! In this case I let MFT do its thing and do not touch the resource nodes myself. And MFT might only scale tank size and not the contents.

- - - Updated - - -

Small dev update: exponent -0.5 for heatProduction, it seems to work now. No idea why last time I had the impression that KSP would ignore this one.

[4plains]

nuFar is still in development, and I am not familiar with it at all, so I don't think I can give any useful support at the moment. Until release I consider it a sack of bees that might change its behavior or interfaces at any moment, so compatibility efforts are better spent once it reached some stability.

From tweakScale's side, all visual models are scaled by writing the variable part.transform.GetChild(0).localScale, no special treatment for any part.

Maybe the similarity between the problem parts is that they are split into a fixed mesh and a moving one?

I will look into the fixed/moving mesh thing and test that. Never considered that.

nuFAR works by approximating the shape of the aircraft with voxels (hence VoxelAeroPort) and calculating the aerodynamic forces thereof. It only goes by the meshes the parts. It ignores all the stats that parts usually feed the game for the aerodynamics. If the rescaling glitches and nuFAR doesn't get the information that the part mesh is scaled up/down, the aerodynamics go all sorts of crazy.

I'm not familiar if changing the visual model also changes the hitbox mesh, which is what nuFAR uses for aero calculations.

Steps 1. - 8. described by me earlier are the way to reproduce this bug. Place part, scale it, move it, rotate it, scale/move..., launch the aircraft and revert or recover triggering the game to reload the craft in the editor and now the aerodynamics are all kinds of wierd.

Wierdest thing is I only have this issue with your version of tweak scale. Biotronics TweakScale for 0.90 does not produce these bees.

In the FAR Thread someone has said that this needs to be in the code for nuFAR to correctly interact with TweakScale. I'm not sure though if that is correct information.

Greets 4plains

Edited May 8, 2015 by 4plains

[Kolago]

is it possible to scale the input and output resources from Module "ModuleResourceConverter"?

MODULE
	{
		name = ModuleResourceConverter
		ConverterName = Reactor
		StartActionName = Start Reactor
		StopActionName = Stop Reactor
		FillAmount = 0.99
		AutoShutdown = true
		GeneratesHeat = true
		TemperatureModifier = 80
		UseSpecializationBonus = false
		DefaultShutoffTemp = 0.8

		INPUT_RESOURCE
		{
			ResourceName = Uraninite
			Ratio = 0.00001875
			FlowMode = STAGE_PRIORITY_FLOW
		}

		OUTPUT_RESOURCE
		 {
			ResourceName = ElectricCharge
			Ratio = 50
			DumpExcess = false
		 }
	}

[Lucius]

Anyone interested in a basic tweakscale config for FASA?

It's not incredibly in depth, nor commented well, but it's a great base as i've combed over several hours worth of the meat work to get the tanks and engines scaling properly.

[pellinor]

The traditional style of TweakScale was to slap a scaling module on everything, if it makes sense or not. I already cut that down a bit by making crew pod scaling optional (it did not work well both visually and from a gameplay view).

After playing some time with KIS, I see another reason why some parts might be better off without a TweakScale module: Stackability. Items can only be stacked in KIS containers if they are guaranteed to be equal, i.e. they have no internal states (like the amount of fuel in a tank or the size of a scaleable part). With the limited number of inventory slots, stacking is extremely useful for small things that are used in larger quantities, like

* KAS pipes/struts

* the small ladder

anything else? I see a conflict for quite a few things, like it is nice to always have a pile of small girders ready but these are also valuable for scaling (in my playing install I currently use the AES beam for stacking, keeping the stock girders scaleable).

[pellinor]

small dev update: support for HX parts from B9-Aerospace

[n0xiety]

Could you make it so that we can scale the wings accordingly to fuel tanks and utilities? When i create a 10000m fuel tank for my plane i can only tweak the wings %400 which becomes really small near the huge tanks. If there is a way to tweak it in files please inform me aswell. Trying to build a behamoth spaceplane yet wings are not getting big enough. If you ask me removing the cap on tweak size alltogether would be alot better. Maybe an interface available in VAB and SPH that allows us to set the tweak cap since some people still might want the cap for whatever reason.

Edit:

Noticed Mk-3 to Mk-2 adapter cannot be tweaked enough to fit even 5000m MK-2 Fuel tanks. I honestly don't understand why there is cap. Thanks for all your work tho one of the greatest mods.

Mk-2 Drone core not using the energy it should use causing near infinite energy in big crafts.

I don't know if this is intended or not but drag seems a bit off to me when parts are scaled. I have an ssto spaceplane that can reach orbit with little fuel and decided to tweak it. Everything got scaled up so i should expect the same kind of behavior but that doesn't happen. When i reached orbit i had more than %60 fuel while the stock one only had %10. Maybe fuel usage of rapier is wrong.

Edited June 3, 2015 by n0xiety

[pellinor]

Could you make it so that we can scale the wings accordingly to fuel tanks and utilities?

Look into DefaultScales.cfg, this contains the increment sizes of the interface. You can edit the file directly or (better) change the values with a ModuleManager patch. The default of 400% was chosen because most models become too ugly to use at this size. The limits only exist because the tweakable needs finite ranges.

Mk-2 Drone core not using the energy it should use causing near infinite energy in big crafts. I don't know if this is intended or not but drag seems a bit off to me when parts are scaled. I have an ssto spaceplane that can reach orbit with little fuel and decided to tweak it. Everything got scaled up so i should expect the same kind of behavior but that doesn't happen. When i reached orbit i had more than %60 fuel while the stock one only had %10. Maybe fuel usage of rapier is wrong.

When doubling the size of a massive object, mass increases 8-fold and area increases 4-fold. So I'd expect that massive crafts have better drag properties than small ones. For the probe core, I'd say the same computer in a larger case does not need more energy. For the reaction wheel I think there was a known issue that consumption does not scale at the moment.