Lisias

There's some ground yet until it is really usable. Now it only scores one single Challenge, and I still need to cook something to easily (or the less cumbersome as possible) add scoring systems. Initially, I thought on some scripting as done by kOS, perhaps using Lua (using Red Onion or perhaps incorporating Selene), but I'm really reticent on shoving an interpreter overhead on the FixedUpdate, where the data gathering happens - as one objective of the tool is to be the most accurate as possible. So I'm learning how to hot load DLLs on C#, as one possible way out for this problem is realising new Challenges into discrete DLLs and load them at runtime. I want to try to hot load/unload such DLLs to avoid restarting KSP. Having to restart KSP to try small changes is cumbersome as hell, and avoiding that will really add value to this tool.

One hour and fifty minutes of some of the most kerbal aircrafts ever.

Wow. It's almost impossible to KSPIE be a source of problems because they don't patch their parts, they hard coded TweakScale on theirs patches. So the thing just works (or don't - but when something doesn't work on the spot, the developer usually notes and fix it). In every single situation in which KSPIE were involved, it was a problem somewhere else and KSPIE was caught on the splash damage. In a way or another, let's crack this nut: [LOG 16:41:56.290] [TweakScale] INFO: WriteDryCost Concluded : 744 parts found ; 0 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 104 Show Stoppers found; 0 Sanity Check failed; 193 unscalable parts. No Checks Failed, so I infer you added my patch above to shutup that pesky Yellow Warning. If I'm right, please remember where you shoved that patch so you can delete it when I finally implement that features. But that 104 Show Stoppers are an issue. It's highly unusual getting a high numbers of ShowStoppers nowadays, so it's probably some leftovers of a old add'on lingering around (or perhaps a new add'on installed wrongly - it happens even to me). The listing of FATALities are on the spoiler: Interestingly, most (if not all) the victims are Near Future. That ringed a bell: [LOG 16:39:22.496] Config(@PART[adapter-125-0625-2]) TweakScale/patches/NFT_TweakScale/@PART[adapter-125-0625-2] [LOG 16:39:22.549] Config(@PART[adapter-125-0625-2]) TweakScale/patches/NF/NFC_TweakScale/@PART[adapter-125-0625-2] That's a bingo! TweakScale is an Add'On that should be completely deleted from the harddisk before applying a new version. Some patches are being phased out, others are moving to promote maintainability, and the new result is that by just applying a new version over the old, you risk having some oldie rogues playing havoc on your instalment. Please delete every single TweakScale file from your instalment and install the latest TweakScale (2.4.3.10 at the moment) again. This will fix the issue.

Release 0.0.1.2 ALPHA available for download, check the OP for the link. Change Log Fixed a mistake on handling the Window life cycle.

Yep! Score: 1575.4 for the subsonic class. Yep**2! Yep**3!

And some others make a good money doing that. But KSP2 is not being made by KSP1 developers. It's a new beast, made by different people with different goals. Point taken. All my argumentation is only valid under the presumption that KSP2 will have DRM on multiplayer. I never said it will work, I never said it's required for success. I said it's needed for the business model I'm speculating about.

The only fairness that matters on a single player is your enjoyment. We do games for enjoyment, not for fairness. There's no shame on fast track things if this is what gets you motivated - and you already did all of that before! I don't have a working joystick on my rig (thanks, Unity 2017). Guess what? I'm using autopilots. And I having fun nevertheless.

Point taken. I remember, however, a statement where Frontier had vowed, in the case they quit business, to provide a patch and a download with the last state of the "Universe", so you could keep playing locally, besides on a static Universe. But I diverged. Having THE Server is not intrinsically incompatible with having local servers. See QuakeWorld - at that time, they had created a dozen "federations" (my term, not theirs), each one with tens of servers, each one hosting a game, each game with different rules and different maps - WADs, as we called them at the time - the whole shebang (map, textures, meshes, scripts in quakeC) were bundled on a WAD. Even Brazil had a bunch (a real achievement, given our network infrastructure at that time). You could raise your own server, but by then you had to communicate your teammates (we used ICQ at that time) the address. Or you could "join" one of what I called "federations", and then you would be listed on that server directory (but then you could be reached by anyone). I don't recall what it took to be listed on the QuakeWord site (and I don't recall even who run that server, no current site appears to be related to that one of my time). We had a different Zeitgeist online at that time. And, again, I'm talking about the business model, not about the infrastructure.

Nothing. But building a stable and usable multiplayer mode on this game is hard, pretty hard, as the current multiplayer Add'Ons demonstrates. As the popularity of the thing, it will depend more on how their marketeers will promote the game than anything. You are expecting that KSP2 will be aimed to the current KSP1 users, I expect that they plan to expand the user base by adding candies with mass appeal on the multiplayer, while keeping the single user more or less on the same track os KSP1 nowadays. I think KSP2 will be essentially two different games from the same franchise, being the multiplayer built over the single player, and so trying to capitalize both on the current user base, but also to expand it with a different audience that are willing to pay money for some extra features. And how much money Microsoft is making selling goodies on the game? Agreed. My argument is reasoned on four points, being the DRM just one of them. Perhaps. But yet, Elite Dangerous suggests it can be profitable. Being the reason I think that multiplayer mode will be somewhat different from the single player, besides sharing the same foundations. I think you are misunderstanding a business model with a game model. Of course KSP (both of them) have a completely different game model. But business model is a completely different beast - you can buy Elite Dangerous and KSP from Steam the same way. Maybe they can manage to sell skins and similar goodies for KSP2 the same way Frontier does for Elite Dangerous. They will do it? Dunno. If they do it, it will work as intended? Dunno. But it appears a possible way to make some money, and on this subject, my guessings are so good as yours: we can be both wrong. Nope, I don't think KSP is mainstream enough to make piracy an incoming problem. It could be the other way around, I know people that downloaded an... "generic" copy from... "alternative" providers, liked the game a lot and bought it - and let me tell you, dude, KSP Demo is being missed. The problem on capitalize on a DRM free game where modding is not only allowed but strongly encouraged is that you can't control what is being offered to the public, so it's harder to make a profit on it. You publish an artefact that overlaps one already freely offered by someone, you got backslashed (even if yours adds real value to the thing - I'm abstracting the glitches introduced on the feature, this is another issue). You publish something that is not as polished as something already on the wild for a long time due time/funding/whatever development constraints, you got backslashed. Someone makes a small Add'On that does only a small thing that your bigger, commercial Add'On also does but it's the main reason of the selling, and your revenue is challenged. And so on. That said, I'm not saying that Add'Ons are not a good thing (common! I'm an Add'On author!). I'm saying that they have a cost, and this cost is making harder to monetise DLCs. And since whoever makes the game needs to keep his teams funded, exploring new alternatives to capitalise on the game while trying to preserve the current Add'Ons rich status quo sounds like a good idea. Of course, I'm NOT telling what they will do. I'm telling what I think they can do. Only time will tell - the ones that can talk about don't know about it, and the ones that know about it can't talk about.

When I said about "Elite Dangerous path", I was meaning the business model, not the infrastructure. The fact that you will be allowed to fire up your own server doesn't change the fact that the server and clientes still be DRMed, and so will be the best place to be monetised. Facts: They need to monetise the game somehow single player will not be DRMed and non DRMed games are very hard to monetise, as KSP1 apparently is demonstrating multi player will can *** be DRMed and allowing free modding of DRMed games erodes the opportunities to monetise on it Elite Dangerous successfully implemented monetisation on a DRMed multi player game I'm not talking about the infrastructure of the game, only about that they successfully implemented monetisation by selling skins on a DRMed multiplayer game So I conclude that selling skins for the multiplayer modes can be one of the ways they will implement to monetise the game, and it's already field proven - what makes the stunt attractive. -- POST EDIT -- I was wrong, its not certain that multiplayer will have DRM. My apologies. See this post for info:

Well... I can't see how you would offer a multiplayer game without creating a server and being online. Even QuakeWorld demanded a server (that could be any one on the network) and being online somehow - unless you are talking about lan-houses. In a way or another, on the context of the argument (how KSP2 would make money), appears to be the way to go. You can't offer private servers with free modding and also try to sell artefacts to be used on the multiplayer. And since multiplayer will can*** be DRMed (at least, it's the what I had read last time I checked about KSP2), you can't allow free modding on it, as it would defeat the very purpose of the DRM. See, multiplayer will can*** be DRMed, not single player. Single player will be free to hack and slash as we do nowadays on KSP1. But this also means that trying to monetize things to it will be somewhat a challenge (as apparently is now to KSP1). So, by inference, they plan to monetize the multiplayer. One possible (and, AFAIK, proven) way to do so is going Elite Dangerous way: they sell skin packs and expansions to be used on a DRMed multiplayer game. -- POST EDIT -- *** It came to my attention that I misrepresented what was said about DRM on KSP2! My apologies. See the following post for the info that had proven me wrong:

I didn't knew they are Australians! Aussie music RULES!

Dude, my apologies! I didn't noticed your follow up, just did it now! Sorry! Google is bitting you too? Here, I had to deactivate almost everything from that guys. Even the Calendar misbehave once, and I missed a meeting! Well, these yellow warnings are annoyances, not problems. That 9 parts are things that I need to fix, but as the time passed, I had postponed due issues on real life, and then holidays, and them more real life (as having to deliver a PoC for an important project), etc. The next holidays are near and if I manage to get keep myself out of trouble, there's a good chance I will tackle at least some of them at that date (I prefer not to make too much promises, real life talks louder on the subject). In a way or another, that patch I published on my last answer to you will "solve" your issue for sure. Just remember to put the patch in some place you will remember, as I eventually fix these thingies, you will need to delete the patch to get that 9 parts scalable. Cheers!

Release 0.0.1.1 ALPHA available for download, check the OP for the download. Change Log Fixed the Speed reading (use the Surface, Luke!) Added an entry on Known Issues.

I don't know if you are lucky, or if me is terribly unlucky. But my crafts misbehave. Some just didn't took off, others had too less drag (and drag is something I depend to airbrakes be successful). I made some contraptions using Blades from the Robotics that worked well on 1.7.3, but rendered the craft completely uncontrollable on KSP 1.8 (this one I still didn't diagnosed, so I need to state that it can be something on an Add'On). There're also the thermals. I make crafts that flies at the very thermal limits, 1150K on skin for the MK1 parts on one of them, and this is another source of headaches due the (lesser) drag. That also made my rockets overpowered, by the way, as there're less drag to overcome on the ascent. And so on. Other than that, I found KSP 1.8.1 pretty usable. But I spent about... TWO YEARS on some savegames, and I'm not willing to drop them and start from scratch due it. The performance gain on Unity 2019 is real, my old rig performed sensible better - but performance without my savegames doesn't interests me - and since I had to buy a new old rig anyway, an old i7 (the older is an older i5), the performance gain was enough to make 1.7.3 as playable as (or better than) 1.8.x on the old rig - and I kept my savegames.

Considerably. Let's crack this nut: [LOG 18:55:40.295] [TweakScale] ERROR: **FATAL** Part KhiSP.SZ (KhiSP-SZ) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 18:55:40.298] [TweakScale] ERROR: **FATAL** Part KhiSP.SZ (KhiSP-SZ) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). It appears to be not that bad, just two fatalities... On the same part??? Boy, this is a new! Congrats! Double patching (i.e., patches being applied twice, rendering the part with two TweakScale sections) are common, but DOUBLED PART with DOUBLE PATCHING (each), this is a new! Well... Lets check what's happening: [LOG 18:48:08.196] DragCubeSystem: Creating drag cubes for part 'KhiSP.SZ' [LOG 18:48:23.726] DragCubeSystem: Creating drag cubes for part 'KhiSP.SZ' [LOG 18:55:40.295] [TweakScale] WARNING: **FATAL** Found a showstopper problem on KhiSP.SZ (KhiSP-SZ). [LOG 18:55:40.295] [TweakScale] ERROR: **FATAL** Part KhiSP.SZ (KhiSP-SZ) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 18:55:40.298] [TweakScale] WARNING: **FATAL** Found a showstopper problem on KhiSP.SZ (KhiSP-SZ). [LOG 18:55:40.298] [TweakScale] ERROR: **FATAL** Part KhiSP.SZ (KhiSP-SZ) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 18:55:48.388] [Filter Extensions 3.2.0.3]: KhiSP.SZ duplicated part key in part path dictionary Hummm No joy. This is every mention of "KhiSP.SZ" on your log. We can see two lines about creating drag cubes for the part (when there should be only one). The last line also pinpoints the problem, Filter Extensions are also complaining about. However... I just remembered that dots on the name became underscores on patches! This is the reason the first log excerpt didn't have any mention for the part being loaded and patched! (I'm getting old! :P) so, let's try again: [LOG 18:46:10.961] Load(Model): Contares/Parts/SolarPanel/KhiSP_SZ [LOG 18:46:12.415] Load(Model): Contares_KHI/Parts/KhiNa/KhiSP_SZ [LOG 18:47:56.165] Config(PART) Contares/Parts/SolarPanel/KhiSP_SZ/KhiSP_SZ [LOG 18:47:56.170] Config(@PART[KhiSP_SZ]) Contares/Patches/Contares_CORE_TweakScale/@PART[KhiSP_SZ] [LOG 18:47:56.177] Config(PART) Contares_KHI/Parts/KhiNa/KhiSP_SZ/KhiSP_SZ [LOG 18:47:56.178] Config(@PART[KhiSP_SZ]) Contares_KHI/Patches/CONTARES_KHI_TweakScale/@PART[KhiSP_SZ] [LOG 18:43:10.047] Applying update Contares/Patches/Contares_CORE_TweakScale/@PART[KhiSP_SZ] to Contares/Parts/SolarPanel/KhiSP_SZ.cfg/PART[KhiSP_SZ] [LOG 18:43:10.047] Applying update Contares/Patches/Contares_CORE_TweakScale/@PART[KhiSP_SZ] to Contares_KHI/Parts/KhiNa/KhiSP_SZ.cfg/PART[KhiSP_SZ] [LOG 18:43:10.685] Applying update Contares_KHI/Patches/CONTARES_KHI_TweakScale/@PART[KhiSP_SZ] to Contares/Parts/SolarPanel/KhiSP_SZ.cfg/PART[KhiSP_SZ] [LOG 18:43:10.685] Applying update Contares_KHI/Patches/CONTARES_KHI_TweakScale/@PART[KhiSP_SZ] to Contares_KHI/Parts/KhiNa/KhiSP_SZ.cfg/PART[KhiSP_SZ] [LOG 18:43:51.019] Applying update WarpPlugin/Patches/SolarPanels/@PART[*]:HAS[@MODULE[ModuleDeployableSolarPanel]:HAS[#chargeRate[>0]]]:FOR[WarpPlugin] to Contares/Parts/SolarPanel/KhiSP_SZ.cfg/PART[KhiSP_SZ] [LOG 18:43:51.028] Applying update WarpPlugin/Patches/SolarPanels/@PART[*]:HAS[@MODULE[ModuleDeployableSolarPanel]:HAS[#chargeRate[>0]]]:FOR[WarpPlugin] to Contares_KHI/Parts/KhiNa/KhiSP_SZ.cfg/PART[KhiSP_SZ] [LOG 18:44:02.813] Applying update B9PartSwitch/CopyEventsPropagator/@PART:FOR[zzzzzz-B9PartSwitch] to Contares/Parts/SolarPanel/KhiSP_SZ.cfg/PART[KhiSP_SZ] [LOG 18:44:02.839] Applying update B9PartSwitch/CopyEventsPropagator/@PART:FOR[zzzzzz-B9PartSwitch] to Contares_KHI/Parts/KhiNa/KhiSP_SZ.cfg/PART[KhiSP_SZ] [LOG 18:44:03.923] Applying update InterstellarFuelSwitch/PatchManager/ActiveMMPatches/IntegratedDecoupler/@PART[*]:FINAL to Contares/Parts/SolarPanel/KhiSP_SZ.cfg/PART[KhiSP_SZ] [LOG 18:44:03.942] Applying update InterstellarFuelSwitch/PatchManager/ActiveMMPatches/IntegratedDecoupler/@PART[*]:FINAL to Contares_KHI/Parts/KhiNa/KhiSP_SZ.cfg/PART[KhiSP_SZ] [LOG 18:44:06.626] Applying update WarpPlugin/Patches/OreTanksFix/@PART[*]:FINAL to Contares/Parts/SolarPanel/KhiSP_SZ.cfg/PART[KhiSP_SZ] [LOG 18:44:06.660] Applying update WarpPlugin/Patches/OreTanksFix/@PART[*]:FINAL to Contares_KHI/Parts/KhiNa/KhiSP_SZ.cfg/PART[KhiSP_SZ] [LOG 18:48:08.160] PartLoader: Compiling Part 'Contares/Parts/SolarPanel/KhiSP_SZ/KhiSP_SZ' [LOG 18:48:08.189] PartLoader: Part 'Contares/Parts/SolarPanel/KhiSP_SZ/KhiSP_SZ' has no database record. Creating. [LOG 18:48:23.690] PartLoader: Compiling Part 'Contares_KHI/Parts/KhiNa/KhiSP_SZ/KhiSP_SZ' [LOG 18:48:23.719] PartLoader: Part 'Contares_KHI/Parts/KhiNa/KhiSP_SZ/KhiSP_SZ' has no database record. Creating. Gotcha! You have two parts with the same name on two different directories: [LOG 18:46:10.961] Load(Model): Contares/Parts/SolarPanel/KhiSP_SZ [LOG 18:46:12.415] Load(Model): Contares_KHI/Parts/KhiNa/KhiSP_SZ .... [LOG 18:47:56.165] Config(PART) Contares/Parts/SolarPanel/KhiSP_SZ/KhiSP_SZ [LOG 18:47:56.170] Config(@PART[KhiSP_SZ]) Contares/Patches/Contares_CORE_TweakScale/@PART[KhiSP_SZ] [LOG 18:47:56.177] Config(PART) Contares_KHI/Parts/KhiNa/KhiSP_SZ/KhiSP_SZ [LOG 18:47:56.178] Config(@PART[KhiSP_SZ]) Contares_KHI/Patches/CONTARES_KHI_TweakScale/@PART[KhiSP_SZ] And each part is being double patched because there're two sets of patches being applied to each one. There's something on Contares_KHI in need to be fixed, I think, as the Contares Core should have precedence. Another possibility is that Contares Core "donated" a part to KHI (or vice versa), and when you updated, you didn't deleted the old files, and so a rogue oldie was left behind playing havoc. Delete completely Contares and Contares_KHI and see if the double patching on doubled parts vanishes. If this fixes your problem, it was a mishap on the installation. If the problem is still there, you will need to reach Contares and/or Contares KHI maintainer and submit a bug report. (Contares KHI is another new for me, I didn't knew it!) Cheers.

But then this is not "Ground Distance Covered"!! It's "linear distance" or whatever, the ground below me doesn't "stretches" as I fly higher! Anyway, let's check: C = 2πr ; r = C/2π; C(Kerbin) = ~3.770Km; r(Kerbin) = ~600Km C(Me) = 5860Km; r(Me) = ~932.648 Km But I had flown at ~21Km high (average), or r(Kerbin)+21; or r(me) = 621Km. So... C(me) = 2π * 621 = ~3901.858Km , being this number that "linear distance" thingy I mentioned. It's merely a 131Km more than travelling on the ground, not 2090!

I'm afraid it will be exactly like this. The multiplayer will follow the Elite Dangerous route, I think.

There're more than one way tô implement this, one of them is artificially making hard to do good Add'Ons. Or parts intended to be used on the narrative. i still think that Making History was the best thing that ever happened to KSP after 1.3.1 A huge potential not propperly explored, that Mars Mission made on this paved a beautiful way to enrich KSP content. But by some reason, it's vastly underused. I don't understand why - the rich Mission Reports content on this forum could render some beautiful content on MB. i'm afraid this hadn't passed unobserved by both development teams. More or less. The key is perceptible value (someone else had already said that, but I'm on mobile now, awkward to check while type). Ban custom skins from the multilayer, and the cash will flow, I think. And multiplayer will be DRMed, so the ban is easily enforceable. Skins are vanity products, and vanity needs audience. Multiplayer will provide such audience. Another possibility is a Market. Authors willing to sell the Add'On would be protected by the DRM, and sharing the revenue to TTI. As long open source Add'Ons are freely allowed on OSI approved licenses, such symbiosis are legally safe. Of course this can create a whole new set of problems, as making copyright trolling really profitable. So some legal enforcement would be needed. For people that knows the Apple Ecosystems, a Market model like the one used on Macs (and NOT the one used on iPhone)

This may be related to patches, maybe to a new added Add'On, or maybe one being deleted. I mangled a lot with my dev instalments, and I managed to break my GameDatabase in a way that ended up trashing a savegame - and fixing the GDB later didn't fixed the savegame. On the 1.4.x era, the GDB wasn't automatically "reapplied" on a living savegame - I know because I learnt my way on modding parts by editing craft files and savegames, and then making a CFG file with the data I mangled (when the result was good, of course). Then I spend some time without doing it again, and on KSP 1.6.1 or 1.7.0 (I don't remember exactly when), that hacks didn't worked as it intended anymore, as KSP started to shove GDB data on stablished craft and savegames on load. I initially though that this would happen when converting a file from the previous KSP version to the new, but even files created with the at the time current KSP version were having this new behaviour. As a corollary, new changes on the GDB now "refreshes" the craft and savegame files, and if something had misbehave and trashed the GDB, you will see your files being infected by problem on load and being perpetuated on save, and the "infection" will persist after you fix the GDB (by deleting the offending Add'On) - as my previous experience also taught me that once KSP "refreshes" the craft parts with the current GDB, the missing data are inserted with zeroes - and stays there. @ANFe26, if you can find the time (and the mood), can you make a copy of the "infected" savegame, open it, remove everything from it but the craft with the problem, save it, load it, check if the problem are still there, and then publish it on a file share? Analysing this savegame can hint us about what happened, and once we know what happened, we can try to cook a mitigation measure.

Neither do I. But I know what they should not do. Check the tragic history of Empyrion on Steam. Read the reviews. Don't let this go the same way. And yeah, I was looking for KSP "replacements' - not because I don't like this game (I love it), but because I'm fearing it could be a good idea to leave it while I still like it. TL;DR IMHO, they need to find a successful compromise between acquiring new users and losing old ones. They/we (this is for the whole ecosystem) need to rescue old gamers from old versions by building a path in which they can follow when they want (instead of the current Modus Operandi that tries to force them to upgrade but essentially makes it so hard to upgrade that some of them choose to simply lock themselves eternally on 1.3.1 or even 1.2.2 - some people finds easier to simply fork everything they uses and maintain themselves (and I'm not the only one neither the first one - there are more people running their own "kspu initiative" out there, I'm the only one doing it openly, as it appears). You manage to realize the reasons such people do it, you get to the problem - and, perhaps, you could try to solve it. I can think of tons os possible advices that could or could not be useful - I don't know enough about what's happening on TTI and Squad to really do some good on this involuntary (and perhaps unwanted) Advice business (I'm not a coach anyway). But there's one single thing that it's essentially universal, and it should be took seriously by anyone on this trade (be doing it for a fee, be doing it for free): Users are your customers, not your subjects. Handle them as such. You don't make money by making your life easier, the money comes when you make their lives easier. But so they would not earn money. They run a business. This thingy must be good for both sides.

I remember an Add'On to automate it, Planetary-Diversity!

To tell you the true, I think it's already made! It's an external application, it doesn't runs inside KSP - what's usually a good idea, since you don't want the galaxy to change once you start a game, and KSP can't have a per savegame GameDatabase (the thingy where everything on the game exists, from parts to planets)

Ohh, that's a bingo!!! @zer0Kerbal? Are you around?

The problem will be what else 1.9 will bring additionally. I'm using 1.7.3 not because 1.8.x is bad, I'm using 1.7.3 because I need to, as my current games didn't coped to 1.8 due a lot of glitches that probably would not be that bad to new comers starting new games, but are killer to my ongoing games. So, ok. 1.9 will have all the fixes that 1.8.2 would had. But 1.9 will have also a lot of new features that, historically, will render again my savegames kaput. So the bug fixes will be useless to me, and the aftermath is that I will still use 1.7.3, even with 1.8 having some very nice features that could worth the effort to migrate. Moreover - by being locked on KSP 1.7.3, why I would spend money on DLCs that will not work on it? Or really develop Add'Ons for newer KSP versions, as I'm not going to use them anyway? You see, the "Eat your own dogfood" is the secret behind every successful piece of software under the Sun (and Kerbol also). So if I'm not going to use it, and I'm not hired to do it, why spend the effort? What would be my loot on this bargain? Now multiply these issues by the number of old farts like me still playing the game.