-
Posts
7,395 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by Lisias
-
[1.4.*] [2.5.3] (2018-04-06) UbioZur Welding Ltd. Continued
Lisias replied to girka2k's topic in KSP1 Mod Releases
KSP 1.9 is a matter of implementing welding of variant parts. About MM, I want a MM which I can support without fixing what's not broken all the time. There're people playing KSP 1.7.3. Damn, there're people still using 1.3.1. And they cannot get the fixes from the latest official MM due some pretty lame decisions. -
Announce TweakScale 2.5.0.20 Beta is now available for the brave Kerbonauts that don't fear burning savegames in sacrifice to the Krakens. Some pretty important fixes were implemented that will allow The Companions to survive third-parties "less than happy" patches (being the proof of concept the complete overhaul of FS patches, that changed a lot of thingies and are now safe to be applied!!!), but will also help in some cases of bad patching (a plague still haunting TweakScale nowadays). This was one of the last real showstoppers preventing TweakScals 2.4.4 to be kicked through my door. Things will start to really happens soon! #HURRAY! Please note that TS Beta is to be used on disposable savegames only. I'm using this stunt on my own savegames, obviously, but now and then a bug passes through - but I know how to edit and fix my own savegames, and I'm a S.A.V.E. heavy user! Any reports about it (being a bug or not) should be posted on issue #42 (or I will get lost - again - on the sea of bug reports!).
- 4,054 replies
-
- 1
-
- tweakscale
- plugin
-
(and 1 more)
Tagged with:
-
Announce TweakScale Companion for Firespitter is now Beta! As soon as I tackle down one or two minor annoyances that I don't know yet if will affect currente savegames, I will promote the thing to Release Candidate! #HURRAY! Please note that you will need the latest TweakScale 2.5 Beta - some pretty important fixes were implemented that will allow The Companions to survive third-parties "less than happy" patches (being the proof of concept the complete overhaul of FS patches, that changed a lot of thingies and are now safe to be applied!!!). Please note that TS Beta is to be used on disposable savegames only. I'm using this stunt on my own savegames, obvious, but now and then a bug leaks - but I know how to edit and fix my own savegames, and I'm a S.A.V.E. heavy user!
-
[1.12.3+] UnKerballed Start v1.3.1 (Happy New Year! Jan 01, 2022)
Lisias replied to theonegalen's topic in KSP1 Mod Releases
It's not a pseudo-code. It's a MM patch. The aftermath (hopefully) will be a node on the GameDatabase with 0, 1 or 2 values (think on it as an array) called "error". On the code, you read that node from GameDatabase and ir there are more then zero ocurrences of that value, you call a "Houston" and try to scare the user into fixing the problem.- 199 replies
-
- 1
-
[1.12.3+] UnKerballed Start v1.3.1 (Happy New Year! Jan 01, 2022)
Lisias replied to theonegalen's topic in KSP1 Mod Releases
That's the thing... It depends of the patch. Lets take one example from the OP's github: @PART[CanardController|tailfin|sweptWing|R8winglet]:NEEDS[CommunityTechTree]:AFTER[zzzUnKerballedStart] { @TechRequired = flight3 } Why it needs to be done after zzzUnkerballedStart? Since you are adding support for an add'on, why not patching together it? There's no real hard dependency between Unkerballed Start and Airplane. I would consider something like this: @PART[CanardController,tailfin,sweptWing,R8winglet]:FOR[AirplanePlus]:NEEDS[UnkerballedStart,AirplanePlus,CommunityTechTree] { @TechRequired = flight3 } The patch would be applied only if UnkerballedStart, AirplanePlus and CommunityTechTree are installed. And since it's just a string edit, there are no hard dependencies involved. This would gracefully allow anyone willing to second guess this TechTree on Airplane to just use :AFTER[AirplanePlus]:NEEDS[UnkerballedStart] , and any race conditions would be a problem to be handled by people willing to second guess Unkerballed Start - what I think is a saner and fairer. Using this same logic, the Unkerballed TechTree itself would be patched as: @TechTree:AFTER[CommunityTechTree] { // Nodes added //fabrication, aeronautics, basicConstruction, earlyAviation, gadgets, //specializedRocketry, customFuelTanks, gizmos, earlyHeatManagement, //specializedRocketry7, specializedRocketry8 <yada yada yada> } So people willing to expand/replace things on Unkerballed Start could just use :BEFORE[UnkerballedStart] or :AFTER[UnkerballedStart] . The problem would be add'ons willing to second guess both CommunityTechTree and UnkerballedStart . A problem that these ones could handle on their zzzThingy themselves. Or just zzz, by Kraken's Sake - what difference it would do with a proper and carefully built :NEEDS ? Conflicts between incompatible add'ons (as another TechTree completely different from Unkerballed Start) would be better handled by another tool, perhaps on Unkerballed Start itself, checking on startup for incompatible add'ons or checking for its integrity and yelling if something is wrong. This is something that would be better served on zzzUnkerballedStart: UnkerballedStartPatchingErrors:FOR[zzzUnkerballedStart] { error:NEEDS[UnkerballedStart,IncompatibleAddOn1,IncompatibleAddOn2] = "IncompatibleAddOn1 and IncompatibleAddOn2 were detected. You should choose only one of them, you can't have both installed" error:NEEDS[UnkerballedStart,IncompatibleAddOn3] = "IncompatibleAddOn3 was detected. This thing is imcompatible with Unkerballed Start, you need to remove it" } And then checking for any values named "error" on that node at startup. -- -- -- POST EDIT -- -- -- I just realised that UnkerballedStart itself is the one willing to second guess Community Tech Tree!!! So I need to examine how Community Tech Tree works in order to be sure what I propose works. I'm doing it right now. -- -- -- POST POST EDIT -- -- -- The Community Tech Tree does its patches into the Tech Tree on the LEGACY phase. So anyone using :BEFORE, :FOR or :AFTER will be good on it. It doesn't specifically mentions AirPlanePlus, so Unkerballed Start doesn't needs to try to preventing collisions to CTT, and it's reasonable to assume anyone else willing to second guess Unkerballed Start should do it's magic after it.- 199 replies
-
- 1
-
One sentence you could say to annoy an entire fan base?
Lisias replied to Fr8monkey's topic in Forum Games!
Space Shuttle neither, but they were only retired due the accidents - otherwise we would still be using it and Elon would not get his chance on this market. The engineer that tried to stop the Challenge's launch was also right. But he was bullied by his colleagues nevertheless. -
[1.12.3+] UnKerballed Start v1.3.1 (Happy New Year! Jan 01, 2022)
Lisias replied to theonegalen's topic in KSP1 Mod Releases
(moved from the old thread) I would suggest :FOR[zzzUnkerballedStart]:NEEDS[zzzUnkerballedStart] and then create a directory named zzzUnkerballedStart on GameData. The :FOR thingy has this nasty habit of creating the MM tag for the Add'On, no matter what config had issued it. The :NEEDS will get rid of if the directory is not found. On a personal note, the GameData will be heavily cluttered with tons of "zzz" directories around.- 199 replies
-
[1.4.*] [2.5.3] (2018-04-06) UbioZur Welding Ltd. Continued
Lisias replied to girka2k's topic in KSP1 Mod Releases
Nope, I think you hit some limitation on the welding algorithm. Please post the (source) craft so I can see what's happening by welding it myself on my (customised) debug enabled DLL. About MM, the only really important changes from 3.1.3 to the current 4.1.4 are concurrent patching (i.e., the patching is done while loading models, textures and sound - what really made things slower on my old Mac Potato, believe it or not) and some bug fixes on a directive called :LAST that at 1.7 era was seldom used. Of course you can be unlucky enough to hit some unfixed bug by using a KSP >= 1.8 add'on on 1.7... (and that's the reason I use my own personal fork). -
totm march 2020 So what song is stuck in your head today?
Lisias replied to SmileyTRex's topic in The Lounge
Didn't knew about these ones, just "discovered" them! -
Sure thing! Can't give you a deadline, but it will be tackled down as soon as possible. Keep an eye on the TweakScale Companion Program. New support is being worked out and published there (as TweakScale "Stock" is being trimmed down to handle only Stock and DLC parts, waiving third parties add'on support to a Companion!).
- 4,054 replies
-
- 2
-
- tweakscale
- plugin
-
(and 1 more)
Tagged with:
-
I had forgot about that. That page is stalled since 2016, when the Author gave KAX to the previous maintainer - that so passed it to me in 2018. Try my updated version, it works for sure on 1.7.3 and I had success playing it on 1.8.1 - but I still didn't tried it on 1.10.1. Weird. Delete the ModuleManager.ConfigCache and load it again. It's by best guess at the moment - if it doesn't works, send me the KSP.log in PM and I will give it a look. 99.99% of the time, it's related to NRE or some other exception being triggered on the Update or FixedUpdate thingy. The first one happens once a frame (ideally), and the former each 50ms (if memory serves me right). So anything being logged on them will rapidly grow up the KSP.log through the roof. When you see this happening, quit KSP, reload it, and play for a few minutes. Then quit KSP again. And so send the KSP.log on a bug report on the Forum - whatever happens on that two thingies, happens all the time so just by playing it a few minutes will (most of the the time) flag the problem on the log.
- 4,054 replies
-
- 1
-
- tweakscale
- plugin
-
(and 1 more)
Tagged with:
-
I don't remember. But since this is what I usually do, and since the first commit's dot files don't look as anything github gave to me on repo creation fest I did now, I was wrong on my initial claim of being github. Now I'm... "curious" to pinpoint from where that file came - but since we live on times of continuous integration, with nearly weekly updates from the mailer to the IDE and the kitchen's sink, that could be something stupid done by some developer on some previous version of some iDE ("hey, let's add this nice gitattributes file for this idio... I mean, UNIX user!") when using the embedded github support while building the first release of Recall. Oh, well... In a way or another, I'm caught with my pants down only ONCE per issue. Development will be suspended for a couple of days while I normalize every single repo of mine with a carefully curated .gitattributes file (and boy, I have quite a few on github and bitbucket...)
- 4,054 replies
-
- 2
-
- tweakscale
- plugin
-
(and 1 more)
Tagged with:
-
Github was innocent on that one. I spend some time creating repos with different options, none of them came with a .gitattributes file. I spent some time checking evert cloned repository of mine, a few have the file - all of them forked from someone else. And as far as I checked, no one was like this one, besides I found some similarities. MSYSGIT is known to add a standard .gitattributes file with a lot of settings for Windows - but the format of the file I had on Recall is different. Agreed. This kind of stung should be considered extenuating circumstances on some kinds of unlawful and permanent activities (not allowed to be mentioned here). And I'm gathering evidences that similar approaches was/is one of the greatest sources of problems lately on a somewhat famous space simulator where you kick some green critters into space.
- 4,054 replies
-
- 3
-
- tweakscale
- plugin
-
(and 1 more)
Tagged with:
-
[1.4.3 <= KSP <= 1.12.5] KSP Recall - 0.5.0.2- 2024-0521
Lisias replied to Lisias's topic in KSP1 Mod Releases
Announce. Github [Some tool] decided to bite me in the SAS, adding a configuration that automatically translated EoL between UNIX and Windows. And did that on a DLL. #facePalm. The 0.0.4.4 only fixes the 666_ModuleManagerWatchDog.dll , the affected one. It should affect only manual installers, as CKAN was told to ignore this. The whole history is on TweakScale thread, where the bork was detected.- 633 replies
-
- survivability
- ksp-recall
-
(and 1 more)
Tagged with:
-
Didn't even started yet. KAX will have to wait until I deliver TweakScale 2.4.4.0 - can't handle both at the same time. -- -- POST EDIT -- -- (one week later) @Kerbalwings, that's the history: there's a (dirty) trick that would accelerate resurrecting that gorgeous landing gear of KAX : making World Stabilizer an optional dependency. If you have it installed, the gears will be available. If you don't, you will have no gears but will an Warning saying you need to install World Stabilizer in order to have access to all parts every time you install or delete something on the GameData. Doing this way, I will not have to rework the mesh, all it's needed is to adapt it to the new wheels modules from KSP. Do you would compromise with such a stunt? (it would be needed to a lot of add'ons too, as Firespitter anyway)
-
I know WHAT but doesn't understand WHY. See below. KAX is mine. But I do not distribute a KAX_Readme file on the zip. Where did you downloaded KAX, @Hypercore? -- -- About the MMWatchDog bork -- -- This is just INSANE. KSP-Recall is being distributed with a corrupted DLL file! That's the reason I didn't found any problems on my rig, the only corrupted copy is on the KSP-Recall zip file. I was scratching my head trying to figure out how in hell I leaked a corrupt file into the mainstream when I decided to download everything I ever published, and that's how I detect it's on KSP-Recall. WORST. The file on Recall is not exactly corrupted, it had ONE BYTE DELETED, all the rest of the file is identical to what I compiled. And not, it's not a missing byte at the end of tile, it's the byte at the position 0x76 (a 0x0D) that was deleted somehow from the file. Since the 0x0D 0x0A is the MS-DOS end-of-line marker, I'm guessing something somewhere preprocessed this file and "fixed" what would be a bad EoL (0D0D0A -> 0D0A) marker completely disregarding the frakking file is binary, damnit. #facePalm I probably didn't detected it before by the same reason I had to put it there - since everybody just unzip files into the GameData, I do the same (end-user simulator ), but since KSP-Recall is alphabetically less than TweakScale, usually is comes first on the Explorer, and so it's unzipped first - and anyone installing TweakScale would overwrite the bad file with the TS's one, what's good. It was needed a non TweakScale user that does thing manually to detect this. @TranceaddicT was the first, but since I had sent him some DLLs on PM on a diagnosing fest, I tacitly assumed I had borked on that DLLs. But now we have @Hypercore with similar problems, so it became clear the problem is on a distribution file. Since TweakScale don't borks on me (I really do tests before shipping), the only remaining suspect is Recall - and since I don't remember testing only Recall, I completely missed this absolutely appalling problem. At least this one is easy to fix. I'm packing a new minor release of KSP-Recall. @Hypercore, this is the reason we always ask for the KSP.log when doing support. I would detect this one in 5 seconds, just looking on the log. -- -- -- POST EDIT -- -- -- It was GITHUB. Recall is a new repository (couple months only), and apparently some idiot on Github decided it was a good idea to "help" people by transparently shoving what follows on new repositories on the .gittatributes : # Auto detect text files and perform LF normalization * text=auto * text eol=lf DAMNIT - I hate when <insert your favorite non forum compliant compliment here> try to second guess me, "helping" me to do what THEY think is right. I just remembered what I did - I usually starts project locally, and create the github repo later, and then I already have a initialised repo to push up. For Recall, I created the repo on the github and clone it first. #facePalm. Oh, well... -- -- -- POST POST EDIT -- -- -- Just for the sake of completude - I created a bunch of repositories locally, on github and on bitbucket (where most of my professional and retro works are hosted). None of them added the .gitattributes file. I don't have the slightest idea from what deepness of hell that file came, all I know is that it's there since the first commit. But it's not Github for sure. It's something else I was using on Feb this year. What I can say for sure is that I didn't added that file consciously, something added it for me and I did't realised it. Oh, well.... Now I have a bunch of release notes to fix. Sometimes the Grumpiness Factor strikes back.
- 4,054 replies
-
- 4
-
- tweakscale
- plugin
-
(and 1 more)
Tagged with:
-
Yes, but I would advise to COPY them, one by one. So if something goes wrong, you don't risk losing them - you can erase the new borked instalment and start again. Only when the new instalment works fine I would consider deleting the old one. To tell you the true, I stil have my 1.4.5 carrer instalment lingering here, I choose to keep it after migrating to 1.7.3 . just in case Dowload a fresh copy of the KSP you want to use (assuming you dont have a backup of it already). Then copy the folders to the new installment, following the telephone method suggested by @TranceaddicT above. Create new savegames to do quick checks. Delete them after using. Once you manage to get the new instalment working fine, just then COPY then savegames from the old instalment to the new.
- 4,054 replies
-
- 2
-
- tweakscale
- plugin
-
(and 1 more)
Tagged with:
-
[1..x, 1.9.x, 1.10.x] Kerbal Research & Development
Lisias replied to linuxgurugamer's topic in KSP1 Mod Releases
I gave this a shot, but ended up stalled. There're fundamental design decisions on both TweakScale, Fuel Switches and KRnD that make them pretty hard to interoperate. KRnD caches all original part's data on startup, and then use that data (together the upgrades info) when you add a part to a vessel to generate the intended values (don't have a clue the reason it doesn't relies on the prefab instead). This essentially overrides or it's overridden by Fuel Switches and TweakScale, that do incremental changes on the part. In order to make KRnD to work with Fuel Switches and TweakScale, it should be rewriten to replace that caching mechanism with something that allow FSs and TS changes to be used instead. Didn't dove on the problem enough to estimate how hard this would be. -
[1.4.*] [2.5.3] (2018-04-06) UbioZur Welding Ltd. Continued
Lisias replied to girka2k's topic in KSP1 Mod Releases
I'm afraid you looked too away. On the post immediately above yours, there's a link to the explanation for the problem: Since you are on KSP 1.7, you can rollback MM to 3.1.3, where things works for Welding Tool. (tl;dr: it was a - non functional - change on MM that broke Welding). You can also try an alternative, experimental fork of MM 4 (with all the latests bug fixes and working for almost all KSPs, from 1.10.1 down to 1.3.1) - but most people finds offensive fixing problems the "official" maintainer refuses to fix - so I will not link it here. -
There's also SXT.
-
Definitively, not a potato. There's something really smelly around here. Well, I put myself on a corner: now I need to redo my benchmarks. I wish I hadn't lost the instalment I used on the previous one, I would like to reuse that craft on this one.
-
I'm still playing on KSP 1.7, so I really don't know about AirplanePlus on KSP >= 1.8 . I fire them up to make small tests, check if the new patches of the Compantions are OK, etc - but the real playing is still on 1.7.3. So I can't say for sure if APP is the source or the problem, or just the screaming victim. The ones I detected on that log appears to be related to emitters, on the Config/Models loading phase. Module Manager wasn't even started to patch things yet. ... .... Hummm... Perhaps I misdiagnosed the problem? It can be also some crucial game files deleted or moved to wrongly places... @Hypercore - There's a good chance I gave you a less than optimum advise (A.K.A., I'm probably wrong). I think you should create a new install from scratch, there's a good chance you removed or moved some KSP assets, and that it's the cause of the AirplanePlus problems! (thinking is a pretty healthy and useful exercise. I should do it more frequently...).
- 4,054 replies
-
- 1
-
- tweakscale
- plugin
-
(and 1 more)
Tagged with:
-
I got bigger ones. Install ZeroMiniAVC. Really. I doubt it's related to your (long list of) problems, but these ones will cause some trouble later for sure. About your log, 326168 Exceptions 29 being "CustomAttributeFormatException: Could not find a field with name guiName" 1 being "IndexOutOfRangeException: Index was outside the bounds of the array." 4 being "MissingFieldException: Field 'KSPField.guiName' not found." 31006 being "MissingFieldException: Field 'KSPParticleEmitter.pe' not found." 155870 being "MissingFieldException: Field 'KSPParticleEmitter.pr' not found." 1 being "MissingMethodException: void PopupDialog.SpawnPopupDialog(string,string,string,bool,UnityEngine.GUISkin)" 139290 being "NullReferenceException: Object reference not set to an instance of an object" Pretty messy - but the really big numbers are happening because these ones are being issued on the Update of FixedUpdate thingy. These ones happens dozens (sometimes near hundreds) of times per second. The "could not find" or "MissingFieldException" happens when the code from the DLL tries to access a code from another DLL that doesn't exists. This happens when the DLL versions you have on the rig doesn't matches the version some other DLL is expecting. Usually, when you compile a DLL on a new KSP version using some of the new thingies, and then try to run it on an older KSP. This also happens when you compile it using an old DLL that had a thingy that was deprecated. Pretty sure this is related to Unity, a lot of thingies from Unity5 were deprecated on the 2019 used on KSP 1.10 you are using. One of the problems I'm sure is AirplanePlus: [LOG 18:11:54.873] Load(Audio): AirplanePlus/Sounds/109_startup [EXC 18:11:54.992] MissingFieldException: Field 'KSPParticleEmitter.pe' not found. As far as I know, AirplanePlus was not updated to KSP 1.9 and 1.10 yet. My advice: remove AirplanePlus and see if the Exceptions go away. If yes, you will need to choose: remove AirplanePlus permanently, or downgrade KSP to 1.8.1 . All these exceptions are hindering terribly your framerate,, your machine will perform way better when you fix these ones. In time... Yeah, there's a lot of FATALities too on the log. Usually, such a huge number of fatalities is due something wrong on the installation. And checking the patching process, I detected that BlueDog is duplicated on your instalment. Somehow, you installed it twice on it: [LOG 18:12:00.604] Applying update Bluedog_DB/Compatibility/Tweakscale/tweakscale_Agena/@PART[bluedog_AgenaA]:NEEDS[TweakScale] to Bluedog_DB/Parts/Agena/bluedog_AgenaA.cfg/PART[bluedog_AgenaA] [LOG 18:12:00.607] Applying update Bluedog_DB/Compatibility/Tweakscale/tweakscale_Agena/@PART[bluedog_AgenaA]:NEEDS[TweakScale] to Gamedata/Bluedog_DB/Parts/Agena/bluedog_AgenaA.cfg/PART[bluedog_AgenaA] You have a copy on Gamedata/Bluedog_DB , but also somewhere else outside GameData but that is also being catched by KSP. My guess is that you installed it too on KSP root. Open the folder where KSP_X64.exe is, then check if there's a subfolder called Bluedog_DB there (as a "brother" of GameData, instead of its son). Delete it. It will fix the FATALities for sure. You will like this one: cat KSP.log | grep -oP "^\[EXC .+? \K(.+?)$" | sort -u | while read line ; do echo $(cat KSP.log | grep -e "^\[EXC " | grep "$line" | wc -l) :: "$line" ; done
- 4,054 replies
-
- 3
-
- tweakscale
- plugin
-
(and 1 more)
Tagged with:
-
Ouch... wrong steve! Sorry! Check the genkernel options (i think I remember you use gentoo) you used to compile the kernel - I think they are on by default. But I don't remember either. On my old Potato, when Apple updated the firmware before declaring it EoL, the performance on it plummeted on KSP 1.7. KSP 1.3.1 doesnt, and it's still the faster KSP to go on an i5-2520M apparently. Curiously, KSP 1.8 and newer made things slightly better on that thing. Now on my less old i7-3615QM, things inverted again. KSP 1.7 is way faster then 1.10 to the point I'm going back to 1.7 for my day-to-day gaming. Why? Don't have a clue, dude. It's about how Unity does multithreading, and how the physics engine is pipelined. Nothing beats Unity5 on my older rig. Why? Because it have the hyperthreading cripped by Apple to mitigate the Intel's idiocy. So anything that is optimized for multicores will flop [and Unity5 is optimised for single cores]. Similarly, data intensive code will hinder multicores with small and shared L0 caches - because the cache will be flushed all the time, hurting all the cores. Multichannel memory access will perform better then singlenchannel on some algorithms, while will make no difference on others. And so goes on. On what KSP version? Better, on what Unity version? The answer will be different for each one we use in KSP: 5, 2017 and 2019. See above for the reason. For a quick&dirty example. Let's talk about loop unrolling from the GCC optimizations bag of tricks. Do you know that loop unrolling can make the code slower on the same CPU depending the size of the L2 cache? On pretty small caches, the taxing of RAM access will outgrow the savings from avoiding break the pipelines with branches. Same thing: code optimised for newer CPUs will perform worse on older ones. Fair enough. So please describe your scenario, otherwise your numbers are meaningles to anyone else. I don't even know the KSP version you are using, besides guessing 1.10. Now I need the CPU model, how many memory, the chipset (are you using dual or single channel?) and the GPU (shared memory or discrete graphics?). The current physics engine optimizations appears to be the main factor here. But how to know without comparing hw specs? You answered yourself. Without a baseline, they are just numbers thrown on the wind. The fact is that the last time I compared KJR/N with KJR, the later made my rig perform so badly that I could not even complete some tests on more complicated crafts. Less then 2 frames per second, while Next was delivering me 10 or 12 on the same craft. Tests made in KSP 1.6.1 on i5-2520M with dual channel memory active and shared graphics. The cost of not detecting robotics is not being able to use them. See my second video using the KJR, the parts just don't move. You need to disable the joint, move the part a bit, then enable the joint again on every fixed update. So the choice is not to blacklist something or not, but to be able to use the thing or not. Without further information, and more benchmarks on different machines with different KSP versions, we will not know. Check the date of the claim. It was true at that time. And more than one confirmed the claim at the time. Me included. It's obvious that something changed, but I think it's unreasonnable call bogus claims made under different times on a different environment. Granted, the OP doesn't states that neither. But IT IS YOUR PC. Because on mine, things performed differently. The magic happens when we realise exactly what changes from your machine to mine so we can try to nail the problem and try a fix. The thing is not working for you. Perhaps will not work for others people too. But the thing worked as intended to me and to a lot of people before, and perhaps it's still working for some guys. As long you dont use robotics. ferram's locks everything, including robotics. And if you blacklist robotics, they will wobble and so why use KJR? on that second benchmark of mine, KJR (original) not only rendered the robotics useless, but also halved the (already limited) frame rate. On KSP 1.6.1 running at i5-2650M with shared graphics. -- -- -- POST EDIT -- -- -- Did you removed all the auto-struts from the test subject?
-
One size does not fits all. You are benchmarking your machine too, and its way beefy than the average gamer is using. Differences on CPU architecture (number of cores and how they share the cache - no to mention the need to mitigate or not Spectre et all), memory controller and GPU will heavily influence the results. You need to benchmark things in multiple machines in order to have figures to be shown to the general public, instead of people that uses what you use. KSP also switched physics engines, and what could be sound on the previous one could bork heavily on the current. Not to mention the requirement of work together Infernal Robotics. On Feb 2019 I made some tests on my old Potato (never reproduced it on the new Potato), and at that time the current KJR/N on a i5 2520M with shared graphics, and the improvement on the performance was noticeable to the point it's possible to to detect it easily on Youtube. http://ksp.lisias.net/showcase/add-ons/IRNext-KJRL/2019-0219_Performance-Test/screenshot40#main-img