Lisias

Nope, but closing them will save memory and it will make your gaming better in a way or another - and without Internet connection, most of them will be useless anyway. Keep in mind that if you confirm our hypothesis, there're alternatives that will allow you to keep the Internet alive but still prevent KSP from opening connections. What we are doing now is just checking things the fastest and easiest way possible. Once we know exactly what's happening, a better solution will be provided.

Nope. I expect it to run faster, as the connections are all off and nothing will be sent or received. BUT… I can be wrong, so please report your findings.

If my hypothesis is right, probably. But the key factor here is latency, the packets are pretty small so more bandwidth will not compensate a bigger lag while making connections or transmitting data. To tell you the true, I think the best way is to just prevent these connections to happen, so there's nothing to be transmitted at all - and, so, the problem is solved by making it impossible to happen.

I completely agree, but we need to put ourselves on P.D.'s shoes: why they would do something that would bite them in the SAS? It's not wise to invest your scarce resources feeding the competition unless you are getting even more back (and this last part of the bargain is not consensus around here). We need to reach a win-win situation: both sides must win enough and loose the less possible to make the solution palatable enough on the worse case, and working on the best. They still have KSP2 to sell, and they are pretty focused on this one. My original proposal (that I should had reproduced on my last post, by the way) is a Controlled, somewhat Restricted access to the Source Code (in the same way Unity does), allowing us to (legally and under Forum rules) access the Source looking for bugs that we can fix (as I do on KSP-Recall), as well gathering intelligence about how KSP really do things internally, avoiding a huge waste of time on infinite black box testings - but at the same time in a way that can't be used to "compete" with them. Frankly, they have none to loose by doing that, because people that don't mind the EULA, Forum Rules and even a few draconian (but perfectly enforceable) legislations in the World are already using tools and shady practices to have access to that Source Code. And these guys don't have anything to loose by using this knowledge the way it best fits to them disregarding everything else - we don't even know their real names, most of the time. They can do whatever they want, the Genie is already out of the Bottle. We, people willing to walk on the right side of the road, are the ones with our hands tied. Opening the Source, even on a controlled and restricted way, will essentially allow more people (the ones still willing to cope with the EULA and Forum Rules, not to mention that draconian legislations) to be able to read it and doing something useful with it - more eyes being able to audit the solutions, more arms being able to do useful work. And the more eyes you have looking on something, the harder is to someone to "steal" it - and since the King is already naked , there's really nothing to be lost now.

Now we have hard evidence that this trick also works for more modern computers, it's not an Old Potato only one!

Sweet!! Thanks for the confirmation of an already long standing hypothesis! Cheers!

Check if the overall performance remains the same. The GPU running cooler caught me with my pants down, this was essentially a CPU trick… Check if the FPS dropped...

On this Window: Click on New and On Variable Name type MONO_THREADS_PER_CPU and on Variable Value type 1 (One). Then click OK. This will not solve all the performance problems, but will mitigate them a bit. On my rig, the benefits were the CPU running 2ºC cooler (seriously) while the rest of the machine remained useable (without this stunt I can't listen to music or watch videos while playing KSP). My rig is crappy enough to any performance enhancement on the game to go unnoticeable (I may had earn 2 or 3 FPS), but some internal KSP processes (as the Garbage Collector) started to run more times, as the KSP's memory usage didn't increased too much anymore on long gaming sessions. Of course, remember the stunt as maybe you would need to remove it to play other Unity games. On MacOS, things are way easier…

I managed to run KSP 1.12 after a lot of tricks and compromises on a MacMini 2012 (i7, 16GB, Intel HD4000). It looked like crap, but it worked. Your hardware definitively is not the issue - your i5 is at least twice as fast as my i7. Try the WiFi stunt - at very least, it will rule out a weird hypothesis that is haunting me for months already.

Try the MONO_THREADS_PER_CPU=1 stunt and see if something changes. It's a bit convoluted on Windows, however. But I helps a lot on my MacPotato, and I have notice it also makes things smoother on Windows (at very worst, it allows the garbage collector to run more times, helping preventing memory leaks). https://www.alphr.com/set-environment-variables-windows-11/

Weird. DOE taxes the 3d engine a tiny little bit for every craft that goes on rails but is still on the configurable visible range - but, frankly, you need to get a really crowded scene in order to perceive something. Not to mention that by removing DOE, things should had be back to "normal". Humm... Let's do a test: completely remove Internet access from the computer (pull the ethernet cable, turn wifi off, whatever). Then reboot the computer and try again. Then restore the internet connection and do the test again. I'm being monitoring KSP's internet access for some time already, and at least on MacOS, KSP opens 3 connections and keep 2 alive for the whole session. Being https connections, I can't check what they are doing, but the packet exchanges besides not being too big, the receiving ones are big enough to transport code - and this is a plausible explanation to a weird "MonkeyPatching Exception" I got once while trying to do something on APP.

I think it's time to get back to this pledge. In the last 10 days I ended up doing lots and lots of black box researches hunting bugs that weren't from our (authors) side of the equation. This is a huge waste of time, and this puts us (authors that are willing to cope with Forum Rules) on a unfair disadvantage over people that don't care about Community, Forum Rules and sometimes even with specific details from pertinent Legislation. Not to mention a uphill battle with such people that just refuses to acknowledge the results of such results, on a circular arguing that can only be really broken by showing the freaking code. Really, the Source is already available to people that don't mind shady practices hiding themselves behind disposable nicknames. This Community needs a change, and a change for the better. The current proposal, that I endorse with a open heart and a educated mind, is still the better option for the Community and probably the whole Franchise. Until a better solution is proposed, I'm still pledging for Legal, Forum Rules compliant access to the Source Code of Kerbal Space Program (the first).

The bug appears to be on KSP itself, its proven more than enough that the piece of code it was under scrutiny is not a factor to the problem: the Problem is being triggered even when the value is not changed. You can't fix a bug that you can't see.

Or public, reliable and Forum Rules compliant information allowing us to write one ourselves - but, frankly, it would be a waste if they are going to implement their own later.

The game Iron Lung (a submarine horror game) is getting popular due the Titan crisis. Some people's kids... https://kotaku.com/submarine-missing-titan-titanic-iron-lung-steam-horror-1850566034

Hi! In order to get TweakScale to scale something, we need some requirements fulfilled: A patch adding a TweakScale module to a part respecting the bulkhead profile, the part's "behaviour" et all Having TweakScale Exponents for every PartModule the part uses. The problem you described happens because Kopernicus used to use a specialised PartModule for the solar panels, as now you can have multiple sources of light (Stock only knows how to handle one). But since Kopernicus usually patches the existent parts replacing the Stock PartModule with its own, then by just adding the new Exponent things used to just works. However, since some time Kopernicus is being heavily changed using Harmony, and now Kraken knows what is being changed inside KSP itself - so I'm unsure if I can really help. What I can say for sure is that TweakScale (the main distribution) only Supports Stock and DLCs, and this is not going to change. What it can be done is adding Kopernicus support by a TweakScale Companion. This way, only Kopernicus users would be risking their SASes on unorthodox patching and I don't risk screwing up everybody else. In a way or another, https://github.com/TweakScale/Companion/issues/27 I expect to have time for modding again next month (hopefully).

Don't ask. I just remembered this crap this week and can't shake it from my head!

Not exactly… You see, the S&R teams costs a lot of money on training and equipment being used or not, the costs of one search itself besides pretty high for our humble standards are just a drop on the ocean that it's the overall budget for keeping these Search and Rescue teams operational. Besides, jumping in on these high profile efforts has a pretty positive P/R to them, helping them to secure funding for the next fiscal year (too much time without accidents, politicians start to withdraw money from them and use it on things that would bring them votes). If any of these guys manage to rescue the submarine with survivors, you can bet your mouse they will secure funding for 10 years - not to mention an increase on the applicants, that currently is their worst nightmare (very few people enjoys the heavy training and the boring routine of S&R, not to mention the meagre payment). And lots and lots of Fundraising events from grateful tycoons.

This was a contributing factor, but the root cause of the tragedy was the MCAS, and this crap was certified by FAA and it matched exactly the documentation aproved by FAA. And I'm not seeing anyone sueing the FAA for fraud. Something to think about. The point you are ignoring is that it doesn't implies it will not neither. In true, for any certified limit you can expect from 50% to 100% tolerance for abuses as a safety guard for future manufacturing problems as low graded material being leaking into manufacturing for a reason or another. Additionally, the certification is done using the weakest link of long chain of parts and materials. A part of the machine can be certified to be used on harsh conditions when matched with better side components. This bureaucratic mindset is exactly the reason that leaded Boeing to fail on StarLiner, while SpaceX succeeded on Dragon doing exactly the opposite. Nope. I just blhad bought a 2012 MacMini, two years before the thing going the Dodo way. You see, MANUFACTURING. 2014 MacMinis are a completely different beast than 2012. And yeah, I learnt that the expensive way: by loosing my time on a 2014 one. Both passed the manufacturer certification standards, but only the older passed on mine. Dude... Six Sigma is a quality assurance process... please do some diligent research before throwing weak arguments on a (until now) serious conversation...

That's the problem I see with the current "safety mindset". 737 MAX had all the documentation demanded by FAA, and still... People just don't understand that "certified limits" are just it: limits that the manufacturer bored to certify, they just don't implies on operational limits. People working on manufacturing knows that it's not rare that whatever you sell is able to sustain way more abuse than certified, but since the customers are not willing to pay for a more thoroughly certification process (as the current certified limits are enough). The whole experimental thingy has its name for a reason. Proof of concept? I have a MacMini working fine for 12 years. I still use that Mac Crap for work, because it's good enough and it had survived my last rig I had bough to replace it due "certified limits concerns". Go figure… (And not, this is not an absurd comparison, I'm talking about manufacturing: the same Six Sigma process that can be used on computers can be used on submarines). I'm not trying to pull any dirt under the rug, but first we need to know about the dirt. Unless you are some authority on the field, the fact you don't have any documents or have doubts means squat. And if you are an authority on the field, then you are accomplice of the problem you are denouncing, and I don't see a reason to take what you say too much seriously due conflict of interest. If the thing was experimental, if everybody onboard were perfectly aware of the risks, and still decided to go - well, it was their choice: it's a free World and people are allowed to make such choices. I will agree with you, however, if known flaws were being covered up for the sake of profit - that would be a criminal offence to my eyes.

If they got entangled on a fishing net strong and heavy enough to drag them into the bottom, anything attached to the hull would probably be damaged in the process. Additionally, depending on how much material would cover the submarine on the entanglement, the material would jut absorb the signals. This can also explain why they are being heard only now - they would be banging the hull for days, but the sound could be being muffled by the fishing net - and only now, when the rescue effort got near enough, the sound could be heard. Keep in mind that the damned sub is mostly made of carbon fiber, a material not exactly easy to be detected using sonar not to mention magnetometers. I prefer to avoid speculating about the motivations that leaded to the accident for now, but yeah… Normalisation of Deviance is usually the root cause of such accidents. — — POST EDIT — — A possible explanation for the ping ceasing from being heard during the descent is by crossing a thermal layer. That would shield the mothership from receiving the pings.

Assuming they are still alive, this is merit of the submarine's project. Au contraire from stupid people criticising the use of a of-the-shelf game controller from a famous game manufacturer, the thing was well engineered. There're lots of safeguards on it (granted, perhaps a few more are needed). However… exploring the bottom of the sea is as dangerous as exploring the space - lots and lots of things can go wrong, and a single one will ruin your day and probably end your life. No matter how well you engineer something, sooner or later it will fail due something no one had thought of, or plain tear and wear. It's unavoidable that an accident would happen one day in the same sense that's unavoidable sooner or later someone will die on space: hell, we can't prevent people from dying while crossing streets! My guess, at this moment? Assuming the hull didn't collapsed, they got entangled by a fishing net or something. These guys are diving for years already, anything related to hardware (other than hull tear and wear) would had happened already. It will be probably the feat of the century! (sincerely hoping for the best)

Post the KSP.log using dropbox or similar service and I will see what's happening. Otherwise, I can't help!

When you try to press ESC and then select Revert to Launch while seeing StarShip doing pirouettes.

Wobbly rockets happens when you abuse the structure. It's meant to be a failure, user's failure, a failure on designing a rocket that both do what it's intended to do as well respects some constraints. This is a game, and building crafts under constraints is part of the challenges imposed by the game. If the wobble is to be gone, it needs to be replaced by something else, as plain R.U.D. It removes challenges. Juno is another kind of game, it promotes visuals over constraints. If we would be talking about kid's toys, Juno is like a Modelling Dough, while KSP is like LEGO: two completely different kinds of toys, to be used in completely different ways. KSP2 needs to decide the way it want to go - LEGO or Modelling Dough. It will fail if it tries to be both. I agree with Nate, besides rockets generally don't just snaps: they plain explodes or just collapses: Snapping is one of the possible "punishments" by not respecting some constraints. If snapping is to be gone, it should be replaced by something else - as plain collapsing. What's just a convoluted way to "snap" after all. Oh, you don't like playing under constraints? Not a problem: here, take this nice cheat and play as you like! I choose to play KSP over Simple Rockets (1 in the past and now 2, aka Juno) and Orbiter exactly because I like to build things under constraints - I always liked more playing LEGO than Modelling Dough. Stock parts doesn't cut it? Finding an add'on that does what I want is also part of the fun, as well as coping with the new constraints such add'on brings to my gaming. If KSP2 is going the Modelling Dough way, I will just not play it - sticking with KSP1. I already have Juno for playing this style, and it's available now and it runs on my current machines. (I wonder what would happen if someone writes an add'on for Juno adding little critters like Kerbals to it - bonus points if they are Kerbals indeed! ) My personal opinion about this is that they should had gone No Man's Sky style: just shut up and do the work with occasional releases. It's nice to have such kind of feedback from them, I'm enjoying reading most of them, but they are also exposing themselves to unfunded and uneducated criticism, and this can be both abrasive to the game's reputation as well also exhausting to the game developers. They start to listen to people around here, and KSP will be reduced to a stand-up guyly [mongrel] and better funded copycat of Juno.