softweir

Scott Manley's analysis of the footage (Includes the - at this time - ironic "Fly Safe" at the end!)

There has been a bit of talk about "attitude", but people have been conflating our attitude with that of SpaceX. My attitude is "sh1t happens. Rockets explode. They were due one. <jeb>It was pretty!</jeb> Let's hope our favourite space company can deal with this without suffering excess financial loss, and no human fallout (ie redundancies) occurs." (Sacking(s) due to incompetence are another thing entirely.) After all, I am not in any way connected to SpaceX, I have no influence over their work practices, technical decisionmaking or corporate "attitude". I have the luxury of taking any attitude I please! SpaceX and other parties involved in the investigation will take a very different attitude. They will be digging through all their hi-res footage and telemetry data and trying to pinpoint the causes of this accident, and will bend over backwards to make sure it doesn't happen again - their company depends on it, their jobs depend on it. Elon Musk is extremely rich but his pocket won't be infinitely deep, nor the pockets of other investors or banks he may tap to keep SpaceX afloat if they start to have too many accidents. Everybody in the company ought to be aware of this, and will do their best to avoid financial stability becoming an issue. Nope. All we know is something went boom. Some amateur video analysis places the observed centre of the boom close to one of the fuel filling ports, but we don't know if that is relevant. We await a potentially long and complex investigation.

Your irony magnetised my monitor and has wrecked it. I will bill you!

According to This Thread it did not happen. (The bit a few posts down about the National Physical Laboratory is a laugh.) However, there have been plenty of real examples of this sort of error.

I love the use of the phrase "flight-proven"!

Do an internet search for memtest and download the latest version for Win10, read the instructions and run it. (Other memory test programs are available.)

That was due to Unity's very bad implementation of 64-but, which most people find has been fixed. Regardless - it won't cost you anything to test your memory, and might solve a few problems!

Might that be because KSP is the only app that uses that much memory? It's always worth getting a memory test app and running it.

Wi-Fi signals are generally omni-directional or at worst have a broad uni-directional beam, so they are relatively immune to vibration. (Not totally immune - pick up your network hub and shake it and some of your devices might well start dropping packets.) There is unlikely to be any wi-fi in the immediate vicinity of a launch-site, and any control signals will be sent from a building some distance from the pad, just in case of accidents. The problem with the barge landings is that satellite video links have to be very precisely directional, and everything is very close to the actual landing so the vibrations are intense. As @magnemoesaid, tactical rockets are weaker and use more powerful transmitters, plus they are using low-bandwidth telemetry systems, not high-bandwidth video. Similarly, tactical missiles are launched some distance from the control centre, and the control centres have dedicated landlines to communicate with the outside world. Interference is just not possible.

Can I suggest you link to your first post on the problem so people don't have to go searching for your description of the symptoms? That would make people much more likely to help.

Indeed. Wind-tunnel tests using pulsed smoke and sparse diffusions of particulates show that the air moves only fractionally faster over the top of the wing than over the bottom, and the difference is too small to explain the lift gained.

That... is impressive. Very, very impressive! (Such concentrated energy - and they still need a mains supply!)

Best place to mention this is in the Suggestions forum! (There may already be a request for scalable UI there, so be sure to not check so you don't create a duplicate.)

This is exactly the right place to talk about it! And yeah, real-life burns take a lot longer than KSP burns, especially ion-drive burns which in KSP have been made very overpowered compared to real life to reduce frustration.

I saw a thread about it on the Egosoft forums back in July 2011 and was tempted. I think it was This Clip which attracted my attention - the fact that very, very silly mistakes had genuine meaning. Back then it was a free download (o.9 iirc), so I went and grabbed it. I bought it when it went commercial, and bought it again when it came out on Steam. I'm taking a rest from it at the moment. I feel I "did" Sandbox mode and Science mode, but am not yet drawn to Career mode. I may revisit it in a version or two if there is a bit more to see and go to.

Q) "The structural fairings don't have this ability (why not?)" A) Because that is the point of the structural fairings! They are intended for use when a player wants to permanently enclose a lot of gubbins, for instance when building vehicle sections that contain batteries, RCS tanks etc etc - things that don't get jettisoned or ejected. Users of PF asked quite loudly for a set of fairings that can't be accidentally staged when, for instance, they are in the middle of an aircraft body. Q) "How can I get this to work?" A) It appears you only have one fairing base for the lower section of fairings - you need two. Insert a second fairing base upside-down above the command capsule, attaching it to the "floating" node of the lower fairing base. Move the floating node above the top of the capsule tip before trying to attach the upside-down fairing base. Also be sure to connect the fairings to both the upper and lower bases as you form them! All this will make everything is properly enclosed until you eject the fairings. I hope this helps!

He was back to talking about SpaceX when he said boosters. That's a bad habit, having multi-topic sentences! It leads to confusion.

The default deployment speed is the same, but you can tweak it so it deploys at a much high altitude and speed without destroying it.

It happens. The good news is that both guys left for completely legitimate personal reasons and there is no suggestion there are any bad reasons. Companies have to deal with turnover, it's part of life. Unlike other fandoms, we get to hear about this stuff because Squad are so much a part of the KSP community, not just the developers!

That looks badly broken. The voxels ought to be hugging and covering the skin of the craft, not hanging off in empty space leaving the skin completely bare. Try removing any tweakscale parts you have on it, then try replacing non-stock parts with stock parts until one of the changes fixes the voxels, in which case the last part you removed was the culprit. Then put back the other parts you removed, and if the voxels go wrong again then you have several culprits!

Taken from http://forum.kerbalspaceprogram.com/index.php?/topic/83213-please-read-before-posting-stock-support-bug-reporting-guide/

Probably dropped FAR on the AVC folder by mistake, instead of on empty space! I do that sort of thing often enough.

Of course, the owner of the "prior art" has to be able to prove how long they have been using the patentable idea. You implied that when you mentioned Carl having emails proving the date, but I feel this point needs to be made explicit! No proof, and there is a danger that the patent may be upheld.

Note: you also failed to supply a log or a craft file of this vehicle. Ferram won't be able to even look to see if this is a bug until he has that information. Also, it would help if you can get the same behaviour with a minimal set of mods, such as FAR and its dependencies and nothing else.

Yep. Two weeks. Thank goodness, they must have been exhausted after so many weeks of debugging!