Lisias

Nothing to be gained. The .8 and .9 releases are merely lock ups to prevent running on KSP 1.8 without warnings. You can safely skip them - not even a typo was fixed. Boldly crashing what no Kerbal has crashed before, sir! Welcome! Send me a KSP log of the thing - from startup until you tried using it, borking, and then quitting KSP (so I have a full session). Procedural wings is something too much cool to leave things as it is.

For KSP 1.4.1 to 1.7.3, yes. The spacedock ".9" is just a repacking to fix a bork of mine on CKAN. Just a remind: on KSP 1.8, officially, will not work. You can hit "Cancel" and keep going - you will be able to fly your crafts, but editing them will be really painful. Too late.

Welcome to the club. Rest assured, whatever is the problem, we will help to diagnose and most of the time fix it in a way of another. Kick me here anytime.

Jeb will outlive all if us, sir! PS: going to space is easy. Going to space a second time is the hard part!

I'm smelling race conditions. And I didn't considered it before, the lucky strike on TS can be even more luckier than I thought, as minimalist forgings on what I expect to be a working configuration didn't gave me any results yet. @kcs123 thanks for bringing me here. You helped me to open my eyes on something I was plain ignoring.

What's a concise way to say the same thing. I'm working on making it to work, but it doesn't works yet.

Bug #24014, sir. This one I know from heart. That weird things are weird indeed, but it's nothing that exoteric. It happens that TweakScale (ab)uses that poor control in different configurations, depending how a thingy called ScaleType is configured - and there's a huge amount of these things, as different parts need different rules to be scaled and these ScaleTypes are part of the process. And by plain luck, a third party decided to write his own rules, and did it the way it wanted, not the way TweakScale were doing things, and by yet more luck, one of that configurations had set up the UI_ScaleEdit control in a way it ended working!! Don''t try to figure out the odds of that happening. We got insanely lucky on this one. What is needed to be done is to identify the code flow of the successful configuration to identify the working settings for the UI_ScaleEdit - something that will demand some time of trial and error, to be executed as Real Life allows. Since UI_FloatEdit and UI_FloatRange appears to be borking in the exact same way as ScaleEdit, there's a good chance that they share the same borking code - and so, figuring out one of them will help the other two. Here and here.

No. A recompile will have zero difference on the problem. The problem is something inside KSP's widgets (PAWs?), and anything running on KSP 1.8, being it recompiled or not, will bork on that thing. The ending results is only a non working UI control. At the time I had issued 2.4.3.8, I didn't knew what as happening yet, and remembering the past problems when Unity had changed, I choose to be extra cautious and recooked the FATAL message. One week later, we know better. But we are 100% focused on making our Add'Ons to work on KSP 1.8, and reissuing a version just to change some text on a Message Box is not exactly a priority right now. And we still don't have neither a fix from KSP 1.8 neither a workaround for TweakScale, so it makes reissuing a new version even less important. Exactly. In the rush, I just shoved the message on something I already had and called it a day. Future versions of the HOUSTON will be more flexible to address better different kinds of failures, this time the message was way overzealous. I will need the full KSP.log (and, to save time, also ModuleManager.ConfigCache) available on some file sharing service in order to be able to help you. Don't publish them here (it would break the Forum for most users due the size of the thing).

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!!!