Lisias

[>= 1.4] TweakScale - Under Lisias' Management - 2.4.3.4 - 2019-0903

Recommended Posts

Posted (edited)
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 by zer0Kerbal
quad damage?

Share this post


Link to post
Share on other sites

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. :cool::P:D

 

Share this post


Link to post
Share on other sites

(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 :P  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. :D 

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. :cool::P:D

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!

Share this post


Link to post
Share on other sites
Posted (edited)
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 :P  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. :D 

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}. :P

 

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. :P 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 by zer0Kerbal

Share this post


Link to post
Share on other sites
Posted (edited)
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 by FreeThinker

Share this post


Link to post
Share on other sites

@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 

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Posted (edited)
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 by Lisias

Share this post


Link to post
Share on other sites

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. :)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Posted (edited)
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. :D

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 by Lisias
Typo maldito, typo maldito... Tralalalalalalá... :P

Share this post


Link to post
Share on other sites

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. :)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

@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.

Share this post


Link to post
Share on other sites
Posted (edited)
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 by whitespacekilla

Share this post


Link to post
Share on other sites

@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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Posted (edited)
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 by Lisias
"at first place"

Share this post


Link to post
Share on other sites
Posted (edited)

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

uxbWLYN.png

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

nosecone black

Edited by Mathrilord

Share this post


Link to post
Share on other sites
13 hours ago, Mathrilord said:

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

uxbWLYN.png

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?

Share this post


Link to post
Share on other sites
Posted (edited)

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 by Mathrilord

Share this post


Link to post
Share on other sites

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 :P . 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

Share this post


Link to post
Share on other sites

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.  

Share this post


Link to post
Share on other sites

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.