Lisias

I think the last time I saw it was on 1.4.3…. It's silly, but little trinkets like this one is surprisingly enjoyable for me!

I don't mind doing beta testing neither. But I prefer doing it when knowing I'm doing it - so I don't waste time looking for problems where they don't exist!!! Yep. But the ScaleType is not the problem, neither is broken. It's the trigger for the problem. There's nothing to be fixed on it, and I'm saying this because in order to identify and perhaps workaround the problem, we need to see beyounf ScaleType, we need to check who is using it and for what. That said, (ab)using of my author powers I instrumented TweakScale's code to fully report everything it's loading into memory, and the state of the data structures once they are loaded. Dude, huge reports - scary even to me. This is how BluedogAntenna (that works) and BluedogStack (that doesn't) looks on memory: [LOG 08:28:00.875] [TweakScale] TRACE: scaleConfig:ScaleType { name = BluedogAntenna family = default suffix = isFreeScale = False 26 Exponents = [ Part:ScaleExponents {Part/Part} ] [ ModuleWheelBase:ScaleExponents {ModuleWheelBase/ModuleWheelBase} ] [ ModuleWheelMotor:ScaleExponents {ModuleWheelMotor/ModuleWheelMotor} ] [ ModuleWheelBrakes:ScaleExponents {ModuleWheelBrakes/ModuleWheelBrakes} ] [ ModuleCargoBay:ScaleExponents {ModuleCargoBay/ModuleCargoBay} ] [ ModuleAnchoredDecoupler:ScaleExponents {ModuleAnchoredDecoupler/ModuleAnchoredDecoupler} ] [ ModuleDecouple:ScaleExponents {ModuleDecouple/ModuleDecouple} ] [ ModuleGenerator:ScaleExponents {ModuleGenerator/ModuleGenerator} ] [ ModuleDeployableSolarPanel:ScaleExponents {ModuleDeployableSolarPanel/ModuleDeployableSolarPanel} ] [ ModuleReactionWheel:ScaleExponents {ModuleReactionWheel/ModuleReactionWheel} ] [ ModuleDataTransmitter:ScaleExponents {ModuleDataTransmitter/ModuleDataTransmitter} ] [ ModuleDockingNode:ScaleExponents {ModuleDockingNode/ModuleDockingNode} ] [ ModuleGrappleNode:ScaleExponents {ModuleGrappleNode/ModuleGrappleNode} ] [ ModuleAlternator:ScaleExponents {ModuleAlternator/ModuleAlternator} ] [ ModuleEngines:ScaleExponents {ModuleEngines/ModuleEngines} ] [ ModuleRCS:ScaleExponents {ModuleRCS/ModuleRCS} ] [ ModuleControlSurface:ScaleExponents {ModuleControlSurface/ModuleControlSurface} ] [ ModuleLiftingSurface:ScaleExponents {ModuleLiftingSurface/ModuleLiftingSurface} ] [ ModuleAeroSurface:ScaleExponents {ModuleAeroSurface/ModuleAeroSurface} ] [ ModuleResourceIntake:ScaleExponents {ModuleResourceIntake/ModuleResourceIntake} ] [ ModuleResourceHarvester:ScaleExponents {ModuleResourceHarvester/ModuleResourceHarvester} ] [ ModuleResourceConverter:ScaleExponents {ModuleResourceConverter/ModuleResourceConverter} ] [ ModuleCoreHeat:ScaleExponents {ModuleCoreHeat/ModuleCoreHeat} ] [ ModuleAsteroidDrill:ScaleExponents {ModuleAsteroidDrill/ModuleAsteroidDrill} ] [ ModuleJettison:ScaleExponents {ModuleJettison/ModuleJettison} ] [ ModuleActiveRadiator:ScaleExponents {ModuleActiveRadiator/ModuleActiveRadiator} ] 4 scaleFactors = 0.6 0.8 1 1.2 4 scaleNames = 60% 80% 100% 120% 0 incrementSlide = 0 TechRequired = defaultScale = 1 scaleNodes = } [LOG 08:28:00.474] [TweakScale] TRACE: scaleConfig:ScaleType { name = BluedogStack family = default suffix = m isFreeScale = True 26 Exponents = [ Part:ScaleExponents {Part/Part} ] [ ModuleWheelBase:ScaleExponents {ModuleWheelBase/ModuleWheelBase} ] [ ModuleWheelMotor:ScaleExponents {ModuleWheelMotor/ModuleWheelMotor} ] [ ModuleWheelBrakes:ScaleExponents {ModuleWheelBrakes/ModuleWheelBrakes} ] [ ModuleCargoBay:ScaleExponents {ModuleCargoBay/ModuleCargoBay} ] [ ModuleAnchoredDecoupler:ScaleExponents {ModuleAnchoredDecoupler/ModuleAnchoredDecoupler} ] [ ModuleDecouple:ScaleExponents {ModuleDecouple/ModuleDecouple} ] [ ModuleGenerator:ScaleExponents {ModuleGenerator/ModuleGenerator} ] [ ModuleDeployableSolarPanel:ScaleExponents {ModuleDeployableSolarPanel/ModuleDeployableSolarPanel} ] [ ModuleReactionWheel:ScaleExponents {ModuleReactionWheel/ModuleReactionWheel} ] [ ModuleDataTransmitter:ScaleExponents {ModuleDataTransmitter/ModuleDataTransmitter} ] [ ModuleDockingNode:ScaleExponents {ModuleDockingNode/ModuleDockingNode} ] [ ModuleGrappleNode:ScaleExponents {ModuleGrappleNode/ModuleGrappleNode} ] [ ModuleAlternator:ScaleExponents {ModuleAlternator/ModuleAlternator} ] [ ModuleEngines:ScaleExponents {ModuleEngines/ModuleEngines} ] [ ModuleRCS:ScaleExponents {ModuleRCS/ModuleRCS} ] [ ModuleControlSurface:ScaleExponents {ModuleControlSurface/ModuleControlSurface} ] [ ModuleLiftingSurface:ScaleExponents {ModuleLiftingSurface/ModuleLiftingSurface} ] [ ModuleAeroSurface:ScaleExponents {ModuleAeroSurface/ModuleAeroSurface} ] [ ModuleResourceIntake:ScaleExponents {ModuleResourceIntake/ModuleResourceIntake} ] [ ModuleResourceHarvester:ScaleExponents {ModuleResourceHarvester/ModuleResourceHarvester} ] [ ModuleResourceConverter:ScaleExponents {ModuleResourceConverter/ModuleResourceConverter} ] [ ModuleCoreHeat:ScaleExponents {ModuleCoreHeat/ModuleCoreHeat} ] [ ModuleAsteroidDrill:ScaleExponents {ModuleAsteroidDrill/ModuleAsteroidDrill} ] [ ModuleJettison:ScaleExponents {ModuleJettison/ModuleJettison} ] [ ModuleActiveRadiator:ScaleExponents {ModuleActiveRadiator/ModuleActiveRadiator} ] 17 scaleFactors = 0.1 0.3 0.625 0.9375 1.25 1.5 1.875 2.5 3.125 3.75 4.25 5 5.625 6.375 7.5 10 20 0 scaleNames = 16 incrementSlide = 0.01 0.0125 0.0125 0.0125 0.025 0.025 0.025 0.025 0.025 0.025 0.025 0.025 0.025 0.025 0.1 0.2 0 TechRequired = defaultScale = 1.25 scaleNodes = } They differ on incrementSlide, scaleNames and Suffix. One (or more) os these ones is/are triggering the problem on Stack. The thing that is borking is the UI_ScaleEdit. So, something on the above data-structures, when applied to UI_ScaleEdit, causes the problem or makes it work. The signature if this control is: public class UI_ScaleEdit : UI_Control { private const string UIControlName = "ScaleEdit"; public float[] intervals = new float[3] { 1f, 2f, 4f }; public float[] incrementSlide = new float[2] { 0.02f, 0.04f }; public bool useSI; public string unit = ""; public int sigFigs; public float MinValue (); public float MaxValue (); public override void Load (ConfigNode node, object host); public override void Save (ConfigNode node, object host); } Your mission, should you choose to accept it is to identify what datum of the data-strucutres are being aplied on which field of the Fields["TweakScale"] in order to see what is making this work, and what is making this bork. This forum will autodestru… Uhhh.. Nope. Here. You will need a DISCARDABLE KSP 1.8 installment, then install the latest TweakScale, then download the zip file from that comment and unzip it over the older DLLs. The link for the source code is on the post too. Keep in mind that this thing is a Log hog. It will log the colour of your kitchen's sink if you run this on a notebook on your kitchen - and all that log will impair your KSP framerate. Not for use on "production".

YOU GOT A SANDCASTLE!!! MAGNIFICENT!!! It's a whole year (if not more) since I got one!

I just updated SpaceDock with the 2.8.0.2, following your heads up. Thanks, and sorry for the misunderstanding.

Sir, I own you an apology. You are right, I forgot to update SpaceDock. Sorry. In my defense, I'm awake for more than 18 hours and worked the whole day, partially business, partially detecting problems on TweakScale, and I'm really wasted. I will update SpaceDock by the morning, as as you can see, it will be probably not the best of ideas to update things at this moment.

KAX is propeller oriented. It even has some engine from near Wright era!

At least for KSP 1.7 downto 1.4, with the engine module of that era, nope. The thrust of the engines are more or less related to real life. I already had discussed this previously: TLDR: You can simply convert the engine HP into KN . The piston engine is way different from jets, and at least for KSP 1.4 to 1.7.3, what KAX have is more or less realistic. It's insane having a small turboprop (as from another add'on) to have the same thrust of a Cessna Citation engine! I have no information yet about KSP 1.8

The parts of KAX that I love most is the cockpit and the engines. The vintage propellers have a huge potential, but they need companion parts. And I really need to make that gorgeous gears to work again!

Dude, thanks! I was kinda offline doing tests and writing that report above, and missed your post. Yes, you reached exactly the same results I did. Now we have two guys' results on different parts, on different ways, but with the very same results. Thanks again!

It is not on CKAN yet, there are a fez adjustments I need to do first. I'm trying to resurrect the gears, and I originally planned to launch it on CKAN with the gears. I didn't planned it would take so much, however. And I`m not even sure this works on KSP 1.8 yet, because I didn''t had time to test it yet! — — POST EDIT — — It should be a better idea not answering support questions late night after a full day of hard work. I registered KAX on CKAN on May, damn it. And completely forgot about….

I have a new diagnosis, and this one is backed by hard, concrete and reproducible evidences. The whole story is on TweakScale thread, because one fellow Kerbonaut found one Add'On where the UI_ScaleEdit was working fine!! I tracked down what was working, then I made it broke, then I "fix" one of TweakScale patches - so I have confirmation on both sides of the equation this time. [KSPField(isPersistant = false, guiActiveEditor = true, guiName = "Scale", guiFormat = "0.000", guiUnits = "m")] [UI_ScaleEdit(scene = UI_Scene.Editor)] The thing I think by now can be the problem is the guiUnits (or even the guiFormat?), but it's all wild guesses. All that I know for now is that is on the TweaklScale thread - there's a ScaleType from BDB that works while default ScaleTypes from TweakScale does not. The visible difference is not using the ScaleRtpe data called "suffix" - I will check this properly tomorrow. See ya later.

I FINALLY figured out what's happening, but don't know (yet) why. Well, baby steps. The problem is on the SCALETYPE. And this is ironic at least, because I would never had though on checking the SCALETYPES of TweakScale, as they are working for years. (sigh) What's happening: Bluedog Bureau has its own scaling types, and they call them BluedogAntenna and BluedogStack. What I did was to get one antenna from BDB (I choose bluedog_mariner2Antenna - A27-C Antenna) and shove on it free_square (one of the TweakScale "stock" types) and then I shoved BluedogAntenna for one of the stock antennas (I choose longAntenna - Communotron 16 ). @PART[bluedog_mariner2Antenna]:FINAL //A27 { %MODULE[TweakScale] { %type = free_square } } @PART[longAntenna]:FINAL // Communotron 16 { %MODULE[TweakScale] { %type = BluedogAntenna } } Guess what? Yep, you right! Now things are inverted! BDB Antenna is kaput, but the Communotron 16 now scales (under Bluedog's rules). On the image below, first one is the "untainted" GameData, the second one with the patch above applied. The Bluedog's scaletype definitions are on this file. The A27C patch is defined on this file. BOTH were committed 3 years ago, and this information is of the upmost importance. There're commits on TweakScale patches aged 3 days only, but I specifically choose that Antenna due its age. For reference, this is BDB BluedogAntenna scaletype definition: SCALETYPE { name = BluedogAntenna freeScale = false scaleFactors = 0.6, 0.8, 1.0, 1.2 scaleNames = 60%, 80%, 100%, 120% defaultScale = 1.0 } And this is TweakScale's free_squared: SCALETYPE { name = free_square freeScale = true defaultScale = 100 suffix = % scaleFactors = 10 , 50 , 100 , 200 , 400 incrementSlide = 1 , 1 , 2 , 5 TWEAKSCALEEXPONENTS { mass = 2 } } My job tomorrow (because I'm totally, completely and utterly wasted by now) is to find exactly what is borking on my patch, why it's borking, but also and most important, WHY IN HELL THIS THING WAS WORKING BEFORE. [naahh, I know it already, it's something on the UI_ScaleEdit - dude, I need to sleep… ] (not to mention the other fellow Add'On authors that also are borking on something related to it!!!) Apparently, it's not the incrementSlide thingy, because the BluedogStack type also has less values on it than scaleFacrtors. but that doesn't means that this is not involved somehow. My current guess is the suffix, but I`m done for today. I will check this tomorrow.

Right now I have solid evidence that every Blue Dog Bureau part I tried [using BluedogAntenna - I got "lucky", all the random parts I tried ended up using Antenna] have the UI working, besides I had hacked out every dependency and DLL from the thing (that poor thing is only assets and configs at the moment). The only DLLs on the GameData are TweakScale's, ModuleManager 4.1.0 stock, and one more on Squad about the steam controller IIRC. At the moment, it's all the information I have - anything else would be guessing. I'm back to the brute forcing, I will give feedback as as soon as I have something reproducible.

I understood. Didn't meant to be rude, I'm sorry - I'm currently in "Search and Destroy" (bugs) mode, and my social skills became a bit hampered on that mode!

Dude, I quit thinking. I'll brute force my way into it. I will go Combinatorial Analysis on the issue, both trying to reproduce a new part with the (fixed) behaviour, as well trying to break one that is behaving. Damn, that adaptor to shove an SSD on my MacMini didn't arrived yet.

Welcome! But the latest it was not a recompile, just a repacking to prevent it to run on KSP 1.8 without a warning, as there're serious glitches on KSP 1.8, as you can see on the previous post. Let me know if you find something weird! Cheers!

Wow… That caught me with my pants down. Thanks for the heads up! I completely forgot about the addon binder!!!

Lack of time, dude! I need to get things right and stable before trying new things, or we will never be sure if the eventual crash is due some bug inside the system, or something you did wrong while scaling. There's a lot of uncharted waters on Serenity, it's not wise to sail on them with a leaky boat! It's the reason we test things one at a time. The blades are behaving different on KSP 1.8, by the way… But so must be everything else, the first few hours I had for playing was yesterday night and a bit of this morning - and I had to did it on KSP 1.7.3.

He's using TweakScale module, and the Scaling control is the one from TweakScale, as far as I could understand. I'm peeking on its source code right now, looking for every occurrence of KSPField (where we hang a UI_Control in order to change the value from the UI), and BDB doesn't instances a single UI_Control. The few KSPFields that appears on the PAW, uses whatever KSP gives them by default. It's merely the presence of the BDB.dll on the part that makes it to work, as it would initializes something that is needed somewhere in memory, and then TweakScale would not doing because parts without a BDB module does not shows the UI_Control correctly. [ NO!!! ] It could be, also, something that TweakScale should not be doing, triggering some problem inside en empty try-catch on KSP guts and aborting whatever it should had done. But that would render the UI_Control problematic with or without the presence of BDB.dll.[ NO!!! ] Perhaps. But I have a yet more serious problem to cope: the mere presence of a third-party DLL "fixed" the problem for a part. This implies that, somehow, a PartModule is affecting the behaviour of another one indirectly and in a unattended way. This creates problems that are horribly hard to detect and fix. [ NO!!! ] If someone is willing to double check what I'm doing, I just rebuilt "The World" around here following the advices from this post trying to identify something that I should not be doing. The new branches are this one for KSPe.Light.TweakScale and this one for the TweakScale dev branch. Everything and the kitchen's sink is compiled for KSP 1.8 and against the recommended DLLs on the post I linked. The Module Manager I'm using is the latest one, 4.1.0, from the maintainers page. The BDB I'm using is exactly this one, obviously the 1.8 build (and I just checked it again). — — — POST EDIT — — — IT'S NOT THE DLL. I just deleted every DLL from DBD, leaving only the patches, configs and assets. And yet, BlueDog parts have their parts with a good UI, while TweakScale ones does not.

Or some inscription on some old construction as a Piramid: "Στο HarversteR έχουμε εμπιστοσύνη."

Hey, I have hard evidences (i.e, proof!!) that I may had misdiagnosed the cause of the problem! When the scaling is being called from BDB.dll, it works. When it's called from TweakScale, it does not. Right now, I'm sniffing into BDB source code to see what it does (or does not) differently from the rest of us.

First, I need to nail down the root cause, otherwise I would be giving misleading information. Absolutely most of the Add'Ons (if not all!) involved are Screaming Victims of the problem, so I want to be extremely careful on trimming down the possibilities, and avoid overload yet more the already overloaded fellow Add'On Authors. It's not funny using your time to dig into unrelated problems while leaving your own pups starving. And about speaking on the Devil, I plain deleted everything from the TestBed, except BDB, TweakScale and CRP. The Module Manager used is the one that came with BDB, by the way. And I got this: Note that the very same control used by TweakScale works under BDB's parts, but not under the ones TweakScale touched itself. So I nailed down the possibilities to Scale.dll and BDB.dll - everything else was deleted (including MiniAVC.dll): macmini51:GameData lisias$ find . -type f -name "*.dll" ./Bluedog_DB/Plugins/BDB.dll ./ModuleManager.4.1.0.dll ./Squad/Plugins/KSPSteamCtrlr.dll ./TweakScale/Plugins/KSPe.Light.TweakScale.dll ./TweakScale/Plugins/Scale.dll ./TweakScale/Plugins/Scale_Redist.dll macmini51:GameData lisias$ And remembering that I had compiled TweakScale in both 3.5 and 4.x compilers without any change on the behaviour. So, it may be something I should had done (or should not) on TweakScale, it may be something BDB is doing (or not doing), or it may be something that is happening when this two DLLs do what they do at the same time (one of that unholy interactions between modules).

Ladies and Gentlemen, we have confirmation!!! Thanks, dude! I reproduced this on my rig!! Now I have something to work on! (there're heroes everywhere!!!)

Made-men.

The UI component is remarkably similar to the one TweakScale uses. And this is not the first report I have about a working TweakScale on KSP 1.8 , besides with a slightly different mod set. Can you, please, send me the KSP.log from your working installment? Are you using Steam or other service with automatic updates? If yes, your KSP 1.8 were updated from 1.7.3 by this service? I'm not (anymore). I'm not the only one with the problem, however. A lot of people expended a considerable amount of effort trying to figure out the problem, initially thinking like me "hummm… ok, where I borked this time?". And in the mean time, we have to explain the users what's happening. Users can be demanding sometimes, but most of them gets satisfied with an explanation - knowing what's happening gave them confidence that the problem will be solved somehow. Welcome! (do you see what I mean?)