Lisias

'Look. Mummy. There's an airplane up in the sky!!'

Pretty Kerbal! Prinoth Panther rotating tracked dumper Not a crane, but you may like it @Ben J. Kerman!

:hailprobe:

I usually don't like to scale jet and LFO engines, but sometimes scaling up a Juno is the best way to reproduce a historical aircraft due the engine's characteristics, i.e, ISP. Older engines have a lower ISP than modern engines, and TS allows me to try to reproduce such aircrafts including their drawbacks. What's exactly the opposite from what you said: I'm using a "worse" part in the place of a better one to keep the crafts properly handicapped, matching (more or less) the technology of the era I'm aiming. Another way TS can really save our sorry SASes sometimes is by scaling Wheels, Landing Gears and Landing Legs. No more need to use a three-rowed non steering landing gear on the nose on your really big crafts - scale up the biggest steering landing gear you have and voilá. And lifting and control surfaces - TweakScale really shines on these ones. It allows you to make pretty nice wings, second only to Procedural Wings (but sometimes, a TweakScale stock wing can be nicer) - and scaling landing gears also helps a lot on these. Welcome! TweakScale would be a useless blob of code without users! Cheers!

It's not TweakScale - TS (and probably some others add'ons) are borking due a nasty bug on a thingy called Assembly Loader/Resolver on KSP - when someone borks while trying to load a dependency, EVERYBODY ELSE also borks too while loading their dependencies no matter if the dependency is good to go or not. In your case, you need to install USITools. This will fix KolonyTools, and then everybody later should be fine too as the KSP's bug is not triggered anymore! [ERR 15:20:49.838] ADDON BINDER: Cannot resolve assembly: USITools, Culture=neutral, PublicKeyToken=null [ERR 15:20:49.843] AssemblyLoader: Exception loading 'KolonyTools': System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflec at (wrapper managed-to-native) System.Reflection.Assembly.GetTypes(System.Reflection.Assembly,bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 at AssemblyLoader.LoadAssemblies () [0x000e6] in <55ba45dc3a43403382024deac8dcd0be>:0 Additional information about this exception: System.IO.FileNotFoundException: Could not load file or assembly 'USITools, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its d File name: 'USITools, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' Cheers!

Not without risking taking this kind of crap. Even by being legal (what's currently under dispute - and I want to emphasise the company suing the modders), it theoretically violates Forum ToS and, so, you are prone to have the thread deleted (or even your account locked) at any time by rules violation. And I will ignore the necessary competence and skills needed to diagnosing problems correctly - something very important when you aim to fix problems without creating new ones. Some problems are buried deep on the KSP guts, and it's unlikely that one could work around these bugs without access (and changes) on private methods (violating the Forum ToS) and without decompiling the binaries into source code (violating the Forum ToS and the game EULA - and, perhaps the Law). As the situation stands, any effort following this line of research may be tolerated or even silently endorsed by the current Administrators and Managers, but people come and go on Companies and any change of personal can gave you headaches later - the kind of headache a professional on the field does not want to have. I surely don't. What is left is the Clean Room Reverse Engineering (the approach I took on KSP-Recall), but instead of having someone decompiling code for me (what can be a source of problems) and writing specifications, I do tests and more tests (we call this Black Box Testing) on many APIs and manually crafted Craft Files and Savegames (Exploratory Tests) trying to infer such specifications - but this is time expensive. And having less than competent people injecting noise all the time on the public discussions about the problems hinders even more the efforts of the (very few) people really wanting to do any help here.

By many reasons. Some, because they don't know better and extrapolate known problems of the past into new problems found nowadays. Others, because people they trust are saying this B.S. and so they repeat it too. A few ones by pure incompetence and/or lack of skills. Or perhaps just people on someone's payroll looking for scapegoats to mask the mistakes. I found at least ONE situation where this "deformation" is happening, and it involves changes at Flight Scene on a craft under stress where AutoStruts (to the Grand Parent for sure, others to be tested) is applied on the parts currently under stress. And this is happening since KSP 1.2.0, when the Auto Struts were first introduced : it's a flaw on the initial implementation that was never detected before (or perhaps it was? ). You may like to check my findings documented on this comment and forward on github .

This is not a car, is a train on tires!!! Source: https://www.indiatimes.com/trending/social-relevance/american-dream-worlds-longest-car-restored-553507.html

Well, it just confirms my diagnosis. In Stock, the celestial bodies can be found on the FlightGlobals.Bodies array, On Kopernicus, they are somewhere else.

Yep, it's it. FlareDraw is tied to the Stock, it doesn't knows how to handle Kopernicus. I need to rework FlareDraw in order to allow adding "engines" or "drivers" to it (as I did on VesselDraw), so I (or anyone else) could just write a new one for it to handle Kopernicus. O added this to the issue on github, I will work on it on my next window for DOE. Not a problem at all. The important thing is to have KSP.log available for downloading somehow. It will not work, unfortunately. The definitions you found is to colorize the planet's flares with its dominant colours - and this is going to be needed anyway later. The problem at hands is that DOE understand how Stock handles the Sun and Planets, but doesn't knows squat (yet) about Kopernicus. The first step is to do on FlareDraw what I did on VesselDraw, create a kind of "engine" or "driver" so I can decoupe Stock specific code from the "business logic", and so adding Kopernicus later would be easier - and without compromising Stock only games.

The process of building a large ship is incredibly Kerbal! (where is the auto-struts?)

I was not aware of that. If no flares are being shown, it's highly probable an exception was thrown inside DOE killing the thread. Please publish your log file on dropbox or something or, if you have a github account, on a comment on this issue: https://github.com/net-lisias-ksp/DistantObject/issues/18

Hi! You are being bitten by a KSP bug on a thingy called AssemblyLoader. There's a bug on it since KSP 1.8.x that, once some add'on fails to load a dependency, everybody else will bork too later. I will need your full KSP.log file in order to see who is the first to bork, as this is the one that need to be fixed (everybody coming after are victims of the bug). In the case TweakScale itself is the one borking, check if the file "999_Scale_Redist.dll" is on the GameData (on the same place ModuleManager.dll is).

METAR After some good researching on the KSP-Recall thread, where I pinpointed the root cause of at least some part drifting (it's likely that we have more than one problem leading to the same symptom), I concluded I found a new (old) problem that it's unrelated to SubAssemblies - it's a mishap, not a misfeature, so it's unlikely that they tried to fix this on Editing time (it was a long shot, anyway - it appeared to make sense at that time because I didn't really knew what was causing this specific drifting I found while probing the SubAssemblies!). In a way or another, since this doesn't affects TweakScale, neither TweakScale affects it (it was by pure chance I found it while TweakScaling), I will now focus on the problem at hands, the SubAssemblies and Craft Merge features, currently being mangled by something on the Editor Scene that it didn't used to be mangled until KSP 1.9.0 (i.e., it worked fine until KSP 1.8.1! ). Now I'm working on the SubAssemblies again - let's see if I get lucky and have something on this WeekEnd! Cheers!

News from the Front III I NAILED IT!!! I **FINALLY** managed to reproduce deterministically and intentionally the problem on a clean KSP install , ruling out any influence from KSP-Recall or TweskScale (or anything else!!!) on the matter!! https://github.com/net-lisias-ksp/KSP-Recall/issues/27#issuecomment-1021553526 The source of the problem is the use of the Grand-Parent AutoStrut! it's not clear at this time if the problem is specific from the Grand-Parent or if it affects every or at least another Auto-Strut. It was not determined neither if this affects every part or just some - I will further investigate the matter as time allows (let's hope for this night!). Cheers!! — — POST EDIT — — On a very interesting twist of fate, it was determined that the initial KSP Release where the problem happens is KSP 1.2.0, the very first release to ever have Auto-Struts. The conclusion is that we have this problem bugging us since the beginning of times. Well… It makes things easier to diagnose, if I choose to pursue a workaround for this one. By now, I only know what and where, but I still need to figure out WHY it happens. Time will tell.

I just inspected the Player.log, found the real cause and explained it there. Cheers!

Try Download Depot. There's a tutorial on Steam called "Guide :: How to Download Older Versions of a Steam Game" (link to the google search, can't link directly to the page because the dude used some Non Forum compliant images, mas perhaps the reddit link would?). It's dated Mar 25, 2017 . Or you can use the Steam Console. You will need the hashes for the 1.3.1: Windows 32 bits download_depot 220200 220201 6129985237511607976 MacOS download_depot 220200 220202 740055444469864354 Linux download_depot 220200 220203 7676773296554629902 MacOS download_depot 220200 220204 4879731577466528628 Common: Optional Language Packs Spanish download_depot 220200 220205 143373120223001808 Russian download_depot 220200 220206 5929644944683924316 Japanese download_depot 220200 220207 2345161979639010300 Simplified Chinese download_depot 220200 220208 8519037663549102451 — — POST EDIT — — Unless you are looking for an Add'On that works only (or best) on KSP 1.3.1, I would recommend trying KSP 1.4.3 instead. While developing DOE, I learnt that Unity 2017 have huge visual improvements over Unity 5, and it may worth the change - not to mention Making History (I really enjoyed this one). Additionally, if you are using an old rig with a 512MB GPU, KSP 1.4.3 is the last version that works fine on these old potatoes. On 1.4.4 they increased the PQS Cache (or something like that) and since then old potatoes started to sweat on it (KSP 1.4.3 runs fine on a MacMini 5.1 : Mobile i5 with Intel HD3000 and ~380MB of VRAM; from KSP 1.4.4 and newer, you will need at least a HD4000 with more than 512MB to have some fun on KSP).

Frankly? I think it will take up to 1.12.8 or 1.12.9 until everything is tight again. Once you fix this problem correctly, all the changes made since 1.8.1 that are relying on the existence of the problem will break on their turn, and then they need to be fixed, and so on. I'm afraid the faster and "safe" way is to go back to 1.7.3 and restart from there.

News from the Front II Well…. Things are slightly trickier than I thought. Currently, I can't fix an issue without opening another one that, once fixed, reopen the former. Obviously, I'm missing something: Not being enough, I ended up doing some regressions tests for other KSP problems and found something very.. interesting… (Forum Rules prevents me to use the term I'm thinking right now! ): do you know that problem with the new Docking Module? Yeah, that one that created a lot of collateral effects, that ended up in drama! This is the thing: the problem was misdiagnosed! It's not related to the ModuleDockingNode, it's something that changed on KSP guts while dealing with part's deformation, and it affects everything - the PartModule itself, and not only the ModuleDockingNode or even the Robotics! And, perhaps (but this is more a educated guess than a hypotheses by now) this is the reason we have the borks during the Merge/SubAssembly but not during the OnLoads - I think that some code that "fixed" a collateral effect of the change may be screwing me up on the Merge/SubAssembly phase. [EDIT: not exactly. the problem is happening since KSP 1.2.0. See this post for more details.] And the problem is, essentially, that KSP is persisting the changes on the part's current position and rotation every time the craft itself is changed - as undocking, having a part destroyed and perhaps more. My guess is that something was done on the onVesselStandardModification handler (or similar), and then something broke on the editing time (perhaps by unduly reuse of code), and then someone "marretou" a half baked workaround on the Editor to counter-act the "marretada". [EDIT: everytime, but not everywhere - the problem only happens when you have AutoStruts activated!!] If I'm right (and the tests until know appears to confirm I am), there's no point on trying to workaround only a few triggers for the problem (as the ModuleDockingNode). We need a fix or workaround to the very PartModule itself. The changed happened probably on KSP 1.8.0 (I just tested downto 1.8.1), and it still happens on KSP 1.12.3 even with the Squad's fix for the DockingModuleNode. [EDIT: It started on KSP 1.2.0, the very first release with the AutoStrut feature]. And by hitting stage: Full report: https://github.com/net-lisias-ksp/KSP-Recall/issues/27 , including the craft files used for the tests. What I will do now is currently RiP (Research in Progress): I'm trying to figure out if this is affecting me somehow on the current issue at hands - my current working theory is that the Merge/SubAssembly code is blindly reapplying the Prefab values on the craft outside the cannonical life cycle of the part, I probably "hit the sweet spot" by accident when I closed #35 and now trying to extend the fix for the Merge, I lost it and need to find another sweet spot. A trial and error effort, unfortunately… — — POST EDIT — — Some corrections were made on the text above. Look for [EDIT: yada yada yada]

Yes!! https://github.com/net-lisias-ksp/TweakScaleCompanion_OPT/releases Keep an eye on the TweakScale Companion Program's Thread for news about 3rd Party support!

Hi! As @ColdJ said, it's safer to call for help on the TweakScale's thread - otherwise I would miss your call for help. Had him not pinpointed me here, it is exactly what would happen, by the way! Well, back to the point: dude, there're a lot of Exceptions being thrown on your rig! I counted about 300…. Almost, if not all (I didnt' inspected every one of them…..) are from Tantares. I recommend to send this log to the Tantares maintainer, there're a huge lot of parts that will give you headaches on the gameplay... Found some others from Contract Configurator too. You will need to ask for help from its maintainer. Now, finally about TweakScale, this is what it reported to me: [LOG 17:36:41.106] [TweakScale] INFO: WriteDryCost Concluded : 2960 parts found ; 0 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 0 Show Stoppers found; 0 Sanity Check failed; 1820 unscalable parts. What's a pretty clean report: TweakScale didn't found absolutely nothing wrong on the Sanity Checks. Keep in mind, however, that you have 2960 parts on your prefab, and 1820 of them does not have TweakScale support. This means that "only" 1140 parts are scalable! Less than half of the parts! I found no Exceptions about TweakScale, and I fond the Module Manager messages telling me that it had applied TweakScale patches with success (on the parts that have TweakScale support, of course): [logs, logs, logs galore!!] ... [LOG 17:19:52.946] Applying update TweakScale/patches/SquadExpansion/MakingHistory/Coupling/@PART[Separator_4]:NEEDS[SquadExpansion,TweakScale] to SquadExpansion/MakingHistory/Parts/Coupling/Separator_4.cfg/PART[Separator_4] [LOG 17:19:52.955] Applying update TweakScale/patches/SquadExpansion/MakingHistory/Coupling/@PART[Size1p5_Strut_Decoupler]:NEEDS[SquadExpansion,TweakScale] to SquadExpansion/MakingHistory/Parts/Coupling/Size1p5_Strut_Decoupler.cfg/PART[Size1p5_Strut_Decoupler] ... [logs, logs, logs galore!!] So, I can tell you with confidence that you don't have a problem with TweakScale at all - what you don't have is support for TweakScale in a lot of parts, more than half of your game database. You will probably find TweakScale support for some of them on the TweakScale Companion Program's Thread: Cheers!

Suggestions are always welcome - they make me think, what not rarely lights up an old rusty bulb on my dull head! We already have something like that! All Tweak! I'm reticent on incorporating the feature on TweakScale because: It will make your savegames and crafts incompatible as soon as someone implements proper TweakScale support for something Let's imagine an Add'On that changes the mass of a part at runtime under some criteria. Without proper TweakScale support, you can scale the part to be twice the size and weight, but the runtime changes will still behave as an unscaled part. Then someone writes proper TweakScale support, and the runtime changes, now, scales as well - voilà, all your crafts are now unbalanced, and on airplanes this is usually fatal. A very few add'ons just blow up into the skies on the most unpleasant ways if someone tries to brute force the scaling. Others just stop working correctly. Kerbalism is one of these later add'ons, you just can't mix parts with Kerbalism support with TweakScale. This is an annoyance, but it's not fatal as Kerbalism doesn't needs to spread itself on every part, so TweakScale is still available for parts not related to Kerbalism. I make TweakScale available on every part by default, it stops to be an annoyance and becomes a problem. I will not enter in details by obvious reasons, but some of the worst complains I had (in the past and in the present, this still happens) are from people suffering from problems created by 3rd parties, but that somehow involves TweakScale (or KSP-Recall) somehow. And these situations can be very tricky, because some of the complainers are not random dudes from Internet, some of them are influent people around here, people that you don't want to liquid off (and boy, some of them came to me really liquided). Until this moment, every single time I was able to pinpoint the real problem on something else, but this always costs time and effort - time and effort that are needed somewhere else. Once the problem is detected, every single of them ended up making amends later - don't take this as a complain against them ("Espernear é direito do enforcado") but this doesn't means that I'm willing to make this a routine. The less this happens, the better. On the bottom line, doing this by default will open a can of worms, and I will be buried under an avalanche of support tickets faster than Jeb can blow up a rocket. I think it's better to keep such…. embracing and extending support for 3rd parties, so I can redirect support calls for them instead of trying to cope with the mess myself. I can only provide support for what I know and understand. The KSP Scene is too much diversified and complicated to risk minimalistic "one size fits all" solution on the wild indiscriminately. Things are already messy enough as they are, as we can easily conclude by posts like this:

So you really found something - apparently I was wrong about having the "Reload Scene" fixed. Can you do me a favor? Can you post our KSP.log after reproducing the problem here or in the Github issue? https://github.com/net-lisias-ksp/TweakScaleCompanion_Frameworks/issues/3 I don't know if I will need it, but if by some reason I could not reproduce it when I manage to have time to check this, I will need the KSP.log to search for some oddities and this will save me some time if it is already there! Cheers, and thanks for the report!

Humm… I remember testing about this, and I think I had solved this some time ago… (I usually create an issue to avoid forgetting things…). Of course, I may be wrong - things were pretty crazy on RL™ in the past 6 months... So, just to be sure: what version of the Companion are you using? Did you downloaded it from what link? The TSCo for Waterfall was deprecated and replaced by TSCo for Frameworks (so I can concentrate all PKMC plugin support on a single place), so are you using the most recent TSCo for Frameworks, or you are using the older deprecated TSCo for Waterfall?