Lisias

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:

Hi! I just noticed that TweakScale 2.4.8.5 was frozen due "bad downloads". Why? https://github.com/KSP-CKAN/CKAN-meta/commit/311b881c565bb81c491ef60d87149bf7e7c21412 https://github.com/KSP-CKAN/CKAN-meta/commit/be401b1c2d078188c6ba858c3c29d1f540b32e38 The SpaceDock download is fine, it is working perfectly yesterday, see: and I downloaded it from there right now with success... What we can do to fix this problem? === == = POST EDIT = == === Since the freezing happened only on 2.4.8.5, releasing a new one will fix the problem?

No, I'm not! [famous last words...] [LOG 22:35:00.068] Load(Assembly): TweakScale/plugins/TweakScale_Waterfall [LOG 22:35:00.068] AssemblyLoader: Loading assembly at D:\KSP Directories\HeavyModded\GameData\TweakScale\plugins\TweakScale_Waterfall.dll [LOG 22:35:00.082] AssemblyLoader: KSPAssembly 'TweakScale_Waterfall' V3.2.3 [LOG 22:35:00.083] AssemblyLoader: KSPAssemblyDependencyEqualMajor 'Scale_Redist' V3.2.3 [LOG 22:35:00.083] AssemblyLoader: KSPAssemblyDependency 'Waterfall' V0.0.0 [LOG 22:35:00.083] AssemblyLoader: KSPAssemblyDependency 'HarmonyKSP' V1.0.0 Humm... Wait.... [LOG 22:35:36.836] [TweakScale] Version 2.4.5.1 /L Oh, crap... I didn't paid enough attention, sorry @Ymmit34!!! === == = TRYING AGAIN = == === @Ymmit34, please completely remove GameData/TweakScale from your GameData, including GameData/999_Scale_Redist.dll and then reinstall TweakScale from one of the sources below: on CurseForge. on SpaceDock (for CKAN users) on GitHub (and KSP-AVC users) You almost surely will want to install the Companions too. Get the ÜberPaket from: CurseForge SpaceDock (for CKAN users) Github Since you are doing manual installings, it's advisiable to install also the ModuleManagerWatchdog thingy that is also on the same distribution file you will get TweakScake. This will fix your issue.

Sorry, dude, wrong tree! [LOG 22:35:00.046] Load(Assembly): TSSafetyNet/TweakScaleSafetyNet I'm not the author of the fork you are using. === == = POST EDIT = == === Nope, the problem is this old dog getting older. Please see below.

Oh, dear.... So CKAN literally changed how things works on purpose? (sigh) Anyway. I hope this pull request fix things for me at least: https://github.com/KSP-CKAN/NetKAN/pull/10216

Indeed, we are not dead yet. This confusion happened due this commit on CKAN-META at Sep 8th: https://github.com/KSP-CKAN/NetKAN/commit/f273da29e2ba472c529dae6c777a7c57b67db651 (due the recent SpaceDock outage). But since most CKAN users didn't updated to the last CKAN, this change ended up masking the stats on some add'ons on SpaceDock by diverging the downloads to github inadvertently. [sigh] CKAN users, please update to the latest CKAN as advised here:

Never mind. It was a change on CKAN that I wasn't aware. My apologies, @VITAS.

I do gradual deployments. GITHUB for the reasons I already explained CurseForge for users still there, and this helps me to iron out eventual mishaps that I may let pass trough. Finally, if no one complains until the moment, I publish on SpaceDock to be available to CKAN users. Very rarely I publish everything at once - usually hot fixes. This helps me control the deployment on the wild, preventing a tsunami of support tickets by wetting my feet first on smaller userbases. Well, essentially all what I publish are there, so I don't really need (neither desire) using github for this,

Because this is screwing my pipeline. The packages distributed on GITHUB are meant for early adopters that wish to help me smoketest the damned thing before it reaches the masses, and to myself be able to easily deploy the thing on my test machines without needing to configure yet another repository. GITHUB releases are not meant to be CKAN safe, only what I deploy on SpaceDock is meant to be used on CKAN. I will enforce this on my next releases. In time, what happened with https://archive.org/details/kspckanmods ? CKAN wasn't supposed to rely on it?

How? Where? What?

How I prevent CKAN from downloading from github?

Oh, so it was that. I stand corrected on this one. But, the removal of the PD Launcher would demand someone there to push the button, no?

Sure thing! I think we need to involve @JewelShisen if we will change or add something into the base partset, BUT... We called it HL Airships Core for a reason: to allow Expansions to be easily created using Core as dependency. So, in a way or another, I will more than glad into assist you!

Curiously, what you said above is also used to describe some criminals... Emphasis are mine. Source: https://ccjls.scholasticahq.com/api/v1/articles/317-the-decision-to-commit-crime-rational-or-irrational.pdf Hedonism. I had forgot about this word...

Given the current status quo, it would be wiser to get written consent first...