[KSP >= 1.3.0] TweakScale - Under Lisias' Management - 2.4.8.6 - 2024-0921

[ansaman]

@Lisias I may have noticed something significant. I used to see while tuning my aircraft that the authority used to go to 150 and default to 100. Now, with UNMODDED KSP 1.8 and UNMODDED Making History, the scale has changed. It now defaults to 20, further, they added the option of deploy angle that did not exist before. I do not know if this is a bug or a feature, but I am speculating that something changed in Unity regarding these variables or in their adoption of the new Unity. The change of scale could be the borking factor, BUT I could be wrong....

 

 

Edited October 20, 2019 by ansaman
To add tag for Lisias and edit authority scale

[Commodore_32]

Maybe thats because TweakScale doent support 1.8

However i cant try it because it gets stuck on the start menu

But if i could play it the same and other problems will happen to me

[Lisias]

6 hours ago, ansaman said:

@Lisias I may have noticed something significant. I used to see while tuning my aircraft that the authority used to go to 150 and default to 100. Now, with UNMODDED KSP 1.8 and UNMODDED Making History, the scale has changed. It now defaults to 20, further, they added the option of deploy angle that did not exist before. I do not know if this is a bug or a feature, but I am speculating that something changed in Unity regarding these variables or in their adoption of the new Unity. The change of scale could be the borking factor, BUT I could be wrong....


 

They shifted the guiUnits from Percentage to Degrees. This is something we set on the KSPField thingy. And then you use a UI_FloatRange to set the limits, and these limits are customized on every Add'On.

[KSPField(isPersistant = false, guiActiveEditor = true, guiName = "Scale", guiFormat = "0.000", guiUnits = "m")]

TweakScale uses Meters, and the UI_FloatRange is constantly being changed, depending of the part`s scale type (free, stacked, etc).

So it's not this change that borked TweakScale, as this setting is specific for Control Surfaces, and TweakScale uses its own settings.

However, YOU HAD NAILED the reason TweakScale is borking, you correctly inferred the inherent problem. Something had changed that rendered the code that updates TweakScale's UI_FloatRange ineffective.

Congrats, dude.  And thank you.

21 minutes ago, Commodoregamer118 said:

However i cant try it because it gets stuck on the start menu

The latest TweakScale shows a scary message, but still allows you to proceed at your risk (hit "Cancel").

If a message is not being displayed, it's something else locking up the process. Publish your KSP.log, with a bit of luck I can pinpoint the culprit and so you can proceed to ask for help from the Add'On maintainer (assuming it's not something silly that can be easily fixable by us, it happens sometimes).

[Commodore_32]

Ahh thats wihtout mods by the way

 

[AmpCat]

@Lisias, sorry, slightly off topic; but you said you were working on something called KSPe.. what's that, if you don't mind me asking?

[Lisias]

1 hour ago, AmpCat said:

@Lisias, sorry, slightly off topic; but you said you were working on something called KSPe.. what's that, if you don't mind me asking?

Not a problem.

A long time ago, in a KSP far, far away, Swamp-ig started a thing called KSP API Extensions, adding a lot of functionalities to the KSP 0.xx series. As the time gone by, KSP implemented some of that, and new Add'Ons migrated to native.

But some others didn't, and they got stuck in the past. I was planning to rescue them to modern days, but I didn't wanted to adopt them - I wanna be able to install the original package and get away with the stunt.

So I realised that KSP API Extensions would be the thing I would need to work on in order to reach that goal.

But then I realised that KSPAPI was not enough. I also needed a KSP Abstraction Layer, in the same faction MACH kernels need a Hardware Abstraction Layer. And then KSPe was born! I thought on naming the thing KAL (KSP Abstraction Layer), but I had a hunch that this name was in risk of being used by someone with bigger guns (too good of a name to keep unused for too much time) and so decided to name it KSPe (KSP Extensions). I also though on naming the thing KFC (Kerbal Foundation Classes), but then I remembered the times I sweated blood with the different MFC versions and ditched the idea. I'm not that masochist!

KSPe will be the foundation in which KSP (and now Unity) differences will be kinda abstracted, allowing the same DLL to run on any KSP version if desired.

And so, both KSPAPI and KSPe would fulfill my goal: run older KSP Add'Ons on modern KSP.

Obviously, this is not simple. And at that time, I lacked experience on Add'On authorship (still does, but a bit less), so I did what a skillful (and stubborn) engineer would do: started to fix anything at sigh in need of being fixed - it's the best way to learn, nothing beated it in centuries of technological advances.

And then some crazy Kerbonauts thought it could be a good idea (poor Kerbals) to handle me over some Add'Ons, and here we are.

KSPe.Light.TweakScale.dll is a very light subset of KSPe, so I can put in production stable features and start to get some benefits from it (otherwise I would end neglecting it).

Edited October 20, 2019 by Lisias
tyops. as usulla.

[Lisias]

I was wrong! =D That was a dead code by design!!  

TweakScale is using UI_ScaleEdit now, I found a note on the Release Notes.

[LOG 19:03:47.828] [TweakScale] TRACE: FIELD tweakScale BaseField UI_ScaleEdit
[LOG 19:03:47.828] [TweakScale] TRACE: FIELD tweakName BaseField UI_ChooseOption
[LOG 19:03:47.828] [TweakScale] TRACE: FIELD currentScale BaseField UI_Label
[LOG 19:03:47.828] [TweakScale] TRACE: FIELD defaultScale BaseField UI_Label
[LOG 19:03:47.828] [TweakScale] TRACE: FIELD isFreeScale BaseField UI_Label
[LOG 19:03:47.828] [TweakScale] TRACE: FIELD defaultTransformScale BaseField UI_Label
[LOG 19:03:47.828] [TweakScale] TRACE: FIELD DryCost BaseField UI_Label
[LOG 19:03:47.828] [TweakScale] TRACE: FIELD MassScale BaseField UI_Label
[LOG 19:03:47.828] [TweakScale] TRACE: FIELD stagingEnabled BaseField UI_Label
[LOG 19:03:47.828] [TweakScale] TRACE: FIELD stagingToggleEnabledEditor BaseField UI_Label
[LOG 19:03:47.828] [TweakScale] TRACE: FIELD stagingToggleEnabledFlight BaseField UI_Label
[LOG 19:03:47.828] [TweakScale] TRACE: FIELD stagingEnableText BaseField UI_Label
[LOG 19:03:47.828] [TweakScale] TRACE: FIELD stagingDisableText BaseField UI_Label
[LOG 19:03:47.828] [TweakScale] TRACE: FIELD overrideStagingIconIfBlank BaseField UI_Label
[LOG 19:03:47.828] [TweakScale] TRACE: FIELD moduleIsEnabled BaseField UI_Label
[LOG 19:03:47.828] [TweakScale] TRACE: FIELD upgradesApply BaseField UI_Label
[LOG 19:03:47.828] [TweakScale] TRACE: FIELD upgradesAsk BaseField UI_Label
[LOG 19:03:47.828] [TweakScale] TRACE: FIELD showUpgradesInModuleInfo BaseField UI_Label

 

Spoiler

HA! GOTCHA!  Yes, it is something in the UI_FloatRange (not a surprise)

This is what happens: TweakScale needs to adapt the Range widget to cope with the module's state. You see this happening when you scale up or down to a point that the widget changes the values.

So, deeply buried on the code-tree, there's this thing (Log.dbg messages are new):

        private void RescaleFloatRange(float factor)
        {
            if ((object)_floatRange == null)
            {
                Log.dbg("RescaleFloatRange _floatRange for {0}/{1} is NULL!", _object, this.Name);
                return;
            }
            Log.dbg("RescaleFloatRange for {0}/{1} to {2}", _object, this.Name, factor);
            _floatRange.maxValue *= factor;
            _floatRange.minValue *= factor;
            _floatRange.stepIncrement *= factor;
        }

Observe that I print "is NULL" when the _floatRange is.. null. And i print the value when it's not. (_floatRange is where the UI_FloatRange for a Field lives inside this object).

And I get this log message when loading the Vessel both on 1.7.3 as in 1.8.0 (I get one set of messages for each part with a TweakScale):

[LOG 15:57:04.084] [TweakScale] TRACE: RescaleFloatRange _floatRange for TweakScale:externalTankCapsule {; isFreeScale = True; 6 scaleFactors = 10  50  100  200  400  400.5  ; tweakScale = 400; currentScale = 200; defaultScale = 100; scaleNodes = System.Int32[]}/DryCost is NULL!
[LOG 15:57:04.085] [TweakScale] TRACE: RescaleFloatRange _floatRange for TweakScale:externalTankCapsule {; isFreeScale = True; 6 scaleFactors = 10  50  100  200  400  400.5  ; tweakScale = 400; currentScale = 200; defaultScale = 100; scaleNodes = System.Int32[]}/MassScale is NULL!
[LOG 15:57:04.111] [TweakScale] TRACE: RescaleFloatRange _floatRange for externalTankCapsule (Part)/breakingForce is NULL!
[LOG 15:57:04.111] [TweakScale] TRACE: RescaleFloatRange _floatRange for externalTankCapsule (Part)/breakingTorque is NULL!
[LOG 15:57:04.112] [TweakScale] TRACE: RescaleFloatRange _floatRange for externalTankCapsule (Part)/buoyancy is NULL!
[LOG 15:57:04.112] [TweakScale] TRACE: RescaleFloatRange _floatRange for externalTankCapsule (Part)/explosionPotential is NULL!
[LOG 15:57:04.112] [TweakScale] TRACE: RescaleFloatRange _floatRange for externalTankCapsule (Part)/mass is NULL!
[LOG 15:57:04.113] [TweakScale] TRACE: RescaleFloatRange _floatRange for PartResource/amount is NULL!
[LOG 15:57:04.113] [TweakScale] TRACE: RescaleFloatRange _floatRange for PartResource/maxAmount is NULL!
[LOG 15:57:04.113] [TweakScale] TRACE: RescaleFloatRange _floatRange for PartResource/amount is NULL!
[LOG 15:57:04.113] [TweakScale] TRACE: RescaleFloatRange _floatRange for PartResource/maxAmount is NULL!

Not exactly what one would expect, since how in hell that UI_FloatRange object is still NULL by the time the code instantiate the Updater?

However, in 1.7.3 this stunt sticks, as we can see:

And by resizing the Engine, I got this on the log:

[LOG 15:59:39.329] [TweakScale] TRACE: RescaleFloatRange _floatRange for Size3EngineCluster (Part)/mass is NULL!
[LOG 15:59:39.329] [TweakScale] TRACE: RescaleFloatRange _floatRange for Size3EngineCluster (Part)/breakingForce is NULL!
[LOG 15:59:39.330] [TweakScale] TRACE: RescaleFloatRange _floatRange for Size3EngineCluster (Part)/breakingTorque is NULL!
[LOG 15:59:39.330] [TweakScale] TRACE: RescaleFloatRange _floatRange for Size3EngineCluster (Part)/buoyancy is NULL!
[LOG 15:59:39.330] [TweakScale] TRACE: RescaleFloatRange _floatRange for Size3EngineCluster (Part)/explosionPotential is NULL!
[LOG 15:59:39.330] [TweakScale] TRACE: RescaleFloatRange _floatRange for AttachNode/breakingForce is NULL!
[LOG 15:59:39.330] [TweakScale] TRACE: RescaleFloatRange _floatRange for AttachNode/breakingTorque is NULL!
[LOG 15:59:39.333] [TweakScale] TRACE: RescaleFloatRange _floatRange for Size3EngineCluster (ModuleEnginesFX)/minFuelFlow is NULL!
[LOG 15:59:39.333] [TweakScale] TRACE: RescaleFloatRange _floatRange for Size3EngineCluster (ModuleEnginesFX)/maxFuelFlow is NULL!
[LOG 15:59:39.333] [TweakScale] TRACE: RescaleFloatRange _floatRange for Size3EngineCluster (ModuleEnginesFX)/maxThrust is NULL!
[LOG 15:59:39.333] [TweakScale] TRACE: RescaleFloatRange _floatRange for Size3EngineCluster (ModuleEnginesFX)/heatProduction is NULL!
[LOG 15:59:39.335] [TweakScale] TRACE: RescaleFloatRange _floatRange for ModuleResource/rate is NULL!
[LOG 15:59:39.335] [TweakScale] TRACE: RescaleFloatRange _floatRange for TweakScale:Size3EngineCluster {; isFreeScale = True; 12 scaleFactors = 0.1  0.3  0.625  1.25  1.875  2.5  3.75  5  7.5  10  20  20.02  ; tweakScale = 7.5; currentScale = 5; defaultScale = 3.75; scaleNodes = System.Int32[]}/DryCost is NULL!
[LOG 15:59:39.335] [TweakScale] TRACE: RescaleFloatRange _floatRange for TweakScale:Size3EngineCluster {; isFreeScale = True; 12 scaleFactors = 0.1  0.3  0.625  1.25  1.875  2.5  3.75  5  7.5  10  20  20.02  ; tweakScale = 7.5; currentScale = 5; defaultScale = 3.75; scaleNodes = System.Int32[]}/MassScale is NULL!

Same thing. The UI_FloatRange is always NULL.

This very same code runs with the very same logs - however the widget works on KSP 1.7.3 and borks on KSP 1.8.

This thing is inside a Updater Class, that lives inside a Container on the Scale Expoents, that by its turn is what TweakScale calls when it needs to rescale something: 

• User: "I want his part to be 5 meters wide"
• TweakScale: "Ok" and then. "ScaleExpoents, scale that part to 5".
• ScaleExpoents: "Humm.. This part has 7 KSP Fields. For each field, Updater, update it to the new scaling"
• Updater: "Hey, this thing has a NULL here!!!"

However, KSP 1.8 borks while drawing that widget, while previous versions don't care about and do the drawing.

Why? Dunno. But I can guess: older KSP has some code to workaround bad behaving Modules, and it was taking this hit for years. While porting the code to Unity 2019, the developer said "shove it, no Module should be borking on it by this time!" and decided to declutter the code-tree by deleting the stunt. I don't know if it was really this, but it's what I would do anyway, it's a rightful move - the less code you compile, less the bugs you need to cope. And Modules should had be behaving by this time, right?   [new guess: older KSP created a UI_FloatRange automatically, newer dont].

I think we have a diagnosis. Now I need to see why this is happening, and once I realized the reason, it's easy to write the fix.

I will keep you on the loop.

— POST EDIT — 

This is what I got until now. I instrumented the OnAwake event handler to check EXACTLY what is happening with the KSP Fields in initialization. Got to this:

1.7.3
[LOG 20:39:26.204] [TweakScale] TRACE: FIELD tweakScale BaseField UI_ScaleEdit : {0.02 0.04}  --  {4}
[LOG 20:39:26.204] [TweakScale] TRACE: FIELD tweakName BaseField UI_ChooseOption
[LOG 20:39:26.204] [TweakScale] TRACE: FIELD currentScale BaseField UI_Label
[LOG 20:39:26.204] [TweakScale] TRACE: FIELD defaultScale BaseField UI_Label
[LOG 20:39:26.204] [TweakScale] TRACE: FIELD isFreeScale BaseField UI_Label
[LOG 20:39:26.204] [TweakScale] TRACE: FIELD defaultTransformScale BaseField UI_Label
[LOG 20:39:26.204] [TweakScale] TRACE: FIELD DryCost BaseField UI_Label
[LOG 20:39:26.204] [TweakScale] TRACE: FIELD MassScale BaseField UI_Label
[LOG 20:39:26.205] [TweakScale] TRACE: FIELD stagingEnabled BaseField UI_Label
[LOG 20:39:26.205] [TweakScale] TRACE: FIELD stagingToggleEnabledEditor BaseField UI_Label
[LOG 20:39:26.205] [TweakScale] TRACE: FIELD stagingToggleEnabledFlight BaseField UI_Label
[LOG 20:39:26.205] [TweakScale] TRACE: FIELD stagingEnableText BaseField UI_Label
[LOG 20:39:26.205] [TweakScale] TRACE: FIELD stagingDisableText BaseField UI_Label
[LOG 20:39:26.205] [TweakScale] TRACE: FIELD overrideStagingIconIfBlank BaseField UI_Label
[LOG 20:39:26.205] [TweakScale] TRACE: FIELD moduleIsEnabled BaseField UI_Label
[LOG 20:39:26.205] [TweakScale] TRACE: FIELD upgradesApply BaseField UI_Label
[LOG 20:39:26.205] [TweakScale] TRACE: FIELD upgradesAsk BaseField UI_Label
[LOG 20:39:26.205] [TweakScale] TRACE: FIELD showUpgradesInModuleInfo BaseField UI_Label

1.8.0
[LOG 20:46:05.003] [TweakScale] TRACE: FIELD tweakScale BaseField UI_ScaleEdit : {0.02 0.04}  --  {4}
[LOG 20:46:05.003] [TweakScale] TRACE: FIELD tweakName BaseField UI_ChooseOption
[LOG 20:46:05.003] [TweakScale] TRACE: FIELD currentScale BaseField UI_Label
[LOG 20:46:05.003] [TweakScale] TRACE: FIELD defaultScale BaseField UI_Label
[LOG 20:46:05.003] [TweakScale] TRACE: FIELD isFreeScale BaseField UI_Label
[LOG 20:46:05.003] [TweakScale] TRACE: FIELD defaultTransformScale BaseField UI_Label
[LOG 20:46:05.004] [TweakScale] TRACE: FIELD DryCost BaseField UI_Label
[LOG 20:46:05.004] [TweakScale] TRACE: FIELD MassScale BaseField UI_Label
[LOG 20:46:05.004] [TweakScale] TRACE: FIELD stagingEnabled BaseField UI_Label
[LOG 20:46:05.004] [TweakScale] TRACE: FIELD stagingToggleEnabledEditor BaseField UI_Label
[LOG 20:46:05.004] [TweakScale] TRACE: FIELD stagingToggleEnabledFlight BaseField UI_Label
[LOG 20:46:05.004] [TweakScale] TRACE: FIELD stagingEnableText BaseField UI_Label
[LOG 20:46:05.004] [TweakScale] TRACE: FIELD stagingDisableText BaseField UI_Label
[LOG 20:46:05.004] [TweakScale] TRACE: FIELD overrideStagingIconIfBlank BaseField UI_Label
[LOG 20:46:05.004] [TweakScale] TRACE: FIELD moduleIsEnabled BaseField UI_Label
[LOG 20:46:05.004] [TweakScale] TRACE: FIELD upgradesApply BaseField UI_Label
[LOG 20:46:05.004] [TweakScale] TRACE: FIELD upgradesAsk BaseField UI_Label
[LOG 20:46:05.004] [TweakScale] TRACE: FIELD showUpgradesInModuleInfo BaseField UI_Label

Amy of my presumptions of being a TweakScale defect is going down by now.

I'm not saying TweakScale was doing everything by the book, the event handling was somewhat messy indeed. But this, besides having the potential to be the cause of some issues I know, definitively IS NOT the problem of this thing.

Until further evidence is found, I decalre UI_ScaleEdit defective on KSP 1.8.

 

Edited October 20, 2019 by Lisias
New Guess

[Frostiken]

Ugh. Tweakscale has been suddenly giving me grief with saved ships.

The biggest one is that my Octo probe cores have shrunk down to <10% scale which obviously causes problems and makes fixing them a PITA since they're a tiny little dots. It says it's at 10% but I can tell from looking at it it's more like 1%.

From the .craft file:

 

Obviously nothing is wrong there. 

There's lots of stuff in my .log but this seems relevant.

[WRN 13:23:44.411] [Part]: PartModule indexing mismatch at probeCoreOcto.v2, index 12.
Node 'USI_ModuleRecycleablePart' found in loaded data, but 'TweakScale' is defined in prefab.
Looking for USI_ModuleRecycleablePart in other indices...
[WRN 13:23:44.411] ...USI_ModuleRecycleablePart module found at index 13.
[WRN 13:23:44.411] [Part]: PartModule indexing mismatch at probeCoreOcto.v2, index 13.
Node 'WBIPartScrapper' found in loaded data, but 'USI_ModuleRecycleablePart' is defined in prefab.
Looking for WBIPartScrapper in other indices...
[WRN 13:23:44.411] ...WBIPartScrapper module found at index 14.
[WRN 13:23:44.411] [Part]: PartModule indexing mismatch at probeCoreOcto.v2, index 14.
Node 'TrajectoriesVesselSettings' found in loaded data, but 'WBIPartScrapper' is defined in prefab.
Looking for TrajectoriesVesselSettings in other indices...
[WRN 13:23:44.411] ...TrajectoriesVesselSettings module found at index 15.
[WRN 13:23:44.411] [Part]: PartModule indexing mismatch at probeCoreOcto.v2, index 15.
Node 'TweakScale' found in loaded data, but 'TrajectoriesVesselSettings' is defined in prefab.
Looking for TweakScale in other indices...
[WRN 13:23:44.411] ...TweakScale module found at index 12.
[LOG 13:23:44.411] [TweakScale] WARNING: defaultScale has changed for part probeCoreOcto.v2: keeping relative scale.

And later on...

[LOG 13:23:45.167] [TweakScale] WARNING: No valid member found for diameter in Part for <unk>
[LOG 13:23:45.197] [TweakScale] WARNING: No valid member found for mass in TweakScale for probeCoreOcto.v2

 

This is on 1.7.3 with TweakScale v2.4.3.4.

I updated a handful of mods about a week ago (pre-1.8) and it seems like everything has loveing broken in all kinds of ways since then  This is one of them.

 

I have also had issues with TweakScale turning my 0.625m parts (Ant engine, for example) into 1.25m.

 

Whenever I fix and save my crafts it appears to stick just fine... but what the love. 

Edited October 20, 2019 by Frostiken

[Lisias]

1 hour ago, Frostiken said:

Ugh. Tweakscale has been suddenly giving me grief with saved ships.

I understand your pain. You just got bitten by the same rogue patching that drove me to this whole series of scaring messages

 

Quote

This is on 1.7.3 with TweakScale v2.4.3.4.

I updated a handful of mods about a week ago (pre-1.8) and it seems like everything has loveing broken in all kinds of ways since then  This is one of them.

 

I have also had issues with TweakScale turning my 0.625m parts (Ant engine, for example) into 1.25m.

You probably is seeing something like this:

It's not TweakScale, sir. It's a rogue patch. Had you be using the latest TweakScale version, this would not had happened, as TweakScale since June, 17 (more or less) detects this bad patching, preventing problems handled by issue #34 to corrupt your savegame.

Well, what remains to be done is to fix things. Please install the latest TweakScale, then fire up your KSP, then send me your KSP.log and ModuleManager.ConfigCache - I will need both in order to salvage your game. I also recommend you to install and use S.A.V.E. .

1 hour ago, Frostiken said:

Whenever I fix and save my crafts it appears to stick just fine... but what the love. 

Your savegame is not fixed, sir. The installment is "contaminated" by rogue patching, and changing anything can break the unstable equilibrium on the installment and then everything can get incorrectly rescaled again. Including the crafts that are flying.

I urge you to update TweakScale to the latest and then send me the KSP.log and the ModuleManager.ConfigCache so we can estabilize your installment and prevent a lot of grief that is waiting you ahead.

And, just to be sure about the problem, it's not TweakScale - it's a rogue patch messing up things. Any new patch you install on the game, or even a single patch you uninstall, can play havoc again on the game.

Edited October 20, 2019 by Lisias
tyops as usulla… and entertaining grammars! :D

[Lisias]

No matter how smart you think you are, you are not that smart. No matter how dumb they say you are, you are dumber.

But yet, you can be lucky,  I spent the whole day accidentally learning everything I need to fix the thing

That's the catch: UI_ScaleEdit is defective on KSP 1.8 . Worst, there are almost no Add'Ons using this thing, there's only 23 mentions on code and 2 on issues (half from TweakScale!) on GitHub right now.

AND I HAVE CONFIRMATION. TweakScale is not the only Add'On borking on it.

• 
• 

UI_FloatRange, on the other hand, has 396 mentions on code, 4 on commits and 9 on issues. Way more popular, way more information available. And TweakScale has code to handle it already, this is where I got lucky, the code to rollback is already there.

TweakScale will be fixed in the next hours, but I will release a beta first. Just in case.

[Sorry, but I'm wasted. I will not risk any more coding today, what to say a release. I will try Monday night.]

 

 

Edited October 21, 2019 by Lisias
no more coding today.

[AmpCat]

Thanks for keeping at this. The 1.8 update is a huge improvement in game performance. Night and day difference.

Just a matter of waiting for all the mods to get fixed. Looks like it broke a lot of little things. Going to be hard for everyone to track them all down.

[Lisias]

1 hour ago, AmpCat said:

Thanks for keeping at this. The 1.8 update is a huge improvement in game performance. Night and day difference.

Welcome!

Yep, It appear's that finally I will have to eat my words on Unity. I was very vocal in the past on how KSP had grown bigger than Unity and deserved better from a self self-proclaimed fist-class 3d engine.

 

1 hour ago, AmpCat said:

Just a matter of waiting for all the mods to get fixed. Looks like it broke a lot of little things. Going to be hard for everyone to track them all down.

The breakage was slightly less worst than I was fearing. To tell you the true, would not be by this marvelous borking on the UI_ScaleEdit, TweakScale would not had needed even an recompile.

I already knew it, as I was reading about .NET 4.5 (and now 4.6) and compatibility with legacy binaries since I heard the word about Unity 2019 on KSP 2.0, but the fact is that today I had run on KSP 1.8 some add-ons that were compiled against 1.3.1, and some of them worked fine. Pretty fine - it took me the whole freaking day to find something that would bork the same way TweakScale borked.

There are just a bunch of Add'Ons that relies on UI_ScaleEdit if the GitHub search results are of some value. And apparently, not even Squad is using this thing, as it's an obvious problem. I doubt they would allow this to pass throught if they had some use for the thing - the change on the 3D engine surely demanded tons and tons of man-hours of testing, essentially meaning: playing the damned thing.

Edited October 21, 2019 by Lisias

[FreeThinker]

@Lisias Perhaps we can conclude that KSP KSPField UI  is simply broken in KSP 1.8. I guess we need an alternative interface solution that will not make use of the KSPField UI.

Edited October 21, 2019 by FreeThinker

[Lisias]

Right now, @FreeThinker, I will be happy with anything that works, even if with issues, that could give me fast results without expanding my exposure surface.

There will be a disposable branch for this change only. Once the fire is off, i will handle the cinders.

[Teratles]

3 hours ago, Lisias said:

Right now, @FreeThinker, I will be happy with anything that works, even if with issues, that could give me fast results without expanding my exposure surface.

There will be a disposable branch for this change only. Once the fire is off, i will handle the cinders.

Ask Kerbalsm Modder, in the dev brand there intregration into the UI works!

[Tsani]

@Lisias Hang in there. You will get it. I know I appreciate what you are doing, as well as others. You make the game more enjoyable for me. Every time I fire the game up, I use this mod. It touches so much. I  gather that this is a very twisted problem at best.

I couldn't understand why you only got 9 failed sanity checks and I got 16.

So I deleted all the visual mod stuff and a couple of other mods, all non part stuff (Tweakscale with the _LOCAL folder, All Tweak, Chatterer, Craftmanager, KXAPI, HyperEdit, KSP-AXC, EVE, SVE). And I got nine. So apparently, even non part mods screw with stuff. A big ball of worms.

Thanks for working on it.

[Lisias]

MARVELOUS. I took a bit of my lunch time to test drive UI_FloatRange. The thing was shoved on the code-tree, just to see what happens - it's not funcional, but should render something on the Screen.

KSP 1.7.3

 

KSP 1.8
 

 It's dead, Jim. Too.

So the fix will not be so simple as a rollback. There's something fundamentally broken with KSP 1.8 widgets - unfortunately.

Branch with the stunt : https://github.com/net-lisias-ksp/TweakScale/tree/dev/orthodox-event-FloatRange

No binaries, this didn't worked.

— — — 

@ansaman, I think we found why they changed the controls for the Surface Control from percentage to degrees!  

— — — 

7 hours ago, FreeThinker said:

@Lisias Perhaps we can conclude that KSP KSPField UI  is simply broken in KSP 1.8. I guess we need an alternative interface solution that will not make use of the KSPField UI.

Yep. I see your point now.

Edited October 21, 2019 by Lisias
moar posts.

[AmpCat]

 

5 hours ago, Lisias said:

13 hours ago, FreeThinker said:

@Lisias Perhaps we can conclude that KSP KSPField UI  is simply broken in KSP 1.8. I guess we need an alternative interface solution that will not make use of the KSPField UI.

Yep. I see your point now.

Not to state the obvious, but how does stock KSP display this sort of data? Whatever they're doing obviously works, and as I understand it, all that's open to modders too, right?

[Lisias]

On 10/21/2019 at 7:47 PM, AmpCat said:

Not to state the obvious, but how does stock KSP display this sort of data? Whatever they're doing obviously works, and as I understand it, all that's open to modders too, right?

They don't. They would had detected this before the release if they would.

But it's only my guess. I would have to reverse engineer the code to be sure, something that I'm not willing even if I had the time now.

Talked too soon - on the heat of the battle, I forgot I had not tried some stunts again with UI_FloatRange. Thanks for the kick.

— — — STUNT DRIVE — — — 

All testing made compiling in DEBUG mode. The .4.x Compiler Chain used is the 4.6, as the KSP provided System.dll pinpoints .NET 4.6.57.0.

The code tree used is here https://github.com/net-lisias-ksp/TweakScale/tree/pub/research/orthodox/KSP180 (I will leave it committed to Unity 2019, .NET 4.6, UI_FloatEdit - remember, the widget's functionally is not implemented, it merely shows on the window) .

I satisfied only the dependencies complained by Visual Studio - it's theoretically possible that hidden dependencies (i.e., not declared on the DLL metadata and so not detectable by Visual Studio) could be playing some role on the mess, but I consider this hypothesis a overreacting paranoia.  

Another possibility is some glitch by compiling it using MacOS. I'm using Windows DLLs to compile against, as historically in the past, using MacOS DLLs made the compiled artifacts be locked down on the MacOS, not working on Windows. Compiling against the Windows libraries, works for everybody.

• Stunt One: Unity 2017 DLLs, Mono 3.5 compiler (and System.dll), UI_ScaleEdit
  • KSP 1.7.3 : IT WORKS!  
  • KSP 1.8 : it does not.
• Stunt Two: Unity 2019 DLLs, Mono 3.5 compiler (and System.dll), UI_FloatEdit
  • KSP 1.7.3 : IT WORKS!    
  • KSP 1.8 : it does not.
• Stunt Three: Unity 2017 DLLs, Mono 4.6 compiler (and System.dll), UI_ScaleEdit
  • KSP 1.7.3 : KSP Borks
    • Not a surprise! It would be a problem if it worked at all!

      [ERR 22:54:45.132] AssemblyLoader: Exception loading 'Scale': System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded.
        at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool)
        at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0
        at AssemblyLoader.LoadAssemblies () [0x00000] in <filename unknown>:0

       

  • KSP 1.8 : 
  • Widget didn't worked.
• Stunt Four: Unity 2019 DLLs, Mono 4.6 compiler (and System.dll), UI_FloatEdit
  • KSP 1.7.3 : KSP Borks
    • Not a surprise! It would be a problem if it worked at all!

    • [ERR 22:26:24.728] AssemblyLoader: Exception loading 'Scale': System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded.
        at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool)
        at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0
        at AssemblyLoader.LoadAssemblies () [0x00000] in <filename unknown>:0

       

  • KSP 1.8 : Widget didn't worked.

I could not think on any other stunt, except compiling the damned thing on Windows to see if anything changes. I should have a rusty Windows VM image somewhere on an old HDD Archive, but may I ask for a kind volunteer to try the Stunt Four on Windows? It could be a good idea to check Linux too.

Edited November 10, 2019 by Lisias
second though

[Grigetio]

I volunteer for stunt four. Downloading now.

 

Edit: I can get most of it to build, but I'm not sure of the proper branch for the KSPAPI stuff, and that leads to a whole other can of worms. Also, the tweakscale project files appear to reference projects which I don't see on github.

Edited October 22, 2019 by Grigetio

[Lisias]

On 10/22/2019 at 2:33 AM, Grigetio said:

I volunteer for stunt four. Downloading now.

 

Edit: I can get most of it to build, but I'm not sure of the proper branch for the KSPAPI stuff, and that leads to a whole other can of worms. Also, the tweakscale project files appear to reference projects which I don't see on github.

Use the KSPe DLL from the latest release. It was what I did.

Compile the Scale.dll and shove it over the latest release installation.

— POST EDIT — 

Im the event you are masochist enough  to want to compile the whole shebang, the OP has the link for the KSPe branch I created for TweakScale (look for KSPe on the post)

Edited October 23, 2019 by Lisias
Hit "Save" too soon.

[AmpCat]

I'd love to learn how to mod for KSP here. I do programming as a real job, and this would be fun, but I have no idea where to start to get things set up and working to test this. Any pointers?

[Lisias]

46 minutes ago, AmpCat said:

I'd love to learn how to mod for KSP here. I do programming as a real job, and this would be fun, but I have no idea where to start to get things set up and working to test this. Any pointers?

It's less hard than it looks. I found most of the information I needed reading this subforum :

https://forum.kerbalspaceprogram.com/index.php?/forum/29-c-plugin-development-help-and-support/

The hard part is testing things. Firing up KSP is somewhat time costly. It's possible to live debug your DLL with break points, but to the moment, all that i needed was good logging (essentially, the Kickstarter for KSPe).

There're a lot of good information on "Help a fellow plugin developer" too.

And github. Boy, GitHub is life. 

[AmpCat]

Yeah, still getting comfortable with github. @linuxgurugamer was patient with me and stepped me through the first couple attempts to do a pull request to update one of the mods he maintains. I've played with unity before many years ago, and as I mentioned, KSP 1.8 performance is a lot better now, so hopefully it's not as painful. I'll see if I can give this a try after work.

[linuxgurugamer]

Just now, AmpCat said:

Yeah, still getting comfortable with github. @linuxgurugamer was patient with me and stepped me through the first couple attempts to do a pull request to update one of the mods he maintains. I've played with unity before many years ago, and as I mentioned, KSP 1.8 performance is a lot better now, so hopefully it's not as painful. I'll see if I can give this a try after work.

Never feel afraid to ask a question.  If you are working on a mod and get stuck, I can usually take a few minutes to take a look.  May take a little while, after all, RL comes first.  But if you put it up in github, I (and others) can always pull it down to take a look.