Lisias

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.

The Kerbal among humans: Scott Winton and his Facet Opan flying... thingy. Can't make a turn without scratching the wings on the ground (just like my planes on KSP!). I wonder how much "maintenance" the wings would need before taking off again! And since we here: A bit less Kerbal (no ground scratching!), but in the same spirit!

Howard's Damn Big Airplane : NASA almost built this!

If you are using anything from 2012 or older, you should probably stick with 1.3.1 to have fun. I had a old CrapMini 2.3 (late 2011), I5-2415M 2.9GHz boost, 16GB and HD 3000 graphics. It runs KSP 1.3.1 to 1.4.3 marvelously. Really good. From 1.4.4, however, that thing became a slide show. These machines are less and less relevant nowadays, but they are still available and used by some people - I had mine MacMini 2.3 doing secondary tasks until recently (these little beasts are resilient!), but for some people they may be the difference between playing KSP or not playing at all. I have notice that a lot of schools in USA still provide similar spec'ed notebooks for their students. Being able to play KSP on these machines, again, is the difference between playing KSP or not playing at all for a part of the intended audience, i.e., primary school students.

Requiem aeternam dona eis, Domine. Et lux perpetua luceat eis. Te decet hymnus, Kraken, in KSC, Et tibi reddetur votum in Kerbin Exaudi orationem meam Ad te omnis caro veniet. Kyrie, eleison! Kraken, eleison! Kyrie, eleison!

NEWS FROM THE FRONT We are not dead yet. Torrent was updated.

Assuming you are on Windows 11, I found this pretty tutorial about: WIndows 10 is the same, changing only the looks. The only restriction I got on using Steam is that sometimes the pathname of an file ends up being bigger than 256 characters, and some native calls choke on it. Other than that, Steam does absolutely no shenanigans on the game's files. Just install the game using the same user you are going to use to play it, and you will be fine. At least until Windows 10...

The intention is to warn the user that CKAN managed installments should had TweakScale installed by CKAN, and that only the packages I had specifically tested on CKAN should be used. This is meant to prevent non CKAN approved TS packages to be unattendedly installed on CKAN managed installments, avoiding stomping in your toes - one of the main concerns is on the TweakScale.WatchDog component that aims to prevent mishaps going unnoticed on manual installations, but that have some features turned redundant when the rig is managed by CKAN where such mishaps would not happen. Note that I have a CurseForge specific package too, where another set of rules is used. You will notice on the commit that I created the boilerplate to do the same for CurseForge. As long as I find a way to detect a Curse Installer managed rig, I will do the same there. The rationale is that things perfectly valid on CurseForge are inconvenient (or plain undesired) under CKAN (and probably vice versa). And manual installations need checks that should not be made on both of them - double guessing CKAN while using CKAN is a bad idea. I will quote what will be logged on KSP.log if the user do a manual install (from github or, Kraken knows why, CurseForge) on a CKAN managed rig for reference: Log.force("**YOUR ATTENTION PLEASE!** This TweakScale packaging is not meant to be used under CKAN. It's usually a bad idea to do manual installings when using CKAN, futurelly this may break things for you! Please CKAN to install TweakScale on CKAN managed rigs."); And, other that having redundant checks activated, this will be the only change the user installing manually a non CKAN approved package on a CKAN managed rig will see.

ANNOUNCE Release 2.4.8.6 is available for downloading, with the following changes: Due recently realised changes on the way CKAN handles alternate downloads, some safeties were implemented to alert the user if by some reason it was installed a non CKAN approved package on a CKAN managed installment. Closes Issues: #339 Prevent non CKAN safe binaries from being used on CKAN managed installations. We are not dead yet. Scale safe!!! (and keep launching) Known Issues There's a long standing issue on TweakScale™ about scaling ModuleEnginesFX's plumes - some engines' plumes is just not scaled, while others scaled pretty badly. It's something that never worked right on TweakScale™, and it will only be really fixed on TweakScale™ 2.5 (when this thing goes gold) The best workaround (and also the reason I'm dragging my feet on this) is to use SmokeScreen or Waterfall. For SmokeScreen, you need: SmokeScreen itself. Real Plumes (to enable SmokeScreen on Stock parts) Additional Part Sets and Add'Ons may need specialised support not included on Real Plumes. For Waterfall, you need: Waterfall itself. StockWaterfallEffects (to enable SmokeScreen on Stock parts) Additional Part Sets and Add'Ons may need specialised support not included on StockWaterfallEffects. See Issue #27 Disclaimer By last, but not the least... This Release will be published using the following Schedule: GitHub, reaching first manual installers and users of KSP-AVC. Right now. CurseForge. Right Now. SpaceDock. Right Now. Being a bug fix release, I hushed the thing into everything at once.

It's more than an year, but this subject never leave my mind, and now I saw this: Manley had similar (but not identical) conclusions as me at that time, but he have now way more information to work with - what at that time was a Thesis for me, now it's an Evidence. What I inferred right: the glue is the most probable cause of failure, probably due unattended stress by being subject to thermal compression and decompression. What I inferred wrong: I thought the point of failure was the rear dome. Perhaps my source of information, that had affirmed that there was no human remains on the rear dome and only on the front one, was wrong. Or perhaps I need to better understand how fluids behave under that circumstances - right now, I don't see how the... (sigh) pulverized human remains (sigh) would be ejected trough the front dome without leaving traces on the back one if the collapse started there. That said, it's still possible (perhaps probable) that Titan was a death trap, an accident waiting to happen. We just don't have enough information. What I'm saying is that we lost time making unfunded claims that didn't helped at all to diagnose the problem, and such unfunded claims will make difficult - due the now lack of confidence on the sources - to detect any still uncovered inherent flaw on the system.

Guys... I have a interesting question about Companies acquiring Companies. In an Incorporated buys a LLC, then strip it out selling or internalizing the assets, and then liquidated it... If that LLC had some royalty, patent or copyright infringement pending to be filed by the offended... Who will inherit the lemon?I doubt that any transgression would just be cease to be prosecutable by acquiring and liquidating the offending LLC... If the company being bought is another INC, there's a difference?

I'm afraid purchasing the KSP¹ IP right now may not be... wise. We don't know what in Krakens is under the hood, and it's evident that TTWO didn't used the due diligence when buying Zynga, what to say about the remaining IP they acquired? Whoever would buy this lemon, will have to deal with it. In PT-BR, we would say: o infeliz que comprar esse abacaxi vai ter que se virar para descascá-lo. Of course, I may be overreacting and it's perfectly possible there's nothing wrong on the IP - but, yet, the license file of KSP¹ is, historically, lacking for mentioning BSD licensed assets but not pinpointing them. Check the LegalNotice.txt file that started to appear on KSP 1.3.x (I had only 1.3.1 installed right now). Important to note that KSP 1.3.0 was released already under TTWO ownership, what is not exactly reassuring... The previous team had way more knowledge (and care) about Open Source, what's can be empirically verified by checking their posts on this Forum until the 1.2.2 era...

Yeah, I just realized that. Tried a fix here: https://github.com/KSP-CKAN/NetKAN/pull/10218 Oh! Already merged! Thanks a lot! Humm... That's a possibility. I'm toying with automation, and rehearsed some new deployments trying to cope with the CKAN rules I learnt this week. I will check it. Thanks for the tip. Acknowledged. 2.4.8.4 is still available, by the way, only 2.4.8.5 is frozen. This will help me a lot to figure out what in hell it happened/I did/Murphy... === == = POST EDIT = == === And, yeah... It was exactly that (see above). My (in development) scripts deployed a new copy of TS 2.4.8.5 with an extra file to identify the source of the download. Double guessing the need for that automation right now. I don't do releases every week, doing it manually is hardly a problem for me...

And this, my friends, it why going Open Source is - at this time - not only the best outcome, but possibility the only successful one. https://www.reuters.com/legal/litigation/ibm-wins-45-mln-verdict-against-zynga-internet-tech-patent-trial-2024-09-16/ and: https://arstechnica.com/tech-policy/2024/09/zynga-must-pay-ibm-45-million-for-farmville-patent-infringement/ Interesting bits: IBM first approached Zynga in 2014, but the at the time management failed to take proper action, and let things develop. TTWO bought Zynga in 2022. And it's probably the reason IBM jumped on Zynga's throat also in 2022 - because they now know someone would have the money too foot the bill. This is about patents, but Copyrights works exactly the same. The owner of the IP have decades to decide to pursue a Copyright infringement, and by then, whoever is the owner of the Company will be the one paying good money in defense and eventually on damages. Such a problem is less of a hassle on Open Source because the Source is open - it's way easier to someone spot something dangerous like something patented by some Really Big Dog, and once the problem is detected, fixing is more than often trivial. TTWO is being cornered, and it's probably the reason they want to sell the whole PD thingy (as well, also the reason no one is buying it). Kraken knows what are under that hood by now, we have more then enough evidences that no everything was handled with the due process diligence there...

Interesting enough, I don't think this is going to happen due TTWO unwillingness to keep this site ongoing. They had a point on the thread @Mr. Kerbin mentioned... it's dirty cheap for them to keep this ongoing, unless adversarial players start to make things harsher for them. Not trying to sweet he pill here, TTWO really dug this hole in which they are now. But they are not the ones still digging. Follow the money.

Dear TweakScale users, By some reason TweakScale entry for the latest release, 2.4.8.5, on CKAN was frozen in the first hours of this day. I don't know what happened, I'm trying to reach CKAN for help: