Lisias

Already made! You can install it alone: https://github.com/TweakScale/Companion_NAP/releases Or you can install it with the Uberpaket (everytying and the kitchen's sink): https://github.com/TweakScale/Companion/releases Cheers! — — POST EDIT — — OUKEY, I had misread the original post!!! (shame of on me ) @kerbmario, I will work on your new parts this weekend! Sorry for the confusion!! https://github.com/TweakScale/Companion_NAP/issues/1

Note to my future self: we handled this one in PVT to avoid cluttering the thread. It was really something else that was updated by CKAN and screwed things.

As you said yourself, it's a CKAN issue. It updated something that broke the game, and TweakScale is the one yelling about the breakage - and not the one causing it. I suggest you to post this log on CKAN thread (after authorising people to download it, as at the present moment I was denied the access) in order to identify the Add'On that is borking - 99% of chances of being the infamous Assembly Loader/Resolver bug being triggered by some missing or wrong dependency from someone else. By searching the KSP.log for Reflection Exceptions, one may diagnose the problem by inspecting the first occurrence of that Exception (it's usually the victim of the problem that triggers the infamous AL/R I mentioned above) - unless you have MechJeb2 installed that due some internal processing ends up changing the order in which things are logged . It's usually easier to temporarily uninstall MJ2 and redo the test do identify the problematic add'on, and when things are tight again installing MJ2 back for playing. — — POST EDIT — — Here, I think I found the problem (I may be wrong, because MechJeb is there): [ERR 01:03:00.860] ADDON BINDER: Cannot resolve assembly: 0Harmony, Culture=neutral, PublicKeyToken=null [ERR 01:03:00.864] AssemblyLoader: Exception loading 'KSPCommunityFixes': System.Reflection.ReflectionTypeLoadException: Exception of ty pe 'System.Reflection.ReflectionTypeLoadException' was thrown. at (wrapper managed-to-native) System.Reflection.Assembly.GetTypes(System.Reflection.Assembly,bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <9577ac7a62ef43179789031239ba8798>:0 at AssemblyLoader.LoadAssemblies () [0x000e6] in <4b449f2841f84227adfaad3149c8fdba>:0 Additional information about this exception: System.IO.FileNotFoundException: Could not load file or assembly '0Harmony, Version=2.2.1.0, Culture=neutral, PublicKeyToken=null' or o ne of its dependencies. File name: '0Harmony, Version=2.2.1.0, Culture=neutral, PublicKeyToken=null' You need to install Harmony.

The only problem I see with this statement is that a less then perfect game is something we already have with KSP¹… People was expecting way too more from KSP2, and I think this is their only really big problem for now (everything else is just going to be fixed as time goes by).

You answered the question yourself. They will not do it just because a random crazy dude sent them an email. The employee receiving it will just delete the email and forget about - Kraken knows how many of the emails I received at day job nowadays are SPAM and go the same way. But now it's not only a random crazy dude, it's some serious bunch of people, some of them influential community members. Additionally, we got a nice brainstorming where the pros and cons of the proposal were discussed, getting a grasp on how to better sell our fish. Sending an email to someone there (as long as we find one that would at least read it) is the final logical step, but never the first. About making plenty of money, assuming this is really happening - how much money more do you think they would make once the worst and more annoying bugs are properly fixed, cleaning up the code base and making at least feasible to repurpose it on new products (tablets, mobiles, whatever - there're wristwatches nowadays more powerful that the desktops that used to run the first versions of this game!)? In essence: we are a bunch of skilled workmanship willing to do some Pro Bono work with our free time in order to get this game tight now. Some people can do it in the shadows, outside this Community and for their own benefit. Some other people prefers to do it in the clear, inside the Community and giving back to it what this Community had given to us in the past. In the end, this is really the only choice to be made: who they want running the Modding Scene? People relying on shady practices or people in compliance with their own EULA? And that's the problem: we don't want another game, we want this one fixed. There're already open source initiatives around, but none of them will remotely open our savegames so we can keep playing them. And this is what really matters in the end for the users. And that's the confusion: we are not pledging a way to create a new KSP, we are pledging legal access to the KSP's source code so we can fix bugs and do a better job on modding it without relying on shady practices in violation of the EULA and Forum Publishing Guidelines and Rules (no to mention some few draconian legislations around the World), and nothing beyound that. Don't you see a problem here? A Community publicly relying on shady, EULA infringement practices in an officially sanctioned Forum? it took me some time to understand "C&D", the result that appeared the most on Google was "Construction & Demolition" But then I found "Creative & Development" and I finally understood. Nope, you are not getting it. The problem on long discussions like this one is that people usually don't have the time neither the patience to read trough all of it and we ended up in a misunderstanding. We do not want to clone KSP. We want legal access (even if limited) to the Source Code (and only to it) so we can do better our job on fixing bugs plaguing users and improving our Add'Ons. We don't want rights over the Creative Assets (meshes, lore, characters, textures, config files, missions, etc), we are not intending to recompile and redistribute the thing. You see, the Source itself is already available on the wild for people that knows how to use certain tools trough shady practices that this Forum consider piracy (believe on me about this one) and so I can't really talk about. But there're people around here (apparently the majority of us) that are not willing to engage on such shady practices, and so the only real way to do a better job on this Scene would be by having legal access to the Source Code, even than a very limited way - we don't need the right to change and redistribute the code, because we are not pledging the right to do derivatives. What we want is the right to legally read the Source Code without risking our SASes by violating the EULA (as well some few draconian legislations as mine) - not to mention this Forum's Publishing Guidelines. The Genie is already out of the Bottle, the Source is already being read by people that don't mind such details. Our pledge is to give us the same right, under EULA and Forum Rules compliance, so we can do a better job without disrespecting such EULA and Forum rules. Additionally, about Development… It's my understanding that game companies relies on outsourcing all the time. Why outsourcing the source code to Open Source workmanship would be bad? Apple did that in the past (Darwin), to say the least…

ANNOUNCE Release 4.2.0.2 is available for downloading, with the following changes: A small glitch on handling Flashing Lights was detected and fixed. A stupid mistake on handling ModuleManager callbacks was detected and fixed. Downloads on the OP. 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. The reasoning is to gradually distribute a potentially Support Fest release in a way that would me allow to provide proper support if anything else goes wrong.

Look for them in the <KSP_ROOT>/__LOCAL/net.lisias.ksp/UbioWeldingLtd/ . There's a small add'on pretty handy, called PartInfo. It shows technical details from the Part on the Part's Palette (or Menu) on the Editor, the directory where the config file is between them. I recommend using it while Welding!

Unlikely. The welding tool (as me) knows squat about FreeIva, if it work it will be by accident! I really don't know how FteeIVA works, so I don't know what to expect. What I can say is the the local coordinates from the meshes will be translated due the new Origin, and so anything relying on them will need to be manually updated. There's also the risk of collisions on the collider's names (I'm guessing FreeIVA knows how to move a Kerbal inside the IVA by using a named collider for reference) and, again, some manual editing may be necessary.

Oukey. found the Windows 10 notebook and installed Epic on the thing. You will find your KSP installation under Epic on: C:\Program Files\Epic Games\KerbalSpaceProgram\English However… It's really not the best of the ideas to mod the default installation directory from a Store (being it GOG, Steam or Epic), because these installers know squat about modding and they may remove or tamper them, screwing your savegames. The best option is to Copy & Paste this directory into some other place (like the Desktop or perhaps a personal games folder in your $HOME, and then placing a Shortcut on the desktop to there) and then modding that personal copy. KSP doesn't have any kind of DRM, so you will not have any problems on doing that. Cheers!

Hi, guys... Since last year, I made a lot of changes on a thingy called KSPe, fixing bugs and getting rid of clutter. And so I remembered this thread and thought it would be a good idea to publish the thing recompiled against the latest KSPe to keep this thing ongoing without a fuss. There's really anything new on this release, only a recompile against the latest KSPe to ensure future compatibility. https://github.com/net-lisias-ksp/UbioWeldContinuum/releases/ As usual, keep in mind that this thing doesn't works with Module Manager (Forum), and so I suggest that you use this on a dedicated KSP installation and then do your main playing on another one using Module Manager (Forum), unless you have reasons to use my fork (there're a few, but nothing that one should consider really necessary). Everything I do supports both versions (Forum and my fork), so you really will not lose too much on sticking on Forum's one if you prefer it. @KspNoobUsernameTaken I think that perhaps this will solve your issue? — — POST EDIT — — ClickTroughBlocker is automatically detected and used by KSPe.UI (used by the WeldingTool) if present. It's not a hard dependency. Toolbar Controller is not needed, KSPe.UI handles the Toolbar itself (with some interesting features added). But it doesn't hurt to have it installed, they coexist together.

Bleh, I didn't gave you the full instructions. Sorry. You need to select "Properties", and then the tab "Shortcut". Take a look on this full tutorial for reference: https://www.addictivetips.com/windows-tips/find-original-file-shortcut/ I think I have Epic installed on some computer around here, I will give this a peek later after day job.

Firing your graybeards can lead to some unexpected results on your business, leading to a decline in your user base - sometimes quite literally. Ask Ocean Gate.

Since the Source is already being used on the wild by shady practices (that are considered piracy on Forum and so I can't name them), the sad true is that they already lost control of it. IMHO opening the Source, even in a controlled and restricted way as Unity does, will only formalize something that's already happening but extending it to people that are still willing to play by the rules. I will say it again: the Source is already available to anyone having the tools and not giving a crap for the EULA and Forum Rules. Our pledge is giving access to it also to people that care about this Game and the Community that formed around it. The best people usually don't like to deal with shady practices! The real value of the Franchise is in the Lore, the Graphic Assets, and this Community! — — POST EDIT — — I think I nailed the text! Found the fonts used on the 1984 Movie (Albertus and ITC Avante Guarde). At least the text looks tight now. There's something to be improve on the Princess image?

New version, slightly more informative. ---- Post Edit ---- I need to.rework the subtitles. It was already marginal on a desktop, but on mobile the central words look like crap.

Ha! I think I kinda did it. Poorly, but I did it! This is what I managed to put together on a Sunday night. Let's see if I managed to do better as the week pass by!

Do you have an Shorcut on your desktop where you launch the game? Right Click on it, it must show you the "target" of the Shortcut.

By doing that you will create new issues on SYD, because you will loose the track of the part as it have it's id "changed" by a reason or another. You need a new tracking method that would detect when the part was cloned and "renamed", otherwise your plugin will be rendered useless when there're living crafts from the same craft file flying around. I'm not making such a fuss just because I'm an idiot, I'm doing it besides being an idiot (because, frankly, only an idiot would be dealing with some <insert your non forum compliant expletive here> "collaborators" instead of doing something else).

THAT specific log. There're some more to compare with. https://github.com/net-lisias-ksp/KSP-Recall/issues/67 Do you want me to fill this thread with tons and tons of logs so your laziness can be satisfied? In a way or another, here: [WRN 17:47:49.979] [ScrapYard] Part mk1pod.v2:FFF7ABE0 has persistentId=4043188831 and it's being changed to 1590504603. The ClassID is 49675735 and the CraftId (cid) is 4294504548. [WRN 17:47:49.997] [ScrapYard] Part mk1pod.v2:FFF7ABE0 has persistentId=1808313221 and it's being changed to 1590504603. The ClassID is 49675735 and the CraftId (cid) is 4294504548. [WRN 17:48:41.567] [ScrapYard] Part mk1pod.v2:FFF7A77E has persistentId=33424378 and it's being changed to 1590504603. The ClassID is 49675735 and the CraftId (cid) is 4294504548. [WRN 17:48:41.580] [ScrapYard] Part mk1pod.v2:FFF7A77E has persistentId=151739214 and it's being changed to 1590504603. The ClassID is 49675735 and the CraftId (cid) is 4294504548. FOUR times the persistentID was changed, and no LogSpam was triggered, on the same log. Interesting, from my point of view it looks like you are cherry picking the pieces of logs I post, and completely ignoring that I posted the logs where the LogSpam happened, between a lot of logs where it didn't (and told about). Should I post them all here? Isn't easier to just check the logs I posted on the issue tracking, looking for a flaw on my Test Sessions, instead of wasting everybody times making assumptions with little to no evidence to support it? If my test sessions are flawed (it happens), pinpoint the source of the flaw. Talk is cheap, show me the code. Besides, as I had said and you conveniently ignored: There's no doubt that SYD is going to be changed. But without understanding why, you will just move the problem to another place and then someone will have to diagnose this problem again. Until I'm convinced that changing the persistentId is really the source of the problem with reproducible evidences, I will keep advocating for looking the problem somewhere else in the SYD's code (or not). AND AGAIN, I'M NOT ADVOCATING TO WORK AROUND IT SOMEWHERE ELSE, I want to understand what's happening and why.. And I was candidly ignoring a detail about this problem: exactly what happens when the LogSpam is triggered? What the real side effects to the game? Memory Leaks? Performance Issues? Savegame corruption? Until this moment, I was focusing on the symptom, because I agree we should be aware about what is happening and why. But if I create a Log filter on SYD and just omit the LogSpam from being written on the KSP.log (what would be a <piiiiii> move, to make it clear, and I do not condone it), exactly what would be the consequences? Because, you see, this may be another case of false alarm, in the same sense that damned ADDON BINDER ERROR that happens when you merely probe if an Assembly is loaded or not.

The MonoBehaviour is always destroyed at the end of a Scene when decorated with a KSPAddon decorator. To prevent it from being destroyed, you need to Instance yours manually (sometimes it can be a good idea) or, better yet, do the following call on the Awake() callback: internal void Awake() { DontDestroyOnLoad(this.gameObject); // The rest of your code, if existent } You NEED to set the once parameter of the KSPAddon decotator to true, or you will have multiple instances of that MonoBehavirour in memory as the scenes changes!

I fear it will not, unless you have something corrupted and mangled that so could be playing havoc at runtime. A Installation Check from Steam would verify the original binaries, and unless you had manually mangled something on the GameData, reinstalling things will essentially end up with the same environment. You can try something: start a new (disposable) game, cheat your way into the same level you have on the "real one" and try to do something similar you are doing on it. Sometimes, installing or uninstalling things on a living savegame can cause some trouble. Doing this test will tell us if this is the case. Additionally, you may want to five this thread a peek: That MONO_THREADS_PER_CPU stunt works, as it appears! (it's a very technical thingy, but in essence, it tells the CPU to run less things at the same time in order to have the ones it effectively run working way faster by less competition to resources).

Useful information, thank you. At 2.4G, you felt a small improvement. At 5G, you didn't felt any difference. So networking is a factor, depending of how your connection behaves. This is surely useful information for people playing KSP on notebooks while commuting or travelling!

Nope, but closing them will save memory and it will make your gaming better in a way or another - and without Internet connection, most of them will be useless anyway. Keep in mind that if you confirm our hypothesis, there're alternatives that will allow you to keep the Internet alive but still prevent KSP from opening connections. What we are doing now is just checking things the fastest and easiest way possible. Once we know exactly what's happening, a better solution will be provided.

Nope. I expect it to run faster, as the connections are all off and nothing will be sent or received. BUT… I can be wrong, so please report your findings.

If my hypothesis is right, probably. But the key factor here is latency, the packets are pretty small so more bandwidth will not compensate a bigger lag while making connections or transmitting data. To tell you the true, I think the best way is to just prevent these connections to happen, so there's nothing to be transmitted at all - and, so, the problem is solved by making it impossible to happen.