[KSP >= 1.3.0] TweakScale - Under Lisias' Management - 2.4.8.8 - 2024-1117

[zer0Kerbal]

2 hours ago, OhioBob said:

Although it might not work well with the stock SRBs, a correct scaling formula would be preferable with BetterSRBs.  For instance, with BetterSRBs the Thumper and Kickback have about double the thrust.  So scaling by size^3 just makes them way overpowered when scaled up.  This makes me feel even more comfortable with my decision to remove the TweakScale config from BetterSRBs.  TweakScale doesn't seem to be designed to work with SRBs having realistic parameters.  It and BetterSRBs is just not a good combination.

so this *might* also address the scaling factor you are talking about and @Lisias

Spoiler

&TWEAKSCALEBEHAVIOR[BetterSRB]:NEEDS[TweakScale]:FOR[BetterSRB] {
	&name = BetterSRB
	%MODULE[TweakScale] {
		&name = TweakScale
		&TWEAKSCALEEXPONENTS[ModuleEngines] {
			&name = ModuleEngines
			&minFuelFlow = 2
			&maxFuelFlow = 2
			&maxThrust = 2
			&-ignore = ModuleEngineConfigs
		}
	}
}


@PART[BetterSRB_1p875x12|BetterSRB_1p875x22]:NEEDS[TweakScale]:FOR[BetterSRB]
{
	#@TWEAKSCALEBEHAVIOR[BetterSRB]/MODULE[TweakScale] { }
	%MODULE[TweakScale]
	{
		%type = stack
		%defaultScale = 1.875
	}
}

@PART[rocketNoseCone_1p5|Size1p5to1Adapter]:NEEDS[TweakScale]:FOR[BetterSRB
{
	%MODULE[TweakScale]
	{
		%type = stack
		%defaultScale = 1.875
	}
}

 

 

Edited June 14, 2019 by zer0Kerbal
quad damage?

[zer0Kerbal]

Moving thread now:

2 hours ago, Lisias said:

This is not wise due reasons explained here:

In a nutshell, it will wash the detectable symptom away, but the nasty bugs will by still there ruining savegames - and I will have to cook yet another sanity check to reach the same goal. What would made the whole effort useless.

So what you are saying is that rather than making the problem evident let it be hidden? I don't want peoples save games destroyed, but as I believe you have said - they are on already on a path to unavoidable, unmitigated doom; that it is not a matter of if but when their save games will crash in a way that would make Jeb feebleminded.

Unless I am mistaken, none of this is TweakScales fault, rather on slip-shod ad hoc patches.

so two paths:

1. for existing savegames: keep on trucking.
2. for new saves: new and improved patches that preemptively correct the inherent problems. If both TweakScale and AllTweak make those changes - then neither can or will (should) be able to ever cause this problem again. (bad patch! go to your corner!)

SO for existing saves - don't update the patches. For new saves (and those brave foolhearted fools) install the updated, stricter patches.

The idea is that with the patches following best practices, that no matter how patches apply the same module, there will always only be ever one module; and the :FOR makes it possible to do :AFTER or :BEFORE (if I am understanding correctly).

I am unable to fix existing savegames, but this might help prevent Krakens from invading new save games, at least that is my goal. If I am wrong, I will wander off and go back to rescuing Kerbals and dealing with a spaghetti wobble in my LKO Station.

 

[Lisias]

(moved from the wrong thread!)

2 hours ago, zer0Kerbal said:

So what you are saying is that rather than making the problem evident let it be hidden?

Yep.

 

2 hours ago, zer0Kerbal said:

Unless I am mistaken, none of this is TweakScales fault, rather on slip-shod ad hoc patches

There's TweakScale, the MODULE, and there's TweakScale, the "stock" Patches.

It's not Module's fault, it is doing exactly what it's being told to do. I'm "teaching" it to detect some bugs, but there's a limit on what can be done automatically.

About the Patches…Well. Some of the problems are on me. Some of the TweakScale stock patches have the problem too, and to tell you the true I completely forgot to check my own patches before doing the release. Until the moment, not a single report was due only the Stock Patches, but yet they are there.

On my defense   only my Career game (still on 1.4.3 , the mainstream version on the last time I really played) detected these problems now that I fired up with the newest TweakScaçe, but as I said, it's more exactly ONE YEAR since I fire up it since the last time!!!  (dude, it was running one of my first "unofficial" compilations of TweakScale yet!)

Somewhere else on this forum I said that would be a good idea having more developers playing more the game in order to foresee in advance some possible consequences about the decisions they make.  Guess what? It applies perfectly to me too.  

Once TweakScale 2.5 goes gold (the Milestone I'm slowly pursuing through the 2.4.* series) I will take a break on this and go back to my Career. No Kerbal should be dragged away from his game for that time!  

 

2 hours ago, zer0Kerbal said:

so two paths:

1. for existing savegames: keep on trucking.
2. for new saves: new and improved patches that preemptively correct the inherent problems. If both TweakScale and AllTweak make those changes - then neither can or will (should) be able to ever cause this problem again. (bad patch! go to your corner!)

There's a possible compromise on this.

Until the moment, almost every single rogue patch was trying to "overcome" the default behaviour. These ones, once everything is fixed, will still be the dominant ones - with the additional benefit of not risking ruining games when Add'Ons are installed, updated or even removed - destabilising the brittle balance that is allowing things to work at the moment.

There're some others that are applying the same patch twice. These ones are 'almost' harmless - but since they are applying themselves twice,  they will be being applied twice even if something else tries to overrule them. And then we would have a new instance of the last problem.

The nastiest problems, however, is when different patches are applied by error on the same part. This is a serious game braker because these patches are not only changing things in a unattended way (the others were doing it on purpose to get a new, predefined behaviour), ruining the current game, but they also are "vengeful"  as they also ruin the game when things are fixed!

 

2 hours ago, zer0Kerbal said:

SO for existing saves - don't update the patches. For new saves (and those brave foolhearted fools) install the updated, stricter patches.

This is not safe, as some rogue patches ends up acting only under determined circumstances. Anything gets different, the savegame is ruined as the brittle balance that were reached is broken and the chain ends up with different results.

So we need a set of deterministic, custom made patches, that would allow these savegames to carry on without being at risk. This is the reason I'm asking people to send me their KSP.log and MM ConfigCaches - to be able to detect if these Doomsday scenarios will be a reality and then, when the TweakScale 2.4.3.1 is issued, I will be able to provide custom parches that would mangle the parts back to the wrong behaviour (saving the game), but without the risk of things going through the tubes due rogue patches going straight.or something.

 

2 hours ago, zer0Kerbal said:

The idea is that with the patches following best practices, that no matter how patches apply the same module, there will always only be ever one module; and the :FOR makes it possible to do :AFTER or :BEFORE (if I am understanding correctly).

EXACTLY!!  

 

2 hours ago, zer0Kerbal said:

I am unable to fix existing savegames, but this might help prevent Krakens from invading new save games, at least that is my goal. If I am wrong, I will wander off and go back to rescuing Kerbals and dealing with a spaghetti wobble in my LKO Station.

Backup everything and kick my up. Once I detect exactly where thing are wrong, I can handcraft a patch that would "break things again", but this time in a deterministic and safe way. What makes me think that I should "mark" these parts somehow and tell TweakScale to remember the user, regularly, that he doesn't should start new games using that installment.

Good brainstorming, @zer0Kerbal . This is what the good software feed on! Thanks!

[zer0Kerbal]

1 hour ago, Lisias said:

Yep.

It's not Module's fault, it is doing exactly what it's being told to do. I'm "teaching" it to detect some bugs, but there's a limit on what can be done automatically.

About the Patches…Well. Some of the problems are on me. Some of the TweakScale stock patches have the problem too, and to tell you the true I completely forgot to check my own patches before doing the release. Until the moment, not a single report was due only the Stock Patches, but yet they are there.

On my defense   only my Career game (still on 1.4.3 , the mainstream version on the last time I really played) detected these problems now that I fired up with the newest TweakScaçe, but as I said, it's more exactly ONE YEAR since I fire up it since the last time!!!  (dude, it was running one of my first "unofficial" compilations of TweakScale yet!)

Somewhere else on this forum I said that would be a good idea having more developers playing more the game in order to foresee in advance some possible consequences about the decisions they make.  Guess what? It applies perfectly to me too.  

Once TweakScale 2.5 goes gold (the Milestone I'm slowly pursuing through the 2.4.* series) I will take a break on this and go back to my Career. No Kerbal should be dragged away from his game for that time!  

 

There's a possible compromise on this.

Until the moment, almost every single rogue patch was trying to "overcome" the default behaviour. These ones, once everything is fixed, will still be the dominant ones - with the additional benefit of not risking ruining games when Add'Ons are installed, updated or even removed - destabilising the brittle balance that is allowing things to work at the moment.

There're some others that are applying the same patch twice. These ones are 'almost' harmless - but since they are applying themselves twice,  they will be being applied twice even if something else tries to overrule them. And then we would have a new instance of the last problem.

The nastiest problems, however, is when different patches are applied by error on the same part. This is a serious game braker because these patches are not only changing things in a unattended way (the others were doing it on purpose to get a new, predefined behaviour), ruining the current game, but they also are "vengeful"  as they also ruin the game when things are fixed!

 

This is not safe, as some rogue patches ends up acting only under determined circumstances. Anything gets different, the savegame is ruined as the brittle balance that were reached is broken and the chain ends up with different results.

So we need a set of deterministic, custom made patches, that would allow these savegames to carry on without being at risk. This is the reason I'm asking people to send me their KSP.log and MM ConfigCaches - to be able to detect if these Doomsday scenarios will be a reality and then, when the TweakScale 2.4.3.1 is issued, I will be able to provide custom parches that would mangle the parts back to the wrong behaviour (saving the game), but without the risk of things going through the tubes due rogue patches going straight.or something.

 

EXACTLY!!  

 

Backup everything and kick my up. Once I detect exactly where thing are wrong, I can handcraft a patch that would "break things again", but this time in a deterministic and safe way. What makes me think that I should "mark" these parts somehow and tell TweakScale to remember the user, regularly, that he doesn't should start new games using that installment.

Good brainstorming, @zer0Kerbal . This is what the good software feed on! Thanks!

Okay , last invasion of this thread. Yes, it has been most enlightening and entertaining.

we are on the same track. No Kerbal Left behind! Just Gremlins.... don't feed them after midnight, and don't get them wet!

Agree on marking the patches somehow - maybe a dummy statement in the MODULE[TweakScale]{ motto = don't panic}.

 

So I plan on uploading the updated patches to a fork on github for your perusal at your leisure wearing a lime green leisure suit. Only about 20,000 changes. If you like, just inform me of what other changes you desire and I shall try to make them. Maybe for now just put them out for 'new save games only'?

PS your English is better than most native English speakers. I am used to ESL speakers as my day career has me mingling with dozens of nationalities (usually 70+). Spell check and Grammerly helps mucho.

 

 

ps - forked and uploaded something like:

Showing with 7,185 additions and 7,185 deletions.

Edited June 15, 2019 by zer0Kerbal

[FreeThinker]

9 hours ago, whitespacekilla said:

Duplicate tweakscale attributes are getting applied to a lot of parts from a lot of mods. It eventually causes problems with vessels in flight and saved craft. One of the problems is ionEngines when KSPIE and Tweakscale are installed (I believe tweakscale is a dependency of KSPIE so this would be a problem for all KSPIE users). Because you remove any previous tweakscale module before adding a new one in your config for ionEngine, you've done nothing wrong and don't need to do anything to fix your mod (I believe it's tweakscale's own stock engine config file that is adding the duplicate type and default scale properties). But, if anyone on your  KSPIE support posts has an issue with "fatal warning" messages on "ionEngine" parts, you'll know that it is the result of this issue. It can eventually cause size changes in parts for saved craft and in-flight vessels (probably destroying them). Users with this issue should be able to get help correcting it if you send them over here.

Ok, but do I have to do anything to resolve exiting or potential problems?

Edited June 15, 2019 by FreeThinker

[Tonka Crash]

@Lisias I updated to your pre-release version this morning to see if I had any Showstoppers. None were found, but I am getting new exceptions that weren't in the log with the previous release or whatever CKAN considered the latest. I've looked at the ConfigCache and I don't see anything obviously wrong with the parts. 

MM.ConfigCache and KSP.Log: https://www.dropbox.com/s/2aonv89x7awr7su/TweakScaleException.zip?dl=0

Spoiler

[ERR 11:07:58.844] Cannot find config in file : dmSIGINT
[ERR 11:07:58.845] [TweakScale] part=dmSIGINT.End (Oversize Signals Intelligence Satellite) Exception on Sanity Checks: System.NullReferenceException: Object reference not set to an instance of an object
  at TweakScale.PrefabDryCostWriter.checkForShowStoppers (.Part p) [0x00000] in <filename unknown>:0 
  at TweakScale.PrefabDryCostWriter+<WriteDryCost>d__3.MoveNext () [0x00000] in <filename unknown>:0 
[ERR 11:07:58.846] Cannot find config in file : dmSIGINT
[ERR 11:07:58.847] [TweakScale] part=dmSIGINT.Small (Undersize Signals Intelligence Satellite) Exception on Sanity Checks: System.NullReferenceException: Object reference not set to an instance of an object
  at TweakScale.PrefabDryCostWriter.checkForShowStoppers (.Part p) [0x00000] in <filename unknown>:0 
  at TweakScale.PrefabDryCostWriter+<WriteDryCost>d__3.MoveNext () [0x00000] in <filename unknown>:0 
[ERR 11:07:58.868] [TweakScale] part=radialEngineMini.v2 (LV-1R "Spider" Liquid Fuel Engine) Exception on Sanity Checks: System.NullReferenceException: Object reference not set to an instance of an object
  at TweakScale.PrefabDryCostWriter.checkForShowStoppers (.Part p) [0x00000] in <filename unknown>:0 
  at TweakScale.PrefabDryCostWriter+<WriteDryCost>d__3.MoveNext () [0x00000] in <filename unknown>:0 
[ERR 11:07:58.891] [TweakScale] part=TonkaSuppliesTank (Radial Snack Canister) Exception on Sanity Checks: System.NullReferenceException: Object reference not set to an instance of an object
  at TweakScale.PrefabDryCostWriter.checkForShowStoppers (.Part p) [0x00000] in <filename unknown>:0 
  at TweakScale.PrefabDryCostWriter+<WriteDryCost>d__3.MoveNext () [0x00000] in <filename unknown>:0 
[ERR 11:07:58.892] [TweakScale] part=RLA.tiny.torque.radial (Tiny Radial Reaction Wheel) Exception on Sanity Checks: System.NullReferenceException: Object reference not set to an instance of an object
  at TweakScale.PrefabDryCostWriter.checkForShowStoppers (.Part p) [0x00000] in <filename unknown>:0 
  at TweakScale.PrefabDryCostWriter+<WriteDryCost>d__3.MoveNext () [0x00000] in <filename unknown>:0 

 

[salsathegeek]

Hey y'all, so just curious about how one would go about fixing a problematic TweakScale patch? I've found that Nertea's MkIV system has issues with the mk4cockpit-shoulder parts (1, 2, and 3 to be specific) and wanted to provide a patch he could integrate into his next release. I also figured this would be a good opportunity to work on some development chops that I don't get to use in my job (most of it is administration and management of assets with few opportunities to code something.) I'm going to be looking and trying stuff, but I figured it couldn't hurt to ask here. Thanks for your patience and I hope y'all have a great day.

[Lisias]

1 hour ago, salsathegeek said:

Hey y'all, so just curious about how one would go about fixing a problematic TweakScale patch? 

The cannonical way is to fork the project, hack the changes, commit, push and from the GitHub site issue a pull request.

It's easier than it looks, but is usually a bit cumbersome for non developers.

But you also can publish the file using pastebin or something and publish the link here. We can compare the fixes, sometimes we miss things.

---------

On a side note, I expect to release a new version tomorrow.

Real Life got into my way about releasing something today.

 

Edited June 15, 2019 by Lisias

[salsathegeek]

Ah. okay. I'd just confirmed that it was an issue with TweakScale's patches. I'm sure that you've got a better fix than what I could come up with. Just learning to be more thorough in my troubleshooting and careful in my reading. Thanks for taking the time to reply. I'll be looking forward to the update.

[ElonsMusk]

Ok you nerds are talking over my head now. Patiently watching this thread, trying to learn.

[Lisias]

1 hour ago, salsathegeek said:

I'm sure that you've got a better fix than what I could come up with. 

Statistically, perhaps. But don't undervalue a good hint given by someone outside the machine room where I'm living from some time.

We usually narrow our mindset when solving problems, what sometimes lead us to take a not so good decision. Not to mention learning a new trick or two from people that knows better some details (yeah, I learnt something too!).

Edited June 15, 2019 by Lisias
Typo maldito, typo maldito... Tralalalalalalá... :P

[salsathegeek]

The thing is I couldn't tell you what was wrong. That's one reason that I was saying that any fix you implemented would be better than anything I could come up with. I'm basically starting from square 1. Anyway, just copied the config file into my main game and I'm gonna see if that works.

[Tonka Crash]

I don't know if anyone reading here would find this useful, but I have a quick and dirty patch to hunt for parts without a TweakScale Module. I wouldn't play the game with this, but it's useful to at least load the game.

// Look for missing tweakscale
@PART[*]:HAS[!MODULE[TweakScale]] { %bulkheadProfiles = NoTweakScale }

It replaces the bulkhead profile with NoTweakScale, so in the VAB when you look at the parts by bulkhead profile, all the ones without a setting are grouped together in a ? folder. It will also tag all of them in the ModuleManager.ConfigCache.

[Tonka Crash]

@Lisias Adding parts on your "banned" list throw exceptions when added to a vessel in the VAB. I was noticing some craft saved before I updated this morning were now throwing exceptions when loading, so I deleted them. But further investigation seems to be that these had problematic parts like the structural tubes or engine plates. Just adding one of these to a craft in the VAB generate NREs

[ERR 17:34:14.103] Cannot find module 'TweakScale' (-699235618)

[ERR 17:34:14.103] Module TweakScale threw during OnStart: System.NullReferenceException: Object reference not set to an instance of an object
  at TweakScale.TweakScale.Setup () [0x00000] in <filename unknown>:0 
  at TweakScale.TweakScale.OnStart (StartState state) [0x00000] in <filename unknown>:0 
  at Part.ModulesOnStart () [0x00000] in <filename unknown>:0 
[LOG 17:34:15.386] Tube2 added to ship - part count: 4

[ERR 17:35:51.974] Cannot find module 'TweakScale' (-699235618)
[ERR 17:35:51.975] Module TweakScale threw during OnStart: System.NullReferenceException: Object reference not set to an instance of an object
  at TweakScale.TweakScale.Setup () [0x00000] in <filename unknown>:0 
  at TweakScale.TweakScale.OnStart (StartState state) [0x00000] in <filename unknown>:0 
  at Part.ModulesOnStart () [0x00000] in <filename unknown>:0 

[LOG 17:35:53.383] EnginePlate3 added to ship - part count: 5

 

@Lisias BTW, I created a PR for a typo in Squad_Engine.cfg. There was a comment without the '//' that was causing a patch to fail.

[whitespacekilla]

22 hours ago, FreeThinker said:

Ok, but do I have to do anything to resolve exiting or potential problems?

Nope. Your method of negating a module before editing / creating it again in module manager patches is sound. Any mod that loads after can mess the modules up, though. KSPIE is the only mod I can think of that bundles/requires tweakscale,, and the tweakscale ionEngine patch was causing duplicate attributes so just about every KSPIE user would have the duplicate type and default scale attributes on their ionEngine configs and depending on version, get the tweakscale warning.

On top of that, once craft and in-flight vessels based on the flawed part configs are built, I'm pretty sure there's no way to push a config to fix it. The save file will need to be edited (or those in-flight vessels and craft will need to be brought home/deleted). If you wanted to be extra cautious, maybe don't change the tweakscale type in KSPIE's ionEngine cfg. @Lisias would know more about that but from what I understand, the bug actually activates once a vessel that depends on a problem tweakscale config is using a fixed/altered version of that problem config. In the majority of cases, a difference in scale type or scales available would be the most likely trigger.

Edited June 16, 2019 by whitespacekilla

[viperwolf]

@Lisias Im not sure why, but you make laugh when you post threads. You er a funny guy, but humble at the same time.  You have patience of steel, something I do not posses.

[Lisias]

18 hours ago, Tonka Crash said:

@Lisias Adding parts on your "banned" list throw exceptions when added to a vessel in the VAB. I was noticing some craft saved before I updated this morning were now throwing exceptions when loading, so I deleted them. But further investigation seems to be that these had problematic parts like the structural tubes or engine plates. Just adding one of these to a craft in the VAB generate NREs

[ERR 17:34:14.103] Cannot find module 'TweakScale' (-699235618)

[ERR 17:34:14.103] Module TweakScale threw during OnStart: System.NullReferenceException: Object reference not set to an instance of an object
  at TweakScale.TweakScale.Setup () [0x00000] in <filename unknown>:0 
  at TweakScale.TweakScale.OnStart (StartState state) [0x00000] in <filename unknown>:0 
  at Part.ModulesOnStart () [0x00000] in <filename unknown>:0 
[LOG 17:34:15.386] Tube2 added to ship - part count: 4

[ERR 17:35:51.974] Cannot find module 'TweakScale' (-699235618)
[ERR 17:35:51.975] Module TweakScale threw during OnStart: System.NullReferenceException: Object reference not set to an instance of an object
  at TweakScale.TweakScale.Setup () [0x00000] in <filename unknown>:0 
  at TweakScale.TweakScale.OnStart (StartState state) [0x00000] in <filename unknown>:0 
  at Part.ModulesOnStart () [0x00000] in <filename unknown>:0 

[LOG 17:35:53.383] EnginePlate3 added to ship - part count: 5

 

Hummm .. So this is what happening. I didn't understood the first time this was reported

https://github.com/net-lisias-ksp/TweakScale/issues/41

Yeah. Somehow, KSP is using both prefab and craft data to instantiate something. Now that I have a deterministic way to reproduce the problem, I can test it and try a fix.

On a wild guess, I think I should instrument TweakScale to detect these issues and shutdown itself for that part.

[Azic Minar]

Just wanted to say, thank you for your hard work!

[Tonka Crash]

33 minutes ago, Lisias said:

Hummm .. So this is what happening. I didn't understood the first time this was reported

https://github.com/net-lisias-ksp/TweakScale/issues/41

Yeah. Somehow, KSP is using both prefab and craft data to instantiate something. Now that I have a deterministic way to reproduce the problem, I can test it and try a fix.

On a wild guess, I think I should instrument TweakScale to detect these issues and shutdown itself for that part.

It's probably something in how you exclude these parts from scaling. These problem parts (tubes and engine plates) have a tweakscale module defined in the ModuleManager.ConfigCache on my computer, so they look scalable until TweakScale decides it doesn't work with them.

[Lisias]

12 hours ago, Tonka Crash said:

It's probably something in how you exclude these parts from scaling. These problem parts (tubes and engine plates) have a tweakscale module defined in the ModuleManager.ConfigCache on my computer, so they look scalable until TweakScale decides it doesn't work with them.

More or less.

The ConfigCache is how things will be on the prefab. Then, after MM data injection, on the Main Menu a lot of Add'Ons are triggered, and they do some specialised changes on the GameData. SscanSAT, KAS, Mission History, and more, do that. And now TweakScale.

The net result is that the GameData doesn't reflects anymore what ConfigCache have in its records.

TweakScale, however, appear to be the only one that undo some things when it detects a problem. It plain withdraw any TweakScale support from problematic parts, so the problem is not even saved on a craft file (and savegames) with TweakScale support, preventing triggering problems on older TweakScale installations.

What caught me with my pants down is KSP insisting on using prefab's TweakScale module information from a part that have the info on its MODULE node.

If such data is on the craft, what's the point on trying to use the prefab data to overrule the craft data? And if the prefab data is meant to overrule craft data, why such data is saved on the craft file at first place?

In a way or another, it's unfeasible to expect KSP change this (be it a mistake or a valid change that fixed some other problem), so it's up to me to deal with it.

 

Edited June 17, 2019 by Lisias
"at first place"

[Mathrilord]

?????????? (drag)

mk3 to 2.5m adapter scale down from 3.75m to 1.875m 

nosecone black

Edited June 17, 2019 by Mathrilord

[Lisias]

13 hours ago, Mathrilord said:

?????????? (drag)

mk3 to 2.5m adapter scale down from 3.75m to 1.875m 

nosecone black

Interesting. Apparently drag is not being scaled down. Could you please test if it scales up?

[Mathrilord]

what all my part now have drag and lift. That's new?

edit: after testing my conclusion is that this part drag/lift doesn't scale properly.

(It does scale up) but drag is still too high

edit2: there is some weird thing going on with this. 

edit3: replaced adapter by a single nosecone scale up to 1.875m and now it's the cargo bay that have too much drag.

edit4: maybe tweakscale only amplified a bug from the base game as I just found more weird thing with mk3 part on a stock install.

edit5: avoid using any mk3 

Edited June 18, 2019 by Mathrilord

[Lisias]

News from the Front.

Real Life stubbornly insisted on getting on my way, but I managed to accomplish the needed tasks for 2.4.3.1 . It's currently under tests.

I will not set a deadline however - last two times I did that, I botched  . But it will happen soon.  

For the curious:

https://github.com/net-lisias-ksp/TweakScale/tree/dev/emergencial/2.4.3.1

https://github.com/net-lisias-ksp/TweakScale/milestone/7

[Galland1998]

When I install the 2.4.3 version of this mod I get an error dialog box that tells me bad this are going to happen.  If I roll back to the 2.4.2 version that is on CKAN I don't get the failure message.  I am running KSP on 1.7.1 but have a ton of other mods installed so I don't know what is causing this.