Lisias

Nope. Squad will be taxed everytime Unit detects you installed the game again, with or without downloading it. Unity has telemetry embedded, and remember they merged with IronSource last year, gaining access to a whole set of tools. Things are that bad. You will need to keep your game installations completely isolated from the Internet by firewalls, but I suspect that the merge with IronSource will allow them to cross reference data by other means - like other programs installed using InstallCore being able to search your system for copies of Unity Runtime and reporting. Do you know all that tracking mechanisms used to spy on users? They are going to be used against Developers and Publishers too. They had a whole year of planning before announcing the stunt - the tools they need should be already deployed by our backs. I said before and I will say again: these guys are not stupid. Things are really that bad. ---- POST EDIT --- @ColdJ, I think you will (NOT) like to read this: Sorry.

Yes, or at least it worked last time I tried. As long the depot is not removed from the system, it's available for downloading by using the Steam Client's console or an 3rd party tool like https://github.com/SteamRE/DepotDownloader I recomend doing it anyway. As well any other Unirt game you had bought there. Or in GoG.

You are not going to be directly affected. Squad will. Suppose you buy a Windows notebook and a Steam Dexk too for Christmas, and you have installed KSP on them too. Now Squad will be taxed by 2 installs if you do it after January 2024. Now imagine the you decided to upgrade the Deck's SSD and reinstall everything from scratch. Squad will probably be taxed by another install (probably because theoretically only new installs are taxed, but Unity openly says they don't track individuals, they will infer the count by aggregation). Now your Linux machine's HDD dies and you replace it with an SDD and reinstall the World. Guess what? A new Install for sure, because the previous install wasn't counted because it happened before 2024 but this one will count for.sure. Squad will pay a fee every time an SDD or HDD with KSP installed is replaced.

"Tiger, Tiger, Tiger" (tygah,. tygah, tygah) There're alternatives, but it's nothing that one vendor can accomplish alone.

To anyone still wondering why Open Source is needed, google about the ongoing Unity drama about the Unity Runtime. I had warned months ago that we were on the verge of an Inflection Point here. It's not time to start to move?

Problem on Linux is that people trying to make money from it still believes on the "one size fits all" model used by Windows. It doesn't works - Linux would not exist at first place if it did. Steam Deck is an excellent example on how someone needs to tailor the thing to a finality to make Linux useable for the average end-user. What you really need is someone tailoring Debian to be used by people like you. Anyway. On a blind guess, I think that your programs need to have the setuid configured to root. https://www.liquidweb.com/kb/how-do-i-set-up-setuid-setgid-and-sticky-bits-on-linux/#:~:text=This is primarily used to,in Linux is 'sudo'. It's really a bad idea from the security point of view, but still… It may help on your problem.

Weird, the problem is happening on a DLL called GroundConstruction, and you must have it in your GameData, because it's being logged as expected: [LOG 20:45:47.982] Load(Assembly): GroundConstruction/Plugins/GC.UI [LOG 20:45:47.982] AssemblyLoader: Loading assembly at J:\SteamLibrary\steamapps\common\Kerbal Space Program\GameData\GroundConstruction\Plugins\GC.UI.dll [LOG 20:45:47.983] Load(Assembly): GroundConstruction/Plugins/GroundConstruction [LOG 20:45:47.983] AssemblyLoader: Loading assembly at J:\SteamLibrary\steamapps\common\Kerbal Space Program\GameData\GroundConstruction\Plugins\GroundConstruction.dll [LOG 20:45:47.985] AssemblyLoader: KSPAssembly 'GroundConstruction' V2.6.0 Do you use CKAN? In a way or another, please send me a new KSP.dll . Don't bother to reproduce the problem, just reach the Main Menu, then quit KSP, then send me the new KSP.log.

Kindly dedicated to Unity3D users around the Word. The Who - Won't Get Fooled Again.

No. He's going to buy everything they can using stooges, and when things get better (and it will this time eventually, see below), he will be able to excerpt yet more power over the board. There're people smarter than you scattered over the World, some of them earning money from you. It's better to keep this in mind, it may save your business eventually. And this is precisely the reason Unity Tech is able to do whatever they please, besides not exactly how they want. Unity has a lock-in on their market, and they has decided it will be more profitable to exercise their muscles on people like you than trying to increasing their market share by luring people from other engines. I think they will accomplish whatever they really want exactly because of that - it's perfectly possible that this drama is a plot to accomplish something we are not seeing - as perhaps enabling a hostile take over, like Stephen Elop did on Nokia before Microsoft grabbed it. In a way or another, what remains to be answered is: what you are going to do to not be fooled again? Uh.. Whoops. — — POST EDIT — — Found very interesting information here: {SNIP} Given the sensibility of the subject, I will copy&paste the post here in the case that one gets removed by some reason. Ladies and Gentlemen… I think we are witnessing a hostile takeover. — — POST POST EDIT — — The Unity's ToS repository was deleted. Thanks Kraken there're mirrors made recently : https://github.com/thaliaarchi/unity-termsofservice I strongly suggest to anyone developing on Unity to mirror and clone **everything** on https://github.com/Unity-Technologies as soon as possible, because the dices are starting to roll.

I disagree. It makes sense perfectly, these guys are not stupid. Someone made some calculations about the Unity's prospects for the future and realised they will not get the money they want by going that path - perhaps due competition, perhaps due the cost of fixing the long list of technical debits, perhaps because the new processors being launched are screwing them due some unhappy design decisions made in the past and fixing it is going to be hugely expensive - or perhaps by any other reason beyound me. Or all of them together. So if they are not going to make enough money by increasing their user base, the obvious solution is to squeeze the installed user base the most they can while the ship is afloat. It's a "sound business decision" : if your asset is going to be scrapped on the end of the current fiscal year, you don't need to waste money on preventive maintenance, and can use it on activities that will reduce its life span (as long it's not destroyed before the end of the fiscal year). As a matter of fact, you must do it as this is the best way to maximising the incoming the asset is able to provide. Unreal Engine is not only a completely different engine, but also has no bindings to C#. Restarting from scratch to use Unreal will demand not only a completely restart on development, but also a complete new team to start with - what would include the decision makers. I find it unlikely it will happen - mainly because this crapstorm is not going to affect them that much: TTI is big enough to be able to cut a nice deal with Unity Technologies to minimize the fees. And since, as I said above, they are not stupid, they obviously know it. If they know it and tried the stunt the same way it's because they know they are not going to get enough money on new sales - what implies they are betting there are going to be way less sales for Unity Games than they want. If your marketshare is stagnating and you want more money, your only option is to squeeze the marketshare you already have. And, in time, the money for Research & Development should be already on their budget. If this money is not there anymore, it's because someone took it. Who? Why? When? That's the problem: misalignment of expectations between Unity's stakeholders. Unity's high brass are there for the money. They realised that trying to stay competitive will incur in costs that will undermine their expectations for profit. So they think Unity3D is going to loose market and, again, the only way to keep the profit at the levels they want is to milk the installed base instead. This is hardly a novelty - Oracle, SAP et all do exactly the same: most of their income is not by doing new sales (how many people buy a new SAP license nowadays?), but by the recurring fees they get from the current costumers (or new products they force them to buy by deprecating older ones and offering replacements). All of this had happened before. All of this will happen again. Exactly. Fool me once, shame on you. Fool me twice, shame on me. And, frankly, this is hardly the first time Unity screws their customers over. Such a decision, IMHO, should have been considered for at least 12 months, 24 from a technical point of view.

It really depends of the nature of the mods. PartSet only mods, you can shove as much as you wish as long you have memory for them. There're still a few loose ends on KSP where a badly configured Part Config can cause some damage, but these are the exceptions. Mods that adds features to the game, when well written, are also usually safe - as long no one screws with them. If something breaks TweakScale and prevents it from work, it's obviously that all you scaled parts will be screwed too. Mods that changes features on the game, on the other hand, are the hairy ones. These need to have a high degree of testings and validations that are not usual to be done by enthusiasts. Interestingly enough, most of them around here ends up working pretty well. We have a minority of add'ons playing havoc nowadays, and all of them - and I want to say it again, all of them with known issues that are being refused to be fixed. 95% of the support I do is about known bugs that are recurrent in the wild because they are simply not fixed.

Found the problem! Or, at least, what looks like being the problem: [EXC 20:51:35.274] MissingMethodException: AT_Utils.UIBundle AT_Utils.UIBundle.Create(string) System.Reflection.MonoCMethod.InternalInvoke (System.Object obj, System.Object[] parameters) (at <9577ac7a62ef43179789031239ba8798>:0) Rethrow as TargetInvocationException: Exception has been thrown by the target of an invocation. System.Reflection.MonoCMethod.InternalInvoke (System.Object obj, System.Object[] parameters) (at <9577ac7a62ef43179789031239ba8798>:0) System.RuntimeType.CreateInstanceMono (System.Boolean nonPublic) (at <9577ac7a62ef43179789031239ba8798>:0) System.RuntimeType.CreateInstanceSlow (System.Boolean publicOnly, System.Boolean skipCheckThis, System.Boolean fillCache, System.Threading.StackCrawlMark& stackMark) (at System.RuntimeType.CreateInstanceDefaultCtor (System.Boolean publicOnly, System.Boolean skipCheckThis, System.Boolean fillCache, System.Threading.StackCrawlMark& stackMar System.Activator.CreateInstance[T] () (at <9577ac7a62ef43179789031239ba8798>:0) AT_Utils.PluginGlobals`1[T].init_instance () (at <dfa2fbe96124462794ebeceb1d666cb2>:0) AT_Utils.PluginGlobals`1[T].Load () (at <dfa2fbe96124462794ebeceb1d666cb2>:0) AT_Utils.PluginGlobals`1[T].get_Instance () (at <dfa2fbe96124462794ebeceb1d666cb2>:0) GroundConstruction.JobBase.get_GLB () (at <153e62ae099745349276ac22b21d61e0>:0) GroundConstruction.VesselKit+<>c__DisplayClass20_0.<count_kit_resources>b__1 (PartResource res) (at <153e62ae099745349276ac22b21d61e0>:0) AT_Utils.CollectionsExtensions.ForEach[TSource] (System.Collections.Generic.IEnumerable`1[T] E, System.Action`1[T] action) (at <dfa2fbe96124462794ebeceb1d666cb2>:0) GroundConstruction.VesselKit+<>c__DisplayClass20_0.<count_kit_resources>b__0 (Part p) (at <153e62ae099745349276ac22b21d61e0>:0) System.Collections.Generic.List`1[T].ForEach (System.Action`1[T] action) (at <9577ac7a62ef43179789031239ba8798>:0) GroundConstruction.VesselKit.count_kit_resources (IShipconstruct ship, System.Boolean assembled) (at <153e62ae099745349276ac22b21d61e0>:0) GroundConstruction.VesselKit..ctor (PartModule host, ShipConstruct ship, System.Boolean assembled, System.Boolean simulate) (at <153e62ae099745349276ac22b21d61e0>:0) GroundConstruction.GCEditorGUI.Update () (at <153e62ae099745349276ac22b21d61e0>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) You have a serious versioning conflit between GroundContruction and AT_Utils. This is generating tons and tons of Exceptions, INSIDE THE EDITOR's UPDATE, and this may explain these weird misbehaviours on it - things inside Editor happens under a somewhat fragile equilibrium between add'ons. and if something royally screws up the timings (and logging into KSP.log every Update is a hell of a timing screwer) , things start to happen out of order and this may explain this misbehaviour. Uninstall Ground Construction and see if the problem goes away - I suggest to do it on a full backup, because removing (or deactivating) add'ons and loading savegames will completely screw up any crafts that would be using them (it's the reason people gets screwed when TweakScale is killed). If yes (and I think it will), advise here and we will try to find a fix for it - I want to have confirmation before poking on other authors' code… "If you wish to catch a rabbit you put a ferret into the hole, and if the rabbit is there he runs." — Hercule Kerman.

Do you trust them? They will be the one counting the installs, they will be the ones deciding when if they are wrong about it. Ah, yes, they will be the ones that will lose money if they find they counted something too much. Essentially: "We are going to decide, using our own methodologies, how much to you own us every month. If you find we made a mistake, submit a form to our compliance team, those salaries are paid by the fees we are charging you, so we can analyse your case". (and I had to control myself to do not purposely misspell "analyse" here).

@Tokamak, you are not the first case I read about - someone on reddit got it recently: I initially misdiagnosed the problem to be something preventing TweakScale from being loaded, but somehow the problem just vanished from that user's machine without any action from them. What's kinda rule out TweakScale, this thing when misbehaves, do it consistently. Now you are telling us that this is happening on Stock 1.5 tanks - and on them alone. Since you are still getting the problem, can you please send me both a botched craft file as well the KSP.log with a test session where the problem happened? Please quit the game into Main Menu (or close KSP) before copying the KSP.log to prevent it from being truncated. Cheers!

These CEO guys, they are not stupid. They know it. It's the reason I'm convinced Unity is going to cash whatever they can and ditch the engine, perhaps selling it to someone else. They are quitting the milk business and entering the steak one - using the old cash cow as Startup. And so they will just pay the racketeers, and will need to make the money somehow to keep afloat. It's the reason I think that the developers that will linger will be the ones that will screw their users the same, because I don't see a way of survive this ordeal otherwise. What's essentially a self realizing prophecy: since I think Unity developers will be forced to screw me over somehow, I will avoid games made on Unity to avoid getting screwed, what makes the developer's life harder by decreasing their incoming, forcing them to increasing their revenue by exploiting the current user base instead of increasing it, screwing users that so will avoid Unity games. Rinse, repeat.

And how they will tell a new installation of mine from a reinstall due a Windows crash followed by a total reinstall (see Vãos on YouTube this week). How they will tell a pirate install from a legitimate one? How they will tell honest installs from unethical competition reinstalling the game ad nauseaum on some sort of install farm to drive them out of business? How they intend to do that without breaking the GDPR on EU, or LGPD in Brazil? Who will be liable to the inevitable fines, Unity or the Game Developer?

Worst case scenario - both KSPs will be DRM'd next release (to be launched before 2024), and previous releases without DRM will be withdrawn from the Stores as a way to cut losses, preventing people to make multiple installs - what tax them further without any incoming to counter-part it. As a colateral effect, kiss mods bye-bye. Murum aries attigit. There's no way to put the genie back to the bottle. It's clear that they want to increase the incoming my exploiting the installed base, not by increasing it. This fails to stick, they will try something else later. They are going to milk the cash cow to the death, and then sell steaks. It's not a matter of "if", but "when". They are not changing the contracts. They are changing the licensing terms of the Runtime. This is perfectly legal on USA (Game Publishers do it all the time, not to mention Microsoft). It's shady at best, but not illegal. And if someone wins a legal battle about the older Runtimes, suddenly a zero day vulnerability will be detected on it and anti-virus will start to block the old runtimes as well Stores will be forbidden to distribute it, and then Unity Tech will "kindly" provide a patch with the new runtime (for "free") with the new licensing terms for the game developers that are not willing to refund the games. Microsoft will just pass the cost to their costumers. MS will not risk challenging something they need to keep Windows users under their will. 1) Because is 20 cents per installation, not sell. And a sell can have many installs over the lifespan of the product. 2) Tell that to the Cult of the Lamb developer. How? I had already bought the thing, the sell is done. But it will still be generating costs to the developer every time I install it again (I have a machine with a install for every last KSP versions - 1.0.5, 1.1.3, you got it. How they will pass this cost to me? They weren't. They laid off 600 of their workforce last may. There's no research anymore, and I doubt it will be any further development - I'm betting that whoever is left, will be only closing issues from now on. Not to mention the elephant on the room: how in hell they plan to track these installs? Someone remember IronSource? It's obvious by this time that they were planning this movement for more than a year already, way before merging with IronSource. This is the reason I think that Unity3D's cash cow will be sold as steaks - they don't find the milk profitable anymore.

I'm going to side with Squad, it's their pockets being picked. Assuming this krapness sticks (apparently they are backpaddling on this - hopefully), first we need to know what happens if "bootleg" copies of KSP are detected by Unity. Are Squad liable to pay for pirated copies installed? If no, so damn Unity - KSP¹ at least is extremely friendly for modding and we have authorisation to tinker with the API as long we don't touch private entities. I paid Squad, and so my legal obligations is to them. They had authorised us to have multiple installations as long we run only one at once, and we have the right to use firewalls. Linux and Mac users have already user configurable firewalls, a simple external Mono executable can be made to download a list of IPs to be blocked from somewhere and automatically configure the machine. Some of us already do it, anyway. Windows, on the other hand, will be a problem (as usual). We will have an issue if somehow Squad would be fined by these actions. We, users, may not have signed any contract with Unity, but Squad did - and, as we can see, Game Publishers and Developers are now suffering the same abuses some of them inflicted on us, end users: licensing terms can be turned against them as easily as it can be done with us. Problem is that this will prompt Squad to remove all previous releases from the Stores and publish a 1.12.6 with DRM as a measure to cut losses, what will shut down modding on KSP¹ for good unless creative (and probably illegal) measures are taken by us. It's absolutely hilarious that I just took notice of this: Well, if RockStar can do it, perhaps Squad can do it too? Releasing "cracked" copies of their own products, with all possible telemetry turned off? P.S: Yeah, I know Unity Tech said that only new installations counting from 2024 will be taxed - but they didn't said that only new games will be affected, so you can bet your mouse KSP¹ would be affected too. In a way or another, we have 4 months to "crack" this nut. (pun really intended) Sorry… — — POST EDIT — — Just found this one: https://www.gamesradar.com/viral-developer-says-their-free-survival-game-and-squid-game-parodies-would-have-cost-them-dollar56-million-under-new-unity-rules/

And then committing into "piracy" on a thingy I had bought legally? If I going to commit a crime, why bothering starting legal at first place?

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.