Lisias

Oh, well... Unity will start to charge a flat fee on the Unity Runtime starting 2024. This will royally screw up small indie developers. At only 10 cents per install, it may look small but if you are shipping 2000 copies/month, it's an additional 20 bucks you own them. Costs pile up. Some questions are left to be answered, however. What's an "Install"? If people uninstall the game and later install it again, it's new "Install"? I think they would use the term "fee on Licenses sold" if it would be the case. Additionally, if the developer updates the game releasing a new version, it will be a new Install? I find this new business model... Weird. https://www.gamedeveloper.com/business/unity-to-start-charging-fee-pegged-to-game-installs --- post edit --- What happens of the Store decides to sell your game at discount, increasing your install base without increasing the revenue? What happens when the Developer goes kaput and the game itself switches owner. The new owner didn't signed ant Coontract to Unity, did they? Past experience suggests that Unity may have decided to milk the cash cow to its death because they don't belive the Cow will keep profitable for to long and they want to maximize the earnings. — post post edit — Small little question: I'm an add'on author. I have a test-bed of **every** last minor release of KSP ever released on Steam (1.0.5, 1.1.2, 1.2.2, 1.3.1, you got it) - sometimes for regression tests, sometimes for research, sometimes just to have some fun with older versions of the thing. (obviously, I follow the EULA and only fire up one copy at a time - my rig wouldn't support more than one running at the same time anyway) Every one of these installations would impose a fee to the developer? If I upgrade or switch my rig and install them again, this will impose additional fees to the developer?

Fisher XP-75 Eagle . Sell a plane project, go to the warehouse for old sparing parts, slap them together and get a hell of a (weird) plane. To keep design and development of the new system short, the idea presented was to build an aircraft out of proven portions of existing airframes with the entire concoction fitted around the Allison V-3420. Outer wing surfaces were pulled from a P-51 Mustang while the wings themselves were originally slated to resemble the inverted "gull wing" implements as found on the Vought F4U Corsair fighter. The inverted gull wings were dropped from the design and, instead, the wings of a Curtiss P-40 Warhawk was used in its place though the undercarriage of the F4U was still selected for use. The empennage was to be made up from the system of a Douglas Dauntless dive bomber. https://www.militaryfactory.com/aircraft/detail.php?aircraft_id=420 --- post edit --- Found this video explaining the development. Fast forward to the 50% approximately and enjoy the engineers getting screwed ont the SPH!

These ones? CJFiftyOne (WMB VI "Vortex" Engine ColdJ) CJBiplanegear (KS-H1 Fixed Landing Gear ColdJ) The CJFIftyOne is the old and faithful 51prop (WMB VI "Vortex" Engine), but using Stock animations making it more suitable to be used by people the prefers how the Serenity Engines look and feel. The purpose of this engine is to provide an alternative to the "standard" look and feel . I plan to provide an option on Airplane Plus to make the engines behave like this (worth to mention that people, like me, that likes more the current look and fell will keep the option to maintain them this way). The CJBiplanegear is similat to the biplanegear (KS-H1 Fixed Landing Gear). Essentially, the mesh were reworked to better cope with Stock wheel modules. There're some small glitches yet (as one of the wheels rotating contrary to the motion), but the new wheels appears to be working better than the older. These parts where provided so people could experiment with them and give feedback before committing more resources (a.k.a. time) on the refactoring. Cheers!

I didn't knew this one until recently, what's a shame. Pretty inspiring one!

METAR I found an error on a KAX part that will tax you with extra drag and less stiffness - one of the attachment nodes from KAXmedTail was wrongly set. I'm still working on some improvements on KAX, so a release with this fix will not be available right now. Until there, the following patch will solve the issue for users of the current KAX release: @PART[KAXmedTail]:FINAL { %node_stack_bottom = 0.0, -10.8, -0.9, 0.0, -1.0, 0.0, 1 %bulkheadProfiles = size2, size1 } Shove this on a file called KAXmedTailANFix.cfg or something, somewhere in your GameData - this time, I suggest to do it inside the GameData/KAX directory (completely the opposite from what I usually recommend) because the next KAX version will have this tackled down, and this time you will want to get rid of this patch when installing the new release. Cheers!

ANNOUNCE Release 26.6.2.0 is available for downloading, with the following changes: New parts, courtesy of ColdJ! CJFiftyOne (WMB VI "Vortex" Engine ColdJ) CJBiplanegear (KS-H1 Fixed Landing Gear ColdJ) Attachment Nodes' sizes overhaul Fixing a lot of attachment nodes from parts that weren't adhering to Stock standards Some small scattered fixes on Category icons @thumbs directory removal this thing is auto generated by KSP at first run, and failures on installing these files crashes KSP. Doesn't worth the hassle to distribute them Normalizing part configs for easier maintenance. Certifies the thing to run from KSP 1.4.1 to the latest!! #HURRAY!! It's possible that this thing will also work fine on KSP 1.3.1, but I didn't checked too much - and this may change at anytime in the future. Removes Drag0nD3str0yer parts from the distribution, as they decided to pursue their own Add'On, Moderately Plane Related. Users of the following recently added (and now removed) parts should install Moderately Plane Related: f100intake (K-100 Intake) F22_Elev (K-22A Stealth Control Surface) mk0rampintake (Mk0 Ramp Intake) mk3s1scoop (Mk3s1 Side Intake) shorterramp (Shorter Ramp Intake) shortramp (Short Ramp Intake) F100 (K-100 Super Kabre) Closes issues: #13 Cargo Bays are working - from 1.3.1 to 1.12.5 (but not all of them) #12 Mk3S1 Liquid Fuel Fuselage model glitch #7 Remove parts from Drag0nD3str0yer #4 Add proper attributions to Alioth FAR patch #2 Add a Category entry to A+ I finally got my <piii> together and managed time to consolidate a lot of small (or not so small) fixes into a proper release - my time lately was kinda of squandered by diagnosing (and misdiagnosing) things on KSP, but in true without such efforts I would not be able to detect some of the problems I found on A+, so… Kinda of worth it. On the bright side, fellow Kerbonaut @ColdJ graciously gave us new parts to be used on Airplane Plus! Thank you! Additionally, Drag0nD3str0yer choose to pursue their own Add'On, Moderately Plane Related, and so their parts were removed from Airplane Plus distribution. You will find them (and many more) on MPR, there're some nice parts there waiting for you. What's next As I said, I didn't managed to execute all what I was intending to do, so this is what I will deliver in the next version (that I will not make any promises about the timeline… ): Tackle down for good the Wheels problems (including merging fixes from collaborators) https://github.com/net-lisias-ksp/AirplanePlus/issues/3 At least one engine is terribly unbalanced, I will do on engines the same work (but further) I did on the Attachment Nodes. I will provide a way to keep the older behaviour for them, for people that build planes around the faulty engines. https://github.com/net-lisias-ksp/AirplanePlus/issues/5 The helicopter parts are screwed. I will fix them, using the knowledge I'm gathering working on KAX https://github.com/net-lisias-ksp/AirplanePlus/issues/6 Additionally, besides being a bit above my head at this moment, I'm slowly gathering knowledge to build SOFIA, as requested on https://github.com/net-lisias-ksp/AirplanePlus/issues/8 . I really enjoyed the idea. Finally, now that I have something worth of value to show, I'll reach @blackheart612 and see how to proceed about a formal adoption. All the current distribution channels will be preserved. Disclaimer By last, but not the least... This Release will be published using the following Schedule: GitHub, reaching first manual installers and users of KSP-AVC. Right now. Others are being worked out at this moment.

This explains the different Modus Operandi. EEX is probably being screwed by reusing the Stock ReRoot calls (or it's borking itself too, together but unrelated to Stock ReRoot) - but I'm guessing, I will need to check EEX myself to be sure. In a way or another, it's important information. Thank you. As far as I remember, the connection between the Lab and the Cargo Bay was fine - but I need to look on the code craft file to be sure. What really screwed you was the SEQ parts being "transplanted" into the Lab, being removed from the Cargo Bay's authority. And so, the game engine applied drag on them as they were parts ordinarily attached on the craft - what they, indeed, were besides being (only) visually placed inside the Cargo Bay. This one was insidious to diagnose, I must tell you - I almost didn't diagnosed it, I ended up insisting on crazy hypothesis (as the order of the part files on the file) more on desperation than method. "When you have eliminated all which is impossible then whatever remains, however improbable, must be the truth." Sherlock Kerman. The Cargo Bay was working as expected on the craft files where the SEQ thingies were still attached to one of its internal nodes. The problem was "only" the SEQ being "physically" attached to something else, instead of the Cargo Bay, so the ModuleCargoBay just didn't cared to check if these parts were inside its colliders. In the end, it was that simple.

Sun induced seasons, for sure. But... Kerbin is a small but incredibly dense planet, so whatever they have under their feet must be very active. They could have seasons based on some geological cycle below their mantle. With the Mun also pretty near, sea tides are a thing there, and this can be used to pile up on the geological seasons somehow (combining the tidal forces with Kerbol). So, whoever would implement weather on Kerbin, could use this excuse to also simulate seasons- with the duration of week's, perhaps, as everything in this game is small in time scale.

Well, I'm not really an expert on FAR or ReStock, but a few years ago I wrote support for it on DOE, as well reviewed and merged support for in on TweakScale, and I learnt some things from these tasks: ReStock really changes the models and, more interesting, makes heavy use of multiple meshes for defining a part, promoting reuse and getting a better visual result with a smaller footprint. This have two consequences: 1) Different models, different automatically generated dragcubes. 2) Having multiple models for a part caught me with my pants down on DOE, it was really embarrassing but in the end, it's still Stock behaviour and so I just reworked my code on DOE to accept multiple models for a part and the problem was solved. I'm pretty confident you can workaround on "Stock" ReStock by stealing the dragcubes from the Vanilla Stock parts and shoving them on the ReStock equivalent Part Config. This should work as long no one triggers a recompile on the drag cubes of the thing - KSP's aerodynamics' [drag] don't really care about the models, all that means to it is the drag cubes. My guess about FAR is that one (or both) of these points above is leading FAR to "misbehave": if it, like DOE initially, don't expect a part to have multiple active (drawable) models at the same time, it may be calculating wrongly the voxels (IIRC, FAR replaced the stock drag cubes with voxels) by not considering all the models of the part. Additionally, since the voxels are calculable at runtime, they probably can be cached to save time as it happens to drag cubes and, so, perhaps the same stunt can be applied? Precalculating the voxels for the Stock part, and then applying this data on the ReStock equivalent, instead of recalculating the voxels using the ReStock models. I think this may solve the problem, but you will need to bring this case to the FAR's maintainers and ask them about the idea. — — POST EDIT — — I just remembered about the colliders. Colliders are simplified "shapes" used to detect colisions - and they are embedded on the models. In order to get all colliders you need to detect when something touches it, you need to know about multiple models per part. I don't know exactly how (or if) the colliders would affect the aerodynamics, but the different attitudes on reentry may be related to it. Assuming this is the case, perhaps a new mesh with a collider carefully shaped to behave like Stock would help to salvage the situation without reworking ReStock meshes.

Do a google for Lippisch P.13a - a god damned COAL fuelled fighter. And the thing were intended to be unarmed, its goal (by using coal - yeah, bad joke) was to ram the poor bombers in their way. Can't be more steam punk than that!

Chatterer as we would like to see on KSP.

It's raining clicks! Hallelujah! It's raining clicks! Amen! I'm gonna go out to Forum and let myself get Absolutely soaking clicked!!!! (no click images this time, only one set per page, I say! ) 202309090459z

That "shady ass" MMWD is not Module Manager, but a watchdog to warn you if you screw up with Module Manager. Tons of problems can be avoided when you just prevent more than one copy of Module Manager on your rig, and this is exactly what MMWD does. If you cared to look into the tool instead of calling wolf on it, you would had noticed that it never touches Forum MM, au contraire - it protects it if the user install any other version, older or alternative. @JebIsDeadBaby, you have an older Module Manager lingering on your rig, and an internal KSP bug is electing the older one to be used. Note that on the top of the list you posted, Module Manager is saying you have two copies of Module Manager 4.2.2.0 , but below on listing the files, you will find Forum's ModuleManager.4.2.2.dll and ModuleManager-4.2.3.dll. Checking on Forum Module Manager's source, we have confirmation that it's being compiled with the right Version number, so it's definitively the older one your KSP elected to use. Since you was using an older version of MMWD (1.0.1.1), that have this check deactivated on KSP 1.12.x (because I was told KSP was handling this correctly - what revealed being not exactly true some time later), the MMWD didn't barked at you about the problem. MMWD 1.1.1.1 (the newest) would had detected this for you. Seeing the Forum's MM release notes, this last version fix two problems, one of them on "loading the wrong physics file when you use the faulty PDLauncher workaround". Are you using any PDLauncher workaround? If yes, we may have found an issue - using an older MM even by having the newest installed, courtesy of one of the many bugs on KSP that Module Manager Watch Dog aims to detect - that is leading to your KSP to load the wrong data files.

"Father!!!! The Sleeper has clicked!!!!" AGAIN!!!

Ladies and Gentleman, we have a diagnosis. #houseMdFeelinds Somehow, your craft managed to get royally screwed: See, the SEQ containers are attached on the Lab, not on the Cargo Bay! So the SEQ weren't shielded from drag, plain simple. But HOW this happened? How some user could manage to attach a Lab with parts attached on its top node on the bottom node of another part? Well, they coudn't. This craft was screwed by something programatically. And we have already an issue about the Editor where the ReRoot is known to royally screwed up the attachment nodes (issue #66 on KSP-Recall). @Krazy1, do you remember using the ReRoot from the Editor on your craft?

Ah, I just remembered this one!!! (the second best KSP video ever!)

"Father!!!! The Sleeper has clicked!!!!" 202309081042z

EXACTLY! And that's the real power of Open Source - some maintainer are not doing a good job in your opinion? Anyone can do something about. Most will fail, usually, but we only need ONE success to have things back to rails (pun not intended). Again, there're drawbacks too (there's no free lunch), but most of the time the cost-benefit is positive. On a side note - be cautious about the CC-BY-NC-SA - the NC bites where you don't see it, it can be really counterproductive.

No, I'm not talking about this. I would be the first on the list if I would! I will not derail the thread with unrelated details, but I was meaning exactly what I wrote: active refusal to fix bugs even after the diagnosis was confirmed and a fix was proposed and even implemented. The last one I ended up shoving the fix on Recall, what's a hell of deviation of its intended purpose (not to mention bringing to me yet more responsibility on the damned thing as I now virtually doubled my test cases for acceptance).

I took them both. Amusing, but gave me a hell of a hang over!!! In time - CONFIRMED. Things happened on my rig exactly as you described. Thanks for your report and artefacts, now I have something to work with. I didn't did any further tests or analysis due working hours, but I will come back to this issue tonight (hopefully). Since I still think it's a KSP issue, I'm working this on Recall: https://github.com/net-lisias-ksp/KSP-Recall/issues/70 If I realise it's a problem on something else, I will move the issue to the right place. Cheers! — — POST EDIT — — I removed all non essential dependencies from the rig, and nothing changed. So this is not something being cause, induced or triggered by 3rd parties for sure. It's something on the CRG-15 Cargo Bay, or it's something on KSP itself. @Krazy1, on a side note… Since I was toying with your contraption, I found that setting the Chute's "Min Pressure" setting to 0.45 would bring us the most realistic (or the less unrealistic!) behaviour. With the chute firing up too soon, your craft would be facing down yet, and the chute wold surely be entangled on the aerodynamic brakes (nice idea! I liked it!). Setting the Min Pressure to 0.45, it will only fire after the brakes managed to do their jobs putting the thing nose up. (yeah, completely unrelated, but hell - I wanna play too!!! )

You care enough to use your time talking about it. (this is a compliment) That's the part of my argument I think you missed: people are leaving KSP not because they stopped loving it, but because they are tired of hating to love it. What's driving people away are the unsolved bugs and the cavalier attitude about user's long term experience that is plaguing this game for years. Most people never leaves Kerbins' sphere of influence, rare are the ones that reach Dune. Why? Because doing it is hard and time consuming as hell, and the last thing the user wants is to restart everything from scratch every time something is updated. But the user choose to update because besides potentially bringing new bugs, the update also fixes bugs that are peskying them and they can't take them anymore. So the user ends up caught on doing only minimalistic playing - what's, frankly, boring as time goes by. Sooner or later the user gets tired of doing the same things all the time (fooling around Kerbin), but he's still afraid of engaging in long term missions (months of planning and executing) because they're fed up of being hit by mysterious bugs - that suddenly goes away, but there's no hope that for good and so the user just stops playing. And I'm kindly ignoring the elephant in the room around here: a modding Scene that actually refuses to fix their own bugs too. And then the user goes hunting something else to play, and they will adopt the game that gives them whatever they mostly liked on KSP, even that at expenses of losing the things they care a bit less. Every single one of the games I mentioned gives you something that you have on KSP at expenses of some other things that they don't - so different people will prefer to migrate to different games. No, Juno is a completely different concept under similar mechanics. Juno is a "modelling dough" game, everything is procedural and you can build whatever you want. KSP is a LEGO game, you have a finite set of parts and try to build what you want from them. Being able to fly the contraptions later is just a logical aftermath, and everything else is just support. It may not look this way, but Juno is in a way better position to linger than KSP right now. Whatever Juno doesn't have yet, it can be implemented and better (like using the procedural parts as building blocks for "shelf parts" that need to be tested et all, and only then be useable - think on KSP's and Factorio's loving child), but whatever Juno does better, KSP is not following suit and, as it appears, never will. You are right about things not changing overnight - but they are changing nevertheless. To where this is going, it's up to us to decide. The 5 steps of Grieving/Acceptance. denial, anger, bargaining, depression and acceptance KSP is going to have a hell of a long Grief as it appears.

Well, "competition" is anyone that may "steal" your users from you, not necessarily by doing the same thing. If the user leaves you in favor of other game, then even Sky Rogue is a competitor because, hell, I'm using my free time playing Sky Rogue instead of KSP lately because I got fed up of finding and fixing bugs most of the time I decide to play KSP. As a matter of fact, KSP it's also its own competitor. I finally managed to built a KSP installation with good enough performance and excellent stability (now that I worked around the worst bugs) using… KSP 1.4.3 (this is the first week this whole year I didn't fired Sky Rogue). Yes, it's missing a lot of features, but yes, it's also missing a lot of bugs - and I can live without the features (since most of them are available on add'ons, and I'm skilled enough to fork most of them and make them running on it). So, if you are betting KSP is safe because there's no direct replacement yet for it, I'm afraid you are going to loose your money. Starfield is going to lure players willing to do interstellar travels - and you can customize your ships. No Man's Sky is a hell of a surviving and exploring game, and a decent open world adventure one - some of the things that some KSP players are asking for years. Space Engineers are a hell of a fun game for builders - just forget about newtonian physics while travelling on space and you will be good. There's also this Empyrion game, but I'm still to find time to explore this one. Elite First Enc… I mean, Dangerous is another hell of a open work rogue style game - combat, mining, survival, you name it. Oukey, no custom ships on this one. Surviving Mars will surely attract people willing to manage colonies. But, hey, all of these are high profile games. There're also the underdogs! About 5 years ago, some dudes from Czech Republic pulled a game called Planet Nomads from their hats. Hell of a game, very decent survival and building game. I spent a couple years playing it instead of KSP, and just stopped because I noticed that this game share some of the Unity problems that KSP has, that were mitigated exactly the same way, and then I caught myself writing tools to make my life easier on the game… And then I realised that, hell, I don't need another KSP in my life (and then I bought Sky Rogue!! ) This freaking game is not half of what KSP provides, but the other half is fun enough. Imagine a KSP where you can modify the terrain and build shelter with sparing parts and still need to survive (including hunting the local fauna). Kiss baby bye-by to newtonian physics, though - this game literally gave the finger to Sir Isaac Newton. Other interesting game that can lure some of the current KSP players is this new kid, EarthX - it appears to be more focused on the managerial aspect of Space Exploration, but I only discovered it this week and didn't bought it yet. (they directly support Linux and MacOS! #hurray!!!) And the list goes on. Once people decide to ditch KSP, they will ditch KSP for any other game (or games) that gives them whatever they were seeking on KSP. Different people play KSP by different reasons, and this was one of the reasons that made KSP such a Cultural Phenomena: it gathered together different people that, otherwise, would not spend time together on the same place. About Juno… Boy, don't belittle these ones. I don't think they are doing everything rigth if they really want to be a KSP alternative, but they are on the right track. But Squad was in the exactly same waters 10 years ago - there's nothing preventing them to do the same (other than a hell of a more fiercely competition nowadays…). KSP goes belly up, Juno is where I'm going. This is another game that I'm playing now and then, by the way. Would probably be playing it right now had I didn't managed to stabilise my KSP 1.4.3 for "serious playing". I completely missed that one… Thanks God this wasn't a rock aiming my nose. Yeah, KSP2 is a serious competitor for KSP¹ - I completely forgot they are/were maintained by different companies inside a Corporation… They are, indeed, competitors!

For reasons beyond the scope of this discussion, something happened in the past that made Forum Module Manager incompatible with the Welding Tool. TL;DR, I gave up and forked MM for my own use. Other tools were created to help keeping your KSP healthy using knowledge I gathered while doing Support around here, having them installed will prevent more than 80% of the issues that used to plague KSP in the past. This is the reason I advise to have a special KSP installation for welding things, as you need to have my MM Fork installed in order to use the Welding tool, as most authors around here will not support you if you use my fork of MM (obviously, I do). Additionally, I use a toolset that help me on maintaining homogeneity on my development, it's the KSPe thingy. Some people suggested me to create a All Batteries included package to make first installers life easy, it's the Modular Management thingy - it have all he startup add'ons you need. Installing the thing could not be easier (as long you know who to copy files on your Operating System!): whatever is inside the GameData on the zip file, should be copied inside the GameData of your KSP. Remove the Forum's MM if you have it installed on that GameData (again, it's advised to use a dedicated KSP for welding, so your main gaming one will be supported by all authors on this Forum - I will support you both ways, but I don't provide you with all the add'ons you need, so…) This file and this file give you hints about how your GameData should look after installing things. The following videos may help you if you need to learn how to unzip things on Windows (the most used O.S. around here, there're similar videos for MacOS and Linux if you need them), as well how to copy files from a place to another. Again, I strongly suggest you make a full copy of your gaming KSP and try things with it first - do not mangle with your main KSP until you are able to install and remove things with success, or you will ruin your KSP!!! Use a copy as guinea pig while you learn your way. I strongly suggest you unzip the distribution files on a temp directory, and then copy the respective GameData contents to inside your KSP's GameData. Remember, you need to copy the Zip's GameData contents to your KSP's GameData, not the thing itself (i.e., you don't want a GameData inside the game's GameData directory).

Can you provide us with a minimal craft where you reproduced the problem the last time? I'm sure you found something, I just didn't managed to zero on it. I'm digging around not only Forum, but also github and reddit for reports of problems involving Cargo Bays and drag and, indeed, there're some reports blaming Attachment Node Sizes - but not enough details about, so I'm still on the dark. However… Remembering my own bad experiences with Cargo Bays in the past (good thing I had saved all that backups!), I came to a possible M.O. : the Attachment Nodes Size may be a problem while attaching cargo on themselves inside the Cargo Bay! All my tests until now used only one part inside the Cargo Bay, but now that it's clear that the problem is more complicated than that, we may be facing a insidious problem on the cargo itself, not on the Cargo Bay… Or at least something on the Cargo Bay being triggered by the cargo's Attachment Nodes (instead of the Bay's inner attachment nodes as I had initially thought). You are not the first one to report such thing: where there's smoke, usually there's fire - or at very least a source of heat.

Because the assets is what make the game… The Game. And we are not pledging that the Game itself would be made freely available, we don't want to "steal" the game from them. The Source Code is just the nuts and bolts that ties the internal mechanics together. The difference between a Beetle and a Porsche is not the nuts and bolts they use, but on how they are used. There's this weird thinking on the wild giving too much importance and value to the Source Code. The Source Code is just the means, the end is where the money is, everything else is just operational cost. Commercial enterprises tend to hide their Source Code not because the Source Code is valuable, but because the ideas expressed in the Source Code are valuable, and by reading the Source Code you would get the whole idea without effort (i.e, without spending money on trials and errors until the damned thing started to work). On a thought experiment: if KSP would be completely rewritten from scratch using Unreal Engine, it would be the same Source Code? Not by a mile. But KSP would be still KSP, the Kerbals would be still the Kerbals, and other than the absence of a few glitches from Unity (and the presence of some new ones from Unreal), the end user would hardly note any change. Now, another thought experiment: there's no DRM on KSP, there's absolutely nothing preventing me (other than my sense of morals and my professional ethics, of course) to illegally distribute bootleg copies of KSP on the wild [edit: under a nickname or fake persona, obviously!]. What difference would make if by any reason I manage to recompile the whole thing fixing the bugs before illegally redistributing it? Whoever had downloaded the illegal copy would just download another illegal copy of the damned thing. No (further) harm, no (further) foul. on the other hand, if I have the rights to legally recompile KSP with the bugs fixed and legally distribute such binaries (and only the compiled binaries) to people that had legally bought KSP (and they have to buy the thing, because I would not redistribute any of the assets that make the game The Game), exactly where are the harm of this endeavour? If only people that had bought the game would be able to use such derivative binaries, people that don't have the game would be enticed to buy the damned thing, or just no use it al all. people that had downloaded a bootleg copy of the game would also have access to it, but they already choose to be on the dark side, nothing will change here. Again, no harm, no foul. But people that had bought the game would have a better experience, and people that didn't would have an incentive to buy it. Source Code is nothing but cement, bricks, nuts and bolts. The first time you build something incredible using a novel combination of such commodities may give such Source Code some intrinsic value due it's scarcity, but as soon as people out there figure out how it was made (or create new ways to accomplish the same thing), that value quickly erodes into oblivion. KSP's Source Code worths very little right now, to tell you the true. Not only because there're shady ways to get it anyway (the shady practices I mention all the time), so anyone with the will and freely available tools and knowledge (and a bit of skills and free time) already have it - but because there're already alternatives to KSP on the wild, some of them with better implementations of some KSP's features. What's still worthing something is the RIGHT to use this Source Code legally because there're still demand for KSP itself, but such demand is also eroding as the eternally unfixed bugs on KSP are making people enough fed up. The World is evolving, the competition is not only catching up but surpassing KSP. What still remains valuable are the Cultural Phenomena KSP still are due the good memories of the past achievements. But this will not last forever.