Lisias

Now I was caught with my pants down… There should be no binary interaction between the Scale and Recall assemblies…. Well, I will give this a try later, thanks for the heads up!

You should had forgot to completely remove the TweakScale folder. I downgrade things here now and then just to see what happens, and no problems were detected - as long you completely get rid of all binaries before "downgrading" to the previous release. Keep in mind that 2.4.6.x is a deal breaker to some Companions (it's the reason I had to update some of them). In order to use TweakScale 2.4.5.0, you will need to downgrade also the Companions mentioned on the github's Release page. Breaking binary compatibility sucks, I know, but I had drawn myself to a corner with some APIs and had to do it sooner or later, and took the opportunity to do it now since some new APIs would need the Companions to be rewritten anyway, so we would endure two pains by the price of one. Exactly. Scaling Crew down works - since nobody is launching exceptions when this happens. Observe that the U,I. adapts itself normally with you scale down a 3 crewed part to 2 and then 1 crew. I fail to understand why this would be a problem for scaling up. The excuse of "people would find weird the IVA not following the new crew size" - as people would not be using borrowed IVAs from other parts and shoving more (or less) kerbals on it that the available seats. As I said, you can MM your way on it and KSP doesn't complains about the part having more crew on the prefab than IVA seats. Mangling the IVA seats was something that I had though, but since KSP resets everything to the prefab on launch, TweakScale needs to reapply the scaling on the first frames of life of the Craft - and by then, KSP already had thrown that Exception on me. The Solution for this would be writing a new PartModule with a new Crew support to avoid the KSP's ban (like KIS does with cargo). From there, I could do anything I want (including generating IVAs at runtime - a somewhat daunting endeavour ). But then we have R.L. kicking my balls and forcing me to compromise - there're more pressing things in need to be done ASAP (as you can see above).

Yeah, unfortunately it's a known issue. It's two bugs bitting you in a row: the first (and most serious, as it affects everybody) is from KSP, that now and then screw up something on the UpgradePipeline (probably) and invert the Z Axis of the part (or at least, from the attach nodes). Sometimes the fairings get inverted, and you can't build the fairing towards the right end of the rocket due this. This I can't help, it's a long standing KSP problem that started to happen on 1.8.0 (I first noticed it on the control surfaces). The second bug is on TweakScale. In all these years since the first version, no one (including me) thought that someone would want to invert the part before scaling, and so the code was made assuming the part is always pointing towards the root. This is scheduled to be fixed for the next release, in which I (hope) to start to work on the middle on this next week. Until there, the only workaround is to detach the affect parts, invert it, and reattach them. This solves the problem for good on this craft - or at least, I still didn't got a report of the thing happening again on the same craft on the same savegame - the KSP bug triggers when loading crafts from another savegame I think (but I'm not 100% sure). Until this moment only ReStock parts are being reported - but I really doubt this is a ReStock problem. Once you fix the craft and save it, you can remove and reinstall ReStock that the bug doesn't triggers anymore. A more thoughtful discussion can be found on this post:

Announce! TweakScale Companion for PKMC 2.1.0.1 is on the wild! Fix a bug on patch. Thanks to AccidentalDissassemly! Closes issues: #5 Missing curly braces in patch file Downloads here and in the OP.

Not yet. Eventually I will deprecate for good the old patches on TS distribution, but this will not happen until I tackle down this dependency problem. As far as I know, the current patches for KAS are still acceptable, so is unlikely that I will rework them in the short run. But you can aways check the TweakScale Companion thread for news. Cheers!

The main and most important reason for the recent update to the 2.4.6.x series is the KSPe.Light thingy. This guy has core services that will allow me to install Companions safely without the dependencies installed - a situation that if unhandled will end up with KSP not loading correctly due a bug on the stock AssemblyLoader. How it does it's subject for another (huge) post. (TweakScale being able to run from KSP 1.3.0 to 1.12.2 is a beneficial side effect of that core services - since they are there, I just used them on TS too!) The Companions, due its nature, have a problem called Triangular Dependencies (a "plague" that happens too on MM Patches, but MM doesn't crashes the game because of that!). Let's take , for example, the TSCo-KIS you just installed: it :NEEDS both Scale and KIS Assemblies to be installed, otherwise its loading will raise a Reflection Exception like this one: [LOG 00:58:11.276] PartLoader: Compiling Part 'B9_Aerospace/Parts/Body_Mk2_Cockpit/body_mk2_cockpit_a/B9_Body_Mk2_Cockpit' [ERR 00:58:11.294] MechJeb caught exception in core OnLoad: System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown. at KSP.IO.File.Exists[T] (System.String filename, Vessel flight) [0x00053] in <9d71e4043e394d78a6cf9193ad011698>:0 at MuMech.MechJebCore.OnLoad (ConfigNode sfsNode) [0x00097] in <2e230d4e49354a07858a9faa52799159>:0 When this happens, something inside KSP gets broken and lots of things start to fail without reason. On the KSP.log I took this example, the following borkage was the consequence : [EXC 01:00:19.076] ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown. System.Reflection.Assembly.GetTypes () (at <ad04dee02e7e4a85a1299c7ee81c79f6>:0) AssemblyLoader.GetTypesOfClassesImplementingInterface[T] () (at <9d71e4043e394d78a6cf9193ad011698>:0) Expansions.Missions.MissionsUtils.InitialiseAdjusterTypes () (at <9d71e4043e394d78a6cf9193ad011698>:0) Expansions.ExpansionsLoader+<LoadExpansions>d__21.MoveNext () (at <9d71e4043e394d78a6cf9193ad011698>:0) UnityEngine.SetupCoroutine.InvokeMoveNext (System.Collections.IEnumerator enumerator, System.IntPtr returnValueAddress) (at <5aeafee3fea24f37abd1315553f2cfa6>:0) CKAN doesn't understand Triangular Dependencies neither - I can't say to CKAN "If TweakScale is installed and KIS is installed too, you need to install TSCo-KIS" . All I can do is to suggest and/or recommend all the Companions on the TweakScale netkan file, what will probably prompt the user to install them anyway - and if by bad luck the user installs the TSCo-FS one by mistake, we will have a crashed KSP on the next boot because the TSCo-FS will fail to be loaded because Firespitter is not installed - and then that nasty bug on the stock KSP AssemblyLoader will screw up the internal game state, and lots of things will not work correctly after the borkage. The example above is just one of the possible consequences, I have tons of these issues on my database. So, in order to overcome this royal borkage from KSP since 1.8.0, I needed to reenginer the Companions to do selective DLL loading: the DLLs that are loaded by KSP are "safe", without hard dependencies. They then check if the needed Assemblies are loaded by KSP, and only then they load the DLLs with hard dependencies - avoiding the whole mess. If any of the dependencies are not met, the plugin just shuts itself down. Not even the patches are applied, as the tag needed on their :NEEDS are generated by that very same code that only does it after checking the dependencies. So, now and just now, it's safe to start to distribute the Companions using Curseforge and CKAN. The final step for a complete solution is a WatchDog for the Companions that will monitor the add'ons installed and then prompt the user to install the respective Companion if needed. It's not as nice as being able to tell CKAN to do it automatically, but at least it's better than what happened to you now! Cheers!

UGH!!! That passed trough!! I'm so used to run TweakScale beta that I just filter out the problem from my sigh!! Fixing this right now. — — — Annouce TweakScale 2.4.6.1 in on the wild, with the fix for the bork mentioned above. All Distribution Channels were updated at once. Cheers!

Ugh… I did a major bork once by uploading the wrong zip file on Spacedock what could explain your problem - but I just checked the file on SpaceDock and it's the correct one. However… The netkan guy's changes on the netkan file exactly due that screw up of mine may be the answer for your problem, if by some reason the netkan client failed to checkout the updated file - what's a bit odd, since the borkage happened last June 27 - many weeks ago. You will need to reach the CKAN guys to sort this out for sure, however. Send me your KSP.log (and since things just freezes on you, the Player.log will also help). The instructions about how to get these ones are on the OP, under a Spoiler on the final. There're many reasons for TweakScale shoving a Houston on our noses, I need these files to checkout what one bite you. Cheers!

From all the possible problems TS 2.4.6.0 would cause, this is the most unexpected one. The difference from TS 2.4.6.0 from the previous are only are essentially the DLL loading mechanisms, and these ones are being tested for the best part of this year. What you are getting now should be happening on TS 2.4.5.x… KSP, sometimes, surprises me in the most obscure ways… Did you installed/updated the TweakScale Companion for KIS? The KSP.log would help me to diagnose the problem - I had not problems like this one while testing the latest release of TSCo-KIS and the TS 2.4.6.0 (when in RC), but something always can pass through...

METAR There's a new old Kraken Food pesking TweakScale these days - but, granted, it's exarcebated by a bug on TweakScale itself. That's the history: at least on a situation that appears to involve ReStock (but it's not ReStock fault! It's only the trigger), sometimes when loading craft files from another savegame some parts ends up with the Z coordinate inverted (i.e., the part with the bottom "down" on the source savegame ends up with the bottom "up"), and this is a situation badly handled by TweakScale: On this sample craft, you will note that the fairing is Z axis inverted (node how the building goes downwards). The fuel tanks under it are also Z ais inverted, and it's the reason you see some texture fight where one tank attaches to the other (meaning that they were misplaced, and this is where TweakScale borks too). It's also the reason the Lander got pushed above the Monopropellant tank (that was also Z axis inverted, triggering the bug that pushed the Lander above it). Making things yet more interesting, the tank's texture is on the right position. What's messed up are the attachment points - and I confirmed this by detaching the tanks and reattaching them upside down - a situation where "normal" tanks would bork the scaling (due a bug on TS, just to make it clear), but on this craft it ended up working (due the swapped attachment points, apparently). Once I invert the misplaced parts (or delete them and get new ones from the Palette), the problem vanish for good. It didn't came back once I saved the craft on a new file, even by removing and adding back ReStock on the installment. And this is the reason I'm sure ReStock is not the troublemaker, but was merely involved on the fürball. Neither installments (mine and the source of the craft) had Harmony, by the way. So this is happening on a "vanilla" Stock binaries. I'm inclined to accuse the UpgradePipeline, as this one was known for screwing up the Z-Axis of Control Surfaces when KSP 1.8.x came to light - and since Control Surfaces are surface mounted parts, the attachment point bug of TweakScale doesn't kicks in, the only annoyance is having to invert the control of the part all the time once you launch it. In a way or another, I'm reporting this so people are aware of the situation - even by fixing TweakScale, the attachment points will still be inverted and this may screw up others add'ons too. Additionally, this TS bug is present on every previous version of TweakScale (including the ones from the 1.3.x era), so there's no reason to postpone the SpaceDock update as I was doing while I was not sure about the real reason of this major group borkage. So I'm updating SpaceDock this night for the latest TweakScale. As the result of this borkage, I'm rescheduling the RoadMap to tackled down this attachment related bugs for the next Release (to be issued Soon™) Cheers!

If this is what I think it is, it's not only Trajectories. These Reflection Exceptions royally screw up TweakScale too - it's a bug on KSP itself, I think (but it still can be something on Unity - in a way or another, I never got this on plain Mono/DotNet). There's no other way out but to have Zero Tolerance® with Reflaction Exceptions - fit the faulty DLL or ditch it.

In time… I just love the way your cars put the road on fire!!!

And by doing that, they had locked themselves on a corner - they are alone now. You are the first and ultimate responsible for the consequences of the license you choose. If the license you choose allows people to do things you don't want, don't use the license - and that's all. Going ARR will not solve the problem. Once you go ARR, you are the only one responsible for checking for compliance and pursing remedies - no one will help you, unless you pay some money. Once you go for a Open Source license, you will get help: lots and lots of people on this industry relies on Open Source Licenses, and it's their best interest to keep the status quo safe. That said, going ARR is not necessarily wrong - it's a valid option, as long you know the consequences and are willing to cope with it. And to check The Pirate Bay frequently. Not to mention that some Open Source licenses even explicitly forbid you from taking any kind of action that would prevent anyone to make such forks - and, so is the life, if an user came to you asking for support on things made by other people, it's up to you to educate the guy. My suggestion, not only to protect your sanity but to value your own work, is to ask the guy to seek support from the source where he/she get the thing. This is the Right Thing™ to be done - people want your support, they should use your artefacts. You start supporting 3rd parties, you end up with your own works left behind. In the bottom line, users do what users do, we have to live with it - it's just part of the zeitgeist. Not necessarily. Sometimes is due local legislations. On this case, katateochi lives on a different country with very different culture and laws, and since he maintains (including with $$$$) the site he also have some responsibilities under his legislation. I surely have some under my own legislation (not only on my site, but also on the code I publish with my real name - and yes, I use my real name exactly due that). There's also the trademarks issues, had he registered the trademark, they bought to himself some duties that may be easier to cope under an ARR license. Time is a scarce resource, most people need to make compromises about where to spend it. Time is the coin of your life. It is the only coin you have, and only you can determine how it will be spent. Be careful lest you let other people spend it for you. Carl Sandburg

NOTAM KSP 1.3.x Informal Compatibility!! By an incredible lucky strike, a small update on the KSPe.Light.DOE.dll ended up allowing DOE/L to run on KSP 1.3.1!! Be warned that this is an INFORMAL compatibility. No troughful tests were made (yet), so try it at your own risk. Download the KSPe.Light.DOE.zip file, unzip the dll and replace the old one in GameData/DistantObject/Plugins. Available on GitHub only.

TweakScale surely helps, but it will only scale the part, not make it rounded. The nice thing of TweakScale is that it will scale up all the part's characteristics for you (wright, resistance, price, etc). But you will still have the collider's problem to solve.

Soon™ .

Not exactly. The Physics Engine is heavy, but what's really screwing up the machine is the SpinLocks stunt explained on this thread. The day someone manage to replace that obnoxious crap with proper code that would behave on computer's multitasking O.S.s, you will see a significant improvement on thermals, performance and on the Deck, even battery life.

You got it! @Krazy1is in the house?

KSP1, I think you mean. KSP2 is still unknown at the present time (Only Windows support were announced, and we don't know how the DRM will behave on Proton). The Deck will be, essentially, an updated version of what I have for gaming now. Quad core, 8 threads, 16GB RAM shared with the GPU. But about 4 or 5 times faster. Memory hungry mods will probably cause some pain due the shared RAM thing - using 4GB of memory for VRAM means you will have 12 GB of RAM for the CPU. Still pretty decent, but 4GB less than a similar system with dedicated VRAM. Just forget about 4K, stick with 1080 and you are going to have a hell of a good performance, rendering some gaming machines still in use nowadays crying in shame on the bed at night...

It's neither! It's a handheld! Other than being picky on you on near irrelevant details, I fully agree. The Steam Deck is probably the most significant release for Linux in decades - at least, from the end user point of view.

Interesting… At first, I though I had forgot to check the viable zone of the craft before drawing it, but I just confirmed on the source that I'm checking it, I'm checking against Vessel.load before attempt to draw it. So my best guess to this point is that you found a borderline situation: the craft entered into Physics Range in the exact same moment DOE checked if it was loaded or not, and we got a race condition. (hummmm) Yeah, I think I need to put something on the FixedUpdated handler. One of the speed ups I made was to remove the mesh building phase from the FixedUpdate (as it was before), and besides this handler is called fewer times then Update, it is called from the hottest code on the Game, the Physics Engine. But now I realised that there was a reason for using the FixedUpdated. I will need to rework a bit this thing - shoving everything on FixedUpdate is not an option, I will not put render time code on the Physics Engine loop. In the mean time, you can ignore this. Other than spamming the KSP.log now and then, nothing serious happens as the drawing code aborts the execution on this situation. https://github.com/net-lisias-ksp/DistantObject/issues/12

As a matter of fact, I know some people where these would be an improvement….

Oukey. Working on it. (nice avatar, by the way! I'll grab some beers tonight in your honour! ) — — POST EDIT — — @WhatALovelyNickIt's not a conflict with TweakScale, it's exactly the other way around: [ERR 15:55:10.011] AssemblyLoader: Exception loading 'Romfarer': System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadEx at (wrapper managed-to-native) System.Reflection.Assembly.GetTypes(System.Reflection.Assembly,bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <9577ac7a62ef43179789031239ba8798>:0 at AssemblyLoader.LoadAssemblies () [0x000e6] in <8861f4ca916d41ddac4d879a32ad34b2>:0 Additional information about this exception: System.TypeLoadException: Could not resolve type with token 01000004 (from typeref, class/assembly ImageEffectBase, Assembly-CSharp-firstpass, Version=0.0.0.0, Culture= This is happening because Romfarer.dll was built with a older version of KSP's Assembly-CSharp (or perhaps Unity, but it's pretty unlikely) that have a method or atributte that it's not available anymore on modern KSPs (usually a protected one, as public ones are easily spotted). This is one of the very few situations in which a recompile may help. This is borking on you because from now on TweakScale relies on a custom AssemblyLoader to locate its assets, but this custom AssemblyLoader relies on the health of the Stock AssemblyLoader (I'm not replacing it - sometimes I think I should), that has a bug that once a Assembly fails to load due a Reflection error, everything else will have problems too. With the Romfarer.dll source code I can compile a working copy for you (assuming the license allows), but right now, since this thing is not being loaded anyway, you can delete Romfarer.dll from your GameData. It's just cluttering your installment and triggering misbehavirous on Stock (poorly maintained, sadly) AssemblyLoader. This thing is not working for sure.

The only "Universal True" about Life is this one: "Death and Taxes". I'm managing to avoid the former until this moment, but I never scored on the later...

What's Romfarer.dll? Please give me a link for it, I will give this a peek. (dirty secret: most of my code neither - I only publish what works!!! )