Lisias

At this time, I think we are facing a corporate coupe d'etat.

Interesting! Wikipedia says he is friend with people from Bungie! What a remarkable coincidence!!!

Not a chance for both. There's a huge opportunity to residual incoming on the Franchise, delisting the game would be a huge management screw up. For starters, you would incentive piracy, what added to the incredibly modding capabilities of the game will lead to some less then desirable outcomes, that given the notoriety of the IP will fatally lead to bad P/R and further damages to the IP But there's no incoming enough to sustain a development team for maintaining (and fixing) it. Chances are by trying to do such a stunt, the new releases would only inject yet more nasty bugs - what was happening already when they pulled the plug. Unlikely at this time. Not only there're still some residual incoming to be exploited, as the IP itself at worst still have good value to be used as a bargain chip on a merge or company/subsidiary sale. And frankly, by the time the IP would be affordable enough to be bought by the Community, chances are that the Community itself would not be big enough to withhold the endeavour, and whoever would be the one that had bought it will need to find "creative" ways to gather money - as licensing the IP to pachinkos... True Story. Check what they did with Metal Gear. On a blind guess, two years ago the Community was big enough - but so was the IP's face value, what means that things didn't changed too much about this subject.

Releasing the IP was never the objective. Only the Source Code. As a matter of fact, given the current status quo, Open Sourcing KSP¹ may be their best shot to make the franchise profitable again. See Doom, Quake, Half Life, Descent et all. The IP (including assets, as music, meshes and textures) are still being commercially explored by the current IP owners, besides the source code being released decades ago. See the recent Tomb Raider Remastered series - they even hired the dude from OpenLara to work on it. Things keep going as they are now, it's a matter of (short) time until things get really, really ugly - what may include, even, malicious 3rd parties trying to exploit the Community. There's no respect for the EULA already (between other problems I had detected, but can't disclose publicly), getting malware agents around here is a question of "When" and "Who", and not "If" anymore. Having the Source Code available will push away most malicious agents from the Scene, as everything will be openly available for inspection. Of course, you will still need to trust the tool that will deliver the binaries to you - but, frankly, the Linux Scene proved again and again that it's possible to have reliable and trustworthy distribution channels for such binaries. The worst problem, right now, is to gather trustworthy and competent people around the project. Too much damage was done in the last few years, some of them really nasty. EULAs are contracts, not licenses (no matter what they say to you) - do you will trust licensing your code to people that don't respect your EULAs? Open Source is based on Trust and Chain of Responsibilities. And every time one (or more) of these two pillars are broken, things goes South. Badly. (Jia Tan anyone?) Open Source is a development model, not a business model. Anyone trying to extract profit directly from Open Source sooner or later will try some scammy stunt - and, frankly, we are losing both the Trust and the Chain of Responsibility on this Scene. They need to tackle down this problem before going Open Source, otherwise the initiative will fail.

None of this started on KSP2. You can track down these problems since the days the IP was sold to TT2 in 2017 (more or less the times KSP 1.3.0 was released).

The first time I read it, I thought on "tupperware". I had to read it again to get it right. Gee...

I hardly would call "optimism" seeing the IP being sold in a closed door sale as scrap, and then seeing the assets and lore being used on pachinkos or something like that. disclaimer: this post is entirely a work of fiction. Hopefully.

As a matter of fact, it's what I think it will happen - but not by the Community, but by some competitor. As a matter of fact, I think the take over is already happening.

And a Hip hip hooray to competition. We had a lot of buyouts around here. Essentially, a big mobile carrier bought the Cable Company some time ago, and a bigger mobile carrier bough that other carrier recently. Right now, there's only 3 possible options for where I live, all of them subsidiaries of one of the 3 remaining Mobile carriers in the country. Welcome to hell. If I ditch my current provider I will be in deep sheets - unless I buy a Starlink. What's, frankly, in the short term plans.

So do I. I'm exactly on the same boat, my cable company is also pesking me to do the same, they want to replace my old and faithful Motorola cable modem (yep, it is that old) for a new WiFi one made by Kraken knows whom. And exactly the same response - until the day the damned thing just stop working, I'm not going to replace it - I will not wave OpenWRT no matter what they want me to do. But once it stops working, it will be replaced ASAP (perhaps even the provider).

I could not find a better place to share this one than here! I'm trying to find time to play KSP¹ again. This will be the first thing I'm going to do! --- -- - Edit Pilot's point if view!

I think that your best bet is CurseForge. AFAIK, it's the oldest Mod Site for KSP still available, you will find things for KSP 0.25 there. (people bashes CurseForge a lot, but in the end, CF is the one that will survive the competition in the long run - mark my words).

You know, once the storm is over (and it will be over sooner or later, in a way or another), this will be an excellent ingame joke. Well... I will give you my 2 cents, as there're some correlation with some things that happens to me on DayJob©. The sad true is that "Done" is better than "Perfect". Clients want their problems solved with the less friction possible (i.e., the less amount of bugs possible), but they want their problems solved. Point. They can handle the bugs, as long the net value is positive (and above the cost of migrating to the competition, of course). I want to share with you guys this excellent article that I think fits this discussion, besides indirectly. https://www.gamedeveloper.com/production/here-s-how-the-small-team-behind-against-the-storm-kept-project-scope-in-check So, nope. They can't stop delivering new features to focus on bug-hunting, they need to do both at the same time - because otherwise they will not sell more copies or keep the engagement high, and I think (for reasons that I don't dare to publish openly) they really need such engagement and copies sold in the short to medium term in order to keep afloat. As usual, we (users and development team) will need to compromise to each other somehow. That said, I'm not saying you are wrong - you are correct in every angle. Without people complaining about the worst show stoppers, the DevTeam will not be able to prioritize them. I'm addressing this in the hopes to help on managing expectations - I doubt they will be able to focus on bug hunting as you (reasonably) want.

Porter turret rifle. Porter had to overcome a problem with Colt patenting the cylinder design for rifles, so he gone with a turret. Problem: the thing has the this strange habit of misfiring - and not only the bullet on the chamber, but all of them in the turret. And since the thing is, well, circular, at least a bunch of bullets were facing the shooter. If no client is back complaining, it must be good, right? Well... https://www.historynet.com/the-porter-turret-rifle-ingenious-features-yet-inherently-flawed/

--- -- - And now for something completely different... I spent the last month bashing my cheeks, burning the midnight oil, to propagate preemptively a change in our infra that would interrupt our services to any client that would not apply a simple update. I tracked down every single client, entered in contact when we detected that the change weren't made, provided the needed information 2 or 3 times for some clients as the information got lost as the task escalated to the infra team. I built a secondary server still keeping the old configuration for some late ones until the bitter end, when the old certificates finally expired on the early hours of this Monday. No one single client was left behind. Except by one. Their production is stalled, they can't operate - and all they need is to push a kraken damned button to apply the new certificate. But the dude can't do it without someone in India approving the change - a change that is late, is more than already due, is approved and was already applied in QAS. But, yet, that freaking button wasn't pressed and this client's production is on halt until this happen. Seriously - I understand the need of a quality process to prevent tragedies. But who process the processes? Who respond when the process itself if the cause of the tragedy? What's preventing that freaking dude in the other side of the World to say "ok, push that button"? (sigh)

When you hit "Abort" by accident! note: I'm unsure about what to think about the joke in the end... note2: made my mind. stupid joke at the end of the video. the history is excellent, but the final remarks are completely unnecessary and detrimental to the content. I suggest to stop the video at 18:00 and call it a day.

ANNOUNCE Release 2.1.1.16 is available for downloading, with the following changes: Updates KSPe.Light to the latest, mitigating that pesky collateral effect on KSP when users brute-force their way into the Steam's Launcher options trying to get rid of the infamous PD-Launcher. Additionally, this release also includes (obviously) the fixes from 2.1.1.15 that wasn't announced here on Forum: Closes issues: #37 Parallax may be inducing DOE to bork the Flares (invalid) #32 Body Flares are being deactivated when Dynamic Dimming Skies are See OP for the links. — — — — — This Release will be published using the following Schedule: GitHub. Right Now. CurseForge. Right Now. SpaceDock. Right Now. Being a simple fix release, I published it on everything and the kitchen's sink at the same time.

I'll update DOE with a new version of KSPe.Light that would had mitigated the problem for DOE anyway. I should had done this sooner, anyway - but, then, you would not had reached me and would ending up with a sabotaged Auto Actions, so... I really hate injecting such gambiarras on the main stream, but the sad true is that this Scene, salvo really rare exceptions, don't give a rat's ass about safety and do things the absolutely easier way completely disregarding the consequences - and then blame the poor stand-up guy that ends up being hit by the crap when things goes South. I think I need to think on something to be put in the KSP.log to help the next fellow Author to detect this problem - what can also be another source of vitriol as I got earlier this year on reddit - it's incredible how some authors really go the extra mile to fight anyone and anything that could prevent problems happening on the field. On a final note, this PD-Launcher stunt is absolutely terrible. The damage this piece of crap is causing on the Scene is beyound imagination. How hard would be do add a "No Launcher please" option and just go straight to KSP if the user asks for it? Thank you for bringing me this issue to my attention in a constructive way.

Coding stupidity - I should be to sleepy when I wrote that code, I was literally overwriting the good contents from the file with default values meant to be used when there's no file. I'm prone to these facepalms mistakes regularly. Yes, it is. I think I know already what's happening. I will check your log and edit this post with the findings. --- -- - POST EDIT Yep, you are using Steam: [LOG 06:22:12.124] AssemblyLoader: Loading assembly at C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\ModuleManager.4.2.3.dll And I'm guessing you are using that dirty trick in the Launcher to avoid the PD Launcher, I'm right? That trick causes too much collateral effects (even KSP gets screwed, you will find a lot of files in the wrong places, as the settings.cfg and the screenshots, a mess).

Are you using the latest release? I think I had fixed this here: https://github.com/net-lisias-ksp/DistantObject/issues/38 I will give this a peek before bedtime, but it will help to publish your current KSP.log (after reproducing the problem, and after quitting KSP to prevent the log from being truncated) it will surely help on the diagnosing. === == = POST EDIT I just fired up my "Acceptance" (acp ) test bed, where I have installed all the add'ons I publish on the latest releases, and... It's working for me. It was a pretty simple test (hey, I sleep now and then and I'm already done for today): Fired up KSP 1.12.5 (acp) Loaded the DOE's smoke test savegame Opened the DOE's Settings Dialog Set Show names on mousever to off (i.e., unticked the check box). It was On at that time. Pressed Apply Quit KSP Load it (again) Loaded the DOES's smoke test savegame (again) Opened the DOE's Settings Dialog (again) The Show names on mousever is still off. Just to be on the safe side, I also used the Tracking Station to jump into a living spacecraft and the option not only was still deactivated when I checked the Dialog, the feature itself wasn't active as expected. Activating the feature on the Settings made it work again, so the cycle is closed. So: there's something fishy in your rig; or your are using an old DOE's release (just checked SpaceDock and CurseForge, I confirm they have the latest); or there's something that you are not telling me on the bug report (perhaps a use case that I had messed up, and that wasn't tested by this simple test session I did). So please send me your KSP.log so I can check the options 1 and 2, and please describe step by step (like I did above) how to reproduce the problem, so we can rule out (or not) the option 3.

When you hit "stage" by accident... Poor cow. https://medium.com/@shermikeholmes88/the-time-we-accidentally-nuked-new-mexico-301489770be2

I fail to see how a Game Industry professional plans to enrich its resume by violating the EULA of a competitor (or former one, who knows nowadays). You know, their employer also has a EULA to enforce - and I really don't think such employer would be proud of their employees violating EULAs on the wild - their business model depends of EULAs being enforced! (or to hire someone that did that)

I'm playing this nice "little" game called Dome Keeper, suggestion from my son. Hard as hell initially, I took weeks until I finally got a grasp on it and started to win a round now and then. There're less demanding modes, as no enemies (essentially, digging without worries) and automatic weapons (that do the service by themselves, but you need to upgrade them or you will be overrun). But they are available only after completing a full cycle, damnit.

You know... Sooner or later someone will try to deploy Commandos with these things! ("Commandos away...." )

Proton is doing a pretty good job on simulating the Windows API nowadays, but I agree that Linux native is, most of the time, better. Problem is, as usual, Unity support.