Lisias

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

How do you are installing things? CKAN? I would suggest you ask directions from them, as they are the ones installing things in your rig! Ah, now I see. Old install being updated! Yes, try installing the Continued version and see if the problem goes away. I think I remember a post talking about renaming the MEMLander once, some time ago! Cheers!

Hi! That's weird… You should had only one FATALity per part, looks like you have multiple TweakScale's running. [LOG 17:26:04.960] Applying update SXT/ModCompatibility/SXT_TweakScale/@PART[MEMLander]:NEEDS[Scale] to SquadExpansion/MakingHistory/Parts/Pods/Size1_5_Lander.cfg/PART[MEMLander] [LOG 17:26:04.961] Applying update SXT/ModCompatibility/SXT_TweakScale/@PART[MEMLander]:NEEDS[Scale] to SXT/Parts/Rocketry/Command/MEM/part.cfg/PART[MEMLander] [LOG 17:26:17.146] Applying update TweakScale/patches/SquadExpansion/MakingHistory/Pods/@PART[MEMLander]:NEEDS[SquadExpansion,TweakScale] to SquadExpansion/MakingHistory/Parts/Pods/Size1_5_Lander.cfg/PART[MEMLander] [LOG 17:26:17.150] Applying update TweakScale/patches/SquadExpansion/MakingHistory/Pods/@PART[MEMLander]:NEEDS[SquadExpansion,TweakScale] to SXT/Parts/Rocketry/Command/MEM/part.cfg/PART[MEMLander] [LOG 17:28:39.389] Applying update 999_KSP-Recall/patches/attached-on-editor/@PART[*]:HAS[!MODULE[ProceduralPart],!MODULE[WingProcedural],!MODULE[ModuleAsteroid],!MODULE[ModuleComet],!MODULE[KerbalEVA]]:LAST[KSPRECALL-ATTACHED-ON-EDITOR]:NEEDS[TweakScale] to SquadExpansion/MakingHistory/Parts/Pods/Size1_5_Lander.cfg/PART[MEMLander] [LOG 17:28:39.581] Applying update 999_KSP-Recall/patches/attached-on-editor/@PART[*]:HAS[!MODULE[ProceduralPart],!MODULE[WingProcedural],!MODULE[ModuleAsteroid],!MODULE[ModuleComet],!MODULE[KerbalEVA]]:LAST[KSPRECALL-ATTACHED-ON-EDITOR]:NEEDS[TweakScale] to SXT/Parts/Rocketry/Command/MEM/part.cfg/PART[MEMLander] [LOG 17:28:44.794] Applying update TweakScaleCompanion/Frameworks/Waterfall/patches/999_Finals-and-Lasts/@PART[*]:HAS[@MODULE[ModuleWaterfallFX],@MODULE[TweakScale]]:NEEDS[TweakScale,Waterfall]:FINAL to SquadExpansion/MakingHistory/Parts/Pods/Size1_5_Lander.cfg/PART[MEMLander] [LOG 17:28:44.802] Applying update TweakScaleCompanion/Frameworks/Waterfall/patches/999_Finals-and-Lasts/@PART[*]:HAS[@MODULE[ModuleWaterfallFX],@MODULE[TweakScale]]:NEEDS[TweakScale,Waterfall]:FINAL to SXT/Parts/Rocketry/Command/MEM/part.cfg/PART[MEMLander] But, in reality, what we have are TWO parts named MEMLander in your rig!! I think you have no alternative but to reach the SXT's maintainer and ask him to rename the SXT's MEMLander to SXT.MEMLander or something when MakingHistory is installed. It's not hard, it's a simple MM patch. In the mean time, you will probably want to delete the file <KSP_Root>/GameData/SXT/Parts/Rocketry/Command/MEM/part.cfg to get thing ongoing until the fix is published. Things get a bit confusing on KSP when you have more than one part with the same name. Cheers!

It's understandable, but also the reason P.D. would not be prone to consider this without some public pressu encouragement. This is some crazy idea of some code monkeys, or there're public support for the stunt? People are really willing to get their paws dirty, or they are just taking the cool aid? Whatever they are going to choose, they will have to live with the consequences forever - so they need to know if the idea worths the shot. Having people supporting the idea is one of the criteria exactly because of this. Please consider being the one that creates the momentum, we surely need the help! Flight Gear is Open Source, and it predates all the features used on X-Plane to the point I really think X-Plane helped to fund this in the past in order to test ideas and algorithms for their product. FG is really impressive, by the way - it lacks some polishing, but the game itself is solid (I play it now and then). Thanks for the question, I had forgotten about it and remembered about it while thinking how to answer you! You will find a somewhat extensive list on https://en.wikipedia.org/wiki/List_of_open-source_video_games . And something I didn't knew about, Space Engineers is listed as having the Source available!!! Boys, we have another Study Case of Success to advertise! Yes, but I have some bitter-sweet remembrances about this ordeal. I want to think that I had helped a bit to inspire the move, but this is also an example on how things can get harsh in the process (and, also, why I'm conceding that P.D. would prefer a "Share Source" model initially). I had some bad moments on Orbiter Forum due licensing, it was really nasty (second to none). Things got really harsh when I realised than since the source code being used as base for almost all the add'ons on the scene was ARR at that time, a lot (if not almost all) the add'ons published at that moment were in copyright infringement and that was pretty hairy. And I was right, by the way - and, yes, they shoot the messenger. A lot. Things got ugly to the point a somewhat influential author tried to push his weight on me using exactly the copyright laws - essentially proving my point. The only reason I got involved on KSP modding is exactly because the Add'On's Publishing Guidelines. That allowed me to use OSI licenses on my work, and that had paid off more than once, I need to say. Copyright trolling is a thing. So, in essence, going Open Source is not an easy solution for all their problems - and it may create some new ones. The point I want to stress, however, is that on the medium and long run it will worth it, and it will worth it a lot not only to us, but also for them (see the Flight Gear example above!). Our job, right now, is to get their attention and openly and frankly talk about the possibilities - and we also need to be open minded to hear a counter-proposal that could be something completely different, but it would also solve our problems. We can lose a battle and still win the war: Our main goal is the wellbeing of the KSP Scene, and having access to the Source is the best way I know to achieve this. But if something better is proposed, hell, we should jump in the same. I'm cautiously optimistic about we having a chance, but there's a lot of pitfalls we need to avoid - we need to focus on our goals, and not on the path we think will leads us to such a goal. I'm convinced that opening the Source is the best way to accomplish what WE (us, as users; us, as authors, and they, as publishers) need to keep things tight - but we should be willing to hear any counter-proposals, someone can have a better idea. But, until such better idea is proposed, The Source Must Flow!

Did you? This is not a single person battle, he needs support. Help to promote the post on reddit (how about a reward?), talk about it on your social networks, spam your twitter with it. Help him to be heard. Talking about the benefits of the ordeal is just part of the solution, we need to be heard by enough people so P.D. would perceive the initiative as a positive move for their customers (and not only a caprice from a few code monkeys). Even if they like the idea, they will not consider opening the source just because a bunch of KSP enthusiasts are asking fot it - they need to see value on move (they have a company to run, and bills to be paid), and with more people talking about, the perception of value increases, and so increases the chances they consider it. Think on it as a very nice feature you want the developers to add to the game: you talking about how nice would be such feature is just the first step, you need more people talking about how nice would be the feature, so the developers would consider implementing it. This is not different, except that now we are proposing a "feature" to P.D.'s management instead to developers.

With this information, and the benchmarks I did last post, I'm inclined into believing that the problem may be affecting only Windows users. If this is a KSP problem, then we have a file handler leakage but I failed to understand why a faster processor would be making this more prone to happen unless... hummm... I checked the i13900k specs and realized it is an asymmetric CPU! 8 pretty fast cores and 16 slower ones. It's more like a hunch than anything else, and the FileShare stunt ended up working around the problem anyway, but I think you will get better overall game performance if you set Windows to run KSP only in the performance 8 cores (assuming you didn't did it yet), I remember a setting calling Affinity in which you tell Windows to use only a subset of the threads for a process. KSP(1) predates a lot of new things as asymmetric cores and unless something on Windows is able to tell an application from a game automatically, KSP is probably spanning itself indiscriminately over different cores. And Unity (ab)using busy waits is probably not helping the situation, as we would have events being consumed slower than others depending what core the thing is frying at that moment. There is some multithreading on KSP, and if the MM thread is fired on a fast core while the Assembler Loading thread is running on a slower one, then we have a race condition aggravated by the difference on the speeds of the cores. The MM mitigation allows the thing to keep going (and, again, my benchmarks above suggests it should stay), but the asymmetric problem may be screwing up others things too - Unity relies reavily on spinlocks and I bet no one ever considered that some locks would be spinning faster than others. I would like to suggest trying the "unmitigated" MM on the new rig setting the affinity to use only similar cores (a run using only the fastest ones, and another using only the slowest) to see if anything changes - not due this problem (it's already mitigated), but to check the asymmetric hypothesis. If we have confirmation about asymmetric cores screwing up something, suddenly a lot of absolutely weird concurrency problems I'm detecting on the field have now a feasible explanation!

I'm owing people a decent documentation for this since some time already. What I have right now are two quick tutorials: https://ksp.lisias.net/blogs/tech-support/TweakScale/How-to-write-a-patch/Part-01 https://ksp.lisias.net/blogs/tech-support/TweakScale/How-to-write-a-patch/Part-02 The Part 2 covers a bit what you want. Looking into Stock parts' patches is the best way to see how things work right now, but you may face some trouble when handling some more exotic parts - a situation in which you would like to do some Requests For Comments anyway, because if there's not a Stock equivalent for the part you are scaling, even me would need to give it a close eye ball to decide how to proceed! Cheers!

TL;DR: KSP may be innocent, the problem may be on how Windows works internally. But I am wrong too (and for sure), as by some reason using FileShare.Read is faster than not using it both on MacOS and Windows under C#'s runtime. Go straight to the bottom of this post for the gory details. The amount of memory between the systems are the same or the new rig has more memory? How faster are the disk access on the most powerful rig (m2 in the new, spinning disks on the old, perhaps)? Now, I need to ask you to bear with me, as this is not a private message and there're lots of people reading us (and probably more in the future) that may not have all the needed knowledge to understand how deep is this rabbit role. It also helps me to think. Rubber Ducking effect. In order to the AntiVirus be a problem, it may be being incited somehow, but since you had the problem before applying the stunt, at worst you exchanged a problem with a smaller one (after all, the stunt worked for you). So, on a second thought, it's probably not the antivirus the cause of the initial problem. Assuming we have a problem inside KSP, the older rig being not too much prone for the problem may be related to memory or disk access more than processor speed (if at all). More memory available means less pressure on the GC, and bigger chances of a leaking file handler be around for more time (if we have a file handler leaking). Faster disk access means we have a race condition, in which the slower disk was delaying things enough to prevent it for the most part (and on this case, we may not have a file handler leaking). As a race condition, I meaning the KSP's thread that was loading all the Assemblies starting the ModuleManager's thread before closing all its file handlers. On a slow file system, the code that MM uses to search the GameData for DLLs would cause enough delay on a slow disk that it would let the caller's thread to finish closing the handlers. On a pretty fast file system, the search for the DLLs may be so quick that there was not time for the caller's thread to close the handlers before the MM's thread try to open one of that files. However, had you having a race condition situation, a delay before trying to open the file should had worked for you - but the ultimate test would be running KSP on a slow disk in the new rig, as a USB thumbdrive or USB to SATA adapter. You reproduce the problem consistently using this, and we rule out definitively the file system from the equation (and, so, a race condition derived from disk access). So we are back to a file handling leakage problem - with me having to eat my words, as you may be right on thinking the problem is in KSP itself. And/or Unity, but KSP is the one borking, so it is, indeed, the prime suspect by now. But to understand why this would be a problem, we need to understand how opening files works on a concurrent environment. And now we are getting technical. When multiple actors try to open the same file for reading, a UNIX O.S. couldn't care less - the damned file are not going to change, everybody is going to read the same data, let them do it as they please. If by some reason you want to be the only one reading the file (as when using the file contents to synchronise multiple processes), you need to explicitly tell the O.S. about. This is where sane O.S.s like UNIX differs from Windows: what happens if someone tries to delete the file when another process had opened it for reading? On Windows, you have a serious data integrity problem, but on UNIXs deleting a file is only removing a named pointer from a directory file - the file itself is located on the disk by a thingy called inode, and when you open a file, you fetch a pointer to that inode. Only when there's nothing else (as another directory entry or at least a file handler) pointing to a inode is that the file is "physically" erased from the disk. And, yes, you can have the same file "linked" in multiple and different directories on a UNIX file system (it's what we call a hard link). And perhaps this is the reason we don't have such complains from Linux and MacOS users? So, by default, on UNICES all files are opened in a way that multiple processes can open it for reading at the same time and you need to go an extra mile to tell the O.S. that the file should be opened by exclusive or controlled access. On Windows, the default is exclusive access and you need to go that extra mile to tell it to allow multiple process reading it at the same time. This difference is pretty important, because programmers used to the UNIX way have a mental posture about reading files completely different from Windows programmers. And this played a role on my initial approach to this case. And it's the reason I was subconsciously averse to the idea of using FileShare (being it Read or ReadOnly) on the solution without further considerations. Yep, my apologies. Using, however, FileShare.ReadWrite is undesirable on an executable file. The ideal mitigation code IMHO should use FileShare.Read (as you already stated on a previous post). Denying write access while opening files may, at very least, get the AntiVirus out of our necks - if no one is going to be able to write the file, there's no need to monitor such a thing. But now we have a serious problem on KSP itself: as it appears, we have a problem of leaking file handlers (or less likely a race condition, see above). KSP loading times is being consistently criticised, and we are only making things worse. So, it's time for some benchmarking. I wrote this little program: And I ran it 3 times on my MacOS rig: > /Library/Frameworks/Mono.framework/Commands/mono Tests.exe Hello World! /Users/lisias/Workspaces/KSP/GIT/net-lisias/ksp/KSPe/bin/Debug/Tests/Tests.exe OpenFileWithRead 00:00:08.24 OpenFile 00:00:09.07 -- > /Library/Frameworks/Mono.framework/Commands/mono Tests.exe Hello World! /Users/lisias/Workspaces/KSP/GIT/net-lisias/ksp/KSPe/bin/Debug/Tests/Tests.exe OpenFileWithRead 00:00:08.14 OpenFile 00:00:08.83 -- > /Library/Frameworks/Mono.framework/Commands/mono Tests.exe Hello World! /Users/lisias/Workspaces/KSP/GIT/net-lisias/ksp/KSPe/bin/Debug/Tests/Tests.exe OpenFileWithRead 00:00:08.39 OpenFile 00:00:08.98 And… I gone down in flames! Using OpenFileWithRead is FASTER. This caught me with my pants down in a very precarious situation... Since I'm here, I ran the same binary on my Windows 10 test bed: C:\Users\lisias\Desktop\OpenRead>Tests.exe Hello World! Tests.exe OpenFileWithRead 00:00:04.65 Exceção Não Tratada: System.IO.IOException: O processo não pode acessar o arquivo 'C:\Users\lisias\Desktop\OpenRead\Tests.exe' porque ele está sendo usado por outro processo. em System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) em System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy) em System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy) em System.IO.FileStream..ctor(String path, FileMode mode) em Tests.MainClass.OpenFile(String fn, Int32 i) em Tests.MainClass.TestSession2() em Tests.MainClass.Main(String[] args) C:\Users\lisias\Desktop\OpenRead> My Windows is PT-BR. The message above is telling that the process could not access the file because it was in use by another process. This caught my attention: the EXE file is kept open while running the program! So I copied Tests.exe to T.exe and ran T.exe instead (and, so, Tests.exe would not be opened at runtime): C:\Users\lisias\Desktop\OpenRead>T.exe Hello World! T.exe OpenFileWithRead 00:00:04.17 OpenFile 00:00:04.50 -- C:\Users\lisias\Desktop\OpenRead>T.exe Hello World! T.exe OpenFileWithRead 00:00:04.07 OpenFile 00:00:04.47 -- C:\Users\lisias\Desktop\OpenRead>T.exe Hello World! T.exe OpenFileWithRead 00:00:04.06 OpenFile 00:00:04.49 Oukey, the results are consistent. Once I avoided opening the file from the executable in use, I got similar results - with the exception that my MacOS is twice as slower than Windows. A real surprise, as my MacMini is using spinning platers and the Windows notebook a M2 - I was expecting better performance from a M2 (perhaps the one I have is crappy?). APFS appears to be less performatic than HPFS, by the way, but since I make heavy use of the CopyOnWrite thingy, I will just take the hit on this. Anyway, since I'm here, I gave this a last shot and created a test case for FileShare.ReadWrite and got the following timings: > /Library/Frameworks/Mono.framework/Commands/mono Tests.exe Hello World! /Users/lisias/Workspaces/KSP/GIT/net-lisias/ksp/KSPe/bin/Debug/Tests/Tests.exe OpenFileWithReadWrite 00:00:08.20 OpenFileWithRead 00:00:08.17 OpenFile 00:00:08.76 -- > /Library/Frameworks/Mono.framework/Commands/mono Tests.exe Hello World! /Users/lisias/Workspaces/KSP/GIT/net-lisias/ksp/KSPe/bin/Debug/Tests/Tests.exe OpenFileWithReadWrite 00:00:08.25 OpenFileWithRead 00:00:08.22 OpenFile 00:00:08.86 -- > /Library/Frameworks/Mono.framework/Commands/mono Tests.exe Hello World! /Users/lisias/Workspaces/KSP/GIT/net-lisias/ksp/KSPe/bin/Debug/Tests/Tests.exe OpenFileWithReadWrite 00:00:08.34 OpenFileWithRead 00:00:08.82 OpenFile 00:00:09.12 Well, I'm not that wrong after all - opening with FileShare.ReadWrite is, indeed, slightly slower then FileShare.Read, but barely. And it's way faster than not using FileShare at all. On Windows, I got: C:\Users\lisias\Desktop\OpenRead>T.exe Hello World! T.exe OpenFileWithReadWrite 00:00:04.06 OpenFileWithRead 00:00:04.03 OpenFile 00:00:04.48 -- C:\Users\lisias\Desktop\OpenRead>T.exe Hello World! T.exe OpenFileWithReadWrite 00:00:04.04 OpenFileWithRead 00:00:04.04 OpenFile 00:00:04.48 The difference is way tighter than on MacOS, but it's still there. Perhaps due the M2? Well, concluding: I'm still smelling something funny on the root problem, but I'm not convinced anymore it's something in KSP. It may be something on Windows, taking some time to wave the file handler of the opened DLL file (in a similar way Windows kept the EXE file opened while running it - I had completely forgot Windows does this stunt). However, intentionally or not, LGG solution for the problem is not only a working mitigation for the problem at hands, it's also the near the best way to open a file on C# - second only to my counter-proposal, FileShare.Read (and by a very narrow margin, virtually negligible in Windows). Given the results I got on these benchmarks, I recommend to everybody to always open files on C# using FileShare.Read when reading files.

Well, I am. A bit.., I'm the "low level" specialist on my Company. I have some background on management, enough to realize I would be a crappy manager - but learnt a lot about how to keep them happy and out of my neck! That's the point: you get what you pays for, there's no free lunch. "Free" labour comes in essentially two variants: Unskilled labour by people willing to try their teeth on the thing They are really cheap and willing to work for free to get experience. But that's all we can say for them. Skilled labour with a lot of strings attached They are really good, but they are not cheap - they may wave the money, but they are taking something back in exchange and if you don't know what it is, you have a problem. And I don't know of a single company (Mozilla included) that managed to get away only with these ones. Fast; cheap; good: pick two. About that, there's no doubt!!! Unfortunately, happiness can't be used to pay bills - I never managed to convince my Power Company to accept it for my Electricity Bills. I think it's the same for P.D. We need to reach a compromise that would be good enough for both sides. But they are also a commodity, not a full featured product. That's the difference. You don't sell Unity to the end users, you sell them games made on Unity. So it makes sense to open their source so every game developer can give a peek and use the knowledge to make better games - at least, it's the theory: the infinite amount of annoyances, bad decisions or plain crappyness on this thing is an example that Open Source will not solve problems by itself. Open Source is a path, not a destination. That's the reason I don't think it's the P.D.'s best interest to open source KSP2, they are planning to sell this thingy as a product, not as a service. I see we are getting into the same page, except by a detail or two. I think that opening KSP2 source may harm the incoming more than they would benefit it - once you open your source, smart people is able to get a grasp on where you are going to be in the future, and then your competition will have time to try to get it the market first. There's still a competition for the user's money out there, and being the first to deliver a nice feature usually pays off. Going open source makes hard to hide your intentions from the competition. Unity doesn't have this problem because they are, well, a commodity. There's nothing to hide on a commodity. Yes. This is exactly my point. The niches overlap, but I would not call it a direct competition because: People willing to buy KSP2 had already bought KSP1, or are not going to buy it at all. People willing to buy KSP1 are people that are not going to buy KSP2 for a reason or another. Using Doom and Quake as an argument right now is stretching things a bit , because even my crappiest device with a screen is able to run these two nowadays. Damn, there're people running Doom on pregnancy testers, by Turing's Sake!! But the fact is that KSP2 is a resource hungry game, and not everybody is prone to replace their perfectly fine old machines just for it (not mention being a Windows only game). And not only that, can you imagine running KSP2 on a Steam Deck? You can run KSP1 perfectly on it, not to mention the 8th generation Consoles owners that still wants to play KSP on their consoles but have a terribly buggy product right now. There's life beyound AAA gaming, and these people also spends some money on it. On the long term, I think it's unavoidable that KSP2 will outmatch KSP1 by a mile (just like Doom Eternal outmatches all the other Dooms combined). But this is not happening right now, and I think it's suicidal to fail on taking advantage of this still favourable times; this is not going to last forever. Would not be a bad thing If and only if KSP2 sells take off!

Of course we can. But of course they will deny it for sure. I surely would. These are two completely different situations: KSP(1) is currently in life support at best, I doubt there's a single developer allocated on it for debugging or fixing things. It's on a dead end right now. KSP2 is an ongoing, live effort with a team of developers working on it. And they are capable developers, they will deliver it unless some corporate <piiiii> screw them up: the sad state of the code at launch is not their fault. I'm not telling you I don't want it - of course I want it! . I'm telling that it makes absolutely no sense for them to do it. Because KSP2 is not cutting it yet, and KSP1 is far from being in an acceptable state and they need to get some revenue from KSP(1) to keep funding KSP2 (as you can bet your Staging Button KSP2 will not be able to fund itself for some time). KSP(1) is not a competitor, KSP(1) is a source of incoming to fund KSP2. Anything they do in order to get revenue from KSP will benefit KSP2 in the end. You need to take in account that the legacy is currently doing 6 to 8x more online players on SteamCharts than the new thing - if you are in need of milk some cash, where you would try it? https://steamcharts.com/cmp/220200,954850 Besides, it's a mistake on believing that KSP(1) wil compete to KSP2 - Doom 1, Doom 2, Quake, Quake 2 had their source published and even made OSI - and it only helped to promote (and, so, indirectly funded) Doom 3. And Doom Eternal is doing pretty well, IMHO: https://steamcharts.com/search/?q=doom An OSI style license is what I really want, but I concede that P.D. may have plans that may be hindered by it (my opinion is that it will not, but they are the ones in need to be sure about it, not me). So going Unity style may be a compromise solution in the near term (and it doesn't prevent going OSI later, they are not mutually exclusive solutions). Additionally: only the source code needs the be licensed, not the assets or the Intelectual Property. Again, check the Doom and Quake licenses: you are not allowed to publish a derivative of the game. Not even Doom1 coders are doing that, what they do is publish the compilated binaries, that so need to be complemented by the shareware version of Doom in order to be tested. Of course, nothing prevents the user to use a full release version of Doom if they own it - and, let me tell you something, I have bought Doom, Quake et all to be able to legally play them nowadays on these new, opensourced binaries. Going this way may increase a bit the KSP(1) revenue for some time. But this discussion is only valid pertinent if they are considering going OSI. If they go Unity licensing style, they can buy time to consider all of this and still collect some benefits in the short term, as allowing us, authors, to know exactly what we are doing without the need of relying on shady practices that we aren't even sure is really legal in all countries in the World. I already answered it above, but I will do it again: no, it makes absolutely no sense at all opening KSP2 source code. We are not asking P.D. to go the Mozilla way - to try to make money on OSI products by donations or whatever. I'm not telling you I would not like to have "intimate" access to KSP2 development process, but I really doubt this will be a successful development model for them. P.D. is not a Non Profit Foundation neither are going to be, they are on this business to make money, not to promote a better Society somehow. KSP(1) is a completely different animal, however. It's a product that had ran its course, but is still loved by the users and has the potential to give them some incoming to help funding KSP2, that will be unavoidably the next cash cow for them - if they manage to keep it alive until there. What it's being proposed is a deal where we, people that already had paid for the thing, would be willing to hunt and fix problems in order to have the game we had paid for at first place - and if these efforts are going to help fund KSP2 indirectly, it's not a problem for us. Not every Kerbal enthusiast is going to buy KSP2 on the foreseeable future (perhaps too much for KSP2's good), so it makes sense to keep KSP(1) healthy and sound.

Having it on a file would help on diagnosing these hard to crack problems on the field... @jost, do you remember something weird on that text box at the time the bug had bitten you last time you tried?

CKAN has a log, so I can acquire new information to contribute?