Lisias

Meno male. Check Kerbal Konstructs first. It was the one directly involved on the crash.

Granted, I my had made a mistake. This is my reasoning. On my post, I took the "less favorable" KSP2 stats as well the "most favorable" ones, observed the gap and established that we have a huge margin for errors, from KSP2 selling ~3.58% of the KSP¹ copies to ~16.48%. I compared the values from the same sources. I used Play Tracker's KSP2 values against KSP¹, then I used Steam Spy's to do the same. I'm not averaging values from different sources because I don't know their sources neither the methodology they used to reach these values. I just assumed all them are equally competent to report these values, but without knowing their sources, I could irresponsibly use the same mass of data more than one time, contaminating the sample space. So I ruled out averaging the different sources reports on the spot (seriously, this should be a no brainer). Where is the error on declaring that we have a margin for errors from 3.85% to 16.48% ?

You are claiming a 95% of confidence on an average number between (278.9k - 836.9k) ?

Your arguing sounds like that, no doubt. Average? You are using average to support your claim? You still have a margin of error between 3.85% and 21.2%!! If you cared to check at least ONE of then, you would find a very, very interesting data: Stats Copies sold: 557.9k (278.9k - 836.9k) Gross revenue: $25.6m ($12.8m - $38.4m) Source: https://gamalytic.com/game/954850?utm_source=SteamDB Do you see that two values between parenthesis on copies sold and gross revenuw? What do you think they mean? You are averaging numbers already averaged, damn it!

All this hype train about KSP2 recently made me remember this one today: Ozzy Osbourne, Crazy Train.

Fact check. Let's munch the numbers so everybody can see by themself: https://steamdb.info/app/220200/charts/ vs https://steamdb.info/app/954850/charts/ Steam Spy KSP¹ : 3.58M KSP2 : 590K Ratio: 0.164804469273743 , or ~16.48% Play Tracker KSP¹ : 6.24M KSP2 : 240.7K Ratio: 0.03857371794871795 , or ~3.85% You see, given this margin for errors, 1% is not that off. Mainly because we don't know how these trackers handle refunds. Users that got a refund are removed from the tracking? Because, if not, the numbers for KSP2 are highly inflated.

That AWS borkage was hilarious! https://www.linkedin.com/pulse/oops-we-forgot-30m-bandwidth-charges-david-penny

It's a possibility. But to be sure about that, some heavy testing in on the way - do you have plans for this weekend? Reinstall only KSPCF and try to run your test bed again. This will rule out KSPCF at once, or will definitivelly pinpoint it as the cause of the problem. If Principia borks by installing only KSPCF, then you already have a minimum test session to reproduce the problem and can file a bug report on the KSPCF guys. It would be nice to also post an alert on the Principia's thread about the subject, once the KSPCF guys give you a feedback about the problem and, perhaps, a workaround. But I'm jumping the gun here, let's first be sure about the source of the problem. Do you use CKAN or similar tool?

Without knowing exactly what and why is borking, no. It's the reason I choose to left Principia to be the last one to be removed. You should really try to remove KSPCF and put Principia back to see what happens. Otherwise we will not know to whom ask for help. If Principia borks without KSPCF installed (better, without Harmony at all), then the issue is surely on Principia and you should reach them for help. If Principia works without KSPCF installed, then the issue is related to KSPCF and they would be the dudes you need to reach for.

Before or after the huge layoffs happening on the whole industry in the last 6 months?

"We have proof of the existence of Intelligent Life on Planet Earth".

Well, whatever happened, it literally killed the whole process on the spot. Sudden death, instakill. It's like Thanos snapping the fingers using the Infinity Gauntlet on the process. KK was only the poor stand-up guy trying to load something when the whole process got instakilled by Windows. Such a drastic measure bypassing the Unity's crash handlers in the C++ Land means that something wrong happened in the Kernel domain, that so panicked and just bluntly removed the whole process from the system as a last measure resort to keep the system alive for time enough to at least log the event. The Windows' system log should have the exact information about the event, but I have a guess about what could be happening. I think you blew up your VRAM capacity, and this somehow leaded to the chain of events that ended up with the process being killed. It may be a NVidia driver bug, or it may be a unfortunate interaction between Principia e KSPCF, as both these things make some deep changes on the KSP's internal software stack, and it's probable that one of them ended up stepping on the other's toes when things started to go to hell. Principia is more likely to be directly involved on the mess (being a victim or the perpetrator) as it makes heavy use of C++ too, but I know that patching the runtime using Harmony may lead to some unforeseen side effects (like about handling App Domains when CIL code is patched in memory). But, and again, I'm throwing "things" into a wall hoping for something to stick. First, let's see if VRAM is, indeed, involved. Make a full copy of the whole KSP installation to somewhere else (like the Desktop, it makes it easier to locate it later). From this point, use only full backups because this is going to be destructive. First, remove ReStock and all partsets what makes heavy use of high definition textures. This will shrink the VRAM footprint considerably. Then try to load a savegame again (it may fail, but a savegame failling to be loaded instead of crashing the process is a progress!) This failing, remove Scatterer. Try again. This failing, remove KSPCF. Try again. At this point, my only suspect would be Principia - but let's worry about it later. If after removing KSPCF things still blows up, send me again the new KSP.log AND Player.log - chances are that they can provide us, now, with some new information.

Apparently you did, but I need to ask: did you reproduce the problem (i.e., loading a savegame and then seeing the thing crash and burn into Desktop) before sending me log?

Well... They are. I'm not agreeing on how the argument is being developed, but they have a point. First, you need to consider that what YOU consider a good job is not necessarily what they would. For an example, I'm a (software) engineer, with an engineer mentality. I can see a very expensive craft hugging the ground and still see it as a success - depending on the mission parameters to be achieved. Using a Real Life® example: as an (software) engineer, I consider the Apollo 13 the NASA's pinnacle of technical achievements in the whole Space Flight history. "How", one would argue, "they not even landed on the Moon!". Well... Nobody died neither. That Project was a failure, they didn't landed on the Moon. But it was a huge and magnificent success for the Program, literally, their finest hours. The Mission was a success - everything that could go wrong did and something more, and yet everybody came home alive. No widows crying in the New's front pages. From a Project point of view, there's a good chance that @Bej Kerman can be right on their opinions. They're arguing about KSP2, the Project- not about the whole franchise and what it could be (what could be seen as a Program).

Gee... It was a "hard crash", the KSP.log suddenly stops here: [LOG 16:42:03.992] KK: [CareerState] Load: Stopwatch: "Loading" elapsed time: 00:00:00.0000055 I doubt KK has any involvement on the matter, because it finished doing its business. On a wild guess, the next step on the loading process triggered the hard crash, but it is so devastating that it kills Unity itself. I have some guesses, but I would prefer to check the Unity's Player.log first to avoid wasting time with false positives. Check this thread for how to fetch it: Or just read the cheat sheet below Where %USERPROFILE% is where your Windows' home directory is. If your windows login name is aviator01, it is probably on C:\Users\aviator01 . So the file you want would be C:\Users\aviator01\AppData\LocalLow\Squad\Kerbal Space Program\Player.log

You see... One of the many problems plaguing KSP¹ lately may be the root cause of this. Check the history here: Once I managed to correct the last standing bug on that !#$!#@#$@!!# problem of being overrulled all the time by Editor (I managed to get everything tight, less the Cloning of parts - heck, I just can't see from where and how my values are being written over on this one), I suggest trying KSP 1.7.3 to see if the Robotics gets more stable. Or less unstable...

I disagree. @HarvesteR ideas were intended to develop a prequel - Flight before Space, and it makes sense. So, nope, it would no be a KSP2 for sure. Since I'm currently playing games heavily focused on biplanes, or at very least, atmospheric flight as a side kick for low orbit flight, I can see where he was intending to reach, and at least me would buy the idea. Heck, I still waiting for "The Barn". and I absolutely loved the @Moach's Motor Wings, I'm still liquided with myself for not being able to jump on it at that time - Kraken damned Real Life™ that became a Pandemonium© Assuming he would had success with such prequel, the next installment would be probably Colonization and the next one, Interstellar faring. You see, he had a Plan - he intended to create a "dynasty", not a mere money grabbing sequel. As I said before, I would buy it. However... You are right too - to an extent. This would be a huge risk taking endeavour, with a reasonable risk of not being profitable as the original KSP¹ was. I'm disagreeing more on how you are building your argument than with the argument itself. The only real disagreement I'm having with you about this is that I think it would worth the shot nevertheless, even by not being so successful as KSP¹ - if not by other reason, as a way to create new technologies that could be applied on the sequel later - without utterly disrupting the original, as it was being done since then. The lane used by Squad was, frankly, a terrible one for the franchise on the long run.

Se não me falha a memória, você precisa transferir a peça (drag and drop) para o inventário do engenheiro. Abra os dois inventários (use o alfinete no topo à direita para manter mais de uma janela aberta), e tente o movimento.

There're worst places to be.

Unfortunately, this site is conditioning the download of the file to click and accept installing a thingy called... OperaGX? (links and images removed, only text) To continue the download of the KSP.log - complete the offer below OperaGX: Install and Open Complete 1 more offer(s) to continue By downloading the file you are hereby agreeing to our terms and conditions. Sorry, dude, no way. Publish the file in some service that would allow me to download the thing without this kind of gotchas and I will help. Dropbox, google drive, sent it to me by email or use the Discussions on github of some add'on of mine if needed, whatever. Cheers!

Interesting news. Take-Two CEO says he's 'not trying to be cute or difficult' with vague answers about the fate of the Kerbal and OlliOlli studios, but is kind of being cute and difficult Take-Two says it hasn't closed Intercept Games or Roll7, two studios it was reported to have closed, but won't elaborate. https://www.pcgamer.com/gaming-industry/intercept-roll7-closures-update/ Well... Perhaps, just perhaps, the backslash had some influence on the matter.

If it's something he's doing incorrectly, the game is failing to provide him with some hints about the problem. Silent failing is the root of all evil. If the parachute can't be opened by some reason, some way to indicate the problem must be provided to the user, otherwise we have a design flaw. Of course, I'm assuming that, indeed, there's no indication of the problem - I never played KSP2, so I can't tell.

There's a difference between a bug, a design flaw and a design consequence. Bugs are fixable, design flaws usually demands a huge refactoring. A design consequence is not fixable, it's mitigable. For example, take the air inflated rubber tires in your car. They have this pesky habit of getting flat when punctured by nails. This is bug, a design flaw or a design consequence? Well, a design consequence. You can't prevent a tire from being punctured, but you can mitigate the problem by making it more resistant to small nails, and to fail graciously when a bigger one happens - but you can't "fix" the fact that they will get flat every time they are punctured by nails, and you can't prevent that they may get punctured eventually when a big enough nail gets in their way. Some of what people says are "bugs" on KSP¹ are essentially design consequences that the Dev Team failed to mitigate. You can't have the cake and eat it too! THIS is a bug, no doubt! This may be a design flaw that is being badly worked around. You see, the whole Unity thingy makes heavy use of floats to do computing. But precision computing needs to be done on doubles - and when you are timewarping, precision starts to get critical pretty fast. One of the problems on the lack of precision of floats is when handling colliders on distant objects that are still on the Physics range (or just getting into it). A tinny little imprecision to the wrong side, and you have a part being clipped into the ground collider and.... So, or we have a design flaw on timewarp that is failing to cope with this problem, or there's no other way to implement timewarp and then the mitigations being used are not working as they should. The mitigation process used by KSP¹ is to instantiate the objects slightly above the near colliders and then graciously "land" them, avoiding having one of the parts spawning inside a ground collider (triggering the badaboom). Obviously, this can lead to some undesired collateral effects, what suggests that the mitigation may need some more thinking (or some more working, or both). On KSP2, the damned mitigation appears to be just broken or half-baked. You got this problem when boarding Kerbals because Kerbals are, in essence, just single part vessels with fancy animations and are subject to the same problems. By "unspawning" the Kerbal, they probably triggered this mitigation process for all crafts in the current physics range "by default", instead of running the current state into a decision process what would decide what crafts would need or not this collider mitigation process. The Fuel Priority may be just a Feature not Implemented Yet™. But the rest is, indeed, some really bad decisions on the design. I instantly rejected the new UI for being way less easier to read on a glance. Look on an old aircraft cockpit - you have instruments scattered over the panel. But they are clustered by need - instruments needed for landing are clustered together, instruments used for navigation too. Some instruments are replicated not only for backup purposes, but also to have a copy available when needed on more that one "cluster". On KSP¹, the most important instrument is the Altimeter, as it's what keeps you from getting RUD'ed by a UGC (Unplanned Ground Contact) most of the time. It's the reason it's on a privileged position on the screen. The navball et all are secondary instruments used when flying and landing - interesting enough, the NavBall is less important on landing than one may think, because or you are landing an airplane, and so you are more or less parallel to the ground already (otherwise you would be in an uncontrolled fall, an unconfortable situation in which you are not exactly worried about anything else but how much time until UGC), or you are on a suicidal burn - another situation in which you already know the craft's attitude, and the only thing that matters are the altitude above the ground, the vertical speed and how much fuel do you still have. Except by the fuel remaining, the current instrumentation is adequate on its current position. Apparently I'm the only one that understood the meaning of the wobbling. In real life, unsound projects would just break apart in flight. This makes diagnosing extremely difficult, because you would need to infer the point of rupture by analyzing whatever you find from the leftovers of the craft and doing a lot of calculations and simulations. Wobbling crafts would be the alternative to plain RUDs when unsound crafts are launched. IMHO they failed to balance what's should be considered a sounding project for the physics engine. I fully and unconditionally agree with you on this one.

But that wasn't the purpose of the exercise I was proposing - I was debating your statement: so I didn't understood that you had changed the subject of the discussion. You kepting my "Nobody is a hell of an overstatement. " statement on the quoting didn't helped me to detect the change neither. Well, now I know.

It's the problem with Google, it will trimm the results to your profile. This is a list from mine (using the very same link I used above): Jovem Nerd Estúdio de Kerbal Space Program 2 será encerrado após demissões 2 weeks ago UOL Kerbal Space Program 2 Is Getting Review-Bombed After Take-Two Shut Down Its Developer Dec 22, 2023 IGN Kerbal Space Program 2 Is Getting Review-Bombed After Take-Two Shut Down Its Developer 2 weeks ago UOL Kerbal Space Program 2 Is Getting Review-Bombed After Take-Two Shut Down Its Developer 2 weeks ago Game Developer Update: Take-Two confirms Kerbal Space Program 2 is safe despite Seattle layoffs 2 weeks ago PC Gamer Kerbal Space Program fans react with anger over Intercept Games closure, and you know what that means: Review ... 2 weeks ago Epic Games Our guide to exploring deep space with Kerbal Space Program 2's For Science! Update Feb 6, 2024 Space.com Kerbal Space Program game director and ULA CEO talk STEM collaboration and companies' futures (exclusive) Feb 23, 2024 Olhar Digital Jogue como Elon Musk! Kerbal Space Program está por menos de R$ 20 no Steam Jun 9, 2023 Terra Jogamos: Kerbal Space Program 2 é mais acolhedor que antecessor Feb 24, 2023 <some others I'm omiiting> Yahoo Finance Canada Take-Two is shutting down the studios behind Rollerdrome and Kerbal Space Program 2 2 weeks ago TechTudo Kerbal Space Program 2: veja gameplay, história e requisitos mínimos do jogo Feb 25, 2023 And so goes on. You see, your initial statement: It's a heck of an overstament at best, or just don't hold itself at worst. For the best or for the worst, KSP in on the media.