Lisias

Some people don't allow autopilots on the challenge neither. But allows clipping - frankly, clipping parts inside others (and so getting twice the functionality with less area - as clipping crew cabins and fuel tanks...), not to mention tricks to fool the physics engine... Exactly what TweakScale helps to avoid. Go figure it out. TweakScale can be a part saving heaven, but also a game spoiler - scaling the engines is nice for cosmetics and fooling around, but even me don't like to scale rocket engines on challenges or career. But some airbreathing and propeller engines (as the ones on KAX and firespitter) I think it's OK, jet engines usually doesn't worth too much (scaling the Juno to have the power of the Wheesley is wasting fuel, due the bad ISP - but it can serve a purpose sometimes). The best parts to be scaled are fuel tanks, structural (as the trusses!!), aero things as cones (and parachutes!), batteries/fuel cells and wing/control surface parts - on these ones, TweakScale shines IMHO Wheels too, there's a terrible lack of variety on stock wheels and TS is a huge help on this. That's the spirit! Just be cautious - abusing TweakScale is almost as fun as the game itself!

In the mean-time, World Stabiliser usually does the trick for me. Give it a try @Kilo60.

Nice catch! Last year, when I added support for the new V2 for the ADTP2-3, I decided to "keep pace" with the legacy as changing the scaletype would render legacy designs unbalanced. So instead of fixing what I also though it was a typo or silly mistake, I decided to keep "erring" to prevent breakage. I don't know for sure if this was the best solution or not - but I have the tendency to err to the safe side - between erring on something that would not affect legacy and erring on something that will affect legacy, I always go for the former. **However**, a complete overhaul for the patches is work in progress (I'm writing tools to help me on the job - so no more mistakes). So this and every other similar issue will be tackled down for sure. But this will be done on a future 2.5 Release, when I plan to write a "revision" control for the patches and, so, be able to fix this one without breaking every craft on Kerbal-X that would be using a fixed part (not to mention crafts and savegames on the user's machine). How much this annoys you? I can write a hot-fix for it, so you can apply it to your instalment. Other than a Warning remembering you that your instalment is not compatible to the mainstream that will be issued every time the MM cache is rebuilt, it will work fine for you.

Hi, @whale_2 I think I found a bug on the chute deployment - if the Kerbal has the JetPack ability, the chute EvaStart event handling ends prematurely, and the Chute is not primed. I made a pull request with the fix here.

Tough year, sirs... tough year.

SIGFAULT 0x666 on thread 666. The crash has awaken.

You got it wrong. The PR LGG applied after the release is about allowing the Window to be draggable. The discussion was about one of the proposals being less than ideal, and also about (my) opinion about the initial proposal from Micha being... hummm... "more orthodox" than a spinlock, that ended up being used for simplicity. But this doesn't means than a spinlock would not safely solve the problem (or at least this problem) - I ended up implementing Micha's way just to compare with the spinlock solution, but RL stroke hard and I ended up not having time to make the benchmarks. I think this was what confused you. -- -- -- POST EDIT -- -- -- And since we are here, I need to advise I was wrong on where the problem is on that discussion.

Well, the front page says The page was edited on July 6, the date of the post I linked to you. Same version too. Not to mention SpaceDock. So, yeah, the problems with the async backups are solved.

See this post:

It's not a mod compatibility, it's Microsoft insanity. Testing it on a clean install will only mask the problem, please keep testing on the current installment. I prefer to keep these one on github, as we will need to exchange a lot of files and this is way more convenient on github. I will post the conclusion here once I manage to fix this damn microsoftian idiocy.

@boribori, I had built new (debugging) binaries and I need you to test the thing on your installment. Check this post on the github, download the new zip file and use the DLL you need. Fire KSP up, see what happens, and then please report me what you got. Please publish the KSP.log either way, this is a Fishing Expedition by now.

Not that I had any doubt, but yeah, even Module Manager is being fooled about your symlink! [LOG 11:03:33.944] [ModuleManager] version 4.1.4.0 at /home/boris/Games/KSP/KSP_linux_1.10.1_LRTR_RF/GameData/ModuleManager.4.1.4.dll won the election against Version 4.1.4.0 /home/boris/Games/KSP/KSP_linux/GameData/ModuleManager.4.1.4.dll It thinks the same DLL are two different ones. This also means that KSP is loading it twice... #facePalm I still didn't found time to write my own AssemblyResolver (what would solve some problems on KSP), so MM will have to wait. In the mean time, I reopened the Issue #6 to handle your case. I had burn some midnight oil, so I'm a bit tired now - but I will tackle down your problem after resting a little. Cheers.

Humm... So I already had updated Recall with it (getting old... ). So, yeah, I need to tackle down your Use Case specifically. The KSP.log is way better for diagnosing things, could you send me this one, please? What you got was my safety belt against loading DLLs outside the KSP root (KSPe can selectively load DLLs too - so ensuring it's something inside KSP is important to keep things safest as possible to the user).

These UNIX guys, always freaking up our clever stunts.... Here is the story: in order to guarantee instalment integrity, there're some features on a thingy called KSPe that checks things and bark on the user when something is wrong. However, in order to be really sure (and to enforce KSP policies of not allowing direct access to outside of the KSP root directory), I resolve dots and double-dots and make sure nothing leaks to outside (of course, the developer can give the finger to it and do things his/her way, but so he/she wave up the KSPe facilities and that's it). Problem - our friendly guys of mono runtime decided it's a good idea to resolve the links and symlinks of the main executable, and so the KSP rootpath given to me is not the same you used to launch the game, and this bit me in the SAS magnificently. I solved this problem using a hell of a stunt, but the stunt works. Thanks @steve_v for it. In a way or another, there's an experimental build of the KSPe.Light for KSP Recall on this post with this fixed. It will be distributed on the next Recall release, but until there you can shove that thing on the Recall's Plugin folder, making sure it's replacing the older DLL. I don't remember if I handled specifically your Use Case, however - I remember tackling down the problems using symlinks inside the KSP root (Steve's Use Case) - I'm not sure if that stunt will work for your case. If not, ping me here and I will rework the stunt for you. Let me know if it works too, so I can update the "documentation".

After months of lockdown, these ones is more of a fit for me... Moar suits.

Yes, it is. I forgot something when I compiled the DLL, I'm checking it. The DLL is there to do the sanity checks and prevent the game from loading if something that could harm the savegame is detected. TweakScale itself knows squat about anything that is not Squad, so anything related to NF will be handled on the Companion for the NF. Please wait a couple hours for a new release on the Companion thread.

Some knows if that soundscape.zip file with the optional soundscapes is available somewhere? It seems to be lost in time...

Vangelis. Forever. (that magnificent video was removed from you tube, we need to cope with this less than optimal version... )

Piasecki PA 97 Helistat. Dr Wernher von Kerman would not made "better". 4 Sikorsky helicopters strapped on a huge blimp. There's a video on Youtube showing its first flight, but since the outcome was less than ideal, I don't know how it would cope with Forum rules so I will not link to it. But you can google for it.

Got it! [LOG 11:06:03.821] [TweakScale] INFO: WriteDryCost Concluded : 4913 parts found ; 3 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 27 Show Stoppers found; 47 Sanity Check failed; 47 unscalable parts. Yep. We have a little mess here, and a pretty huge installment to check on! (pretty good rig, by the way!). Let's check first the 27 FATALities first, as this I can fix for you (most of the time). All of them are about duplicated properties, what means rogue patching. One of the double patchers is Contares, already known issue by the way: [LOG 10:39:51.789] Applying update Contares/Patches/CONTARES_TweakScale/@PART[truss-octo-*] to NearFutureConstruction/Parts/Truss/truss-octo/truss-octo-hub-crew-01.cfg/PART[truss-octo-hub-crew-01] [LOG 10:40:20.518] Applying update TweakScale/patches/NF/NFC_TweakScale/@PART[truss-octo-hub-crew-01] to NearFutureConstruction/Parts/Truss/truss-octo/truss-octo-hub-crew-01.cfg/PART[truss-octo-hub-crew-01] Installing TweakScale Companion for NF will solve that, because on the Companion I decided to force my way on things and that's it. I am the TweakScale guy, after all. But Contares is also patching some parts not touched by TweakScale: [LOG 10:39:51.408] Applying update Contares/Patches/CONTARES_TweakScale/@PART[A1-44_FIN] to Contares_MEU/Parts/A5/A1-44_FIN.cfg/PART[A1-44_FIN] [LOG 10:39:51.877] Applying update Contares_MEU/Patches/Contares_MEU_TweakScale/@PART[A1-44_FIN]:NEEDS[TweakScale] to Contares_MEU/Parts/A5/A1-44_FIN.cfg/PART[A1-44_FIN] And this is beyound me to fix. But we can at least minimize the damage: The fix is still the same from the last one: Install THIS version (0.0.3.2) of the TweakScale Companion for NF. If you are creating new games, you can use the latest one (0.0.4.0) - but only for new savegames This is needed because some scaling rules were fixed, and only TweakScale 2.4.4 (and the TS 2.5. beta) knows how to overcome KSP on some 'automatic savegame updating' thingies that ended up stomping TweakScale toes on the matter. Once TS 2.4.4 is on the wild, you can update to the newest 0.0.4 without fear Delete the file Contares/Patches/CONTARES_TweakScale.cfg . I don't know if this is a left-over from an old version that you forgot while updating, or if it's the same old bug from Contares still not fixed. But removing this file will save you a lot of double patching. But I don't know about any other patching this file is applying. You should ask for directions on the Contares Thread. Let me know if I can help you on something else. Cheers! -- -- -- P.S.: may I suggest to remove the log snippets from your post? Not only they are useless now that you posted the full log, but they also hinder a bit the search engine. I post some log snippets on my posts to have them indexed to a solution, and when there are such snippets on the bug report it makes things a bit more confusing while searching the "Knowledge Base"!

Not exactly real life, but it's too good to let it pass. Microsost stole the MoHole on their Flight Simulator!

Wild guess, but with some heavy textures loaded, the GPU ends up delivering less frames per second - mainly on our case, where the "VRAM" is shared from the CPU main RAM. So the CPU would have more time to act, avoiding triggering the TLA. About the OneDrive links, they are working now (all of them). I'm downloading them and I will give them a look.

So, yeah, you are right about the Particles on the lamps being the trigger. However, I was wrong about a using an older D3D being a possible workaround. I tried to download the logs for inspection, however... I will try again tomorrow. In a way or another, I think we will need to use Harmony to deactivate the Lamp's flickering. Don't know how it will cope with Forum rules about reverse engineering however...

Oukey, I managed to fool Murphy and got time to play a bit. I replicated @Commodore_32's installment, copied the settings.cfg file over mine, started KSP and created a new sandbox game, fire it up and gone straight to VAB. No TLAs. @Commodore_32's machine is beefier than mine, but @GuessingEveryDay's one is a bit near. At least three years newer, but performance are kinda near. He uses a Intel G4400, while I'm using an i7-3615QM one. Besides my i7 having a slower clock, it can turbo up to 3.3GHz by deviating some cores - but the cores still have hyperthreading, so I expect my CPU being a bit faster than him on multitasking - but not on raw power on a single thread. He have better bus speeds, so the overall performance should not be too much different on KSP. His graphics card is a Intel HD 510, while mine is an HD 4000. Surprisingly, my GPU is sensibly faster than him besides pretty older- so the test looked promising! More or less what I was guessing - a faster GPU choking up the CPU. But... No TLAs on VAB neither SPH. (sigh) Commodore_32' said the TLA is happening too when using OpenGL, that it's my only option on MacOS - so we already had ruled out this one. So the difference must be on the GPU, and so I started digging specs. My GPU, due it's age, still use OpenGL 4.0 and, on Windows, DirectX 11.1 GuessingEveryDay's GPU, on the other hand, uses OpenGL 4.6 and DirectX 12! Hummm.. Commodore_32's GPU is an Radeon R4 mobile, more similar to mine than to GuessingEveryDay's GPU on raw power. BUT... It also uses OpenGL 4.6 or DirectX 12! So the guess has teeth, I may be right on it. So I reread this thread looking for hints, and realized something: I don't have sparks on VAB/SPH's lights when the lights flicker! It's a new guess - as always, an educated one , but still a guess: I'm not getting problems on Particles because my GPU handles particles on DirectX 11/OpenGL 4.0. If I'm right, there's something on DirectX12/OpenGL 4.6 that's triggering the problem on Unity. So I dug a bit more, and remembered that KSP uses Unity 2019.2.2f1 since 1.8 (if they updated to a new version, it's not mentioned on the Version History). And digging yet a bit more, I found this entry on the 2019.3.0f6 Release Notes : And on 2019.3.0b8: Both releases newer than the one KSP uses. Of course I'm not absolutely sure about any of that, but it fits. So, and assuming I'm right, the only real fix is to update Unity 2019 to at least 3.0f6. What we need to do now is find a work around for this problem. I have a hunch that KSP is getting some heat due that Stop Action thingy, it appears to fit it crashing on VAB/SPH, as light's sparking appears to allow culling. So... new test: Start KSP forcing d3d11 with -force-d3d11 . Or even -force-d3d9.

Me? Expert? I'm only a smart SAS with some pretty good guesses! @SQUAD are the experts on this here - problem, the more you know about, more possibilities you find - what we are doing here what you are doing here is narrowing down that sea of possibilities in order to make easier (or less hard!) the heavy lifting @SQUAD need to do to nail down this Kraken Damned <insert your favorite non forum compliant compliment here> bug! I'm downloading the settings.cfg. I will take some time (RL job, I'm late on a task...), but I will try your settings for sure - yet this week, unless some crazy dude decides to change something on production again without testing it on QAS (or at least warning me, damnit! ). Hummm... Not exactly a powerful GPU. My guessing need some "refactoring". I was thinking a "too much" powerful GPU would be stomping the CPU's toes by doing things faster than the CPU can feed it. On the bright side, I'm using a Intel Graphics too (MacMini 6,2), so it's feasible I can reproduce the thing here too - unless we are facing something DirectX related crisis...