Jump to content

[WIP] TweakScale - Development Thread


pellinor

Recommended Posts

See also the release thread!

TweakScale was originally developed by Goodspeed and Biotronic. [original release thread]

This work started as a fork to make a feature I wanted for a long time, comfortable free scaling for everything. Since Biotronic has no more time to support the mod, this has also grown into a maintainence thread for TweakScale.

Source: Github

License: WTFPL

Download

Latest dev version (WIP)

Stable Version

Change Log

ToDo / Ideas

  • see the issues on GitHub
  • Sort out interference with tweakable everything
  • Support for D12Aerospace
  • subassembly-scaling, a config file for setting of hotkeys
Edited by pellinor
Link to comment
Share on other sites

If you're interested in stuff to put on "the list" for TweakScale's future... I have two things I can think of off the top of my head:

1) Infernal Robotics *full* support. Yes, it sort of works right now - but very weird things happen when you scale IR parts up. Scaling them down (like their default configs allow) works, but even if you write a correctconfig for scaling them up, weird things happen after 1.5x or 2x size.

2) Updates to scale exponents for the new way Regolith does resource harvesters and converters - fully compatible scaling for drills and distillers and whatnot. For drills, the amount of resources extracted currently can be made to scale easily, but don't know about the other stuff (like electricity consumption - the recipe inputs). For converters, I just couldn't figure out how to correctly write a scale exponent thingamajig because of the lists of values Regolith uses in its configs.

Thanks for working on this! It would have been immensely sad to see TweakScale founder and die.

Link to comment
Share on other sites

What I'm gathering from this posting is that this new maintainer/developer did not change anything that would break support from other mods. This should, in effect, make all other questions regarding "does this work for this mod or that mod" completely pointless. I'm sure the last thing this developer wants is to completely screw over everyone who makes use of this mod in their own mods.

Link to comment
Share on other sites

I'd like to discuss how auto scaling works, or is supposed to behave in the future, with respect to parts from different scaletypes. Here is my view on the subject (might be limited because I don't really use the function yet).

Auto-scaling for stack parts seems clear and well-defined to me: stack parts those have an interface with a diameter and a corresponding stack node. If I auto-scale a new part such that its node matches a target node, I will always get a smooth stack.

For other parts however, the node sizes are quite arbitrary. So I'm not sure if the above rule is any help. For example, the TrussGirderXL has 1.25m-nodes. So if I attach it to the top of a MK1 pod, it is auto-scaled to 50%. Does not make much sense to me. If both parts are identical, it makes sense again to autoscale them to the same size.

Maybe the solution here is to make the autoscaling ability a property of a scaletype, and only work within that scaletype. Then we can set it true for 'stack', false for 'free'. And if someone has a set of parts that should be compatible with each other (like the IR hinges), he can define a custom scaletype with autoscale=true. Then IR hinges would autoscale with other IR-compatible parts but not jump to strange scales when connected to a stock stack part.

At the moment autoscale only works via stack nodes, not for radially attached parts. I don't see wyh (or how) this should change.

Link to comment
Share on other sites

If you're interested in stuff to put on "the list" for TweakScale's future... I have two things I can think of off the top of my head:

1) Infernal Robotics *full* support. Yes, it sort of works right now - but very weird things happen when you scale IR parts up. Scaling them down (like their default configs allow) works, but even if you write a correct config for scaling them up, weird things happen after 1.5x or 2x size.

And this all really comes down to the limitations of the IR parts as well as the engine's limits. I have, however, scaled them up to those sizes with no negative effects being noticed because I exported all of their specific scaling settings from the part configs to separate scaletypes. This allowed me to properly set up the exponential variables so that they functioned properly without having to sift through each and every part specifically.

But... that's a lot of work for the casual user and not something everyone is capable of. I think, however, that issue would be one to take up with the developer of IR. Tweakscale is scaling the values it's being told to in the correct way, it's the IR code that isn't handling the range of numbers in a very efficient or correct way (theoretically, I haven't code dived into IR in a long time.)

- - - Updated - - -

Maybe the solution here is to make the autoscaling ability a property of a scaletype, and only work within that scaletype. Then we can set it true for 'stack', false for 'free'. And if someone has a set of parts that should be compatible with each other (like the IR hinges), he can define a custom scaletype with autoscale=true. Then IR hinges would autoscale with other IR-compatible parts but not jump to strange scales when connected to a stock stack part.

I like this. I mean, I really freakishly like this.

Link to comment
Share on other sites

Now the same for chain scaling. Reading the code, chain scaling propagates an autoscale-command from a part to its children. Probably whenever the parent part is rescaled, but I am not sompletely sure. This also means that chain scaling is only applicable along a chain of auto-scalable parts.

So if I chain scale a stack of random parts, I will end up with a smooth rocket. Is this the intended use case?

Link to comment
Share on other sites

To be perfectly honest, unless auto- and chain-scaling worked perfectly and all the time, it'd quickly become more annoying than useful. Count how many people asked how to turn it off vs how many people liked it in the other thread. That's simply because it didn't work the way people expected it to (for example, attaching the Mk16 chute on top of the Mk1 pod made it default to 1.25m). By all means include it and work on it, it's a great idea, but make it default to off with an option to hold Shift while attaching to toggle it on or something. Disclaimer: For me personally, auto- and chain-scaling were one of the least desired features of TweakScale. If I wanted a part to be a different size than normal, I'd make it so. I don't want the mod to keep making that decision for me until I tell it not to.

That said, I do like it being a property of a scaletype. Would stop a lot of weirdness, for sure.

Link to comment
Share on other sites

To be honest, if it were me working on this (and thank goodness it's not, because I can't code), I would completely abandon the very idea ofautoscaling. Needless complexity, and it takes time you could dedicate to other things. There are so very few use cases for it - and in every single one of those cases, the drawback is just having to click on a part you just attached and scale it to whatever value it's supposed to be. Then, you can just duplicate that part if you need a bunch of them. It is a clever idea for the sake of a clever idea and not one that is really necessary or useful for the function of the mod in *almost all* cases.

Stack nodes are a terrible way of determining the size to which a part should autoscale, too - they do not necessarily correspond to the part's size, and especially not the size at the location of the particular stack node in question. That further reduces the number of cases in which autoscaling scaling actually make sense.

Really, you would need to add a value to every single part in the game such as "actualsizeofthispartatnode_1 = 1.28985m" to implement autoscaling in a meaningful way.

My two cents, others may disagree.

UPDATED the post because I included chainscaling without thinking about it. Really, I mean autoscaling.

Edited by AccidentalDisassembly
Link to comment
Share on other sites

It looks like chain scaling was changed after the 1.47 update. In .47 all children parts were rescaled, and it wasn't dependent if the parts were stacked or radially attached. It was possible to

, just by rescaling the parent part. You probably have to look at the older code or ask Biotronic.
Link to comment
Share on other sites

Stack nodes are a terrible way of determining the size to which a part should autoscale, too - they do not necessarily correspond to the part's size, and especially not the size at the location of the particular stack node in question. That further reduces the number of cases in which autoscaling/chain scaling actually make sense.

Actually the latest version works perfectly for stack parts. Even adapters with multiple node sizes. Only prerequisite is that in the original part every node corresponds to a circular area of the corresponding diameter. If a part does not satisfy this condition, it should not have the stack scaletype.

I'm also not the biggest fan of those functions, it just would be bad to throw them away even before understanding how they are supposed to behave and what people use them for. A restriction to stack-like scaletypes actually looks like a simple solution to only use them in cases where they already work well.

Link to comment
Share on other sites

Actually the latest version works perfectly for stack parts. Even adapters with multiple node sizes. Only prerequisite is that in the original part every node corresponds to a circular area of the corresponding diameter. If a part does not satisfy this condition, it should not have the stack scaletype.

I'm also not the biggest fan of those functions, it just would be bad to throw them away even before understanding how they are supposed to behave and what people use them for. A restriction to stack-like scaletypes actually looks like a simple solution to only use them in cases where they already work well.

But this all assumes that every maker of parts will use size 1 nodes specifically for 1.25m parts, size 2 for 2.5m parts, etc. etc.

What about intermediate sizes? I don't recall intermediate node sizes even existing (is there even such thing as a size 1.58 node?), so what happens with something like a 1.5m or 1.875m part? Granted, there are fewer of those.

What if I just want a strong connection on a 0.625m part and give it a size 4 node? Etc. etc.

I dunno. Maybe it's not a lot of work - and obviously you can do whatever you want, I'm not the one putting time into this!

I do think the chain scaling has more possible uses, though, since you could just totally resize an entire craft with it (in theory), or an entire subassembly, or something like that.

Link to comment
Share on other sites

But this all assumes that every maker of parts will use size 1 nodes specifically for 1.25m parts, size 2 for 2.5m parts, etc. etc.

Would just like to point out that even stock has errors - the large reaction wheel uses too small attach nodes, and the structural panels are incorrect as well. The reason I know this? FAR changes them to be correct in order to calculate drag right. So yeah, you'd have to work around (or with) that too..

Link to comment
Share on other sites

The way Autoscaling was supposed to work was each part/scaletype has a list of nodes and their expected sizes. So a Mk1-2 Command Pod (scaletype: adapter_2_1) has a node called top, with a size of 1/2, and a node called bottom with a size of 2/2. So if this part is scaled to 2.5m to 1.25m, the part scale is 2.5, the top node is 2.5*1/2 = 1.25, and the bottom node is 2.5*2/2 = 2.5. The node sizes (as specified in parts) does not factor in at all.

This is specified in the DefaultScales.cfg file:

SCALETYPE
{
name = adapter_2_1
freeScale = false
scaleFactors = 1.25, 2.5, 5.0, 7.5
scaleNames = 1.25m to 62.5cm, 2.5m to 1.25m, 5m to 2.5m, 7.5m to 3.75m
defaultScale = 1.25
ATTACHNODES
{
base = 2
top = Stack:1
bottom = Stack:2
bottom01 = Stack:2
bottom02 = Stack:2
}
}

"But why use the top-divided-by-base system, why not simply use top=0.5?!?" you might ask. It's a very reasonable question. The problem with that idea appears when when you have a 3:1 adapter. Should I then use top=0.33? top=0.333333333? Top=0.3, and then a fuzziness factor?

Link to comment
Share on other sites

I stumbled upon a gamebreaking bug which involves 3 mods: KAS, Regolith and TweakScale.

Output_log.txt

When I take a scaleable part from a container TweakScale starts a log spam. The error is not present if I remove Regolith.dll from the install. Occurs in both this dev and 1.50 versions of Tweakscale.

If I let the error spam to dwell long enough the game crashes.

Link to comment
Share on other sites

I was not happy with those node lists because they make assumptions about node names in arbitrary part files, and in most cases just bring in redundant information. Like the stock 4-way adapter did not autoscale properly because the scaletype was only designed for two bottom nodes. So I'll consult the prefab part as a default, and maybe bring the lists back as a way to address special cases.

There will probably be an extra scaletype for non-stack parts which like to be measured in m instead of %.

What about intermediate sizes? I don't recall intermediate node sizes even existing (is there even such thing as a size 1.58 node?), so what happens with something like a 1.5m or 1.875m part? Granted, there are fewer of those.

I do think the chain scaling has more possible uses, though, since you could just totally resize an entire craft with it (in theory), or an entire subassembly, or something like that.

Good point about intermediate sizes. In the current system an 1.5m mod would need its own scaletype, and you would scale connections between 1.5m and stock parts manually.

For chain scaling I tend to keep the 'propagate autoscaling across compatible nodes' approach for now, until freescaling has some stability. Then I'll test a 'propagate change of scale across the whole subassembly approach'.

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...