Lisias

To remember younger and brighter times.

Back to the discussion at hand: Had the sales of Juno: New Origins had been impacted by KSP's add'ons being open source? (rhetorical question) Because, you see, there's a lot of features on KSP's add'ons published around here that mimics some of Juno's almost perfectly. The same rationale applied against opening KSP's Source may be used to justify a hypothetical Jundroo decision to go cease and desist or even injunction against KSP's Add'Ons, right? There's this weird thing on business called competition. Of course you have competition, and of course anything you do may be used against you by the competition. As well anything you won't do. You need to measure pros and cons, and then look for the best cost/benefit. Now, bear with me, what would make a major damage to your competitiveness: having your old, legacy features being cloned by your competition in an attempt to fight for any scraps you let drop from your table, or leaving bugs unchecked for years eroding the trust of your paying customers on your product? (hint: Steam Charts have the answer). Of course, I'm ignoring the obvious 3rd option: offering a tightened product, that had its bugs fixed over its lifespan and now, at it's dawn, there's not too much left to be done except doing some promotions to keep things alive while the new iteration is not ready to hit the shelves - but this ship, obviously, had already sailed some time ago. Not to mention that Unity itself publishes its Source code making wide open and available all the knowledge and tools to understand all the data structures, from memory usage to files being loaded - so, really, everything is already on the open to anyone knowing how to use the needed tools. This is the drawback on using Open (or Shared) Source, I concede that: it's pretty, pretty hard to keep secrets from smart people [when publishing the Source], and keeping secrets more often than not pays back on the market. Besides… Even with KSP2 getting feature complete, a lot of people will still be locked out of it. This thing only works (really fine) on Windows over beefy (and expensive) machines, not to mention a lot of low power and way more affordable devices that will never be able to run KSP2, but will run KSP(1) marvellously well if someone care to port it (sooner or later we would have KSP running on pregnancy tests too, do you wanna bet?) And there're also MacOS and Linux users, we still exist!!! Where is our part on this KSP2 bargain? Such people will stick to KSP1 for some time yet.

Dude, you brightened my day - I had laughed so much that I'm felling like I'm a passenger on a plane where Jeb is the pilot: in need to change my underwear!!!

I have a problem with this statement - not because I think you are wrong, but because I fear it may be right That's another statement I have a problem with, by exactly the same reasons. Assuming this will ever happen this way, there will be no Community around anymore and, so, opening the Source will be of little to no effect. Yep. And had I mentioned that these assets are already installed on our rigs (no matter we had legally acquired the game or not?) Everything, absolutely everything (including the source code) is already available to anyone that knows how to use some tools - it only happens that doing so without a legal access to the Source Code is a violation of the EULA and to the Forum Guidelines. And most authors around here are not willing to do it this way, me included. It's interesting how people don't know their own History. The first time I "modded" a game I was a kid toying with disk sector editors on Apple II games - essentially translating text to PT-BR just for the lulz, trying to add more lives or just to understand how in hell that dudes managed to read the analog joystick and reading the keyboard latch at the same time without screwing up the framerate. The second time I was tinkering with QuakeC, unpacking and repacking the Quake1 PAKs with the tools the very developers themselves had published for us and being kicked from Team Fortress (the first!) matches by using macros to make easier to do rocket jumps. Hacking Apple II games didn't harmed Activision neither LucasArts Games - all of them passed through this era with flying colours into MS-DOS Gaming and became a Legend on their own. Publishing the tools needed to (legally!!) hacking the Quake's PAK files (not to mention the QuakeC source code used to script the game!) didn't harmed ID at all, as the following publishings clearly demonstrates. As a matter of fact… It's theoretically possible to build a KSP knock off right now. KSP is so open, so tinkering friendly, that it's perfectly possible to replace the whole GameData with new content, as long someone is wiling to do so. And using the knowledge already available on the myriad of git repos scattered on the wild. And there's nothing preventing such entrepreneur from selling this new GameData replacement on the wild - it only happens that he/she[snip] would not be able to advertise this work here on Forum, but the rest of the Internet is wide open to him/her[snip]. What such a entrepreneur would not be allowed to do is to embed a copy of the KSP's essential binaries (the "managed" stuff on the KSP_x64 folder), so he/she[snip] would only be able to sell the thing to people that had bought KSP (or to people that acquired it on… non Forum Guidelines compliant ways. ) So, even that such knock off ended up being a success, people willing to run such knock off will still need to have bought (or to buy) KSP. So, and again, no loss of revenue here neither.

No doubt! What I'm proposed is a way to allow us, authors, to read the Source in an EULA e Forum Guidelines friendly way, so way more of us would be willing to look for the infinite amount of bugs and code mitigations as add'ons. Such knowledge can be later use by PD to publish a DLC on the consoles, using the already existent patching facilites inside KSP, as the Upgrade Pipeline to salvage existing savegames and craftfiles, and the MonkeyPatching (yeah, there's such a thing inside KSP!!) to apply code fixes where a external mitigating measure is not feasible. The whole proposal, since the beginning, is exactly what I wrote in my previous paragraph: an EULA and Forum Guidelines friendly way to access the KSP (1)'s Source code, all the rest are what we expect them to gain once the Source would be available. Unless, of course, it's know that P.D. is still working on KSP(1), with a small but capable team of developers actively working on such bug fixing. That would, indeed, make our proposal useless. Not to mention that merely compiling the Source is meaningless by itself, because unless the code is made OSI, the resulting binary would still be TTI's Intelectual Property and publishing it would be piracy exactly the same way is piracy to redistribute the game assets, as missions, meshes, models, et all. The compiled binary is essentially useless without assets, and these are not going to be part of the bargain - we don't need them, we already have them as we had bought the game and have them installed on our legally acquired copies in our machines. I won't deny that even 1.3.1 source code would be of immense value, but my experience on KSP-Recall tells me that we really need at least the last release of each minor interation (i.e. 1.3.1, 1.4.5, 1.5.1, 1.6.1, 1.7.3, 1.8.1, 1.9.1, 1.10.1, 1.11.2 & 1.12.5). Every new minor release broke things (being 1.4.0 and 1.8.0 really really disruptive releases) and fixing these bugs are (most of the time) much easier when we have a previous release when the feature was working. It's one of the reasons I'm so adamant (on my add'ons) on supporting things down to the oldest KSP release possible: doing black box testings with the same code over different releases helped me to diagnose problems innumerous times. I diagnosed the Strut bug introduced on 1.2.2 this way! This is were things can get interesting! No new releases are really needed! KSP also have internal mechanisms that can be used to patch and upgrade itself without breaking existing crafts and savegames: they are the Upgrade Pipeline and the MonkeyPatching. These are very powerful tools, already implemented on KSP, that can be explored by a new DLC where the fixes would be applied at startup, making unnecessary the release of new versions - both on Desktop and Consoles (assuming they have DLCs on Consoles, of course, as I really don't know). This may save some money on the process, as it's my understanding that publishing a DLC is cheaper than a full game release. Make the new DLC free to anyone that bought KSP, and you are set.

By publishing the KSP.log, one would be able to inspect it and exactly pinpointing the cause of the problem - saving you all the hassle of reinstalling the whole shebang! Even the **FATAL** problems are only diagnosed by inspecting the KSP.log, where who had patched the victim (and when) are logged and, so, the information can be used to check who is borking on you. For your luck, some other user had already published their KSP.log with this same part flagged, so we already know what's happening. You will find the answer on TweakScale's thread:

Virgin Orbit gone belly up. Bought the farm. Kicked the bucket. An unhappy accident or a worrisome trend? https://gizmodo.com/bankrupt-virgin-orbit-sells-scraps-four-bidders-auction-1850468864

It's BDArmory: [LOG 18:37:34.335] [TweakScale] ERROR: **FATAL** Part BDA.EJ200 (TFJ-EJ200 "Typhoon" Afterburning Turbofan) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 The last release introduced a double patch by accident. AFAIK they are already aware and it should be fixed in the next release. Until there, the known workarounds are: Rolling back to the previous BDA; or removing the file "BDArmory/Parts/EJ200/caesar_hone_60/BDA_EJ200.cfg" this part will be removed from the game, however Cheers!

I never said it would help the sales. I said it would help us to find and mitigate bugs, as well write better add'ons - that, so, will help to improve the sales. I hope I don't have to prove to you how better addons and fixed bugs improve the sales of a game... Point taken. We are advocating for an exception so.

EXACTLY. Opening the Source Code does not cause impact on the sales. I'm glad we finally had reached an agreeement on the subject! My argument stands: since opening the Source Code makes easier to write better addons and to mitigate bugs, and since it's well proven that better addons and fewer bugs improve sales, the logical conclusion is that opening the Source is a winning move! Thank you for your contributions.

Yes. You can publish your KSP.log on drobox and post the link here, so I can see who is borking on you.

It was up to date at the time of the release, in May 2015. And, look, about 6 months later they had one of their best scores! https://steamcharts.com/cmp/244850,220200,954850#All Really doesn't look they flattened the sells to me - au contraire, looks at it helped, and helped at lot!! I'm not sure I could understand this statement. the way I could translated it to PT-BR is something like "Não vai prejudicar as vendas de versões atualizadas do jogo, você precisa até mesmo fazer uso do fonte.", but it sounds like two disconnected phases loosely tied together. I will tackle the part I understood, "make use of the source": There's already shady ways to make such use, but they are not EULA and Forum Guidelines compliant. We want to do things on the clear There's many ways to make use of the source: reading it so we understand exactly how things work inside KSP so we can better and safer write our own code, is one of them. being able to spot and confirm the bugs without spending weeks on blindly doing black box tests is another. knowing the internal KSP's mechanisms to update and patch things so we can code mitigation measures to effectively fix KSP in the user's machines without relying on yet more shady practices is yet another one. None of this involve any kind of "competition" to the franchise, we are not proposing publishing derivatives, There's no way to do such without the assets, and the assets are not needed and are not wanted on this bargain. And we already have them, anyway. Anyone can have access to them by buying the game. And we are not asking for it. We, paying and EULA abiding customers, already have them installed on our machines and we don't need any special right to republish them: Steam, GOG, EPIC, Humble, PD thenselves, they are already distributing such assets - there's no need for us doing it. We are not asking to make the game free as in beer. We are asking to have access to the source code so we can be able to do a better work here, and we are proposing that such work will have a positive impact on the franchise - it surely did for Space Engineers. Non Sequitur: In philosophy, a formal fallacy, deductive fallacy, logical fallacy or non sequitur[1] (/ˌnɒn ˈsɛkwɪtər/; Latin for "[it] does not follow") is a pattern of reasoning rendered invalid by a flaw in its logical structure that can neatly be expressed in a standard logic system, for example propositional logic. Source. It was stated that "As soon as they release the code or make it legal to work on, those sales drop to zero", and I had proved without the slightest doubt that releasing the source code does not have the flattening of the sales as consequence. Ergo, that affirmation was a non sequitur. Publishing buggy games, on the other hand, is a known and proven way to seriously hinder the sales - do I need to pinpoint evidences of such?

Non Sequitur. There's no causality between opening the source and flattening the sales. See Space Engineers, for an example, usually have THREE TIMES more users online that both KSPs combined: https://steamcharts.com/cmp/244850,220200,954850 And they had published the source in the past, when the game was still "young". Links for the (pretty old) sources: https://github.com/KeenSoftwareHouse Link for a discussion about the reason they choose to reduce the source's audience: https://blog.marekrosa.org/2017/08/statement-on-space-engineers-github.html . Open Source can help, but also can hinder, depending on the stage of the development. Our opinion is that at this stage, KSP(1) has nothing to loose on opening the source, as it's already had run its course, are living more on less on life support (I doubt there's someone left for fixing any of the numerous remaining bug on KSP(1)) and there're still some traction for users wanting to have it fixed. P.D. would not be waving the Intelectual Property, people will not be allowed to sell KSP's derivatives - the characters, the histories, the missions, the graphics, all of that will be still under Copyright protection. No one is going to do with the source more than it's already possible using shady practices already being used by people that don't mind the EULA and the Forum Guidelines. I agree that just opening the Source is not a panacea for all evils, and there're risks involved, but success cases in the wild prove that there's no way to affirm that opening the source will be the Doom™ for the franchise. It may be exactly the opposite, it has good chances on extending the franchise life by improving the KSP(1) sells, helping funding KSP2. Not to mention people on Consoles still complaining about the bugs and lack of updates. We manage to openly diagnose and mitigate such bugs, we make it feasible to bring back life to Consoles later, what will at very best be a nice P/R stunt.

Republic AP 100. When Moar Boos... I mean Engines was a thing! Jeb would love it!

Hi. Sorry, but pasting part of the log is not enough. We need the full KSP.log that, almost all the times, it soo big to be posted on Forum anyway. Please publish it on dropbox or similar service, and then I will be able to inspect it. You surely was bitten by the nasty KSP's Assembly Loader/Resolver bug, and only the full log will help me to pinpoint who is the one borking on this.

Yes I am. Not only by discussing things here, but doing what I asking to do and even a bit more. I'm TweakScale's maintainer for almost 5 years by now, and I'm still here giving support to its users - not only on TweakScale (to tell you the true, most of the support "tickets" are about 3rd parties!). Believe me, I'm like a dog with a bone! But this bone is too big for a single hound! Found some already, some of them not exactly what we asking but near enough: I think it's time to consolidate my points (pos and cons - and yep, there's some). I will start working it by night. This may be one of the cons, by the way: contributions. Receiving contributions on an ARR repository is hairy due the different Copyright Legislations around the World. The Berne Convention signatories agrees on a minimum set of rights for authors, but there's no real "ceiling" for them, and one signatory needs to respects the rights granted by others: so, if you accept code from a Brazilian, you need to respect the Brazilian legislation for that commit, and if you accept code from a Australian, ditto. And so on. OSI makes things way easier on this field, as it ties both sides to a common ground (written in blood and sweat over the time - 30 years on it already), but now and then something new still arises. There's also the need to have someone inspecting the pull requests before merging - once you merge something, you get the bonus but also the onus: if the code is infringing some copyright, you ARE* liable to it (and there're probably people that would do it on purpose, unfortunately - in the Internet, no one knows you are a dog unless you say it). So, on an initial move, I would settle to a Shared License style (like Unity does) as this appears to be path of least friction for them to release the source: if they can't accept contributions right now, there's no real incentive for them to release the thing under a license tailored for getting contributions. Make no mistake, I like OSI and I would prefer it as OSI, but there's no free lunch on OSI (to tell you the true, it's easier to get "free lunch" from ARR), and they need to consider things that we don't. I think it would be still a winning move, but they don't need do it all the moves at once: they can go OSI later. Besides less than optimal, a Shared Source approach will still allow us to deep dive in the code and, with such knowledge, will allow us to write better add'ons, fixes and mitigations. There're code on KSP that already allows a lot of external interventions, as the Upgrade Pipeline and the Monkey Patching - we learn how to use them, and suddenly a lot of potential troublemaking and shady practices are not needed anymore. Having Legal, Forum and EULA 100% compliant access to the source code will be a huge benefit to anyone willing to contribute to KSP and still be on the right side of the pertinent legislation for a reason or another. (and yeah, I ended up writing most of my argument in advance! ) — — EDIT — — * Dude, how in hell I let that "not" pass trough? Geez, you are liable for the commits you merge - just to make things clear. I think I need to sleep a bit more...

Damn. Got distract by DayJob© again! Uh… I'm afraid I took the Oreo by accident… Is @WhatALovelyNick around?

Google is your friend. But, here, check this out: https://steamcharts.com/cmp/244850,220200,954850 https://github.com/KeenSoftwareHouse

Space Engineers doesn't agree with you. There're approximately 8550 online players right now, 3 (THREE) times more than KSP and KSP2 combined. Source code for the game: https://github.com/KeenSoftwareHouse

One thing that you will probably want to learn from that tutorial I posted is how to make full backups of your game. So, everytime you are unsure about a change, you just duplicate the whole thing and try it. If it works, you delete the backup and it it doesn't, you restore it using the backup. Of course I believe you. I wrote the patch! You will only be peskied about it when the Module Manager's ConfigCache changes, what is a way to detect when you installed or removed something from the game. It's important to remind you about the HotFix because sooner or later the problem it fixes will be solved, and in a way that may end up screwing your savegame. By example: let's suppose that B9PS patches changes to automatically remove FSfuelSwitch from the parts before injecting itself on it, but you like FSfueldSwitch more and had applied the HotFix that prefers FS. Well, suddenly all your parts with FSfuelSwitch will be converted into B9PS default options, and this will probably ruin some of the crafts flying around in your savegame. Fortunately, modern KSP will (most of the time) detect the problem and yell about it when you try to load a savegame, but yet, it worths to let the user be aware of the problem so they will pay more attention on loading the savegame and hopefully prevent them from automatically click OK without reading the warning. Yep, no log needed! Happy to be of (good) service! Welcome. Don't hesitate in asking clarifications for any message you get that you don't understand, and give that backup ideia a try. It may save your day on a unhappy CKAN update fest, sometimes CKAN ended up screwing things as there's no proactive compatibility checking on it.

"Advertising" is the right word. We need to gather support, and to convince people to support it we need them to know about. And to make people be aware of that, we need to advertise it.

Yep, you open your KSP directorty, then open the GameData folder, then create a __LOCAL diretory, open the __LOCAL and then create a TweakScale diretory. Then you put files on it. About the Raw thingy… Yeah, you right. It would download the file if it's an image or zip file, but text files is just opens it on the browser. Click on the right button on it on the "raw file" being displayed, then select Save As, then navigate on your hard disk to where your KSP is installed, then go opening the directories until the one you created in the last step. Be sure to save it with ".cfg" extension, otherwise KSP will not be able to recognise it - some browsers "try to be helpful" by automatically adding extensions to the filename, screwing up everything. Give a peek on this video: A bit lengthy, but it appears to explain things in a easy way to understand! Cheers!

Here, download one (and only one) of the following patches: https://github.com/TweakScale/TweakScale/blob/dev/legacy/2.4.7.2/Extras/TweakScale/HotFixes/FSfuelSwitch--ModuleB9PartSwitch--Prefer-FS.cfg If you prefer the part to use FSfuelSwitch https://github.com/TweakScale/TweakScale/blob/dev/legacy/2.4.7.2/Extras/TweakScale/HotFixes/FSfuelSwitch--ModuleB9PartSwitch--Prefer-B9.cfg If you prefer the part to use B9PS (click the "Raw" button, on that bar above the file contents). Then move the downloaded file into someplace in your GameData. I suggest to use <YOUR_KSP_ROO>/GameData/__LOCAL/TweakScale/HotFixes to make it easier to keep track of these stunts and avoid losing the patch in a update. Cheers!

So, don't bother. the Uber has it. Ah, found the reason! [LOG 19:15:59.087] [TweakScale] ERROR: Part SXTBalloonGoldB375 (XX-32 Light Fuel Tank (Gold)) didn't passed the sanity check due having ModuleB9PartSwitch together FSfuelSwitch - see issue [#12]( https://github.com/net-lisias-ksp/TweakScale/issues/12 ). at error:0 You can't have both B9PS and FSFuelSwitch installed on the same part due a B9PS bug. When B9PS finds another fuel switch on the part, it deactivates itself but still tries to carry on some events that only works when it's activated - and TweakScale needs that events. And then B9PS ends up throwing an Exception, screwing up with TweakScale. You can ignore the problem, but then that parts will not be scaled. Or you can apply what I call a HotFix - I have one made for people using B9PS and MFT (it have the same problem), but I don't have one for FSFuelSwitch. I will write a HotFix and will come back to you in the next few hours!

Humm… I don't remember that on SXT, but it's some time since I played with it. Yes, send me the KSP.log so I can check what's wrong and work on a fix. These parts are safe to use, TweakScale removed itself from them so avoid... humm, wait. Do you have Firespitter installed? If yes, install this thing: https://github.com/TweakScale/Companion_FS/releases