Jump to content

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


pellinor

Recommended Posts

Just now, Modding Maniac said:

so just copy and paste them into there

Yes , just paste the making History folder in . You will see a B9_aerospace and a Squad folder along with several others, just paste it there.

Link to comment
Share on other sites

  • 2 weeks later...
5 hours ago, JedTech said:

I've uploaded the configs to Spacedock: https://spacedock.info/mod/1806/Tweakscale Configs for Making History

Requires TweakScale from this thread.

License is WTFPL http://www.wtfpl.net/ 

Please make sure to Delete these configs once TweakScale is updated to avoid duplicate config problems.

Thanks, but I'm getting an error from spacedock when I click "download".

Link to comment
Share on other sites

5 hours ago, JedTech said:

I've uploaded the configs to Spacedock: https://spacedock.info/mod/1806/Tweakscale Configs for Making History

Requires TweakScale from this thread.

License is WTFPL http://www.wtfpl.net/ 

Please make sure to Delete these configs once TweakScale is updated to avoid duplicate config problems.

I'm sorry, but
https://forum.kerbalspaceprogram.com/index.php?/topic/101540-14x-tweakscale-v239mar-09/&do=findComment&comment=3332950

Link to comment
Share on other sites

9 hours ago, JedTech said:

Eu carreguei as configurações para Spacedock:  https://spacedock.info/mod/1806/Tweakscale Configs para Making History

Requer TweakScale deste thread.

A licença é WTFPL http://www.wtfpl.net/ 

Por favor, certifique-se de excluir essas configurações, uma vez que TweakScale é atualizado para evitar problemas de configuração duplicados.

Spacedock is out of service "500 internal error" i sugest share another mirror!

Link to comment
Share on other sites

  • 2 weeks later...

I'm sorry if this has been asked here already but could use some help on a tweakscale config that works in my games that are highly part-modded, but isn't nearly as useful (or goes too far) in overhaul packs (like RSS/RO) where there are a lot of MM configs that contradict the intent of the file.So I originally created a tweakscale config that added free-tweakscale to every part in the game. It worked great and could (after a few hiccups with other tweakscale MM's superseding it and disabling them) allow me to scale everything in game:
 

Spoiler

 


@PART[*]:FINAL
{
	%MODULE[TweakScale]
	{
		@type = free		
	}
}

 

Now I'm attempting to adopt this to my 1.3.1 RSS/RO game and can get it to either tweakscale everything or just a handful of things and both of these are to the extreme. When it allows tweakscale to everything (basically with just :FINAL tagged on the part line at the top) it starts almost every part at something like 10% of their normal size, I then step the size up to 100% and it shows a 200% version of said part, then I step it down once and it shows 50% but that is the default scale of the part I'm working with. This is a huge pain to deal with every single part in the game. So I've tried alternate tags like :AFTER[zzzVENSPATHPATCH] or something to that extent as it's the last MM config loaded on my game I believe but I might as well not have an end tag altogether at this point as now it allows me to tweak only a few items. So what I need help on is the first "extreme" where it allows tweakscale to apply to everything but I need the defaultScale to be the default scale of the part it's adding the module to and that's where I could use some help. I'm about to try the following script but since the default scales come in sets of 3 (x, y, z) I don't believe it will take. My next idea will be to set default scale to the rescale factor of the part, which will hopefully keep the scale to the default scale (after realism overhaul rescales the item) but to save me a few 20 minute startups just to debug this I thought I'd ask if anyone has an MM patch that can do this? I believe it would make my original patch more stable and versatile in that I should be able to add it to any scaled system or alternate planet pack, or add any part mod and have tweakscale's module added by default. Here's the patch I'm currently about to test:
 

Spoiler

 


@PART[*]:HAS[!MODULE[ProceduralPart]]:AFTER[RealismOverhaul]  // Tweakscale for all parts EXCEPT Procedural Parts, after Realism Overhaul does it's thing
{
	
	%MODULE[TweakScale]
	{
        @type = free
		@defaultScale = #$/PART[Model]/scale$ // Not sure if this is the correct syntax or not
	}
}

// My next idea is to change it to:
//@PART[*]:HAS[!MODULE[ProceduralPart]]:AFTER[RealismOverhaul]  // Tweakscale for all parts EXCEPT Procedural Parts, after Realism Overhaul does it's thing
//{
	
//	%MODULE[TweakScale]
//	{
//        @type = free
//		  @defaultScale = #$/PART/rescaleFactor$ // I may need help with this syntax as well if the above doesn't work
//	}
//}

 

Thanks for any help/advice you can give me in advance.

If I can't find any help and one of the above methods works I'll post the "winning" script for anyone that wants it in the future.

 

Edit, the first method didn't work, going to the second setup now.

Edited by shoe7ess
Link to comment
Share on other sites

By setting the type to "free" you tell the module to use these intervals for the scaling slider:

SCALETYPE
{
    name = free
    freeScale = true
    defaultScale = 100
    suffix = %
    scaleFactors   = 10, 50, 100,  200, 400
    incrementSlide =  1,  1,   2,    5
}

Defaultscale is which number the unscaled part should correspond to. In a %-based type the defaultScale should always stay at 100. (of course you still need to overwrite it if the old config used a different scaletype).

Link to comment
Share on other sites

7 hours ago, pellinor said:

By setting the type to "free" you tell the module to use these intervals for the scaling slider:


SCALETYPE
{
    name = free
    freeScale = true
    defaultScale = 100
    suffix = %
    scaleFactors   = 10, 50, 100,  200, 400
    incrementSlide =  1,  1,   2,    5
}

Defaultscale is which number the unscaled part should correspond to. In a %-based type the defaultScale should always stay at 100. (of course you still need to overwrite it if the old config used a different scaletype).

Thank you!
So what was happening to me, at least I believe, is that since I wasn't touching default scale before, just setting it to freescale, other patches were changing the scaletype, after my patch goes barreling through I'm assuming the leftover scaletype info was getting used as free instead of whatever it was before (stack, etc.), making most bits start at 10%. So fixing it should be as easy as adding in !ScaleType{} before I create the free scaletype, that way any information from other patches for scaletype variables gets pushed out and then my patch comes through, sets the scaletype to freescale and sets the defaultscale to 100 (which should be all I need)

Result:

@PART[*]:HAS[!MODULE[ProceduralPart]]:AFTER[RealismOverhaul]
{
	-MODULE[TweakScale] {}
	%MODULE[TweakScale]
	{
        %type = free
	%defaultScale = 100 // Actually, since this is now a blank TweakScale module, shouldn't it default to this anyway?
	}
}

*Update:*

Now this works exactly as intended. May be "career-breaking" if you are trying for a completely realistic RP-0 career where large engines and fuel tanks shouldn't be obtainable from the start; however that is up to the user to decide how it is used (great power, great yada yada). Personally I use this because after so many parts are added in my game that I end up with parts that ALMOST align with other ones or ones that I wish had a smaller version for smaller craft (ScienceJR being one of those, as well as construction pieces like girders and the like) and tweaking the scale on a percentile basis allows me to build my ships/planes so much easier. Thanks for your help @pellinor, I hadn't even thought of the fact that I had fragments left over of non free scaletypes and that was the cause.

Edited by shoe7ess
Link to comment
Share on other sites

  • 1 month later...
  • 2 weeks later...

Anyone knows if there's a fix for the Tweakscale/RealFuels compatibility problems for 1.3.1?

Resizing an engine will, sometimes, change its mass to a negative number, causing the craft to either float on the launchpad or be broken apart. Apparently, it's a well known bug (and there are a few issues on GitHub that mention it), but I haven't found any patches that fix it...

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...