Lisias

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.

What Musk intend to do is his problem (this dude is not saint, but he's not stupid neither) - from the human point of view, I know that 14 years old kids don't have yet the maturity to withstand a full time engineering job. He will be shielded, and so ended up being spoiled by lack of honest feedback, or the kid will be crushed by the job demands. You can't expect team mates to fulfil parental tasks - as educating the kid. There's a reason kids are not allowed to drive cars, contract loans et all. And, as the cat, the kid is not going to have his best interests attended.

I have kinda a grudge with 1.11. I had detected and fixed a pretty annoying problem on 1.8 <= KSP <= 1.10.1 where Kerbals and Crafts would drift when parked no matter what. I nailed the problem to be spurious torques being applied to the parts randomly, and cooked a workaround. Problem: on KSP 1.11.0, Squad "fixed" the problem in a way that drifting was still an issue and my workaround was rendered useless so, frankly, I kinda gave up. Debugging, diagnosing and fixing things is a very laborious and task consuming task. So sticking with 1.7.3 ended up being the best cost/benefit to me even nowadays, falling back to 1.4.3 for quick stunts (as this thing loads waaay faster on my rig, and it's also one of the most performatic KSP - second only to 1.3.1 and 1.2.2!) Uh… Yeah, you are right! Anyone enjoying detective games and liking XVIII Century sea tales, Return of the Obra Dinn is a must. Seriously, one of the best games of that genre I ever played. https://www.gog.com/en/game/return_of_the_obra_dinn

Pinpoint this thread. The KSP.log you published may help them to pinpoint the problem. Most of the time us a pretty silly detail we, developers, let pass trough. -- post edit -- Check this post: Do you have DART installed? (On mobile right now, can't see myself). If yes, so there's no need to bother Parallax guys : remove DART and reinstall Parallax and things apparently will be fine!

Appears to be Parallax. [LOG 20:17:28.050] [OD] Enabling Body Kerbin: True [EXC 20:17:28.307] KeyNotFoundException: The given key was not present in the dictionary. System.Collections.Generic.Dictionary`2[TKey,TValue].get_Item (TKey key) (at <9577ac7a62ef43179789031239ba8798>:0) ParallaxOptimized.SubdivisionData.DetermineMaterial () (at <40e34d3c09734e828597afb2f90e2e92>:0) ParallaxOptimized.SubdivisionData..ctor (PQ quad, System.Int32 subdivisionLevel, System.Single subdivisionRadius, System.Boolean subdividable) (at <40e34d3c09734e828597afb2f90e2e92>:0) ParallaxOptimized.PQSMod_Subdivide.OnQuadBuilt (PQ quad) (at <40e34d3c09734e828597afb2f90e2e92>:0) PQS.Mod_OnQuadBuilt (PQ quad) (at <4b449f2841f84227adfaad3149c8fdba>:0) PQS.BuildQuad (PQ quad) (at <4b449f2841f84227adfaad3149c8fdba>:0) PQ.Build () (at <4b449f2841f84227adfaad3149c8fdba>:0) PQ.SetVisible () (at <4b449f2841f84227adfaad3149c8fdba>:0) PQ.UpdateVisibility () (at <4b449f2841f84227adfaad3149c8fdba>:0) PQ.UpdateSubdivision () (at <4b449f2841f84227adfaad3149c8fdba>:0) PQ.UpdateSubdivision () (at <4b449f2841f84227adfaad3149c8fdba>:0) PQ.UpdateSubdivision () (at <4b449f2841f84227adfaad3149c8fdba>:0) PQ.UpdateSubdivision () (at <4b449f2841f84227adfaad3149c8fdba>:0) PQ.UpdateSubdivision () (at <4b449f2841f84227adfaad3149c8fdba>:0) PQS.UpdateQuadsInit () (at <4b449f2841f84227adfaad3149c8fdba>:0) (wrapper dynamic-method) PQS.PQS.StartSphere_Patch0(PQS,bool) PQS.ForceStart () (at <4b449f2841f84227adfaad3149c8fdba>:0) PSystemSetup.ForceInitPQS (PQS pqsIn, UnityEngine.Transform target) (at <4b449f2841f84227adfaad3149c8fdba>:0) PSystemSetup+<SetupLaunchSites>d__38.MoveNext () (at <4b449f2841f84227adfaad3149c8fdba>:0) UnityEngine.SetupCoroutine.InvokeMoveNext (System.Collections.IEnumerator enumerator, System.IntPtr returnValueAdd ress) (at <12e76cd50cc64cf19e759e981cb725af>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) [ERR 20:17:28.453] PQS Kerbin: Restarted Uninstall it to see what happens. If it works, reach Parallax maintainers for help. If it still borks, post a new KSP.log here and mention me and I will check it again! Good Luck!

Elon Musk's SpaceX hires 14-year-old whizz kid as a software engineer at Starlink https://www.thenationalnews.com/business/technology/2023/06/16/elon-musks-spacex-hires-14-year-old-whizz-kid-as-a-software-engineer-at-starlink/ Exactly what one needs to do to get hired as "Engineer" nowadays? (the kid graduated, at least. but… still…)

(late) @AlamoVampire I did i!

Dude... someone was drinking on the job... not enough the weird appearance, the fuel tank was placed between the pilot (over the engine) and the gunner. Ok, it was heavily shielded but yet... Ilyushon IL-20 (1948) https://forum.warthunder.com/index.php?/topic/514891-ilyushin-il-201948/

If this is a bug on Toolbar, yes. If this is a bug on something that Toolbar relies, it may affect something else with not so benign effects. Normalisation of deviance is a problem by itself. It worths at least a superficial investigation to figure out the possible causes. So it's something on code and, so, should be affecting not only Windows. Makes things easier for me, to tell you the true. Let's see what I manage to pull from this hat. Really? So the log is lying to me?

Are you talking about this one? [ERR 06:52:29.853] [Toolbar] [ERROR] button texture not found: KerbalLaunchFailure/PluginData/Textures/warning_24 The file is inside a PluginData, so KSP is not mangling with it for sure. Check if the file <KSP_ROOT>/GameData/KerbalLaunchFailure/PluginData/Textures/warning_24.<something> exists. Check the casing of the pathname, check the casing of the filetype (JPG instead of jpg, for example, or even Jpg). You are running Windows 10, that usually uses a case insensitive file system - but NTFS can be configured to be case sensitive… But it's a wild guess. What is your Windows Localization? Unity has a pretty nasty habit of replacing chars with dots, a living hell on PT-BR, as we have a lot of non-ascii chars on our alphabet and I bet this can be even nastier to non roman alphabets as Greek, Russian and Hebrew. I once got royally screwed because I created a new savegame called Temp without realizing I already a temp one on the file system (I use a case sensitive file system). Dude, files were being written on the wrong savegame, I don't need to tell more… I checked your log, and you are not using any fancy chars on the KSP's pathname, however. But it doesn't hurts to check.

Only "amateurs" get their hands dirty. Professional ones seed the discord to be spread by ingenuous people. A Person is inteliggent, People are dumb! But, and again, pure expeculation. I have no evidence of such practices - but, hey, such practices leave no evidences!

You are forgetting a significantly relevant factor: recently, TT2 fired a lot of people from P.D. and some subsidiaries, most of them management. These people are not happy, and you can bet your mouse that some of them have a grudge about the ordeal and acquired a personal (and professional) interest on the failure of this project. The gaming industry is not exactly above F.U.D., Astroturfing and similar scumbag's practices. I find some criticisms around here way harsher from what it would be reasonable even from disgruntled and vindictive users. Sometimes I wonder if there would be not some big Company interested on devaluating P.D. or even TT2 in order to try an hostile takeover, as Microsoft did on Nokia years ago (where is Stephen Elop nowadays?). But… This is all speculation from my part.

It will work, but I would not recommend doing this way as you would be hardcoding TweakScale into your parts, annoying people that don't want to use it. I would not recommend this solution neither, unless you are not keen on mixing your parts with Stock ones. TweakScale Support is meant to cope with the Stocks (and some common used by 3rd parties) BulkeHead Profiles. So it's way easier to cope with Stock and most Add'Ons out there if you stick with the scaleFactoers TweakScale gives to you. If you really wants to go Percentage way, just use free and call it a day. There's no point on giving to the user Scale Factors that don't match any other part of the game, forcing the user to just turn "Automatic Scaling" on Editor and hoping for the best. There's already https://github.com/TweakScale/Companion_NAP supporting NeistAir, and since this thing is part of the TweakScale Companion Program, anyone installing it already have such support. It's available on SpaceDock and CKAN under the TweakScale Companion Program: https://spacedock.info/mod/3202/TweakScale Companion (the "UberPaket")

Because History, unfortunately, doesn't rewards Planning, but Results. Boeing completely screwed up Starliner, besides having years of planning and "careful" execution (and a hell of a budget). SpaceX hacked and slashed their way into the problem with Dragon and nailed it, with a incredibly smaller budget and timeframe. SLS finally took over, but after decades and billions and billions of over budget. And they are still years behind schedule. It's possible to go Full Cascade and still get good results, but historically this development model failed more than succeeded because… Humans. People lie, people hide, people pretend - you only need one bad apple on a basket of good apples to lose them all. (and I'm kindly ignoring that people made honest mistakes all the time, some of them ruining the planning and scheduling - but, yet, most Companies just fail on admitting failure early on the Cascade's process, what would allow them to rework all the Planning and preventing getting stuck in development hell later, when it's finally impossible to hide that fatal failure).

Geez! You were bitten by an insidious MM bug that I'm hunting for years already! And I let it scape under my nose! Damn! There's a least one situation where MM fools itself on believing the ConfigCache is up to date. I detected one and fixed it on my fork, but recently I published a bad release of KSP-Recall that I initially attributed to a new mishap on the Cache validation, but could not found it by eye balling the MM's code so I reluctantly ended up attributing to sleep deprivation. You just proved to me that there's still one more bug to go! Can you please send me a copy of every log in your KSP rig? ConfigCache, MM Pacthes, etc. Essentially, everything under <KSP_ROOT>/Logs and <KSP_ROOT>/PluginData. And the Player.log too, for good measure. With this info, I can try to look for hints about what would be this missing use case on the MM' cache validation since right now your rig has whatever is the situation that triggers it! Thanks in advance! In time: https://github.com/net-lisias-ksp/ModuleManager/issues/20