Lisias

Strictly and technically speaking, yes. "Linux" is the name of the Kernel, what we are used to call "Linux" among us, users, are technically a "Gnu/Linux" distribution, because it's an amalgam with the Linux (the Kernel) and the Gnu toolchain (bash, gcc, bintools, etc). As a matter of fact, there are some people using the BSD toolchain over the Linux Kernel in some applications - as well as using the Gnu toolchain in other kernels (as Dyson, a distro using a kernel derivate from the OpenSolaris into Debian). Android is an Linux based Operating System, make no mistake about (see it as a Google/Linux distribution). It only happens that Google wrote a huge abstraction layer on top of it, to the point they are trying to replace the kernel with a new custom one (Zircon) on a thingy called Fuchsia.

This is a long term fight, we are not going to get it next week even if we would be exceptionally successful on the endeavour. The first step is to mass promote the idea on the social media, including your personal ones. Twitter, Facebook, GETR, reddit, tiktok, you name it. We need to demonstrate people that if we can do good right now, we would be able to do a lot better having (legal) access to the source code. We need to prove that we are able to help, so P.D. can perceive value on the movement - no Company does things just to be nice (well, Sun did some in the past and then Oracle bought them), they need to earn something on this bargain. Again, see ID Software, that published the sources for Wolf3d, Doom and Quake series and are still rock solid nowadays: every time someone ports Doom to something, they are promoting ID indirectly and keeping the Doom franchise alive. Additionally, "full" (please note the quotes) rights to the Source Code is not mandatory, besides being desirable. P.D. have plans to the future and they may be unsure if Opening (in the OSI conception) the Source will not mangle these plans, so preventing the reuse of the code like Unity does with its licensing terms is still an option. My opinion is that going OSI will not be damaging, they would not be waving the Kerbals as Intelectual Property, no one will be able to (legally) republish KSP and earn money at their expenses - and people are already pirating the game on the wild without (legally access to) the Source, so nothing to loose on this end - and if they release the thing as a GPL-like license, anyone publishing anything using this code will be forced to publish any modification they did on the code, what will help to improve the engine - that may be outdated and even crappy right now, but it still cuts it and so, it's still useful. And by people improving the OSI source code, they will be generating knowledge that will be useful into improving KSP2 in the future (since part of KSP2 had feed from the KSP(1) code), not to mention the console problem right now. By this time, KSP(1) source code is not a technological feature asset per se, is more like a commodity. We aggregate value on it using I.P., and this is sill tremendous strong on KSP. Kerbal is still a thing, a powerful name - no one cares for the code, other than programmers - we care for Jebediah, Valentina, Bill and Bob (and the randomly created Kerbals we acquired on gaming), and they are the real value of the Franchise, not the code. See Linux, anyone can fork and make a derivative, but how many succeeded on it other than Google (and even they had to create a strong name on Android first)? But, yet, we can live for now without KSP going OSI - what we really need is access to the Source so we can understand what's happening and what we need to do on our side to keep this thingy healthy (these are not mutually exclusive solutions anyway, they can go OSI later). Our task, right now, is to promote this idea: that going OSI is not the only option, even by going Unity everybody will still be immensely beneficed (including them), and that we can manage to do it (just look what we managed to accomplish without reading the Source, now imagine what we can do with). It would be interesting to exchange ideas about how to do it. Videos on Youtube and Tiktok? Someone here knows someone on Ars Technica? Do you guys know Slashdot, someone with a better score than me (not to mention a better English) would like to write an article on Slashdot about it?

It's BDArmory, they have a mishap on one of their patches. [LOG 19:51:40.033] [TweakScale] ERROR: **FATAL** Part BDA.EJ200 (TFJ-EJ200 "Typhoon" Afterburning Turbofan) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 Rollback BDArmory to the previous release for while, I heard they are aware of the problem and it should be fixed Soon™ https://github.com/TweakScale/TweakScale/discussions/301

The real issue if that Module Manager is being instantiated twice (or even more). If only one copy of ModuleManager would be in execution, the situation in which it would try to compute the SHA for a given file in different threads would just not happen. Having multiple Module Managers running at the same time on the rig is terrible, with some patches ending up being corrupted (by some reason, the Localization ones are specially prone to the problem). I had said before, and I will say it again: there must be only ONE Module Manager running in memory, and without solving this problem, people will still be screwed by bad patching happening randomly across the system. Once you secure only one ModuleManager running at a given time, you don't need to scramble patching every single place where code that was meant to run solo subtly is facing concurrency with itself.

Hi! You was bitten by a nasty internal KSP bug on a thingy called Assembly Loader/Resolver - this bug is triggered when something tries to load a dependency and fails, and from this point, everything and the kitchen's sink gets screwed when trying to load a DLL or use a thingy called Reflection, that is exactly what TweakScale and the Companions do a lot. In your case, the problem is ScrapYard_ContractConfigurator.dll. You probably don't have Contract Configurator installed, and so it's failing to be loaded, and the AL/R bug is triggered. Install Contract Configurator or delete GameData\ScrapYard\Plugins\ScrapYard_ContractConfigurator.dll and you will be fine. Cheers.

Well, CKAN problems should be reported to CKAN themselves, as I don't have control about how they do things there. All I can do is try to do a preflight check about what their robot is doing and save some time. The NetKAN file looks good: https://github.com/KSP-CKAN/NetKAN/blob/master/NetKAN/DistantObject.netkan My repository is online: https://github.com/net-lisias-ksp/DistantObject/releases And the meta files are fine too: https://github.com/KSP-CKAN/CKAN-meta/tree/master/DistantObject https://github.com/KSP-CKAN/CKAN-meta/tree/master/DistantObject-default In special: https://github.com/KSP-CKAN/CKAN-meta/blob/master/DistantObject/DistantObject-v2.1.1.12.ckan https://github.com/KSP-CKAN/CKAN-meta/blob/master/DistantObject-default/DistantObject-default-v2.1.1.12.ckan So, nope. CKAN itself is looking fine. Perhaps SpaceDock? https://spacedock.info/mod/2274/Distant Object Enhancement / Humm… Nope, it looks fine too. I tried a direct download using the download link from the CKAN file, https://spacedock.info/mod/2274/Distant Object Enhancement /L/download/2.1.1.12 , and it worked too. So I don't have the slightest idea about what could be happening, but it looks link something on the CKAN application itself. You will need to reach CKAN guys for help.

Hi. Recently, a mishap on BDArmory injected a double patch problem that was flagged by TweakScale. Since you have BDArmory installed, I'm betting this is your case. Try to rollback BDArmory to the previous version and see what happens, it worked for some people. https://github.com/TweakScale/TweakScale/discussions/301 Additionally, posting the KSP.log is way better than the mod list - in 95% of the times, the KSP.log have enough information for diagnosing the problem without the need of reproducing your installment and firing up KSP, what saves a huge amount of time. In this case, I was able to (probably) quick diagnose your problem because I have a flood of other people with this problem. Anyway - the solution is to rollback BDArmory to the previous release for while - and don't forget to file a bug report for the BDArmory's manintainers if it works for you. If it didn't solve your problem, publish your KSP.log and I will inspect it! Good luck!

There's an ongoing battle on reddit. The OP's post there is being continuously upvoted and downvoted! It reached 10 upvotes somewhere in the morning, then got to 5, then upvoted to 8, now is on 5 again. Apparently we had hit some nerve… @WhatALovelyNick, you earned one week on the r/lounge. It's nothing special, other that frequented by very fewer people. Perhaps you could get more traction there, with less people trolling you? Click in your Profile Picture top right in the page (on Desktop), then Account Settings on the DropDown Menu, then Signature on the Left Panel. — — Post Post Edit — — Now it's on 8 again! Now it's on 5! Now it's on 4! Now it's on 6! Now it's on 9! Now it's on 8 again! I may not look like, but the thing is kinda on fire - lots of people downvoting and upvoting the thing - each reload is a new score!

Sometimes nothing happens, sometimes you get royally screwed, sometimes even KSP goes to a CTD - it depends on what parts is being double patched and what PartModules it uses. Since it's impossible to write a code that could analyse every single combination (not to mention being aware of them before they happens!), the less worst solution is to bark on every double patch being found. I agree it's a pain in the SAS, but it's better than losing your savegames. Even by doing backups, you lose your progression since the last one so it's still an annoyance. Well, back to business: this is the list of patched being applied to the offended part: [LOG 10:54:24.953] Applying update 999_KSP-Recall/patches/fundskeeper/@PART[*]:HAS[!MODULE[ModuleAsteroid],!MODULE[ModuleComet],!MODULE[KerbalEVA]]:NEEDS[KSPRECALL-FUNDSKEEPER] to BDArmory/Parts/EJ200/caesar_hone_60.cfg/PART[BDA_EJ200] [LOG 10:54:25.109] Applying update 999_KSP-Recall/patches/refunding/@PART[*]:HAS[!MODULE[ModuleAsteroid],!MODULE[ModuleComet],!MODULE[KerbalEVA]]:NEEDS[KSPRECALL-REFUNDING] to BDArmory/Parts/EJ200/caesar_hone_60.cfg/PART[BDA_EJ200] [LOG 10:54:25.279] Applying update 999_KSP-Recall/patches/stealbackfunds/@PART[*]:HAS[!MODULE[ModuleAsteroid],!MODULE[ModuleComet],!MODULE[KerbalEVA]]:NEEDS[KSPRECALL-STEALBACKFUNDS] to BDArmory/Parts/EJ200/caesar_hone_60.cfg/PART[BDA_EJ200] [LOG 10:54:25.577] Applying update BDArmory/MMPatches/000000_HitpointModule/@PART[*] to BDArmory/Parts/EJ200/caesar_hone_60.cfg/PART[BDA_EJ200] [LOG 10:54:26.380] Applying update BDArmory/MMPatches/BDA_battledamage/@PART[*]:HAS[@MODULE[ModuleEnginesFX]] to BDArmory/Parts/EJ200/caesar_hone_60.cfg/PART[BDA_EJ200] [LOG 10:54:26.601] Applying update BDArmory/Parts/EJ200/caesar_hone_60_TS/@PART[BDA_EJ200] to BDArmory/Parts/EJ200/caesar_hone_60.cfg/PART[BDA_EJ200] [LOG 10:54:36.352] Applying update SimpleRepaint/Patches/SimpleRepaint/@PART[*]:HAS[~SR_Ignore[]]:FOR[zzzzzzSimpleRepaint] to BDArmory/Parts/EJ200/caesar_hone_60.cfg/PART[BDA_EJ200] [LOG 10:54:36.595] Applying update SimpleRepaint/Patches/SimpleRepaint/@PART[*]:HAS[~SR_Ignore[],~SR_RepaintType[]]:NEEDS[B9PartSwitch]:FOR[zzzzzzSimpleRepaint] to BDArmory/Parts/EJ200/caesar_hone_60.cfg/PART[BDA_EJ200] [LOG 10:54:37.302] Applying update SimpleRepaint/Patches/SimpleRepaint/@PART[*]:HAS[~SR_Ignore[],#SR_RepaintType[B9PS],#SR_MaterialMask1[*]]:NEEDS[B9PartSwitch]:FOR[zzzzzzSimpleRepaint] to BDArmory/Parts/EJ200/caesar_hone_60.cfg/PART[BDA_EJ200] [LOG 10:54:51.930] Applying update SimpleRepaint/Patches/SimpleRepaint/@PART[*]:HAS[~SR_Ignore[],@MODULE[ModuleB9PartSwitch]:HAS[#moduleID[SimpleRepaint]]]:NEEDS[B9PartSwitch]:FOR[zzzzzzSimpleRepaint] to BDArmory/Parts/EJ200/caesar_hone_60.cfg/PART[BDA_EJ200] [LOG 10:54:52.744] Applying update SimpleRepaint/Patches/SimpleRepaint/@PART[*]:HAS[#SR_RepaintType[*]]:AFTER[zzzzzzSimpleRepaint] to BDArmory/Parts/EJ200/caesar_hone_60.cfg/PART[BDA_EJ200] [LOG 10:54:52.940] Applying update SimpleRepaint/Patches/SimpleRepaint/@PART[*]:HAS[#SR_WhitelistOnly[*]]:AFTER[zzzzzzSimpleRepaint] to BDArmory/Parts/EJ200/caesar_hone_60.cfg/PART[BDA_EJ200] [LOG 10:54:53.219] Applying update KSPCommunityFixes/MMPatches/ModSupport/KSPRecall/@PART[*]:HAS[@MODULE[Refunding]]:LAST[999_KSP-Recall] to BDArmory/Parts/EJ200/caesar_hone_60.cfg/PART[BDA_EJ200] [LOG 10:54:53.561] Applying update KSPCommunityFixes/MMPatches/ModSupport/KSPRecall/@PART[*]:HAS[#hasRefundingOnRecovery[?rue]]:LAST[999_KSP-Recall] to BDArmory/Parts/EJ200/caesar_hone_60.cfg/PART[BDA_EJ200] [LOG 10:54:53.900] Applying update KSPCommunityFixes/MMPatches/ModSupport/KSPRecall/@PART[*]:HAS[#hasRefundingOnRecovery]:LAST[999_KSP-Recall] to BDArmory/Parts/EJ200/caesar_hone_60.cfg/PART[BDA_EJ200] [LOG 10:54:54.145] Applying update 999_KSP-Recall/patches/attached-on-editor/@PART[*]:HAS[!MODULE[ProceduralPart],!MODULE[WingProcedural],!MODULE[ModuleAsteroid],!MODULE[ModuleComet],!MODULE[KerbalEVA]]:LAST[KSPRECALL-ATTACHED-ON-EDITOR]:NEEDS[TweakScale] to BDArmory/Parts/EJ200/caesar_hone_60.cfg/PART[BDA_EJ200] KSP-Recall and KSPCommunityFixes don't touch TweakScale, so we can rule them out for sure. So we have BDArmory itself, or SimpleRepaint as possible suspects. Temporarily remove SimpleRepaint and see if the problem goes away. If yes, then file a bug report to SimpleRepaint maintainers, as it has somehow a buggy patch on it involving TweakScale. On the other hand, if by removing SimpleRepaint you still get the problem, then the only remaining suspect is BDArmory itself, and then you need to reach them to file a bug report and ask for the fix. Where the fix is to look on their patches and remove the double patching - the log excerpt above tells exactly what are the possible offenders, so I think they can zero in the culprit pretty fast! Let me know when the problem is solved! — — POST EDIT — — Another Kerbonaut have the same issue, reported on github. The only add'ons you and they have in common is KSP-Recall (that doesn't applies TweakScale patches, so it's ruled out) and BDArmory itself on the following patches: BDArmory/MMPatches/000000_HitpointModule/@part[*] BDArmory/MMPatches/BDA_battledamage/@part[*]:HAS[@module[ModuleEnginesFX]] BDArmory/Parts/EJ200/caesar_hone_60_TS/@part[BDA_EJ200] I think we can declare BDArmory as the current main (and only) suspect!

A image with Valentina dressed as the Princess would be nice, no?

Sure thing! As soon as someone send me the KSP.log so I can check the patches and see what's happening!

Spreading the word in the social networks. Twitter, Facebook, TikTok, you name it. Giving some awards on the reddit will also help the cause. — post edit — The Source must flow!!

Something is double patching your GameData. Send me your KSP.log as well your ModuleManager's patch log and I will diagnose the problem. In time, this is not a TweakScale problem. TweakScale is the one telling you about the problem.

It originally intent to meant that the installation was faulty and something was forgotten to be copied, but then we found a bug on KSP on a thingy called Assembly Loader/Resolver - a component responsible for loading DLL and resolving dependencies. The bug is that once anything fails to be loaded (by absolutely any reason, from missing dependencies to borked DLLs), it triggers this bug and from that point, everything else trying to be loaded fails too no matter what - it's terribly annoying. CKAN makes things worse because they don't really have a proactive approach on QAS, they just reacts when people complains - not rarely blaming the wrong author for the problem, what ends up perpetuating it. So, back to your problem: if TweaakScale is installed correctly (an 99.9% of the times, it is), then CKAN updated something that broke a 3rd party that leades to the AL/R problem, that screwed TweakScale that so is yelling about the problem - and make no mistake, it's not only TweakScale being affect, but everybody else (it only happens that TweakScale prefers to alert you instead of making believe nothing is happening and letting you get screwed later on the savegame). You will find the trigger for the problem (not necessarily the cause of it) by looking for every occurrence of a Reflection or Loading exception in your KSP.log. If you don't have MechJeb installed, the first occurrence will pinpoint the cause - you will need to diagnose it or to remove it. With MJ installed, things get a bit messy because MJ do some things internally that ends up shuffling the order in which things are logged on the KSP.log, I found that it's easier to temporarily remove MJ to reproduce the error without the shuffling, fix the problem, and then install MJ2 back instead of trying to figure out where the problem ends up going when MJ2 is installed. Alternatively, you can post your KSP.log here (without MJ2 installed, please - reinstall it later when fixed) and I will do the heavy lifting for you! Cheers!

If we are talking about the issue reported here: Then you need to remove GameData/TweakScaleCompanion and then reinstall it. TweakScale is not the problem, it the one telling you about the problem. The previous TSCo was shipped with a faulty component, that I removed on the ..4 release, and so you need to completely remove the TweakScaleCompanion folder in order to be fine. Remove TweakScaleCompanion this time and try again. If anything goes south, you will find the KSP.log on the same folder the KSP's .exe is. You will find further instructions on this link.

Completely remove all the TweakScaleCompanion directories and files, then install the latest one - a faulty component was removed, and if you just install the new one over the older, the faulty component will still be there. If by completely removing the older contents before installing the new release the problem is solved, then you found a problem on CKAN. Otherwise, post the KSP.log on the TweakScale's thread and I will inspect it. Cheers!

We need every single bit of help possible, and yours will be hugely appreciated! Thank you!

No, it's just how reddit works. You need time to get traction on a post there, and in the mean time, you need help to prevent people from downvoting you enough to remove you from the main page. You need help to upvote your post to counter-measure the downvoting from the trolls. The trick is to monitor the voting count, and every time it reaches 0, someone upvote to get it positive again. Lots of people upvoting preemptively not necessarily helps, because all the trolls need to do is to use their ghost accounts to downvote and the work is undone. The trick is to upvote gradually, just enough to get to 1, and then start monitoring again until the trolls attack again - rinse, repeat.

It's a way out of the problem, probably the best. But this would involve expending resources that, at this time, I don't think they have available - I don't think they have even a budget to hook these expenses right now. This kind of OpenSource may get expensive to run, you need skilled people available to code review the pull/requests - you become responsible for every commit you merge in your repository (and, yeah, there's always a risk on merging ARR code into your ARR code). I had already said it in the past (premonition!!! hehe), one of the best examples of a ARR code base going Open Source is the Netscape, not only due the huge success they had in the past, but also due the major screw ups they had to survive - and, boy, they had a steep learning curving to cope with! And since I really doubt they would release the code under a OSI license (what, frankly, may backfire on them later), allowing pull-requests into an ARR code may be legally tricky - not impossible, tricky. And this may be a one trick more than are willing to handle at this point. P.D. is in a messy state, whoever is trying to cleaning it up need to be careful to do not add yet more burdens to their shoulders. Having the source code in an archived/read-on git repository (it may be bitbucket, it may be gitlab - you know, this CoPilot thingy is really a concern for everyone willing to publish code on github!!) [edit] under an Unity's style Share Source license [/edit] will be, by itself, a huge difference for the best by itself. Even by not being able to apply patches, being able to clone it into a local repository and submit the codebase to some tools (or even compile it under debug mode and firing it up) will by itself be of a huge service. At very least, will make my work on Recall insanely easier and safer - and this is only me, just imagine what the others Authors may be able to accomplish - from Waterfall to Principia. Make no mistake, I would love your solution - but IMHO we need to aim first into the ones they may manage to afford. You can always go further later, these are not mutually exclusive alternatives. But, in a way or another, this is not a decision to be made lightly.

I'm afraid it was, sadly. [snip] From now on, I'm afraid the best line of action is to mutually ignore each other. [snip] Have a nice day.

Sir, you are completely misguided. We are not free cheap work-force that will drive all the work for them. You don't need to rewrite the entire game, the absolutely most terrible bugs are rooted on silly mistakes and mishaps on the code - and a few bad decisions, granted. I'm seriously questioning your ability to keep this discussion productive, you really appears to do no understand about what you are talking about. Some of them, yes. Some others, are rock solid as soon as you detect where KSP is breaking them and work around the problem. There are more things in heaven and earth, Horatio, Than are dreamt of in your philosophy. There are different ways inside KSP to accomplish some things, including how to deploy some really deep fixes. I had detected them in the past, but never managed to understand how they work precisely by not being able to see the Source Code without breaking Forum's Guidelines and the EULA. Really, you need to stop thinking that every add'on Author is a kid trying their way to see what happens. There were (and still are) very skilled professionals around here, and that's the reason it's important to do some things right (as access to SC) - because professionals can't break the law without consequences to their day-jobs.

You are not well acquainted to the KSP Modding Scene, are you? Such affirmation from someone out there that never had played KSP before is understandable, but from someone that its a frequent user on this Forum, it's quite hard to believe that you had said that. KSP is highly modular. There're a lot of things that can be made to work around almost all flaws on it - all of them way easier to accomplish when we have access to the SC and know exactly what's happening, instead of taking days on black box test sessions in order to finally nail down some ancient bug that nobody was able to detect before. There're a lot of internal mechanisms that we don't know exactly how they work, and once we manage to get a grasp on it, will help us a lot to accomplish exactly what you said is not accomplishable - and following the Forums' Guidelines and the EULA.

nasty, perhaps. But it's effective? Some pills are bitter to swallow, but they still are the pill to cure us. As far as I know, it is. Patching is the only choice. We are not the publishers, we can't just recompile the damned thing and republish it ourselves. They had years to fix things. They didn't. It's time to @HarvesteR what they had sowed.

Perhaps we should try reddit? No one is proposing rewritting KSP1. The goal is to patch its flaws and give the Franchise a bette chance on the short term. There's life everywhere else - ESA has teamed up with Jundroo to launch a ESA mission inspired update for Juno:New Origins. Do I need to say more? The time is now. Tomorrow is too late.

Not only that. They are, right now, on the verge of a Strategic Inflection Point. [snip] We are asking that such privilege be extended to people that does mind Forum's Publishing Guidelines and the EULA. Whatever is their decision about this subject, will shape the people that will be around here publishing add'ons for the Community. This may change with more skilled people with real experience on handling and refactoring legacy systems being able to help. If we can manage to fix KSP(1) properly, without risking our SASes on shady practices and being able to see in situ the effects of what we do, we may give the Franchise some air to breath, what will increase the KSP(1) incoming, that so can be injected into funding KSP2. They get some skilled QAS being able to do their magic easier and quicker, and we finally get the game we had paid for for starters. A good bargain, if you ask me - this will be a real improvement on the status quo. Of course, there will be drawbacks - there're always drawbacks. Perhaps one of them may hinder the endeavour - but, hell, really big guys did it in the past, and still do it and it also will help to detect unduly use of the reversed engineered SC that it's already in the field. The benefits may outweigh the risks by a mile if things are done properly. This will not solve all T2I problems, no doubt. But every surviving mosquito lay eggs that leads to more mosquitos - we don't clean up our houses to completely kill all the mosquitos of the Word, we clean our houses to keep them in an acceptable level.