[0.23.5] Goodspeed Aerospace Parts v2014.4.1B

[Castun]

Fixed! ...hopefully. However, what you're doing there won't really work the way you probably want it to. If you look at the comment after defaultScale = 1, you'll see that a value of 1 means it's a 1.25m part. Not every single part in the game is. If you do what you've done above, then place a 2.5m part, the scaling on it will be wrong - a value of 0 will make it a 1.25m part, 2 will make it 5m, 3 will be 7.5m and 4 will be 10m. For a smaller part the result will be the opposite - 0 will be 31.25cm, 2 will be 1.25m, 3 will be 1.875m, and 4 will be 2.5m.

Instead, you will have to make a ModuleManager config for every part, and set defaultScale accordingly.

I know, I just wanted to test that it would work. I grabbed that .dll and it still didn't work, not sure if ModuleManager is even loading the config properly or what, or if it doesn't like the wildcards used. Manually putting in the module code works fine. EDIT: Got it working, think I forgot a bracket or something somewhere.

Are there any plans to support 'smoother' resizing like what is possible with other procedural parts mods?

Edited May 5, 2014 by Castun

[HoneyFox]

Judging by your earlier post:

...snip...

this is rather likely to be the problem.

If you are setting defaultScale correctly per part (0 for 62.5cm parts, 1 for 1.25m and so on), and the scale is still wrong, please give some more information, and I'll see if I can figure it out. You could even post the .cfg files.

Now #2... there is nothing in Scale.dll that even remotely involves the camera. Are you sure it's this plugin? If the problem only occurs with this plugin, does it disappear if no other plugins are used? Can you identify a minimal set of plugins that gives this problem?

So the problem is: how should I set defaultScale values for one part?

Some parts have "scale = " or "rescaleFactor = " ... in part.cfg.

Some parts uses "MODEL {... scale = ...}" as well as "scale = ",

What value should I use for these? I don't think I can simply use 0 for 62.5cm parts and 1 for 1.25m parts, 2 for 2.5m parts, 3 for 3.75m parts, 4 for 5m parts ... based on *what size I think it is* or *what size it looks like*.

P.S. some plugins like ProcFairings' interstage adapters and RealChutes utilize part scaling as well, and will be locked by the TweakScale so I guess I need to add some exceptions.

Edited May 5, 2014 by HoneyFox

[Biotronic]

So the problem is: how should I set defaultScale values for one part?

Some parts have "scale = " or "rescaleFactor = " ... in part.cfg.

Some parts uses "MODEL {... scale = ...}" as well as "scale = ",

What value should I use for these? I don't think I can simply use 0 for 62.5cm parts and 1 for 1.25m parts, 2 for 2.5m parts, 3 for 3.75m parts, 4 for 5m parts ... based on *what size I think it is* or *what size it looks like*.

Actually, you can, and that's exactly what you should.

MODEL { scale = ... }, scale = ..., and rescaleFactor = ... are all completely irrelevant to TweakScale. For stack parts (engines, fuel tanks, fuselage, RCS tanks, science laboratories, what have you - place the part on top of a 2.5m stack part. If it's the same diameter, defaultScale should be 2. If it's smaller, check if it's 1.25m. If so, defaultScale should be 1, and so on. If it's not a stack part, it might be that the default scaling is wrong, and you can read my answer to phoenix_ca above for a solution.

defaultScale is simply a place to start - when you place a part in the editor, it will have the default scale that KSP thinks it should have, and the TweakScale slider should reflect that. If KSP thinks it is a 2.5m part, then the TweakScale slider should read 2, so that setting the slider to 1 makes it a 1.25m part.

If the plugin was to determine the scale automatically, it would need to do some advanced heuristics. It might work with fuel tanks and some other stack parts, but what about solar panels? Antennae? Stack parts that can unfold, like KSP Interstellar's solar sail or KOSMOS's Balka solar panels?

If all stock parts and all mod parts were scaled for 2.5m, we could leave defaultScale at 2 all the time. As it is, it is necessary to customize for each part. Without an imperial ****-ton (imperial ****-tons are larger, right?) of work that will likely not give a satisfactory result, this is the best solution.

[Biotronic]

I know, I just wanted to test that it would work. I grabbed that .dll and it still didn't work, not sure if ModuleManager is even loading the config properly or what, or if it doesn't like the wildcards used. Manually putting in the module code works fine. EDIT: Got it working, think I forgot a bracket or something somewhere.

Are there any plans to support 'smoother' resizing like what is possible with other procedural parts mods?

That's actually already possible:

MODULE
{
    name = GoodspeedTweakScale
    freeScale = true // Default false
    stepIncrement = 0.1 // Default 0.01 when freeScale is true
}

With this module definition, you can scale your part from half scale up to 4x scale in 10% increments. By changing stepIncrement, you can fine-tune the smoothness.

[phoenix_ca]

Yeeeah. That plugin is more interesting than all the parts combined. >.>

[Biotronic]

Yeah, I'm not sure how Gaius feels about that. On the one hand, I feel I should make a separate topic for the plugin, on the other, that feels like I'm stealing the plugin.

[Castun]

That's actually already possible:

MODULE
{
    name = GoodspeedTweakScale
    freeScale = true // Default false
    stepIncrement = 0.1 // Default 0.01 when freeScale is true
}

With this module definition, you can scale your part from half scale up to 4x scale in 10% increments. By changing stepIncrement, you can fine-tune the smoothness.

Thanks, that works pretty well. I used 0.05. For the part I was trying to resize however (which was the stock spotlights) I was having an issue trying to smoothly resize it: the menu jumps everytime you resize it so you can't just click and drag the slider as every increment breaks the click since the menu moves. PFairings parts dynamically change size and other variables when you click & drag the slider, whereas this plugin seems to kill the part and reload that increment size which is why the menu jumps.

Another question (and I realize my application of the plugin is probably going beyond the scope of what it was originally intended for) but is it possible to allow an even wider range of scaling? Like right now, it can only go down to 0. If the default scale is 1 for the spotlight, will changing the default scale to 2 just means it defaults to bigger? I manually cloned the two stock lights to have a rescalefactor of .25 which is about the size I needed, but rescaling the original stock one down to 0 is still a decent amount larger.

EDIT: So yeah, by limiting the min & max scale from 0 to 2, this enabled the minimum size to be much smaller for some reason, whereas the default 0 to 4 didn't let it go that small. Seems that 0.25 scale matches perfectly with the manually rescaled .25 light.

Just before I found this mod, I even applied the PFairings module to the stock light to test it out. It resizes smoothly, but for surface mount parts it doesn't scale the attachment node, so it floats. One of these days maybe I'll get around to comparing the source code between the two and see if I can tweak it.

Edited May 5, 2014 by Castun

[HoneyFox]

defaultScale is simply a place to start - when you place a part in the editor, it will have the default scale that KSP thinks it should have, and the TweakScale slider should reflect that. If KSP thinks it is a 2.5m part, then the TweakScale slider should read 2, so that setting the slider to 1 makes it a 1.25m part.

Wait a minute... what do you mean by "if KSP thinks it is a 2.5m part"? I don't think KSP even needs to think about it.

And some mod parts might have non-uniform scale in its own model, that's the problem I was wondering about:

the TweakScale plugin seems to adjust the model gameObject (or a child gameObject of it) 's transform.localScale, what if that localScale is not {1,1,1} initially?

EDIT: alright it seems like TS is just scaling the localScale, that should be no problem then...

One thing I feel strange is: although I haven't added any defaultScale definition in the .cfg so that all parts use 1 by default (according to the source-code), some of these 2.5m/3.75m/5.0m parts (some parts from AIES/NovaPunch2) seem to be working normally while almost all parts from KW (no matter if it's 1.25m or 2.5m or 3.75m) don't behave correctly.

Edited May 6, 2014 by HoneyFox

[Biotronic]

Wait a minute... what do you mean by "if KSP thinks it is a 2.5m part"? I don't think KSP even needs to think about it.

When a part is placed in the editor, it has some size. Let's call that the default size. No matter if the part uses TweakScale or not, it will have the same default size - TweakScale does not change the size of a part until the user changes the scale slider.

The default size is a result of how the model file looks, what scale is used in the MODEL{} block, and the rescaleFactor.

If the default size is such that it fits on a 2.5m part, we call it a 2.5m part. If it's a 2.5m part, TweakScale's defaultScale should be set to 2.

I'm not sure how many ways I can describe this - the default size is what I refer to when I say KSP thinks something is a 2.5m part.

One thing I feel strange is: although I haven't added any defaultScale definition in the .cfg so that all parts use 1 by default (according to the source-code), some of these 2.5m/3.75m/5.0m parts (some parts from AIES/NovaPunch2) seem to be working normally while almost all parts from KW (no matter if it's 1.25m or 2.5m or 3.75m) don't behave correctly.

Now that IS weird.

Edited May 6, 2014 by Biotronic

[Castun]

I remember someone else mentioning that KW parts don't rescale properly with the mod too.

[Biotronic]

Thanks, that works pretty well. I used 0.05. For the part I was trying to resize however (which was the stock spotlights) I was having an issue trying to smoothly resize it: the menu jumps everytime you resize it so you can't just click and drag the slider as every increment breaks the click since the menu moves. PFairings parts dynamically change size and other variables when you click & drag the slider, whereas this plugin seems to kill the part and reload that increment size which is why the menu jumps.

The reason it does this is because it marks the menu as dirty whenever something changes. This causes the menu to be redrawn, and updates the values for all resources. If this was not done, the values shown would be wrong. I guess it could be disabled for all parts that do not hold fuel or other resources. This is still not a solution I like, though. On the other hand, with free scaling, the current solution is horrible. I guess not updating the menu is the lesser evil.

EDIT: So yeah, by limiting the min & max scale from 0 to 2, this enabled the minimum size to be much smaller for some reason, whereas the default 0 to 4 didn't let it go that small. Seems that 0.25 scale matches perfectly with the manually rescaled .25 light.

I'm not sure I understand - the same part, with the same defaultScale, has a different minimum size when maxScale is 2 than when it's 4?

[ZodiusInfuser]

I just have to say, thanks Gaius and Biotronic for your work on this plugin. This has allowed me to avoid duplicating the parts in my Infernal Robotics Model rework by 3

[Biotronic]

I can't speak for Gaius, but it's certainly been a pleasure to me. Great work on those parts, btw!

[sirkut]

I just have to say, thanks Gaius and Biotronic for your work on this plugin. This has allowed me to avoid duplicating the parts in my Infernal Robotics Model rework by 3

I couldn't agree more. This certainly unbloats the parts list for robotic parts.

[Biotronic]

Oh, and another update! This time, support for solar panels, you can now drag the slider (only for freeScale or parts without resources, as a test), and mass can be coupled to surface area and diameter in addition to volume (for parts where thickness would be unchanged with scaling, like solar sails, solar panels, etc).

MODULE
{
    name = GoodspeedTweakScale
    massFactors = 0, 1, 0 // Scale with surface area, not volume
}

Oh, and because it's unlikely something will scale only with surface area:

MODULE
{
    name = GoodspeedTweakScale
    massFactors = 0, 0.9, 0.2 // Scale with surface area, not volume
}

might be more realistic.

Edited May 6, 2014 by Biotronic
Clarification of massFactors

[Castun]

The reason it does this is because it marks the menu as dirty whenever something changes. This causes the menu to be redrawn, and updates the values for all resources. If this was not done, the values shown would be wrong. I guess it could be disabled for all parts that do not hold fuel or other resources. This is still not a solution I like, though. On the other hand, with free scaling, the current solution is horrible. I guess not updating the menu is the lesser evil.

I'm not sure I understand - the same part, with the same defaultScale, has a different minimum size when maxScale is 2 than when it's 4?

Yes, I'll take a couple comparison shots when I get a chance. I couldn't get it small enough until I set the max scale to 2.

Oh, and another update! This time, support for solar panels, you can now drag the slider (only for freeScale or parts without resources, as a test), and mass can be coupled to surface area and diameter in addition to volume (for parts where thickness would be unchanged with scaling, like solar sails, solar panels, etc).

MODULE
{
    name = GoodspeedTweakScale
    massFactors = 0, 1, 0 // Scale with surface area, not volume
}

Oh awesome! Is the energy generated also scaled appropriately then?

Edited May 6, 2014 by Castun

[Biotronic]

For solar panels? Yeah, that's the support I'm talking about.

[Biotronic]

I'm on a roll!

New features: Reaction wheels, engines(!!!), and lots of KSP Interstellar parts. See the repository for a list of all features.

[Biotronic]

Apparently there are some problems with getting correct updates for some parts. Will have a look-see at that tomorrow, but now it's 04:24 here, so I'll go to sleep.

[HoneyFox]

I'm on a roll!

New features: Reaction wheels, engines(!!!), and lots of KSP Interstellar parts. See the repository for a list of all features.

Engines!!!??? Oh-YEEESSSS!!!

EDIT: Checked the source-codes. and:

1. Don't forget the ModuleEnginesFX

2. Can you add support for ModuleEngineConfigs from RealFuels/ModularFuelTanks? Currently TS modify the engine's max/minThrust directly in OnStart(), but that might be overridden by RF/MFT. Should work well for non-MEC engines though.

Edited May 7, 2014 by HoneyFox

[phoenix_ca]

I'm on a roll!

New features: Reaction wheels, engines(!!!), and lots of KSP Interstellar parts. See the repository for a list of all features.

Dude. That is fantastic (I've always wanted to scale-down the B9 Atlas to a 1.25m size). You should make your own development thread. Expanding on TweakScale could be the best thing since Module Manager for modded KSP installs. Just...imagine a world where we didn't need 3 different parts for 1.25m, 2.5m, and 3.75m. Just one. Good god that'd be glorious.

If possible, it'd be very nifty to see single-axis scaling, to support trusses/I-beams and the like. Things where it makes sense to scale them say, lengthwise, but not in any other direction. Or, is that what you mean by "free scaling"? Because if it is...well **** me with a bagel. That's awesome.

2. Can you add support for ModuleEngineConfigs from RealFuels/ModularFuelTanks? Currently TS modify the engine's max/minThrust directly in OnStart(), but that might be overridden by RF/MFT. Should work well for non-MEC engines though.

See the github:

Integration with Modular Fuel Tanks!

Will automatically update MFT's volume and the volume of existing tanks.

I sincerely hope this sees some serious wide-spread acceptance by other mods when you're done. Part-count reductions abound. We might be able to actually get piles and piles of parts with the 3.4GB limit. (No more finagling the Linux copy to work.)

Edited May 7, 2014 by phoenix_ca

[HoneyFox]

Dude. That is fantastic (I've always wanted to scale-down the B9 Atlas to a 1.25m size). You should make your own development thread. Expanding on TweakScale could be the best thing since Module Manager for modded KSP installs. Just...imagine a world where we didn't need 3 different parts for 1.25m, 2.5m, and 3.75m. Just one. Good god that'd be glorious.

If possible, it'd be very nifty to see single-axis scaling, to support trusses/I-beams and the like. Things where it makes sense to scale them say, lengthwise, but not in any other direction. Or, is that what you mean by "free scaling"? Because if it is...well **** me with a bagel. That's awesome.

See the github:

I sincerely hope this sees some serious wide-spread acceptance by other mods when you're done. Part-count reductions abound. We might be able to actually get piles and piles of parts with the 3.4GB limit. (No more finagling the Linux copy to work.)

You didn't get my point... and I've checked the source-code at GitHub.

ModuleEngineConfigs is a different module from the ModuleFuelTanks, it adjusts the engine's performance/propellants while the latter one give customizable-fuel-amount capability.

[phoenix_ca]

You didn't get my point... and I've checked the source-code at GitHub.

*facepalm* I read that wrong. My bad.

[Castun]

I just made a discovery by total accident...your command modules which all rely on the stock command module textures? When using Texture Replacer to replace the textures for the same stock command modules, it causes issues. Sometimes your parts have corrupted looking textures, but even worse, sometimes it causes the stock parts to have corrupted textures instead.

I was using the KSRPC mod which replaces some textures using Texture Replacer, and just earlier today noticed the Squad capsules all had goofy texture issues which did not exist before I installed your mod:

[Biotronic]

I'm testing a new way of scaling. Currently you have the simple numbers 0, 1, 2, 3, 4. I want 0.625, 1.25, 2.5, 3.75 and 5. This new test version does that, but I'm not sure I'm more happy with how it works. Feedback pl0x?

Also, the regular version has been updated with booster support (also included in the test version).