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

[Taverius]

I actually haven't tried this yet (too busy updating B9) but here's some notes on scaling and stock balance from making Pizza and B9:

• 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.
  

• Engine heat is related to thrust/mass ratio. For example, if you scale an engine by just doubling its thrust and mass, heat stays the same, as ratio is identical.
  

• Non-FAR wings are an unholy mess of random values. The code in pWings to scale lift/drag (which I wrote) is probably your best bet for hints on scaling those in a pseudo-realistic way, but abandon all hope of taking 2 stock wings of similar shape and scaling them to be the same size and getting the same values, unless a) you use my code from pWings and you're stating from Pizza Pack lift/drag values.
  The stock lift/drag values are just semi-random numbers C7 and Nova put in way back when, and have little to no relation to the actual dimensions of the wings, not even the surface area.
  The first rule of rescaling wings is: drag scales with mass and lift, so as you change the mass and lift of a wing when you rescale, the dragCoefficient does not change. It is determined purely by the shape of the airfoil.
  

• Intakes are horrific. Specifically, their drag scales with mass as with everything else, so changing the mass of an intake when resizing can drastically alter performance in unexpected ways. There's 3 variables you can use to fix it so a smaller area (to give the right drag for the mass) performs like one of the right size, but because of a bug in the code, one of the values is used twice.
  The formulas are:
  
  • area: divide by (mass/0.01). Intake drag in stock assumes an intake weighs 0.01. This means that the stock Air Scoop (mass 0.1) has 10x the drag it should.
    
  • unitScalar: default is 0.2, multiply by sqroot(mass / 0.01). supposedly a flat multiplier on the amount of air coming in, buut.
    
  • maxIntakeSpeed: default is 100, * (unitScalar + sqroot(mass / 0.01)) / (unitScalar + 1). Is used twice in the code instead of once. written as intakeSpeed in the stock .cfgs ... which is a parameter the module does not have.
    

  [*]Also, when shrinking intakes, its best to not change the amount of IntakeAir they can store, or you can get rolling flameouts on the runway even though you technically have enough airflow, just because of how resource requests work.

Edited May 21, 2014 by Taverius

[CaptainKipard]

It looks like some parts which are scaled in their configs, aren't scaled correctly, e.g. the 1.25m KW nose cone is suddenly smaller than 1.25m.

[BrutalRIP]

engines and decouplers also

[Kolago]

I am confused with KSPAPIExtensions.dll.

I have 3 Version in GameData:

C:\Kerbal Space Program 235\GameData\TweakScale\plugins v1.4.3.12

C:\Kerbal Space Program 235\GameData\ProceduralParts\Plugins v1.4.2.0

C:\Kerbal Space Program 235\GameData\ProceduralFairings v1.4.1.0

ProceduralParts is broken, nodes are in mid air, texture change is gone.

ProceduralFairings looks ok.

[sirkut]

I am confused with KSPAPIExtensions.dll.

I have 3 Version in GameData:

C:\Kerbal Space Program 235\GameData\TweakScale\plugins v1.4.3.12

C:\Kerbal Space Program 235\GameData\ProceduralParts\Plugins v1.4.2.0

C:\Kerbal Space Program 235\GameData\ProceduralFairings v1.4.1.0

ProceduralParts is broken, nodes are in mid air, texture change is gone.

ProceduralFairings looks ok.

That's most likely because the ProceduralFairings KSPAPIExtensions dll is being loaded first due to it being alphabetically first compared to the other 2 directories.

[CaptainKipard]

Should I delete KSPAPIExtensions from procedural fairings?

Could this be the reason for the scaling problems?

Is Procedural Fairings updated for the new dll?

[sirkut]

Should I delete KSPAPIExtensions from procedural fairings?

Could this be the reason for the scaling problems?

Is Procedural Fairings updated for the new dll?

You will probably run into problems because it would appear that each mod has been compiled using a different version of KSPAPIExtensions. This is what I ran into with TweakScale:

http://forum.kerbalspaceprogram.com/threads/80234-TweakScale-Rescale-Everything%21-%28Version-1-5-0-1-Updated-2014-05-21-00-36-UTC%29?p=1170185&viewfull=1#post1170185

Now you can try it and if it doesn't work you can check the logfile and see if you get the same error that I did.

[Kolago]

Newest ProceduralFairings is v3.01, thats the one I have installed.

ProceduralParts was v0.9.9, now I have the newest (v0.9.10) installed with KSPAPIExtensions.dll v1.4.3.1. But still broken.

Will renaming directory's to get a different load order do something useful? These dependences are a mess.

Renaming the TweakScale directory to 1TweakScale doesn't work.

Edited May 21, 2014 by Kolago

[Gaalidas]

I'm having a problem that seems to be identical to the other ones considering the API extensions being the wrong version for a specific mod, except that it's stopping the entire game from even loading. I use procedural fairings more than scaling, so I'm going to have to choose that way until you all can get this dll stabilized properly.

[sirkut]

Newest ProceduralFairings is v3.01, thats the one I have installed.

ProceduralParts was v0.9.9, now I have the newest (v0.9.10) installed with KSPAPIExtensions.dll v1.4.3.1. But still broken.

Will renaming directory's to get a different load order do something useful? These dependences are a mess.

Renaming the TweakScale directory to 1TweakScale doesn't work.

Renaming directories isn't going to make it work. If you have more than 1 mod that requires KSPAPIExtensions which happen to be different versions it will fail.

[marce]

swamp_ig pushed a new update so hopefully we will hear from Biotronic soon

[Biotronic]

I'm back! New version is up! This fixes the problem where parts get the wrong scale after loading/duplicating/changing scenes. Sorry about the long wait - yesterday did not look the way I planned it to be.

Currently looking into the scale problems with KW parts.

[Azimech]

But ... the DLL soap or should I say soup, continues. Which is kinda funny in a way. Just a bit impractical at times.

[marce]

But ... the DLL soap or should I say soup, continues. Which is kinda funny in a way. Just a bit impractical at times.

swamp_ig pointed out that each mod using the KSPAPIExtensions has to be compiled against and delivered with exactly this version.

As far as I understand it at the moment the three mod creators (TweakScale, PP & PF) have to provide new builds whenever one of the others is published wit a new version of KSPAPI. But that shouldn't be much of a problem when development for the KSPAPIExtensions slows I suppose.

Currently all 3 mods are working for me with a different KSPAPI dll each

[Biotronic]

I'm with marce on this - it works for me with all three installed, and three different KSPAPIExtensions.

A question to to other mod makers out there - TweakScale currently changes part.transform.GetChild(0).localScale. That's the way GoodspeedTweakScale did it, so I saw no good reason to change that. Now I see that removing GetChild(0) from that fixes the scale problems with KW parts. I don't really know why, as I haven't looked too closely at the values there, but it seems this change does good things and nothing bad. Any reasons why I shouldn't do this?

Scratch that, I just found plenty reasons not to do that.

Edited May 22, 2014 by Biotronic

[sirkut]

Just a heads up, TweakScale has a debugging statement that is spamming the output_log file:

TweakScale.Update() - !isFreeScale. TweakScale new value = 1

[sirkut]

Also, is there a method where you can use ScaleExponents.cfg to specify a specific part rather than a module?

[Biotronic]

Also, is there a method where you can use ScaleExponents.cfg to specify a specific part rather than a module?

Currently, no. But now that there's a demand, I guess you can expect it in a future update.

[sirkut]

Currently, no. But now that there's a demand, I guess you can expect it in a future update.

Great to hear. This would be a tremendous help. In fact it would be nice to somehow scale other values In a comma delimited format.

Don't forget the post I did previously.

[Biotronic]

Currently, no. But now that there's a demand, I guess you can expect it in a future update.

Actually, I'm gonna ask for a bit of clarification - do you mean that a specific part (say, IR_Pivotron_Basic) should have a different factor for some module parameter (say, keyRotateSpeed should scale with the cube of the scale)?

Or are you thinking of something else and I haven't quite understood what you meant?

[sirkut]

Here's the scenario:

Suppose I have an Infernal Robotic part called AdjustableRail

While resizing the actual size of the part is wonderful, it would be nice to resize the translateMin and the translateMax to be a comma separated list rather than just multiplying the scale to variables. This would also be beneficial for specific speed translations. If there was a way for the plugin to handle this without adding a dependency to TweakScale this would be useful.

[NathanKell]

I'm going to guess that the issue with KW parts is that they use MODEL nodes and non-1. rescaleFactors. Thus it'd be great if you could scale the part's own transform, but as you doubtless saw that will (IIRC) scale all its children. Well, you could try changing part.transform.localscale?

Anyway, to deal with the KW problem--do you currently multiply, or just set, the scale? If you're setting it, try reading the scale first, storing it, and then multiplying your scalefactor against it.

[blspblackdeath]

For me the stock 1.25 Tanks and engines are scaled wrong. The stack nodes are on the right places but the part is too little.

Which looks like that:

[falken]

Is this still breaking Procedural Parts?

[AccidentalDisassembly]

To add to what NathanKell is saying, there does seem to be a problem with parts that use a scale other than 1.0 inside the MODEL {} thing - for example, the 1.25m NovaPunch reaction wheel scales fine, but all the others appear in the VAB to be 1.25m in size to begin with but have nodes and strengths associated with their actual part size, I think... When I messed around with one of the KW engines and changed its scale to 1.0 inside the MODEL {} bit, it then scaled correctly too, although it still would appear to have moved up inside the fuel tank a bit on VAB reload.