Lisias

Damn. Pasted a broken link! Fixed! But here it goes the same (youtube doen't allows embedding anyway): https://www.youtube.com/shorts/IakABYfTsAQ

Things change, people are replaced, golden gooses die. Sooner or later someone that doesn't have anything to hide neither to loose will remember this (or a similar thread) and will reach to the same conclusion as me: that there's nothing worthy left to be lost, and many possible things to be gained on this stunt. Nothing is risk free - but sooner or later, there will not too much things left to be risked. And we are significantly near this point today. Heck, Classic Tomb Raider are being sold in PHYSICAL MEDIA! And they would not had managed to do that in a cost effective way without open source - see who they hired to the job (hint: Open Lara). Someone, somewhere, still owns this IP and is willing to get some bucks back. It's a matter of time until this person decide to play again Tomb Raider (what they almost surely did when a teenager) and then connect some dots. And if they don't do it, someone else will do it at their expenses - and then someone else will profit with it. People are not respecting the EULA today, what do you think will happen in 6 to 12 months?

I think they are. If you are talking about machine code, two consecutive jmps will, well, take twice the time of a single jmp. Worst case scenario, a patch is a chained sequence of jmps, 4 to be more precise (the original one replaced, the prefix, the patch, the postfix). Perhaps 3, if the prefix and postfix are used as decorations for the patch, instead of of the patch being a call in the middle of the two other calls. For anyone else not understanding, in ASM it would be something like: METHOD_BEING_REPLACED: <some boiler plate> CALL METHOD_BEING_REPLACED_PREFIX CALL METHOD_BEING_REPLACED_BODY JMP METHOD_BEING_REPLACED_POSTFIX ; Optimization, using the POSTFIX RTN to return to the caller Or perhaps: METHOD_BEING_REPLACED: <some boiler plate> CALL METHOD_BEING_REPLACED_PREFIX <the method being replaced body> JMP METHOD_BEING_REPLACED_POSTFIX ; Optimization, using the POSTFIX RTN to return to the caller On the best case, we have 3 extra JMPs: the CALL to prefix the respective RETURN, the JMP to the POSTFIX The return on the POSTFIX doesn't counts, as the original method would had used one the same So a patch would spend 4 jmps to make the same job of the original 2. Or twice the time. And I need to remember that JMPs screws the CPU's pipelines. And that consecutive JMPs screws the CPU's pipelines consecutively. Obviously, this on the x86 machine code level. Kraken knows what the CLR is doing with the CIL code. So perhaps we would just need a better clarification about what's "actual code instruction"?

Nope. It's also a (estimated) 80 Millions USD investment that gone down trough the tubes.

You don't imagine how many projects I had seen dying due egotrips from someone in charge. Some people prefer to let the plane crash (even when they are on the ride, but most usually they aren't) than to help a pilot they don't like. Secrecy is the excuse some use to accomplish their real, underlining intent. It's absolutely appalling. Pathological Narcissism are the root of all the Humanity's evils. Hanlon's Razor proposes to "Never attribute to malice that which is adequately explained by stupidity." - but sometimes we just run out of options. IMHO there're really few now.

Given recent discoveries about the current zeitgeist: I want to say again: going Open Source (really Open Source now, as the future appears to be somewhat bleak right now) is the best outcome possible for the franchise, the current IP owners and for the future of the KSP Community.

Something everyone should be aware off! https://www.youtube.com/shorts/IakABYfTsAQ (damn... you tube doesn't allows embedding of this video...)

Hey, if it works, it works!

Because it is. The immensely supportive modding support from KSP¹ was a huge source of headaches for him, but it was also one of the key factors that made KSP¹ the huge success is was (is?). Now, compare it with what was done on KSP2: besides not being a error from the managerial (and probably technical) point of view (as modding causes a lot of friction on the development cycle, just see how things developed on the KSP¹ times and see for yourself), from the P/R point of view was a huge disaster - they essentially let 3rd parties break the EULA to publish a toolkit that, frankly, didn't fell in the hearts of most of the existing modding scene, managing to alienate exactly what helped to made the sequel a success. So, in a nutshell, besides being initially a Good Idea© to postpone mod support, the tragic launch and the stupidly huge delay on publishing something that would be barely usable ended up alienating the dev team from working modding support in an acceptable time frame - and an official modding support was one of the main complains of modders from the prequel. TL;DR: KSP2 managed to liquid off everybody, from players to modders. Modding Support on KSP2 is one of that weird and bizarre situations in which you got royally screwed up by doing the Right Thing®. KSP¹ (by reasons beyound the scope of this post) is one of the yet more weird and rare situations in which not doing things "right" was the key for the success. @HarvesteR may just had plain luck on the situation, but it's undeniable that he was capable enough to harvest (pun really intended) the opportunities presented to him and seize the day. Again, I still agree with your underlined argument - that @HarvesteR probably is not the right guy to lead an AAA project like KSP2 is now. He's more than capable from the development point of view, but he have no previous experience on handling the management duties, the heavy politics and internal drama that an AAA project brings with (I don't want to mention people trapped behind NDAs, but I'm pretty sure you understood who I'm talking about). I not only agree with you here, but add that this would probably destroy his career (or, at very least, his will to keep pushing on it). HOWEVER. We are missing a very, very interesting point... You see, KSP2 does not need to be handled as an AAA project. Build it as an Indie Project with deep pockets, shield @HarvesteR from unrelated activities he's not seasoned to handle, and suddenly you will see that we still have a viable project to carry on. And, with a bit of luck, a very successful one. KSP¹ was a huge success not only besides @HarvesteR's mistakes - it was a huge success exactly due some of them. Some people just have this touch, smart people learn how to cope with them and work together. Not so smart people try to mimic them, perhaps believing that there are time enough in the Universe to apply the Infinite Monkey Theorem on game development.

Well, since you asked it... When you have a large codebase, having patches jumping between a far address and back will screw the L0 and L1 caches of the CPU. Every time the cache have a miss, it needs to reach the main RAM (some orders of magnitude slower) to fetch the instructions (thanks Turing there're separated caches for data and instructions nowadays), and this makes the CPU halt for some cycles waiting for the data. The bigger the original codebase, far are being stored the patches compared with the code being patched, and more cache misses you will have. The Harmony's site have a nice explanatory graph about the anatomy of a patch: See? The original code will be on a basket of bytes glued together by the compiler, and the Assembly Loader will load that basket on memory after doing some more gluing (link edition). Then Harmony goes there and switch the address of some methods to pinpoint another address, that will hardly be near the original code - we call this a "far jump". A code that originally was a loop making near calls may perform drastically different if one switch the address to a far call, depending of how much L0 and L1 cache the CPU have to play with. But KSP runs on a virtualmachine called CLR, and this thing when "transpilling" CIL (the bytecode in which C# is compiled into) into x86's machine code (the thing the CPU really understands) does some optimizations that may influence the problem for the better (or for the worst - this is where some profiling would help, but not on the high level as being advocated here). On some virtual machines (and now I don't really know if Mono does that), having memory to spare means that the vm can transpile the bytecode code into different x86 "versions", each one optimized to one circumstance (at least the JVM does that), and this would allow the code to use the best possible "version" on a given time. Again, I do not know Mono enough to know if it does that - but if it does, patching the code may mask the caller in a way that would make the transpiler take an less optimal decision, again influencing performance. There is another possible explanation for things happening this way on my rig: not only my i7-3610QM processor have "only" 6MB of Cache for the 8 Threads (4 Cores) that are heavily disputed by everything and the kitchen's sink on the machine, but some years ago Apple royally screwed up performance on this machine when they mitigated the Meltdown and Spectre security flaws on Intels with hyperthreads (like my i7-3610QM). You will find me complaining about on this post (and on this one, and this another one - yeah, this bit my SAS badly). This mitigation is applied on the Firmware that does the hardware initialization, and so AFAIK it's impossible to deactivate it, and so MacOS machines using affected processors will behave differently than any other rig using the same processor but that is not being mitigated (Linux machines have the option to turn it on or off!!). This may be the explanation for the weird behaviour of KSPCF on my MacMini 6.2. And since I didn't knew (as I still don't) if your rig have or not an affected CPU (as you only said it's a potato, and not exactly what flavor of potato), there was a reasonable chance of you having an CPU that is affected like mine, and that a similar mitigation could be in effect for you too. Or not! And this is also why (only) profiling this machine will not help. You need to benchmark it with similar rigs where the Meltdown and Spectre are not mitigated in order to rule out the CPU from the equation. And it's also the reason I said to go on and try KSPCF the same - worst case scenario, you would have the same performance as me, but would still have the other features that could help you with. === == = POST EDIT = == === For the sake of curiosity, I noted a reduction of 30 seconds on my tests from the 23th (today), without: [LOG 13:54:12.325] [ModuleManager] INFO: Total loading Time = 234.368s. with: [LOG 13:31:02.376] [ModuleManager] INFO: Total loading Time = 203.560s. Or about 13% better loading times. It's something, but not exactly a miracle. 3.9 min vs 3.39 min. The 22th numbers are completely screwed... The rig with KSPCF took about 900s to load, while the rig without took 218 (even faster than today). This is completely off, had I noticed it before I would had discarded the Test Run and made another - Kraken knows what MacOS was doing at that time under the bonnet...

Hey, it's me! Mario... Uh... Lisias! Is @jost in the house?

And I never claimed I was. I was answering to the user, not to you. What I was doing is a Benchmark. Really, could you please put your ego aside stand down a bit? How about opening a new thread and avoid derailing this one?

I mean... An old Mac Potato is dirty cheap nowadays. You don't have the financial means to acquired one? You see... I have a Windows 10 notebook, a MacPotato (well, two) and a SteamDeck to do tests - with the SteamDeck having the additional benefit of being... a Steam Deck! You should try it. Testing andp rofiling mods only on Windows is a huge disservice to your users.

Well, I did. The files are on my Google Drive. WITHOUT KSPCF: WITH KSPCF: KSPCF's stil presents some "jerkyness", but the average FPS (what really counts) didn't changed. However... You still have a point. My second run on WITHOUT KSPCF looks slightly smoother, so it's a change - not to mention that I have a big "bump" here now. Interesting enough, it also happened on WITH more or less a the same time - so we have some determinism, this is not 100% chaotic. Thinking about, I concluded that this is environmental. I was wondering about what could caused the bump on "WITHOUT" when I noticed the Notifications icon on the Forum's page going red on the secondary monitor, and clicked on it. And then that little bump on "WITH KSPCD" happened (the first one, after the first FSP ascension). And so I think we have some evidence that these bumps may be related to the Garbage Collector, as other process requested memory and the O.S. granted it, shrinking a bit the physical RAM available to KSP and triggering the GC. Right now is a guess, this is where we would need a better profiling tool to graph not only the FPS, but also what GC is doing. This also hints that what I identified as "jerkyness" on "WITH KSPCF" may be related to KSPCF being a bit more memory concerning, triggering the GC regularly - what would be a better idea than letting the HEAP to be clobbered before triggering the GC - better a slightly lower FPS all the time than regular stutterings.

Because this is how users evaluate performance. And since it's an user asking questions, this is exactly how I answered them. So you are telling me that I'm in fault with the Trueness when I said (and I quote myself): Emphasis are new. Thanks for clarifying it. Now, now let's try to reproduce the tests on a Potato machine, like mine and @anis? In time, could you please publish the logs of that test run, the same way I did, so I can compare these results? Not exactly a good comparision, because you have a better GPU and half the memory. [edit: wrong! It's an excellent comparison, because it's showing differences between machines of the same class with slightly different configurations] Additionally, did you used my settings.cfg? If not, you didn't reproduced my Test Session. That settings are the settings I use to play 1.12.5 on my Potato, and besides I doubt it would be the same settings @anis is using now, depending on how potato is their machine, they should consider. But since it was used on both Test Sessions, the negative effects nullified themselves on the final results - we are not on a contest, this is a benchmark and it's the reason the test must be done on the same machine twice, one with and another without KSPCF. I'm not worried about how much "real" are the numbers. The difference between the numbers on the two Test Sessions is the goal of these Tests - this is a benchmark, not a contest for the best FPS! No doubt, being the reason I'm not using these tests to any other objective but to answer's @anis questions. In special, I'm putting in check the affirmation: What you debunked yourself, while I was initially thinking that perhaps the problem would be my potato being too much of a potato: And, please, note what I had wrote myself: IMHO I'm managing to manage the user's expectation in a somewhat better way. You just helped me to prove this point, your test session using your potato got about ~4 FPS higher between using KSPCF or not, what's besides being a better score than mine, can be attributed to the better GPU too, and so KSPCF would not be doing too much of a difference on mine because the GPU would be screwing any performance improvements. Being that the reason I said to the user to give KSPCF a chance nevertheless, they need to see the results on their machine, as it's where they are going to play the game. This dirty and quick benchmark of mine is something that they can do on its machine themself, so it's something that they can validate (or not) and then take a better decision. The purpose of this benchmark is getting clear now? Can you guys please understand that I'm not trying to undo KSPCF's reputation, but instead trying to answer the user in a way he could understand and see, and manage their expectations so they don't get disappointed when the miracle doesn't happens? People here are not addressing the user's questioning, but turning this into a World's Columbian Exposition trying to gather attention to their stand by yelling louder. Yes, you need. This is not a contest, we are trying to understand how KSPCF behaves on different potatoes so we can give a proper, expectation managed answer to the user. Specific fixes that are not being demonstrated on my potato, and so I can't affirm to the user KSPCF is going to be that "miracle mod" you promised. Now, it would be a excellent idea to create some savegames with specific scenarios demonstrating where KSPCF would really help performance (because there's no doubt that it helps on other areas of the game, just to make it clear). === == = BRUTE FORCE POST MERGE = == === Just an addendum: This is the reason one should not use MacOS as a primary profiling tool. [edit: you should profile your weakest link, not the strongest!] MacOS does transparent memory compression, allowing a process to overcommit way more memory than Windows, masking these performance problems caused by memory leaks. My rig has only 16GB of RAM, but I managed to get KSP to commit over 38 GB before getting liquided enough to kill the process. Someone must tell me that there's a severe memory leak or I will just not notice it without looking specifically on the issue using vm_stat (or whatever you think you should use to locate how the memory is being overcommited). So huge memory leaks as KSPCF aims to workaround don't have that impact on MacOS as it have on Windows, unless the leak is so severe, but so severe, that it would be happening on Update or FixedUpdate - but that would make the thing unusable on Windows before a Mac Users would even be aware of the mod existence.

Because users don't understand profilings, but they do understand FPS. Remember, it's an user asking for information, not a developer. === == = POST EDIT = == === I checked this tool. Sorry, it will not do. I'm not worrying about optimizing code, l'm looking into how performatic is the whole stack. How this profiling tool would show me how much the FPS drops when the KSC is being drawn in flight scene? How this tool would show me the "jerkyness" of the FPS curve when using KSPCF? How it would help to explain the FPS curves being "smoother" without it? And, most important of all, how this profiling will explain why it didn't improved my potato's performance as you had claimed? (I'm not saying it didn't improved something, I'm just saying that performance wasn't between them). Did you profiled KSP with and without KSPCF as I'm doing using a controlled Test Bed with a deterministic Test Session? Did you compared the results? Can you publish them, as I did now?

@anis, I did a "quick & dirty" benchmark between an almost pristine 1.12.5 installation (Stock + DLCs + a few mods to allow checking the FPS) and tried it with and without KSPCF. The host machine is a MacMini 6.2, 2.3GHz upgraded to 16GB RAM 1600 DDR3. I used the Stratolauncher aircraft as subject (115 parts). This is the FPS count without KSPCF: And this is with KSPCF: When I originally checked this, I was on a pretty dirty KSP installation (I was helping a fellow Kerbonaur to diagnose a nasty memory leak, and the dude had a hell of a modded KSP!! ), and I indeed got about ~6 FPS less using KSPCF on that test bed. On this test above, there was absolutely nothing installed, except my personal forks of MM and ShowFPS (and the KSPe thing in which they run over), and KSPCF with Harmony (or not), obviously. On a pretty vanilla KSP, I think you will not perceive any FPS droppage on the long run - the yellow line (average FPS) is pretty "dirty" when KSPCF is installed, but the average FPS is less than 1 FPS below without it, what's frankly... Negligible. From the performance on Flight Scene point of view, I'm not seeing what KSPCF could do for you - but it does some other things that may interest you, so you probably should try it and see for yourself if it will make things better for you in any other area. For anyone interested, everything needed to reproduce the tests (including the savegame, settings.cfg, logs, et all) are available on my Google Drive. How to reproduce: Load KSP. Load the perf-tests savegame On KSC, activate the ShowFPS icon. That nice image with colored points will be shown. While on KSC, the FSP will be terrible, 22 FPS only on my rig. On both test cases. Then move the camera to look to the runway head and click on the Stratolauncher's marker (already launched) to "move into" the craft. Now the FPS will rise, it's the first ascending curve on the graph Wait a few minutes until the average FPS stabilizes. It's that flat line on the graph WITHOUT KSPCF. Now move the camera until you see the whole KSC complex, exactly how is shown on the screenshots above. Leave the thing at rest, and watch the points being plotted for some minutes as I did. Keep in mind that this test sessions were made without too much "scientific rigor" - I didn't closed any running programs (Firefox, Thunderbird, etc), didn't rebooted the machine between tests, nothing. What I did was to first do a test run with KSPCF installed and then another one without, and vice versa - and I got similar results on the respective test sessions. What I reported above was the second batch (without KSPCF first). Well, I didn't did such affirmation. I said that Macs are more resilient. You will not find on this thread a phrase of mine saying that. What I said was to people using Windows do their own performances checks using... Windows. It's way more productive to detect the problems on Windows (as the majority of the users use it), and counter check on MacOS than otherwise - for starters, SCANSat's memory leaks would not be detected on my Mac on a quick test session, due the reasons I explained about (resilience). Had me not being informed about it, I would dismiss the problem after a reload or two, as the machine just didn't crashed as it was reported to me (and the dude's machine had twice the RAM!!!!). === == = POST EDIT = == === I DID NOT used that MONO_THREADS_PER_CPU=1 trick! It would be interesting repeating both tests with it! I will try do find time to do it tomorrow (hopefully at lunch, but no promises).

Agreed. Feel free to do so, I couldn't - being the reason I tried to work with what I had at hands.

Most people don't use Macs - what's a pitty, because besides decaying over the years (Mission Control is terrible, I miss Expose a lot), is still way better than Windows under the bonnet. The SCANSat memory leak just started to cause problems when the VM (virtual memory, not machine!) reached 38Gb of memory allocated for the process (my rig has 16, shared with the GPU), and it didn't crashed, just became barely responsive. It makes the Macs a terrible platform to optimize for. They are too much resilient, you need to aim lower. Do the performance checks on Windows. Whatever affects a Mac, it does way worse on Windows for sure.

I didn't made myself clear. KSPCF, somehow, lowered a bit the FPS on flight scene. I fired up KSP, loaded a savegame and focused an aircraft in the runway. Took note of the FPS. Then I uninstalled KSPCF, reloaded the same savegame and focused the same aircraft, and got about half a dozen FPS more - what on an already handicapped rig, it's something. What, why and how I didn't bored to check, as I was busy diagnosing something else. I suggest that someone running KSP on a Windows potato try this and check the FPS with some FPS meter with and without KSPCF. It will render some data more comfortable to you. MacOS has a BSD style Kernel, and it manages memory and processes in a somewhat distinct way. For starters, KSP can overcommit almost 10 times the virtual memory on MacOS than on Windows before crashing.

No, CKAN takes the ZIP file from SpaceDock, and I had updated it with the last compilation. This one appears to be on me: I almost surely forgot to update an internal datum while building the thing - it was early Sunday, and I was already tired. So you are good to go! Cheers (I will check the KSP-Recall and update it if needed, thank you for the warning!) --- -- - POST EDIT - -- --- Confirmed, I forgot to update the versioning. I'm issuing a new KSP-Recall release, fixed, to prevent further misunderstandings like this one! Thanks again! --- -- - POST POST EDIT - -- --- Done! KSP-Recall 0.5.0.2 was published!

Not only that. the rigid bodies are deformable, and so (besides consolidating all parts into a single rigid body, as done by Juno), the thing still deforms under stress, literally replacing what we know as wobble on KSP for something... just better.

Checking it. For starters, please, please, pretty please, update KSP-Recall to 0.5.0.1. I works around a very important idiossyncrasy that started to happen on Editor on KSP 1.9.0 (uh? me, late?). Really, it fix an issue related to Attachment Nodes when merging crafts (i.e., you load a craft, then you load another one but clicking on "Merge" instead of "Load"). About the issues, I think you are using an older version of the ModularRocketSystems. The one currently on SpaceDock is this one: https://github.com/zer0Kerbal/ModularRocketSystems/tree/master/GameData/NecroBones/ModularRocketSystems And the TweakScale patches are on a directory called Compatibility, while on yours is on a Patches one. Just to be sure: I checked the following repositories: https://github.com/zer0Kerbal/ModularRocketSystems https://www.curseforge.com/kerbal/ksp-mods/modularrocketsystems https://spacedock.info/mod/86 https://forum.kerbalspaceprogram.com/topic/211992-1125-modular-rocket-systems-mrs-v13990-adoption-edition-12-feb-2022/ And I could not find the faulty patches on: NecroBones/ModularRocketSystems/Patches/MRS_HotRockets.cfg NecroBones/ModularRocketSystems/Patches/TweakScale.cfg That are the sources of your headaches - again, because there's no Patches directory on these repositories. I think you should update MRS (too - please, please update KSP-Recall). If by some reason you are unable, I think that removing the file NecroBones/ModularRocketSystems/Patches/MRS_HotRockets.cfg may fix this issue, but I'm unsure if this would not screw something else - as I didn't found this file for inspection on the web. When updating, please completely remove all files from the previous version(s). Cheers!

KSPCF reduced the FPS on my potatoes. Just a little bit, but it did - at least on MacOS. Didn't bothered to check why, however - perhaps it just allocated that bit of extra memory that triggered the swapfest again, but since I had already lowered the texture's quality to the lowest level, there's no other place to run.

It's all they have left in life. Prey.. uh.. Pray for them.