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

[pellinor]

update of the dev branch:
* merge several pull requests for patch updates
* scaling support for resource lists (for drills and converters)
* merged the derivedModules branch into dev (so TWEAKSCALEEXPONENTS should now affect not only the mentioned module but also derived modules, e.g. ModuleRCS=>ModuleRCSFX)

There is someting wonky with the tree on github. In my local repo, dev derives from the derivedModules branch (and it also contains its changes), but in the tree diagram it seems not to. But it looks like the content is ok.

[AccidentalDisassembly]

4 hours ago, pellinor said:

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

Maybe scaletypes could look something like this:

SCALETYPE
{
    name = stack
    freeScale = true
    defaultScale = 1.25
 	suffix = m
 	scaleFactors   = 0.1,  0.3,   0.625, 1.25,  2.5,  3.75, 5.0, 7.5, 10, 20
 	incrementSlide = 0.01, 0.025, 0.025, 0.025, 0.05, 0.05, 0.1, 0.1, 0.2
	
	relativeScalingLimit
	{
		increment = 1, 2, 3
		//meaning "up or down one, up or down two, up or down 3 from its default on the scaleFactors list"
		//Or, for more advanced control:
		increment = 1,0; 1,1; 2,1
		//meaning "can go up one and down none; can go up or down one; can go up 2 and down 1"
		scaleMultipleLimit = 2, 3, 4 //// OR: scaleMultipleLimit = 1.5, 0.66; 2, 2; etc.
		//this value OR increment could be defined, but not both: this one would control ratios rather than use the scaleFactors list
		//value of "2" would mean "can be doubled or halved at given tech," value of 3 would mean tripled or reduced 2/3, etc.
		//could apply same kind of fine control in the alternative case, which would mean "can be 1.5x bigger or scaled down to 0.66x at minimum..." etc.
		techRequired = whatevertech1, whatevertech2, whatevertech 3 
		//names of techs that unlock each increment or ratio limit
	}
}

If what I wrote even makes sense... it might be nice as well if there were a way to override that limit on a per-part basis without having to write a new scaletype, but it might not be essential. So, for example, you could easily create a patch for all engine parts (let's say) that would add some variable, like "relativeScalingOverride = 1" that would only ever allow those particular parts to be scaled up or down one notch, no matter what the relativeScalingLimit says otherwise.

Alternatively, it could be possibly simply to define only one value for "increment" within a scaletype, and make one scaletype for engines and one scaletype for everything else. That'd be pretty easy too. If it looked like this:

relativeScalingLimit
{
	increment = 1 //or increment = x,y
	*Or, alternatively:*
	scaleMultipleLimit = 2 //or scaleMultipleLimit = x,y
}

Then tweakscale could maybe interpret that to mean "never allow this part to scale up or down more than one increment in the list of scaleFactors applied to it." Same could be done using scaleMultipleLimit as a fractional value +/- instead, or something.

Dunno if that's useful.

Edited March 26, 2017 by AccidentalDisassembly
clarity

[mark7]

Dont know why but when I trying to scale down a fuel tank, its mass become negative. I am using RealFuel on x64 togather with TS. 

Edited March 26, 2017 by mark7

[eberkain]

8 hours ago, pellinor said:

update of the dev branch:
* merge several pull requests for patch updates
* scaling support for resource lists (for drills and converters)
* merged the derivedModules branch into dev (so TWEAKSCALEEXPONENTS should now affect not only the mentioned module but also derived modules, e.g. ModuleRCS=>ModuleRCSFX)

There is someting wonky with the tree on github. In my local repo, dev derives from the derivedModules branch (and it also contains its changes), but in the tree diagram it seems not to. But it looks like the content is ok.

Thanks for the update, I'm going to be doing some more updates for parts that are missing a config.  

Have you tried tackling the problem with plumes getting out of whack when engines are scaled.  Lets look at the Terrier, its a good example because it uses separate positions for the flare and plume, and one is a zero.  Here is the RP config. 

@PART[liquidEngine3]:FOR[RealPlume]:NEEDS[SmokeScreen] //LV-909 "Terrier" Liquid Fuel Engine
{
    PLUME
    {
        name = Hypergolic-OMS-White
        transformName = thrustTransform
        localRotation = 0,0,0
        flarePosition = 0,0,-0.35
        plumePosition = 0,0,0
        fixedScale = 0.3
        energy = 1
        speed = 1.44
    }
    @MODULE[ModuleEngines*]
    {
        @name = ModuleEnginesFX
        %powerEffectName = Hypergolic-OMS-White
    }
}

And here is the engine at stock size and 0.625 size.  

Its hard to see in the screenshot, but the plume is still in a good position on the rescaled version, only the flare is not.  Since the flare is already a negative number I'm assuming it just needs to be a bigger negative number.  I tried adding this to the configs, but to no effect.  

TWEAKSCALEBEHAVIOR
{
    name = Engine
    MODULE
    {
        name = TweakScale
        TWEAKSCALEEXPONENTS { mass = 2.5 }
    }
	PLUME
	{
		TWEAKSCALEEXPONENTS 
		{
			flarePosition = 2
		}
	}
}

I'm assuming that because the value is a vector and not a single number it doesn't work, or maybe because its in a PLUME node and not a MODULE node.  We need a way to define exponents that could adjust the flarePosition, plumePosition and localPosition values, and then be able to assign those exponents on a per engine basis.  We may also need to be able to assign a flat offset to each position on a per engine basis, because I can picture a problem where I could get the plume position to scale correctly, but its always too close or too far away.  

[pellinor]

1 hour ago, eberkain said:

I'm assuming that because the value is a vector and not a single number it doesn't work, or maybe because its in a PLUME node and not a MODULE node.  We need a way to define exponents that could adjust the flarePosition, plumePosition and localPosition values, and then be able to assign those exponents on a per engine basis.  We may also need to be able to assign a flat offset to each position on a per engine basis, because I can picture a problem where I could get the plume position to scale correctly, but its always too close or too far away.  

Keep in mind that TweakScale does not work on config nodes but on the internal c# structures. For engine plumes you rare probably seeing this issue: https://github.com/pellinor0/TweakScale/issues/11

[pellinor]

7 hours ago, AccidentalDisassembly said:

relativeScalingLimit

I don't really understand, this does not look simpler to me than what eberkain already has.

My idea is more like this

techRequiredPlus = largeTech, largerTech, hugeTech
techRequiredMinus = smallTech, never

which can be defined globally, in a scaletype, or on the part level.

By default everything is allowed at start. If the list is shorter than the available scales, the last entry would be applied. So in the example hugeTech would allow arbitrary upscaling, and downscaling would always be limited to one step.

 

3 hours ago, mark7 said:

Dont know why but when I trying to scale down a fuel tank, its mass become negative. I am using RealFuel on x64 togather with TS. 

Known issue with MFT+TweakScale, fixed in the dev version

Edited March 26, 2017 by pellinor

[eberkain]

9 minutes ago, pellinor said:

Keep in mind that TweakScale does not work on config nodes but on the internal c# structures. For engine plumes you rare probably seeing this issue: https://github.com/pellinor0/TweakScale/issues/11

Yes, and I am using Real Plume.  I can adjust the particle effect in real time with the SmokeScreen interface, so I would assume there is some way that Tweakscale could be made to scale those values too.  The fixedScale value even lets you adjust the overall size of the particle effect.   I know one of the things that turns off alot of people is the particle effects on rescaled engines not matching up, it would be truly awesome if it could be made to work.  I don't mind going through all the engines one by one and writing the configs to make the plume scale properly, I just need to get 1 to work first. Currently an tweakscale engine config looks like this.  

@PART[liquidEngine3] // LV-909 Liquid Fuel Engine
{
    #@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { }
    %MODULE[TweakScale]
    {
        type = stack
        defaultScale = 1.25
    }
}

I need to be able to add something like this and have it do what I want it to do...

@PART[liquidEngine2] // LV-T45 Liquid Fuel Engine
{
    #@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { }
    %MODULE[TweakScale]
    {
        type = stack
        defaultScale = 1.25
    }
	PLUME 
	{
		TWEAKSCALEEXPONENTS { localPosition = 2 }
		TWEAKSCALEEXPONENTS { flarePosition = 2 }
		TWEAKSCALEEXPONENTS { plumePosition = 2 }
		TWEAKSCALEEXPONENTS { fixedScale = 2 }
	}
}

 

[pellinor]

15 minutes ago, eberkain said:

TWEAKSCALEEXPONENTS { localPosition = 2 }
TWEAKSCALEEXPONENTS { flarePosition = 2 }
TWEAKSCALEEXPONENTS { plumePosition = 2 }
TWEAKSCALEEXPONENTS { fixedScale = 2 }

Why 2? Shouldn't all geometry scale linearly (exponent=1)? And do we need a config interface for this? My understanding is that it can be hardcoded because these things should always scale like the rest of the model geometry.

This is what TweakScale does today concerning particle effects (I'm not familiar with that code yet):
https://github.com/pellinor0/TweakScale/blob/master/Updater.cs#L140-L241

Maybe you could have a look, if you are already familiar with the smokescreen interface?

[eberkain]

16 minutes ago, pellinor said:

Why 2? Shouldn't all geometry scale linearly (exponent=1)? And do we need a config interface for this? My understanding is that it can be hardcoded because these things should always scale like the rest of the model geometry.

This is what TweakScale does today concerning particle effects (I'm not familiar with that code yet):
https://github.com/pellinor0/TweakScale/blob/master/Updater.cs#L140-L241

Maybe you could have a look, if you are already familiar with the smokescreen interface?

Sorry, I'm not familiar enough with KSP coding to be of any help.  Maybe @sarbian could offer advice?  I see he has commits on SmokeScreen from just a couple weeks ago. 

[eberkain]

I see these are all commented out in the config file? 

//@PART[HighGainAntenna5] // HG-5 High Gain Antenna
//{
//    %MODULE[TweakScale]
//    {
//        type = free_square
//    }
//}
//@PART[RelayAntenna5] // RA-2 Relay Antenna
//{
//    %MODULE[TweakScale]
//    {
//        type = free_square
//    }
//}
//@PART[RelayAntenna50] // RA-15 Relay Antenna
//{
//    %MODULE[TweakScale]
//    {
//        type = free_square
//    }
//}
//@PART[RelayAntenna100] // RA-100 Relay Antenna
//{
//    %MODULE[TweakScale]
//    {
//        type = free_square
//    }
//}

 

[pellinor]

3 minutes ago, eberkain said:

I see these are all commented out in the config file? 

Yes because changing antenna power does not work while a vessel is unloaded (which is the main use case for a relay antenna). This is a problem of the base game: non-persistent values can only be modded for loaded vessels.

[eberkain]

29 minutes ago, pellinor said:

Yes because changing antenna power does not work while a vessel is unloaded (which is the main use case for a relay antenna). This is a problem of the base game: non-persistent values can only be modded for loaded vessels.

That makes sense.  I finished going through all the Squad and Vens Stock Revamp parts and did another pull request.   Going to go through the other mods I have soon. 

 

[AccidentalDisassembly]

3 hours ago, pellinor said:

I don't really understand, this does not look simpler to me than what eberkain already has.

My idea is more like this

techRequiredPlus = largeTech, largerTech, hugeTech
techRequiredMinus = smallTech, never

which can be defined globally, in a scaletype, or on the part level.

By default everything is allowed at start. If the list is shorter than the available scales, the last entry would be applied. So in the example hugeTech would allow arbitrary upscaling, and downscaling would always be limited to one step.

That would work in the same way as the first half of what I was throwing out there; the rest was an attempt to think through how it might work if scaling were limited by ratio rather than the list of scaleExponents. Then, the splitting of values with commas and semicolons was an attempt to think about how finer control (if that's even needed) would be achieved.

One other thing that occurs to me and makes the creation of scaletypes annoying even if we have relative scaling values - a different set of techRequiredPlus and techRequiredMinus would need to be created for parts that appear at different places in the tree (maybe...) - and different patches again for someone using CTT or other tech trees. Is it possible to "read" the tech tree in-game and find "higher" techs? E.g. read the tech that unlocks the part, then read the techs that require that tech? 

[pellinor]

10 hours ago, eberkain said:

Sorry, I'm not familiar enough with KSP coding to be of any help.

Never mind, I just read something with using smokescreen in real time and thought that implied coding (because configs are only read once at the start of the game).

9 hours ago, AccidentalDisassembly said:

Is it possible to "read" the tech tree in-game and find "higher" techs? E.g. read the tech that unlocks the part, then read the techs that require that tech? 

I see no fundamental problem with having a single tech that would for example allow all engines to be scaled up. We could also code something with child techs but note that a tech may have multiple children or none at all.

Also if the restrictions are scattered too far across the tech tree, how shall the player know when which scale is unlocked? Trial and error in the editor? Spam the tech tree with dozens of dummy parts? You don't want a flood of bug reports from people who don't understand the restriction system.

Edited March 27, 2017 by pellinor

[eberkain]

14 minutes ago, pellinor said:

I see no fundamental problem with having a single tech that would for example allow all engines to be scaled up. We could also code something with child techs but note that a tech may have multiple children or none at all.

Being able to scale a part to any size is one of the fundamental problems I have with Tweakscale, it kind of breaks the need for having more than one part.  I typically end up just grabbing the highest Isp engine and scaling it to whatever size I need and ignoring the other engines.   Restricting scaling by tech would help preserve the part progression, but it doesn't help to fix the problem where having different size parts becomes largely pointless, that is why I like the idea of each part getting a restricted scaling range, you still get much of the flexibility with not being restricted, but it requires you to unlock the the tech tree to get the bigger stuff. 

[AccidentalDisassembly]

51 minutes ago, pellinor said:

Never mind, I just read something with using smokescreen in real time and thought that implied coding (because configs are only read once at the start of the game).

I see no fundamental problem with having a single tech that would for example allow all engines to be scaled up. We could also code something with child techs but note that a tech may have multiple children or none at all.

Also if the restrictions are scattered too far across the tech tree, how shall the player know when which scale is unlocked? Trial and error in the editor? Spam the tech tree with dozens of dummy parts? You don't want a flood of bug reports from people who don't understand the restriction system.

Hmm, yes, I see your point - seems sufficient just to have one tech as a solution then. And it probably wouldn't be ridiculously hard just to make two different scaletypes (one for 1.25m engines, one for 2.5m engines, or whatever) if it turned out to be more effective for whatever reason. In which case it might be possible to make that process even easier by making TweakScale patches based on a part's bulkhead profile... it would rely on mod authors' rigorous application of bulkhead profiles, but it could radically simplify things as well... Hmmm....

[pellinor]

11 hours ago, eberkain said:

Being able to scale a part to any size is one of the fundamental problems

I'm not talking about this. All I am saying is that the tech to scale any engine up one scale factor could be the same.

11 hours ago, AccidentalDisassembly said:

bulkhead profiles

I don't know if a part needs to have a bulkhead profile. What I know is that it can have multiple ones and people can invent their own profile names. So probably not a good idea to rely on people using them in a consistent manner.

[pellinor]

11 hours ago, AccidentalDisassembly said:

make two different scaletypes (one for 1.25m engines, one for 2.5m engines,

We also have the TWEAKSCALEBEHAVIOR nodes I use for group-specific exponents
https://github.com/pellinor0/TweakScale/blob/master/GameData/TweakScale/ScaleExponents.cfg#L456-L504

or MM patches that look for specific modules.

[Mikeloeven]

12 hours ago, eberkain said:

Being able to scale a part to any size is one of the fundamental problems I have with Tweakscale, it kind of breaks the need for having more than one part.  I typically end up just grabbing the highest Isp engine and scaling it to whatever size I need and ignoring the other engines.   Restricting scaling by tech would help preserve the part progression, but it doesn't help to fix the problem where having different size parts becomes largely pointless, that is why I like the idea of each part getting a restricted scaling range, you still get much of the flexibility with not being restricted, but it requires you to unlock the the tech tree to get the bigger stuff. 

I agree and disagree I agree in the fact that options for balancing should be available however restrictions imposed by hard-coding in the mod would also defeat part of the purpose of the mod

[rockets-don't-make-toast]

you never said that tweakscale came with module manager.

[AccidentalDisassembly]

9 hours ago, Mikeloeven said:

I agree and disagree I agree in the fact that options for balancing should be available however restrictions imposed by hard-coding in the mod would also defeat part of the purpose of the mod

Don't think any hard-coding is going to happen, based on what I understand - think we're all talking about something that would be completely controllable via config files.

[TheRagingIrishman]

49 minutes ago, rockets-don't-make-toast said:

you never said that tweakscale came with module manager.

In order for the module that tweakscale uses to resize parts to actually be added to anything, MM has to be installed. Also, why is it a big deal?

[AccidentalDisassembly]

FYI - in the dev branch NFT patch, there's this which throws an error:

@PART[XE-100 Xenon Tank] (should be xenon-125-3, I think commented description and part name got swapped).

I rewrote the config to be more manageable for my own personal tastes, removing maybe 1100 lines in the process - if you want to use it, you're welcome to:

// ========== NEAR FUTURE CONSTRUCTION ==========

// ----- Adapters and Docking -----

	//Rockomax Skeletal Structural Adapter
	@PART[adapter-25-125]
	{
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale= 2.5
		}

	}

	//SE-4-OMNI Stack Multi-Adapter
	@PART[adapter-25-multi-01]
	{
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 2.5
		}
	}

	//SM- series stack adapters and radial stack adapter
	@PART[adapter-125-0625-*|adapter-rad-125]
	{
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 1.25
		}
	}

	//Rockomax Skeletal XL Structural Adapter
	@PART[adapter-375-25]
	{
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 3.75
		}
	}

	// S-MINI Radial Stack Adapter
	@PART[adapter-rad-0625]
	{
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 0.625
		}
	}

	//Grip-O-Tron Large Docking Connector
	@PART[docking-25]
	{
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 2.5
		}
	}

// ----- Trusses -----

	//Annular Trusses XL
	@PART[truss-circular-*]
	{
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 3.75
		}
	}

	//Modular Multipurpose Hexa-Girders
	@PART[truss-hex-*]
	{
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 2.5
		}
	}

	//Modular Multipurpose Octo-Girders XL
	@PART[truss-octo-*]
	{
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 2.5
		}
	}

	//Modular Spinal Trusses
	@PART[truss-spinal-*]
	{
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 2.5
		}
	}

// ----- Batteries -----

	//B-12K Rechargeable Battery Bank
	@PART[battery-25]
	{
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 2.5
		}
	}

	//B-6K Rechargeable Battery Bank
	@PART[battery-125]
	{
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 1.25
		}
	}

	//B-10K Rechargeable Battery Bank
	@PART[battery-375]
	{
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 3.75
		}
	}

	//B-3K Rechargeable Battery Bank
	@PART[battery-0625]
	{
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 0.625
		}
	}

	//B-800 Rechargeable Battery
	@PART[battery-rad-125]
	{
		%MODULE[TweakScale]
		{
			type = free
		}
	}

// ----- Capacitors -----

	//CAR-EXTRA Capacitor Bank
	@PART[capacitor-25]
	{
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 2.5
		}
	}

	//CAR-8K Capacitor Bank
	@PART[capacitor-125]
	{
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 1.25
		}
	}

	//CAR-1.6K Capacitor Bank
	@PART[capacitor-0625]
	{
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 0.625
		}
	}

	//Radial capacitors
	@PART[capacitor-rad-0625*]
	{
		%MODULE[TweakScale]
		{
			type = free
		}
	}

// ----- Nuclear Bits -----
	
	//MX-1 'Prometheus' Fission Reactor
	@PART[reactor-25]
	{
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 2.5
		}
	}

	//MX-L 'Excalibur' Fission Reactor
	@PART[reactor-25-2]
	{
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 2.5
		}
	}

	//MX-4 'GARNET' Fission Reactor
	@PART[reactor-125]
	{
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 1.25
		}
	}

	//MX-2 F.L.A.T. Fission Reactor
	@PART[reactor-375]
	{
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 3.75
		}
	}

	//MX-EXP 'KerboPower' Fission Generator
	@PART[reactor-0625]
	{
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 0.625
		}
	}

	//MF-1 Nuclear Fuel Drum
	@PART[nuclearfuel-25]
	{
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 2.5
		}
	}

	//MF-4 Nuclear Fuel Drum
	@PART[nuclearfuel-125]
	{
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 1.25
		}
	}

	//MF-7 Nuclear Fuel Drum
	@PART[nuclearfuel-0625]
	{
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 0.625
		}
	}

	//PB-AS-NUK Radioisotope Generator
	@PART[rtg-0625]
	{
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 0.625
		}
	}

	//Whirlijig Nuclear Reprocessor
	@PART[nuclear-recycler-25]
	{
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 2.5
		}
	}

// ========== NEAR FUTURE PROPULSION ==========

// ----- Fuel Tanks -----

	//2.5m argon, xenon, lithium tanks
	@PART[argon-25-*|lithium-25-*|xenon-25-*]
	{
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 2.5
		}
	}

	//1.25m argon, xenon, lithium tanks
	@PART[argon-125-*|lithium-125-*|xenon-125-*]
	{
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 1.25
		}
	}

	//0.625m argon, xenon, lithium tanks
	@PART[argon-0625-*|]
	{
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 0.625
		}
	}

	//Radial argon, xenon, lithium tanks
	@PART[argon-radial-*|xenon-radial-*]
	{
		%MODULE[TweakScale]
		{
			type = free
		}
	}

// ----- Engines -----

	//0.625m engines
	@PART[ionArgon-0625*|ionXenon-0625*|mpdt-0625|pit-0625|vasimr-0625]
	{
		#@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale]{}
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 0.625
		}
	}
	
	//1.25m engines
	@PART[ionArgon-125|ionXenon-125|mpdt-125|pit-125|vasimr-125]
	{
		#@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale]{}
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 1.25
		}
	}
	
	//2.5m engines
	@PART[ionXenon-25|mpdt-25|pit-25|vasimr-25]
	{
		#@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale]{}
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 2.5
		}
	}

// ----- Lithium RCS thrusters -----
	@PART[rcsblock-gridded-01|rcsblock-hall-01|rcsblock-mpdt-quad-01|rcsblock-mpdt-quint-01|rcsblock-mpdt-single-01|rcsblock-mpdt-triple-01|rcsblock-pulsedplasma-01]
	{
		#@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale]{}
		%MODULE[TweakScale]
		{
			type = free
		}
	}

	//M-2 Cryogenic Gas Separator
	@PART[cryoseperator-25]
	{
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 2.5
		}
	}

	//AIReS Atmospheric Sounder
	@PART[gasspectrometer-01]
	{
		%MODULE[TweakScale]
		{
			type = free
		}
	}

// ========== NEAR FUTURE SOLAR ==========

	//Blanket arrays
	@PART[solarpanel-blanket-*]
	{
		%MODULE[TweakScale]
		{
			type = free_square
		}
	}

	//NIV-18 Curved Solar Array
	@PART[solarpanel-curved-25-1]
	{
		%MODULE[TweakScale]
		{
			type = stack_square
			defaultScale = 2.5
		}
	}

	//NIV-3 Curved Solar Array
	@PART[solarpanel-curved-375-1]
	{
		%MODULE[TweakScale]
		{
			type = stack_square
			defaultScale = 3.75
		}
	}

	//SOL-A Expanding Curved Solar Array
	@PART[solarpanel-curved-deploying-25-1]
	{
		%MODULE[TweakScale]
		{
			type = stack_square
			defaultScale = 2.5
		}
	}

	//Deploying and static panels, free_square type
	@PART[solarpanel-deploying-*|solarpanel-static-truss-*]
	{
		%MODULE[TweakScale]
		{
			type = free_square
		}
	}

// ========== NEAR FUTURE SPACECRAFT ==========

	//LV-95-6 Orbital Maneuvering Engine Assembly
	@PART[orbital-engine-25]
	{
		#@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale]{}
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 2.5
		}
	}

	//LV-601 Orbital Maneuvering Engine
	@PART[orbital-engine-125]
	{
		#@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale]{}
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 1.25
		}
	}

	//LV-601-4 Orbital Maneuvering Engine Cluster
	@PART[orbital-engine-375]
	{
		#@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale]{}
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 3.75
		}
	}

	//LV-95 Orbital Maneuvering Engine
	@PART[orbital-engine-0625]
	{
		#@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale]{}
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 0.625
		}
	}

// ----- Fuel Tanks -----

	//FL-R-B3000 Monopropellant Tank
	@PART[monoprop-tank-25-*]
	{
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 2.5
		}
	}

	//FL-R-A750 Monopropellant Tank
	@PART[monoprop-tank-125-*]
	{
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 1.25
		}
	}

	//FL-R-C6000 Monopropellant Tank
	@PART[monoprop-tank-375-*]
	{
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 3.75
		}
	}

	//FL-T6000 Service Tank
	@PART[servicetank-25]
	{
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 2.5
		}
	}

	//FL-T9000 Service Tank
	@PART[servicetank-375]
	{
		%MODULE[TweakScale]
		{
			type = stack
			defaultScale = 3.75
		}
	}

// ----- RCS Thrusters -----

	//RV-105x5 RCS Thruster Block
	@PART[rcsblock-aero-5way-1|rcsblock-orbital-2way-45-2|rcsblock-orbital-3way-1|rcsblock-orbital-4way-1|rcsblock-orbital-5way-1|rcsblock-orbital-linear-1|rcsblock-orbital-2way-45-1||||]
	{
		#@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale]{}
		%MODULE[TweakScale]
		{
			type = free
		}
	}

// ----- Structural and Utility Parts -----

	//SD-01 Radial Engine Pod
	@PART[engine-pod-*]
	{
		%MODULE[TweakScale]
		{
			type = free
		}
	}

	//LT-POD Landing Assembly
	@PART[landingleg-pod-1]
	{
		%MODULE[TweakScale]
		{
			type = free
		}
	}

 

[eberkain]

8 hours ago, AccidentalDisassembly said:

FYI - in the dev branch NFT patch, there's this which throws an error:

@PART[XE-100 Xenon Tank] (should be xenon-125-3, I think commented description and part name got swapped).

I rewrote the config to be more manageable for my own personal tastes, removing maybe 1100 lines in the process - if you want to use it, you're welcome to:

 

Ah man, I redid all the NFT mod configs yesterday.  

EDIT: So far I've done all the mods I use except these.   I'll do another PR when I'm done.  

SXT (just a ridiculous number of parts)

Mk3 Expansion (has not config)

Stockalike Mining Extension (has no config)

Feline Utility Rover (has no config)

Planetary Base Systems (not sure about this one)

Edited March 28, 2017 by eberkain

[Mikeloeven]

@AccidentalDisassembly That error may have been my fault, sorry. I double checked the config files before making the pull request but that one seems to have slipped by. Thanks for Catching that.

Also those comments you redid were something i came up with designed to work with notepad ++'s folding in comments feature for custom language definitions. They allow code collapse and make it easy to jump to specific sections.

If you use notepad ++ try using this language definition

Spoiler

 <UserLang name="KSP CFG" ext="" udlVersion="2.1">
        <Settings>
            <Global caseIgnored="no" allowFoldOfComments="yes" foldCompact="no" forcePureLC="0" decimalSeparator="0" />
            <Prefix Keywords1="yes" Keywords2="no" Keywords3="yes" Keywords4="yes" Keywords5="yes" Keywords6="no" Keywords7="no" Keywords8="no" />
        </Settings>
        <KeywordLists>
            <Keywords name="Comments">00// 01 02 03 04</Keywords>
            <Keywords name="Numbers, prefix1"></Keywords>
            <Keywords name="Numbers, prefix2"></Keywords>
            <Keywords name="Numbers, extras1"></Keywords>
            <Keywords name="Numbers, extras2"></Keywords>
            <Keywords name="Numbers, suffix1"></Keywords>
            <Keywords name="Numbers, suffix2"></Keywords>
            <Keywords name="Numbers, range"></Keywords>
            <Keywords name="Operators1">&apos; &quot; =</Keywords>
            <Keywords name="Operators2"></Keywords>
            <Keywords name="Folders in code1, open">{</Keywords>
            <Keywords name="Folders in code1, middle"></Keywords>
            <Keywords name="Folders in code1, close">}</Keywords>
            <Keywords name="Folders in code2, open"></Keywords>
            <Keywords name="Folders in code2, middle"></Keywords>
            <Keywords name="Folders in code2, close"></Keywords>
            <Keywords name="Folders in comment, open">Region</Keywords>
            <Keywords name="Folders in comment, middle"></Keywords>
            <Keywords name="Folders in comment, close">/Region</Keywords>
            <Keywords name="Keywords1">@PART</Keywords>
            <Keywords name="Keywords2">type&#x000D;&#x000A;defaultScale</Keywords>
            <Keywords name="Keywords3">%MODULE</Keywords>
            <Keywords name="Keywords4">#@TWEAKSCALEBEHAVIOR</Keywords>
            <Keywords name="Keywords5"></Keywords>
            <Keywords name="Keywords6"></Keywords>
            <Keywords name="Keywords7"></Keywords>
            <Keywords name="Keywords8"></Keywords>
            <Keywords name="Delimiters">00[ 01 02] 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23</Keywords>
        </KeywordLists>
        <Styles>
            <WordsStyle name="DEFAULT" fgColor="FFFFFF" bgColor="000000" fontName="" fontStyle="0" nesting="0" />
            <WordsStyle name="COMMENTS" fgColor="000000" bgColor="FFFFFF" fontName="" fontStyle="0" nesting="0" />
            <WordsStyle name="LINE COMMENTS" fgColor="80FF80" bgColor="000000" fontName="" fontStyle="0" nesting="0" />
            <WordsStyle name="NUMBERS" fgColor="FF80FF" bgColor="000000" fontName="" fontStyle="0" nesting="0" />
            <WordsStyle name="KEYWORDS1" fgColor="8080C0" bgColor="000000" fontName="" fontStyle="0" nesting="0" />
            <WordsStyle name="KEYWORDS2" fgColor="00FF80" bgColor="000000" fontName="" fontStyle="0" nesting="0" />
            <WordsStyle name="KEYWORDS3" fgColor="80FFFF" bgColor="000000" fontName="" fontStyle="0" nesting="0" />
            <WordsStyle name="KEYWORDS4" fgColor="408080" bgColor="000000" fontName="" fontStyle="0" nesting="0" />
            <WordsStyle name="KEYWORDS5" fgColor="400040" bgColor="000000" fontName="" fontStyle="0" nesting="0" />
            <WordsStyle name="KEYWORDS6" fgColor="000000" bgColor="FFFFFF" fontName="" fontStyle="0" nesting="0" />
            <WordsStyle name="KEYWORDS7" fgColor="000000" bgColor="FFFFFF" fontName="" fontStyle="0" nesting="0" />
            <WordsStyle name="KEYWORDS8" fgColor="000000" bgColor="FFFFFF" fontName="" fontStyle="0" nesting="0" />
            <WordsStyle name="OPERATORS" fgColor="FFFF80" bgColor="000000" fontName="" fontStyle="0" nesting="0" />
            <WordsStyle name="FOLDER IN CODE1" fgColor="FFFF80" bgColor="000000" fontName="" fontStyle="0" nesting="0" />
            <WordsStyle name="FOLDER IN CODE2" fgColor="000000" bgColor="FFFFFF" fontName="" fontStyle="0" nesting="0" />
            <WordsStyle name="FOLDER IN COMMENT" fgColor="FF80FF" bgColor="000000" fontName="" fontStyle="0" nesting="0" />
            <WordsStyle name="DELIMITERS1" fgColor="FFFF80" bgColor="000000" fontName="" fontStyle="0" nesting="0" />
            <WordsStyle name="DELIMITERS2" fgColor="000000" bgColor="FFFFFF" fontName="" fontStyle="0" nesting="0" />
            <WordsStyle name="DELIMITERS3" fgColor="000000" bgColor="FFFFFF" fontName="" fontStyle="0" nesting="0" />
            <WordsStyle name="DELIMITERS4" fgColor="000000" bgColor="FFFFFF" fontName="" fontStyle="0" nesting="0" />
            <WordsStyle name="DELIMITERS5" fgColor="000000" bgColor="FFFFFF" fontName="" fontStyle="0" nesting="0" />
            <WordsStyle name="DELIMITERS6" fgColor="000000" bgColor="FFFFFF" fontName="" fontStyle="0" nesting="0" />
            <WordsStyle name="DELIMITERS7" fgColor="000000" bgColor="FFFFFF" fontName="" fontStyle="0" nesting="0" />
            <WordsStyle name="DELIMITERS8" fgColor="000000" bgColor="FFFFFF" fontName="" fontStyle="0" nesting="0" />
        </Styles>
    </UserLang>

 

 

edit: Fixed and Pull Request Submitted

 

 

Edited March 28, 2017 by Mikeloeven