[1.4.x] TweakScale v2.3.12(Apr-16)

[HurricanKai]

Im Writing a TweakScale Wiki (For Devs) at your Wiki Side at Github if you dont want this talk to me ill write a bit and then you can think of it

 

https://github.com/pellinor0/TweakScale/wiki

 

Have Fun 

HurricanKai

[HurricanKai]

On 9.3.2017 at 5:47 PM, Skalou said:

something like this can be more user friendly

https://twominutetutorials.wikispaces.com/Scale+Factors+of+Perimeter,+Area,+and+Volume

Is it like that? 

 

That woud mean if i take any SSTO and scale the hole think up (area) by a factor of 4 the colume of tanks and Wings woud increase by a factor of 8!

But that woud mean just scaling the SSTO up gives it more range?

 

What i want to say: Scaling up = more Delta V?

Edited March 17, 2017 by HurricanKai

[Loren Pechtel]

13 minutes ago, HurricanKai said:

Is it like that? 

 

That woud mean if i take any SSTO and scale the hole think up (area) by a factor of 4 the colume of tanks and Wings woud increase by a factor of 8!

But that woud mean just scaling the SSTO up gives it more range?

 

What i want to say: Scaling up = more Delta V?

No--while the fuel would go up by a factor of 8 so would the mass that fuel has to push.

You would get a bit further because drag wouldn't go up by a factor of 8, though.

[Fredde104]

On 2017-03-17 at 4:40 PM, HurricanKai said:

Im Writing a TweakScale Wiki (For Devs) at your Wiki Side at Github if you dont want this talk to me ill write a bit and then you can think of it

 

https://github.com/pellinor0/TweakScale/wiki

 

Have Fun 

HurricanKai

Thank you! This saved my project!

[Jasseji]

On 17.03.2017 at 4:40 PM, HurricanKai said:

Im Writing a TweakScale Wiki (For Devs) at your Wiki Side at Github if you dont want this talk to me ill write a bit and then you can think of it

 

https://github.com/pellinor0/TweakScale/wiki

 

Have Fun 

HurricanKai

Hello,

Can you elaborate perhaps on the type = parameter ?

For free rescale i understand it to be set as type = free but what about other scaling ?

I want to be able to rescale in measured increments, is it important to differenciate each part as type = stack ?

what are other possible values for type = ?

 

I wonder if this will work:

    MODULE
    {
        name = TweakScale  
        type = stack
        defaultScale = 3.75
    }

[HurricanKai]

11 hours ago, Fredde104 said:

Thank you! This saved my project!

@Fredde104No Problem

 

5 hours ago, Jasseji said:

    MODULE
    {
        name = TweakScale  
        type = stack
        defaultScale = 3.75
    }

@Jassejihmm, Ill have to look a bit into the code, right now i just had a look into the Example Configs....

[HurricanKai]

Anyone knows where to get the code? dotPeek cant Render those propertys in scale.dll/Tweakscale/Scaletype //I Think there shoud be the ScaleType Handler... (If this is done with Handleres?)

 

Ok, got it to work with ILspy

 

Edit2: Ok, I cant find the "type" register i just get a bunch of references which end up in System.Linq.Enumerable.First/IEnumeralbe TSoruce Funk TSource: TSource

 

Sorry @Jasseji But I cant Find any Further Information, I just havent got any sort of source code and the code isnt commented at all...

Edited March 19, 2017 by HurricanKai

[Jasseji]

2 hours ago, HurricanKai said:

Anyone knows where to get the code? dotPeek cant Render those propertys in scale.dll/Tweakscale/Scaletype //I Think there shoud be the ScaleType Handler... (If this is done with Handleres?)

 

Ok, got it to work with ILspy

 

Edit2: Ok, I cant find the "type" register i just get a bunch of references which end up in System.Linq.Enumerable.First/IEnumeralbe TSoruce Funk TSource: TSource

 

Sorry @Jasseji But I cant Find any Further Information, I just havent got any sort of source code and the code isnt commented at all...

No big deal, will work with trial and error

[Mikeloeven]

Does anyone have information on the free_square and stack_square types.  I cant find any info on these but they appear in several config files and seem to be used mostly for solar panels

[AccidentalDisassembly]

"Types" are defined in configs - they are shortcuts for telling the game what sizes/scales are allowed for a given part, what kind of increments the part scales in, and the exponents to apply to different properties of the part (like mass, or tank size, or whatever) when it's scaled.

free_square is the same as the free scale type, but the mass of a part that's scaled using free_square will be increased x4 for each doubling in size rather than x8 (exponent of 2 rather than 3).

[pellinor]

I'm happy to see some sharing of knowledge here. Feel free to use the wiki. There is also a bit of documentation here: https://github.com/pellinor0/TweakScale/blob/master/GameData/TweakScale/documentation.txt. I'll have a closer look at the wiki when I find the time, there seems to be a bit of confusion about how the stock/MM config syntax works.

On 19.3.2017 at 3:38 PM, Jasseji said:

Ok, I cant find the "type" register i just get a bunch of references which end up in System.Linq.Enumerable.First/IEnumeralbe TSoruce Funk TSource: TSource

Not sure what a 'register' is. The 'type' in a TweakScale MM patch refers to (the name of) a configNode of type SCALETYPE, like the ones found in DefaultScales.cfg. Those nodes define the behaviour of the UI and also act as an intermediate scope for scale exponents (this feature is used in the "*_square" scaletypes).

Other mods can bring their own scaleTypes, for example IR.

Edited March 22, 2017 by pellinor

[linuxgurugamer]

On 5/27/2015 at 2:33 PM, pellinor said:

TweakScale and tweakableEverything do not play well together, so stats might be off when you have both modules on the same part. Other than that they do not break anything

Could you contact me via PM, I'd like to see if we can fix this.

[eberkain]

I've been using tweakscale with an added step in between each size and have been enjoying it alot.  

0.35 ,0.625 ,0.9375 ,1.25 ,1.875 ,2.5 ,3.125 ,3.75 ,4.375 ,5.0 ,6.25 ,7.5

I wish there was a limiter built into the system, so that a part could only be scaled two steps up or down.  So my 1.25 meter fuel tank would be restricted from going any larger than 2.5 or smaller than 0.625.   But that shouldn't apply to all parts, like adapters I want to scale to anything as sometimes its hard to find the right one when dealing with the odd sizes. 

For the config file, what does incrementSlide do?  I didn't change it and things seem to work fine.  

[AccidentalDisassembly]

12 hours ago, eberkain said:

I've been using tweakscale with an added step in between each size and have been enjoying it alot.  

0.35 ,0.625 ,0.9375 ,1.25 ,1.875 ,2.5 ,3.125 ,3.75 ,4.375 ,5.0 ,6.25 ,7.5

I wish there was a limiter built into the system, so that a part could only be scaled two steps up or down.  So my 1.25 meter fuel tank would be restricted from going any larger than 2.5 or smaller than 0.625.   But that shouldn't apply to all parts, like adapters I want to scale to anything as sometimes its hard to find the right one when dealing with the odd sizes. 

For the config file, what does incrementSlide do?  I didn't change it and things seem to work fine.  

To piggyback on this, a feature I requested a long time ago would accomplish a similar thing - it would be neat if a part could only be scaled X increments up or down from its defaultScale, within whatever scaletype it's using, until a particular technology was researched. E.g. a 1.25m tank could only be scaled to 1.875m and down to 0.625m until you research large-volume containment: then it can go +/- two increments in the scaletype, so still 0.625m at the bottom (or whatever is the lower bound), but now 2.5m or 3.75m at the top end, and so forth. Could be neat, but maybe a lot of work...

Edited March 24, 2017 by AccidentalDisassembly

[pellinor]

13 hours ago, eberkain said:

For the config file, what does incrementSlide do?  I didn't change it and things seem to work fine.

This is the increment size for the slider (for each interval). It should be roughly small enough to give enough steps, and large enough so searching a particular value does not get too fiddly.

22 minutes ago, AccidentalDisassembly said:

it would be neat if a part could only be scaled X increments up or down from its defaultScale, within whatever scaletype it's using, until a particular technology was researched

I keep procrastinating this because it feels much like another piece of duct tape on an issue (proper restriction configs for career mode) that already has a config interface but is missing both a good concept and someone motivated to implement/balance it.

[eberkain]

15 minutes ago, pellinor said:

I keep procrastinating this because it feels much like another piece of duct tape on an issue (proper restriction configs for career mode) that already has a config interface but is missing both a good concept and someone motivated to implement/balance it.

I see what your getting at.   Someone could make part specific configs with the current system, and implement those restricted size choices that way.   Hmmm... 

[AccidentalDisassembly]

57 minutes ago, pellinor said:

This is the increment size for the slider (for each interval). It should be roughly small enough to give enough steps, and large enough so searching a particular value does not get too fiddly.

I keep procrastinating this because it feels much like another piece of duct tape on an issue (proper restriction configs for career mode) that already has a config interface but is missing both a good concept and someone motivated to implement/balance it.

The problem with the existing config interface is (I think, though there is a good chance I have misunderstood how things work currently) that the logic is very different from the intended result of the +/- limiters.

Right now, I think, you can specify a tech required to unlock a particular size within a scaletype, right? This creates a slew of logical problems as a result of using the same scaletype applied to parts with different original sizes, ultimately. The only way to fix that - and you're right, it definitely could be done - is to create a big heap of different scaletypes for different scenarios. One scaletype for every size of part, really, and then possibly some extra scaletypes for special cases.

Then, if you want to use a mod with non-"standard" sizes, like BlueDog or HGR or what have you, that means you have to re-do every single scaletype to accommodate new sizes. That is way too complicated.

The logic of the +/- limiter is essentially "we get better at adapting any given design to different-than-intended sizes as we get better materials technologies" (or engine techs, or whatever), and it automatically adapts to any number of size increments the user wants to use. The difference is that it only takes a few adjustments to affect the logic of scaling for all parts - no need to write a complete set of custom scaletypes and re-patch every part in the game in order to use this logic. In addition, it also allows for more interesting possibilities regarding different types of part - for instance, the +/- limit makes a lot of sense for engines. It seems strange to be able to take a 3.75m engine design and scale it all the way down to 0.625m. But if there were logic built in to tweakscale that allows for control over the ratio you can scale a part to rather than the particular value in a scaletype... Again, a person could account for this with the existing config interface, but only by creating a big load of scaletypes and overhauled patches every part. Monumental amount of work vs. changing a few values in one setting in one config somewhere.

That's my $0.02 anyway, and why I think it would be a useful feature.

EDIT: probably even more useful if you can define limits (absolute or tech-based or whatever) by different modules present in a part...

Edited March 25, 2017 by AccidentalDisassembly

[eberkain]

So when thinking about TweakScale in the context of career mode, what do you think could be done to make it balanced?  Restricting how much you can scale parts would be good, and I'm fooling around with some configs for that.  I don't feel that crew parts or science parts should be scalable either for a career game.  Anything else?  

[Loren Pechtel]

53 minutes ago, eberkain said:

So when thinking about TweakScale in the context of career mode, what do you think could be done to make it balanced?  Restricting how much you can scale parts would be good, and I'm fooling around with some configs for that.  I don't feel that crew parts or science parts should be scalable either for a career game.  Anything else?  

Most science has no capacity, thus what would scaling mean?  I would say the goo and the materials bay should be able to be scaled up (giving additional uses), nothing can scale down.

As for everything else--I would be inclined towards the various sizes being unlocked by nodes in the research tree that are one above the spot level where objects of that size are introduced (as unlocking a size would allow manipulation of multiple types of parts) or else have separate unlocks for various types of parts and introduced at level.

[eberkain]

9 minutes ago, Loren Pechtel said:

As for everything else--I would be inclined towards the various sizes being unlocked by nodes in the research tree that are one above the spot level where objects of that size are introduced (as unlocking a size would allow manipulation of multiple types of parts) or else have separate unlocks for various types of parts and introduced at level.

I dont think that unlocking different scale sizes is not something that could be done with simple MM patches.  But that gives me an idea, I could make it so parts could only be scaled a couple steps smaller from their default, but not any larger.  You would still get alot of flexability, but it would require you to unlock a 2.5 tank in order to have a 2.5 tank, etc...  I guess its the nature of the way the tech tree is setup. 

[Loren Pechtel]

1 minute ago, eberkain said:

I dont think that unlocking different scale sizes is not something that could be done with simple MM patches.  But that gives me an idea, I could make it so parts could only be scaled a couple steps smaller from their default, but not any larger.  You would still get alot of flexability, but it would require you to unlock a 2.5 tank in order to have a 2.5 tank, etc...  I guess its the nature of the way the tech tree is setup. 

Allow the top-size things to scale up normally, then. 

[eberkain]

3 hours ago, Loren Pechtel said:

Allow the top-size things to scale up normally, then. 

Yeah, but you can't be sure what the top size is though, SpaceY has parts up to 10m.  

 

EDIT: I've been playing around with it some, let me know what you think.  

 

Edited March 25, 2017 by eberkain

[pellinor]

4 hours ago, eberkain said:

EDIT: I've been playing around with it some, let me know what you think.  

Ah, finally someone who is willing to work on the problem of restriction configs for TweakScale, thanks for your effort! This is some nice MM magic for sorting out the stack sizes.

I thought about the relative scaling limits you wanted and agree they are a good idea (and probably can coexist with the tech tree interface we already have). And now this whole thing getting more serious I am also willing to adapt TweakScale to make your life easier (considering things like config interface, packaging, CKAN definitions). My wish is just that a liberal configuration remains available.

21 hours ago, AccidentalDisassembly said:

Right now, I think, you can specify a tech required to unlock a particular size within a scaletype, right?

You can do this at part level (instead of scaletype level), so the config interface is powerful enough. My gripe with it is that a complete set of configs would probably be a nightmare both to write and to maintain.

[AccidentalDisassembly]

10 minutes ago, pellinor said:

Ah, finally someone who is willing to work on the problem of restriction configs for TweakScale, thanks for your effort! This is some nice MM magic for sorting out the stack sizes.

I thought about the relative scaling limits you wanted and agree they are a good idea (and probably can coexist with the tech tree interface we already have). And now this whole thing getting more serious I am also willing to adapt TweakScale to make your life easier (considering things like config interface, packaging, CKAN definitions). My wish is just that a liberal configuration remains available.

You can do this at part level (instead of scaletype level), so the config interface is powerful enough. My gripe with it is that a complete set of configs would probably be a nightmare both to write and to maintain.

Yeah, that's my gripe too, and the reason I haven't already made a set of configs to make this all work =) I think that it must be possible to still allow complete flexibility of configs (specifying stuff however you want) while creating the possibility for a relative/ratio restriction for scales - maybe a setting within a scaletype that you can have (or not), rather than something inherent to how TS works, right? I dunno, not much of a coder and therefore not really sure how to help and/or think through how it would work in meaningful programming-ese. =(

[pellinor]

My current idea is:
* if there is a techRequired entry (from the part or inherited from the scaletype) then this is used (= the old interface)
* otherwise look for a new entry that has yet to be defined, containing tech requirements for relative scales