Lisias

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?

TweakScale is a very nosy Add'On , it sniffs its nose on every possible part of KSP (and Add'Ons) - I need to inspect and change things on (almost) every PartModule in order to scale things. If any of them has a problem, TweakScale will bork. Additionally, TweakScale has the policy of not hiding problems. TS doesn't ignores things going wrong in the hopes it blows up somewhere else, saving face. If there's anything (known) not right, TweakScale will complain (being its fault or not). The bad side of this is that TweakScale can be very annoying on problematic installments (and vanilla 1.12 KSP is problematic by default, as it appears… ). But the very good side is that if TweakScale is silent, you can be reasonably confident that there's nothing wrong on your rig (or, at least, nothing serious - but bugs happens, after all). In the end, it's the matter of choosing how do you want to be notified by problems: before they happen, of after destroying something valuable. Cheers!

Good news on the KSP-Recall thread: Ping @Mircea The Young, @Aussie Toad Stool!

News from the Front I finally understood the problem on SubAssemblies (if it will solve Merging Crafts is currently Work In Progress) - I was chasing my tail on this one, the solution I was pursuing was impossible (because the problem was completely unrelated to the way I was trying it!!). I'm currently testing the SubAssembly solution to see if I didn't created any undesired collateral effect, then I will check merging crafts to see if I got lucky and they were the same problem. I will spend the next 2 days fooling around with my test beds to see if I get something (unlikely, exploratory testing was never one of my strong skills ) and then I will release a new Recall version. https://github.com/net-lisias-ksp/KSP-Recall/issues/35 Please note that, besides TweakScale being the most notoriously affected Add'On, this problem affects ANYTHING that tries to change the attachment too. Cheers! — — POST EDIT — — Two days I said? HA!!!

What leads to the unavoidable conclusion that Squad had made crucial changes on the engine without the proper planning, care or testing. They are plain throwing… things.. into the wall in the hopes they stick… Look, I'm not complaining about the enhancements (besides not agreeing with the "price" being paid until the moment for them). I'm not even complaining about the bugs anymore. I'm really worried about the current Modus Operandi on the "development" (that, frankly, is more as undevelopment than anything by this time). I'm doing what Squad should had done at first place: I'm doing regression tests for the complains I find here to see when and where they started to happen. Dude, this is not pretty - we have versions and versions of KSP with bugs pilling up on each other, what unavoidably leads to being trapped into a corner: you can't fix a nasty bug because some workarounds were build around it and by fixing the problem you will be reopening a lot of issues that would be needed to be reworked properly this time. And we know that, at this current state of affairs, reopening issues is the last thing they are willing to do. — — POST EDIT 2022-0122 — -- I think some people will be interested on my findings reported here: https://github.com/net-lisias-ksp/KSP-Recall/issues/27#issuecomment-1018550508

Good to know! Really. On the not so bright side, I fail to understand how a so simple fix for a very annoying and widespread problem is not yet on the mainstream. They had the code ready to be used on the codebase, why nobody had the idea to activate it - or at least, create an option to activate it under user's choice if, by some reason, some collateral effect is expected from it?

NYC's M-497 "Black Beetle" Turbojet Train. Oh the Kerbal Way!!! Source: https://www.american-rails.com/m-497.html

Marionette / Letter Box. Surprisingly, it's a royalty free music from youtube. The video below is from someone else (pretty good video, by the way)