Lisias

"The Winter is coming."

That's the spirit!! There's also a very, very nice video on the pinned comment of this video - but I'm unsure if it would be Forum friendly , so I used the audio only version.

Remember the Japanese Kyushu J7W Shinden ? This is the XP-55 Ascender: Art imitates Life!

Announce! New release 2024.10.09.0 for the TweakScale Companion ÜberPaket with everything (and the kitchen's sink) included for the lazy installers !! Updates the Companions: Frameworks to 0.4.0.5 See the project's main page to details. Your attention please Completely remove all the previous contents in the GameData/TweakScaleCompanion directory, or you will trigger some FATALities on TweakScale's Sanity Checks! This thingy needs TweakScale v2.4.7 or superior to work Download here or in the OP. Also available on CurseForge and SpaceDock. (by night) [edit: nah... they are there already!]

Good news, so! I had detected some not so good news from my side involving the last release of Waterfall, but apparently it's related to my rig and not to any code. Other than the glitch I had reported on the Waterfall thread, I didn't found anything cheesy on my side neither. I didn't made any magic, though. Just rewrote the code that detects Waterfall, everything else remained the same. Anyway, I'm promoting this release to.. "Release" now.

Yikes... The files were available, the directory holding them wasn't... Fixed! Let me know if you need me to do any more testings (it may include recompiling the thing with some debugging info if needed).

On EVERY Unity Game I'm playing on Steam(Deck), using the MONO_THREADS_PER_CPU=1 stunt gave me the very same performance, but the thing ran cooler and the battery life was extended. On my Computer, ditto (except by the battery, of course) - but on at least another one besides KSP, I managed to build bigger things than on the times I wasn't using the stunt because suddenly I had more memory to play with (hint: GC). [Oh, yes... It also allowed me to play Youtube while playing the game - something I couldn't do before] By this time, it became a Unity problem because... Well, this trick is working on the ones I had tried consistently - from older games from 2017 to new ones published this year. If people are "holding it wrong" unchecked for so many time, it's really past the time for Unity start to worry about this and do something about. At the very least, their documentation are lacking and their default settings are unsuited for the workload most games are using. - - - And, yeah, you are derailing the thread.

Hi. I installed the newest Waterfall and started to get this weird magenta thingy instead of the plumes: This is an absolutely vanilla KSP 1.12.5 installment, with only: Module Manager 4.2.3 Waterfall 0.10.1 StockWaterfallEffects 0.8 The craft is a Stock AeroEquus - I just load it on Editor and launched it. The engine involved is the LV-T45 Swivel . KSP.log: https://drive.google.com/drive/folders/1Mh2OoO8o7O1oRi4cvar7KEZQxny-RQ4E?usp=drive_link

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).