Lisias

No, it was not. I have right now a setup where the problem is not happening. #67. [snip] Again, I want to refer to KSP-Recall's #27 and #66: what is now known as bugs on the AutoStrut (since 1.2.2) and on the ReRoot (since 1.8.0) were being attributed to TweakScale for years merely because only TweakScale was being used on the machine when the user got screwed by these bugs. It could be TS? Of course it could, and that's the reason I spent so many man/months trying to find something on TS. But in the end, it was not. Exactly why do you are so sure this is not happening again right now? [snip] if it would be so easy to reproduce the problem as it's happening now, @zer0Kerbalwould had already acknowledged the problem since the first occurrence, not to mention I would had reproduced it from late last month and early this one when I caught and diagnosed #66. And I want to say it again: for a whole week, from April 26 to May 6 (more or less), I was using all my free time (about 4 to 5 hours per day) pursuing this problem without success, where the only situation in which I reproduced the problem was by loading a savegame from the one of the users that was kindly enough to not only report the problem, but provided us with all the material we had asked. And that rig had KSPCF installed where my rig did not. Yesterday, May 26 Friday, was the first time a savegame created on my rig manifested the problem. [snip] I ruled out an influence of MM, because on my rig changing between Forum and my own Fork didn't affected the results. (yeah, it crossed my mind too) [edit] Unless MM (or ScrapYard) would be running more than once in memory, as it had happened before with MM (Forum) under special circumstances. Long shot, but it worths checking. Thanks for the insight! [edit2] Nope, I just ruled out again MM (no matter which one), and the "double threading" hypothesis, besides still possible, appears to do not be causing the LogSpam neither (besides, hypothetically, being a possible explanation for some double logging I found). Contract Configurator is not needed, the rig I used yesterday (where the problem was finally consistently reproduced by the first time) doesn't had it installed. Remove ScrapYard_ContractConfigurator.dll from the Plugins folder and you are good to go - the less things installed you have, more easier is to zero in into the target.

Anyone willing to play LEGO? https://www.space.com/lego-astronauts-fly-to-near-space-video

[snip] Differential diagnosis. KSPCF is one of the few constants we had to work with. And since KSPCF royally mangles with KSP internals in ways in which most authors can't audit if they want to respect the Forum Guidelines, I'm afraid that you have no other choice but to carry the burden you had put in your own shoulders. YOU are the one bringing up unfounded claims about other people's works, this is not the first time - and you had been proved wrong twice already. How in hell we are supposed to trust you now about KSPCF? No one can double check what you are doing without infringing the EULA and the Forum Guidelines, damnit! All we have is your word about, and right now it's not worthing too much. And TweakScale changes half the World, from mesh sizes to PartModule's internal attributes, and nevertheless the damned thing is working and essentially the worst bugs I ever handled on it had their root cause on a KSP's internal bug in a way or another The safest place for a ship is the harbour, but this is not what ships are built for. By you logic, no Mod should be mangling anything inside KSP at all, but yet this is not what mods are built for. Including yours. What leads to the conclusion that once the FlowGraph logspam does not happen, there's no more problem at all as KSP handles the situation? We are on the same page on this one.

By not being! Or perhaps it does, but it's not that simple as you are thinking! All YOU had to do to reproduce it, other's people mileage may vary and, indeed, it does vary. Do you really think that if this would be just so plain simple as you says, @zer0Kerbalwould not had acknowledged the problem already? On every single time I reached him with something he could reproduce, he acknowledged the problem on the spot and no rarely published a fix in the next day. Last time I heard you saying this, you was attributing to TweakScale what was in reality a bug on KSP's AutoStruts since 1.2.2, the first release to had it - this feature never worked correctly all these years, as it appears. You are still having some hard time on telling Cause from Effect, but on your behalf, this one is really tricky and it still may be something on SYD - it only happens that, if it's on SYD, it appears to be unrelated to persistentId. You know, Add'On's Authors can be tricked into believing that a problem on KSP is on their shoulders, right? @severedsolocould be wrong on believing it's something on his shoulders (not saying it was not, I'm saying that we have evidences that suggests it might not, so his post is not proof of the problem, just another evidence pinpointing a problem involving SID). This is the point in which you could be right (about SYD, the statement itself is true), but since you failed to thoughtfully check your hypothesis, you got unlucky on the claim, as there's a chain of events in which SYD works PERFECTLY. Really, @zer0Kerbalwould had already acknowledged the problem otherwise, early this month to be more specific. Because I was trying to diagnose this problem at that time, and I am 100% sure about the date because it was while doing my white and black box testings on SYD that I caught and diagnosed the ReRoot problem. And this is the point in which you ended up being useful (even if by accident), because since I was trapped on a configuration in which I just could not reproduce the problem easily, I was prone to conclude that the ReRoot problem could be the trigger for the SYD's mishap. You just proved that the ReRoot is just not a factor on this one, and this helped to shrink the targets. Now, let's go to the (real) problem at hands: SYD is working perfectly once something still to be diagnosed happens (or start to misbehave once a mysterious event happens!). Once this mysterious event happens, SYD just works without any flaws and, right now, I'm trying to figure out what I had did on my rig today that suddenly made it start to behave. What I know for sure right now: I have a sandbox savegame where the problem is happening deterministically. I have a career savegame where the problem just doesn't happens, but happened once. I remember clearly that on the last time I worked on this, there was a day in which the problem didn't happened at all no matter what. The items 1 and 2 appears to suggest a race condition while initialising SYD on career mode (and a faulty initialisation on sandbox), and so SYD may be involved or even at fault here. However, the item 3 strongly suggests otherwise, that SYD may not be at fault at all because otherwise I would not had spent 2 or 3 days bashing my sorry SAS relentlessly trying to reproduce the problem without success early this month. Anyway, this time I documented things: https://github.com/net-lisias-ksp/KSP-Recall/issues/67 I will update that issue as I learn more.

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.