Lisias

If you are stup... uh... kourageous enough can you please try this Experimental Release? https://github.com/TweakScale/Companion_Frameworks/releases/tag/PRERELEASE%2F0.4.0.5 I changed how Waterfall is detected, but kept the rest of the code the same. I know for sure this will work fine with older Waterfalls, but doing a thoroughly test session with Waterfall 0.10.x (a huge change set on a monolithic commit - the QA tester nightmare came true!!) will take time I can't dispose until the weekend. === == = POST EDIT = == === Apparently, I found a glitch on Waterfall (and I'm not the only one).

When you launch the craft, and then do a Revert to Launch, the plume's scalings are reset to the default and I can't rescale it again. When Reverting to Editor and then launching the craft again, the glitch doesn't happens. https://github.com/TweakScale/Companion_Frameworks/issues/3 I never managed to understand what's happening on this one.

Well, I fired up my test bed using the 0.9 Waterfall and 0.7 StockWaterfallEffects to see what I get (it's what I used to smoketest the respective Companion last time). No problems detected (other than that pesky and stubborn one on Revert to Launch): [LOG 02:30:33.047] [AddonLoader]: Instantiating addon 'Startup' from assembly 'TweakScalerModuleWaterfallFX' [ERR 02:30:38.158] ADDON BINDER: Cannot resolve assembly: TweakScalerWaterfallFXIntegrator [LOG 02:30:38.161] [KSPe.Binder] Looking for TweakScalerWaterfallFXIntegrator.dll on GameData/TweakScaleCompanion/Frameworks/Waterfall/./PluginDa [LOG 02:30:38.162] [KSPe.Binder] Found it on /Users/lisias/Workspaces/KSP/runtime/1.12.5.acp/GameData/TweakScaleCompanion/Frameworks/Waterfall/Pl [LOG 02:30:38.184] [TweakScaleCompanion.Frameworks] TweakScalerWaterfallFXIntegrator Version 0.4.0.4 /L BETA is loaded. This is was I expected to see on your rig. Oukey, I didn't screwed up (this one :P). Then I updated both to the latest (0.10 and 0.8 respectively): misbehaviour reproduced. Yes, something changed and fooled the Companion. I will work on it ASAP. Until there, there's a chance you can revert Waterfall to 0.9 while I don't update the respective Companion? https://github.com/TweakScale/Companion_Frameworks/issues/10 In time, the double call I mentioned above happened on my rig too. This is something I did wrong. I will fix it Soon™. https://github.com/TweakScale/Companion_FS/issues/12 [LOG 02:30:28.124] [AddonLoader]: Instantiating addon 'Startup' from assembly 'TweakScaleCompanion_FS' [LOG 02:30:28.125] [AddonLoader]: Instantiating addon 'Startup' from assembly 'TweakScaleCompanion_FS'

Wow, thanks for the comprehensive logs! Yeah, I found the symptom: [EXC 14:18:44.103] DllNotFoundException: An Add'On Support DLL was not loaded. Missing Interface : TweakScaleCompanion.Frameworks.Waterfall.Integrator.Notifier KSPe.Util.SystemTools+Type+Find.ByInterfaceName (System.String qn) (at <4596164eec694c33b823d99d5882d3b1>:0) TweakScaleCompanion.Frameworks.Waterfall.TweakScalerWaterfallFX.InitModule () (at <a85d8dd814874d41a200154164b60c50>:0) TweakScaleCompanion.Frameworks.Waterfall.TweakScalerWaterfallFX.Update () (at <a85d8dd814874d41a200154164b60c50>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) But I didn't located the trigger, because apparently the supporting DLL was loaded: [LOG 13:28:20.956] Load(Assembly): TweakScaleCompanion/Frameworks/Waterfall/TweakScalerWaterfallFX [LOG 13:28:20.956] AssemblyLoader: Loading assembly at D:\KSP_win64\GameData\TweakScaleCompanion\Frameworks\Waterfall\TweakScalerWaterfallFX.dll ... [LOG 13:28:20.956] AssemblyLoader: KSPAssembly 'TweakScalerModuleWaterfallFX' V0.4.0 ... [LOG 13:28:28.188] [AddonLoader]: Instantiating addon 'Startup' from assembly 'TweakScalerModuleWaterfallFX' ... [LOG 13:37:53.549] [AddonLoader]: Instantiating addon 'SanityCheck' from assembly 'TweakScalerModuleWaterfallFX' ... However... I didn't found the message "TweakScalerWaterfallFXIntegrator Version {0} is loaded." and it should definitively be there. This explains the message above, but not why it happened. At least I'm sure that TweakScalerWaterfallFX is loaded (its the one trying to load he other one). I double checked, and I found the "TweakScalerWaterfallFXIntegrator.dll" file on the distribution files (both the standalone and the UberPacket). I have now two Working Theories: I screwed up something the mentioned DLL is not present in your hard disk in the directory: "GameData/TweakScaleCompanion/Frameworks/Waterfal/PluginData" I'm firing up my test bed to see about the Theory 1. If you read this before I finish, please check if the mentioned file is present in your rig on the right place. === == = POST EDIT = == === Humm... Found something fishy... [LOG 13:28:28.216] [AddonLoader]: Instantiating addon 'Startup' from assembly 'TweakScaleCompanion_FS' [LOG 13:28:28.216] [AddonLoader]: Instantiating addon 'Startup' from assembly 'TweakScaleCompanion_FS' This DLL was started twice... It's probably unrelated,but yet, it's an anomaly.

And you make it sound like it was fixed already. You see, shifting to 64 bits was what allowed the problem to grow bigger, as it allowed more textures to be loaded exacerbating the symptom. This is the expected behaviour of a long standing problems that are not solved (for a reason or another - some problems can't be solved at all): new people came, became experienced and then detect (again) a problem, talk about it, veterans explains the situation, new people gets acceptance and became eventually veterans. And then new new people came and the cycle continues with the new veterans taking the torch. Yelling "old news" to new people will not help to solve the problem, neither help on keeping them around so they would eventually became veterans. But you could had helped by linking the posts you had read about, so the "new veterans" like me could get new glimpses of the problem, instead of relying only on my own results as well the posts from other people that talked about on my time. There're at least 168.673 visible threads on this Forum (as on Oct 1st early morning). No one (including you, I bet) had read them all - and the Forum's Search engine, besides useful, is not Google and it's lately imposing delays of many seconds between an search and another, bittering the process. Relying on the experience of people like me and you (and yes, I'm pretty sure you have some knowledge to contribute to this discussion) is still our best way to feed a good and constructive discussion. As a matter of fact, it used to be this way since our times living in caves...

On a side note, sometimes I flirt with the conclusion that they managed to get that huge success they got exactly by doing (almost) everything "wrong" during development. Some of the worst and most lingering problems on KSP happened on the very first release after the original team left the company, and where replaced by professionals that made things "right". Fun fact:

And I think both of you missed the point. I want to quote the OP on this: Again, we DON'T NEED to know the OP's mod list to answer this guy. He's talking about an architectural decision made on KSP that, besides IMHO had server the base game well over the years, is starting to bite our collective arses nowadays with VRAM hungry add'ons being published by modders. There's no difference between installing 10 mods with 10MB each, or installing 5 with 20MB each, or installing a single one with 100MB - the net result is you consuming 100MB of VRAM. In all cases, if you by some reason are exhausting your VRAM, no matter the add'ons you have installed, you will need to experiment with the Graphics Settings to recover your sweet FPS. And I need to remind you that even Browsers eat VRAM nowadays, and I'm pretty sure it's the reason the OP listed the other processes running on the rig at the time of testing - note the OP said Chrome is unstable - this means that it's also starving while playing Youtube - something that I managed to mitigate on the stunt I mentioned before : May I ask you both to reread the OP's post?

I don't see your point. In more than 6 years of support, I dare to say that 80 to 90% of the suttering that happens immediatelly after installing new things are related to VRAM exhaustion - even when the installed thing isn't an add'on, as when the initial versions if the infamous PD Launcher caused users of GPUs with 6GB of VRAM to stutter KSP 1.12 when the game is launched from it. GC is the next suspect, but it usually happens after some playing. In the end, it's really simple like that: if you get stutter after installing something, lower the settings and see if the problem goes away. If yes, decide what's more important: FPS or Visuals. If want to keep the Visuals and get back the FPS, then something will have to be uninstalled. If nothing changes, revert the changes and then ask for help, because now you will be sure that it's something that you can't help yourself. And this is where the exact list of mods is important, because it may be some unholy interaction between some of them.

But it means that they are not that different neither! Mods (usually) have some common characteristics, like making heavy use of meshes and textures. And, so, also have similar problems, like overflowing the VRAM, what leads the GPU driver to borrow CPU RAM, what leads to heavy contention as both Processors can't access the same RAM at the same time. Granted, there could be further bottlenecks on the rig that would bite the user when using a set of mods and not others. Without some digging, it's not possible to tackle these down. BUT... As a rule of thumb, if you have nice FPS and then you install more add'ons and then your FPS plummeted, lowering the graphical settings it's cheap and works most of the time - and when it doesn't, just revert the changes and try something else. You don't even need to reboot the game to check it, what renders this a really no-brainer first troubleshooting action!

Well, since lowering the settings helped them to get better framerates, it's probable that the set of mods is not that different!

I need a list of acceptable opinions to avoid being delisted!

Developers are (surprisingly, I admit ) humans beings, after all. Lefting apart who did what, unless the dude/gal is a psychopath they have feelings and need to pass trough all the 5 steps of grief as anyone else. And, by then, they will have new lives, new jobs, new problems to cope with, and all of that takes time, a lot of time - restarting your life from scratch is a huge and painful task, it's not a surprise that most people avoid switching jobs unless there's absolutely no other option (even when the job sucks by a reason or another). And on the list of priorities, old allegiances always ends up taking the back seat. Heck, I'm still active around here, but due Real Life™ and Day Job© issues I'm barely being able to interact with people in the last 6 weeks. I just didn't had the time to engage in a meaningful way most of the time. And I didn't lost my job (yet... ), what to say about them?

It's not what happens to me. Modded KSP¹ works best. Now, there's indeed a limit for installing things in your rig otherwise the architectural limitations of the game will bite you. But my experience tells me that, usually, performance plummets due hardware abuse, usually VRAM. Do a test: go to Settings, Graphics and set all Quality levels to the lowest (Textures, Meshes, Terrain, everything). The game will look like crap, really ugly. But if by doing this your game start to perform better, then your problem is VRAM being exhausted - this induces the graphics driver to use ordinary RAM as VRAM, and this screws up FPS horribly. Of course, now you will have to make a decision - what's more important to you? Because you will need to cut down graphically intensive add'ons or keep the settings at low. And, yeah, tough call.

Lightly injured, things could had ended way worse. I found this video, where the whole incident was recorded: I think that the elevator's cable broke.

I'm getting them essentially everyday. What it happens is that they appear to shift timezones.

NEWS FROM THE FRONT Release for the 2024-09 is online, the AI torrent was updated. All partial warc 202409* files were replaced by the proper, consolidated and sanitized ones. ALL_URLS.csv was updated accordingly. I do not intend to do partials anymore. It's 4 times the workload of a monthly update And I had already coded the tools I need, and they are stable by now - no need to probe them all the time, not even as a testbed as there's no need for so many tests anymore. It expands my "surface of attack" I had noticed that things get gradually harsher for me on every update on the IA archive. I don't think it's healthy to speculate about this. Forum's Archive is more or less feature complete. All known topics up to October 1st were scraped at least once, but it still miss about 60% of the profiles. From now on, the efforts will focus on: Scraping missing profiles; Scraping new topics; update previously scraped topics when needed (low priority). New revisits warc kind, preserving the recorded… well… revisits. revisits are not needed for playback, but will play a role now that topics and profiles should be updated regularly. revisits and redirects from 202407 and 202408 were reworked (and replaced). Better sanitizing processes were applied on them. https://archive.org/details/KSP-Forum-Preservation-Project There's a missing file, movies, that I didn't uploaded yet. I don't know what in hell Forum is hosting buried deep somewhere here (didn't bored to find the reference post yet!), but there're 16 (SIXTEEN!!) Gigabytes of videos on this file (what by Kraken's sake are you uploading here, guys?? ). This is going to hurt... And it's the reason the torrent wasn't updated yesterday, I left the thing uploading and gone to bed and... well... obviously Murphy noticed it and screwed the upload lefting 5 or 6% to finish. I'm uploading everything again now, but the movies. I will update the torrent with the movies as soon the current uploads are merged into the torrent (Internet Archive takes some time to do it). Please check the torrent link by night - everything but that pesky movies are already online. [edit: It's there already - finally!!] Additionally... I'm not willing to beat a dead horse, but the problems I depicted on are starting to bite, and it's one of the reasons I didn't published (or coded), yet, some code about collaborative scraping. I need to find a secure way to distribute the jobs to whoever would be willing to help me with the scrapings. See below. What lead me to the next problem: on every single release of the scrapings, something changes around here making my life harsher. It happened in 202407, it happened on 202408 and lately on 20240901* (the first September partial). And it happened in less than 12 hours after the publishing, you can easily correlate it with the graphs I'm keeping about the Forum's health during the process. So, now, we have a new problem to tackle down before distributing the work: protecting the supporters, preventing them from being hit the way I was (being in the bad side of CloudFlare will make your life significantly harsher on any other site handled by CloudFlare). It would not bother me if things would be improving around here, but they aren't: At least, for me. So whatever it was done that hindered my efforts on archiving the site (that would be done by this time otherwise), it's not improving the current situation (kindly assuming this is the reason these measures were taken). And, yes, @Dakota, this is the reason I didn't cooked a way for collaborative archiving (yet). As I published some source code or updated the torrent, something changed around here and made the task harder, as well caused me some drawbacks on my connections with CloudFlare's shielded sites. There were a day that I almost didn't managed to visit half the sites I use to attend... Anyone helping me directly will suffer the same reprisals unless we keep the data private, but - by then - why doing it this way at first place? In a way or another, I managed to carry on the task until now: I have, essentially, all topics up to 226017 were scraped at least once. I'm working on reports to check if all pages from each topic were archived correctly But only about 38% of the profiles were archived, I intent to focus on this on October.

Just to formalize what everybody else's probably know by now: Things are not improving. (the gaps on 26th and 27th are me not monitoring the site, but I had posted on that timeframe and got some 50x errors the same).

One step at at time. You will struggle a bit to make the first one - you need time to go trough your grief, and the first step out of it is always the hardest. Don't think about it right now, don't think about the future, it will come no matter what. So, why worry? Rescue your past. There's always something in our past that will help us to take that terribly hard (and harsh) first step. Keep Walking.

Virtual Reality is a shrinking niche toy.

=== == = AND NOW FOR SOMETHING COMPLETELY DIFFERENT = == === === == = EDIT = == === Oh, boy²... Another inherent ability of mine is to miss the tone sometimes... I'm terribly sorry for your loss, @AlamoVampire. I know how this hurts (getting old is getting acquainted with such losses). All I can say is that time is the best medicine. The pain never really leaves, but the good remembrances gradually grow stronger to a point in which you don't really feel the pain anymore (besides it's being there, deep inside). Be well, take care. Things will be better.

There's no way to tackle down this problem and still adhere to the EULA and Forum publishing guidelines. (the Source is our best bet to fix this problem - access to it will allow us to, legally, do a lot of things. Better.)

You know, I had played this marvelous game on the "good old days". On a PS/2. When the game was still a novelty! I'm missing playing this game - or, perhaps, I miss the person I was when I was playing this game? ICO.

Welcome! Not mutually exclusive options. You see, there're a lot of pesky bugs (some of them since 1.2.2 - 8 <insert your favorite non forum friendly expletive here> years with this bug screwing us!) that should had been tackled down early, but lingered enough to force new features to be built over it and now fixing it is some order of magnitude harder - and then we have a self feeding vicious cycle. There's this other thread where this was discussed: There're alternative options, discussed there, about how to do it. And also some other options that we had concluded would not be productive. You may want to give it a peek. TL;DR: Beating dead horses rarely brings constructive outcomes. We need to find another way. One of my proposals is on my signature (and here, if you are on mobile).

It may help if you are multitasking while playing, but it doesn't really fix any memory leak. This is how things work: KSP allocates memory preemptively, because it thinks (not wrongly) that you will need any memory you free when changing scenes. For example, when changing from Flight into KSC, everything "alive" goes on rails and so all the living parts, physics engine data et all are deallocated. But KSP knows that you will go back to flight sooner or later, and so it keeps all the memory for itself instead of returning it to the System. This tool kicks KSP regularly to force it to return freed memory to the system regularly. This makes changing scenes a bit slower, because asking the System for memory is a bit slower than just keeping it, but it allows other processes to have some memory left while you play KSP. It have the drawback of heavily fragment the System Heap, so it's common that once you exit KSP and go to the browser (another memory guzzler), the system freezes for some minutes as soon the browser needs some extra memory as the Kernel is defragmenting the huge mess that became the System Heap. Keep in mind, however, that these kicks only forces KSP to free memory that it managed to collect from the garbage collector. Memory Leaks that are not freed by the GC are, obviously, not returned. On the other hand... Reading that thread suggested me that GC is induced to do a deep Garbage Collecting before returning memory to the System, so it may be another viable mitigation for the problem I mentioned on my last post. I would suggest trying both mitigations at the same time to see if you get any further improvement.

This is not necessarily bad - but can get uncomfortable pretty quick as you install more and more texture intensive add'ons. Essentially, KSP was meant since the beginning to be as "middle game load free" as possible. The original designer didn't wanted loading pauses while transitioning between reference frames in Space, or while flyng around Kerbin. Since at that time the game was fitting easily on a 2G RAM machine (this thing was originally meant to run on 32 bits CPUs!!!), this really wasn't a problem for the vanilla game. But then 64 bits versions came, memory intensive add'ons became popular, and now we have this new situation that weren't intended to happen on the game's original architecture. I think the situation is still salvageable with some clever coding tricks, but access to the original Source Code is essential to do a good job without playing havoc on the installed, legacy, code base in use. You are comparing oranges with apples here. COD is not a open world. A better comparision would be MS Flight Simulator 2020. But even this one is not exactly accurate, because you don't keep dozens of crafts "flying" around the Kerbol System and can to switch to any of them at any time. You see, you can have a craft orbiting Kerbin, another one in transit to Dune and a Station orbiting Jool. And you may need to switch to any of them at any instant for a planned burn or something, and the original game designer wanted that such switching would be absolutely transparent and loadless. What he did, indeed, accomplished with success using the vanilla game. Yes, I agree that nowadays a clever memory management is desperately in need but, and again, this is not a problem for the base game. I would agree with you if you were complaining about KSP2, but KSP¹, definitively, can't be blamed for what we have now. WE DUG THIS HOLE OURSELVES. I think you are wrong here. What's hurting right now are memory leaks and terribly annoying bugs on the code base. Like this exactly bug that you mentioned - see, this is a bug. Not a glitch from an architectural decision. One of the terrible bugs in need to be tackled down is about how the game's concurrency utterly breaks when you are using asymmetrical CPUs (that ones with P-Core and E-Core thingies). Synchronization on KSP (as a matter of fact, in Unity) are.... brittle. Everything assumes that all CPUs are running in the same speed, so there's no difference in how much time a process will be tackled down if it's assigned to a different CPU in the middle of the process. With asymmetrical CPUs, this assumption utterly breaks - and anything relying on things happening deterministically across the whole CPU utterly breaks. Try to set up the KSP's process "Affinity" to use only P-Cores and I think this particular problem will be mitigated for you. This is not a new problem, by the way, some other strange thingies can be explained but this problem. They already tried that. It helped on loading times, but didn't fixed (obviously) the flaws I mentioned above (as they are essentially Unity being Unity, and not KSP¹'s fault on the most part). What I think you are missing is that a way worse problem is... well... memory leaks. Due how Unity do things, the Garbage Collector is always in deficit and is never really allowed to do a proper deep garbage collecting, so the tendency over time is to have lots and lots of memory being left on the bin can to never be collected and reused. What you are proposing will increase the pressure on the GC, probably making things worse instead of better. You will find the gory details here: But, TL;DR, setting the environment variable MONO_THREADS_PER_CPU to 1 before launching KSP MAY mitigate a bit the problem (besides not really solving it). Interesting enough, doing it increase the FPS a very tinny bit, and decreased my CPU's temperature while running KSP (keep in mind, however, that I play on a potato - your mileage will vary). I also managed to decrease the system temperature and increase the battery life on the Steam Deck by using this trick, and not only on KSP, but on any Unity game I'm playing lately. I think you should try this trick - but, keep in mind, it may bite you - it depends on what you have installed on your rig. Try this trick on a disposable KSP first, before using it on your "production" KSP installments.