Ultimate Steve

Adsii's comment on the new technical issue thread implies that it isn't adsii, but someone from the new owners.

Update: The weary load of scrolling endlessly through jobs I'm not qualified for and updating my rejection spreadsheet wore me down, so I caved and looked at the NSF McGregor engine data set despite the fact that I said I wouldn't and shouldn't. I made code to go through the data and it returned 102 instances of an engine at McGregor firing two or more times from the same stand in any 30 minute time interval. My code is not perfect - notably, 1 firing, and then 5 firings in 5 minutes 29 minutes later would show up as a "2 firing test" and a "4 firing test" rather than the more sensible arrangement of "1-5" but ehh it is what it is. Raw output from my code: Important note: I don't think the NSF data set makes a distinction between Raptor 1, Raptor 2, and Raptor 3. We know for sure Raptor 3 has been fired, but it does not show up in the data set (the whole data set, not just the restart tests). So when it says Raptor 2, keep in mind that it might instead be 1 or 3. Here are my assessments of the various test campaigns: Of the 102 tests, there appear to be: 6 Raptor tests with erroneous data 5 Merlin tests, likely mostly or fully with erroneous data (No shot they would fire two MVacs at the exact same time from the same stand, that is likely the same burn being accidentally entered into the database twice) 19 tests involving a delay between firings of more than 6 minutes 34 tests that in my view are likely related to middle-ring engines restarting for the boostback burn 27 tests that in my view are likely related to inner or middle ring engines restarting for the landing burn 7 tests that in my view do not neatly fit into any given category (this category may be larger as it is possible I have been too broad in what I consider to be boostback/landing restart tests) 2 tests involving restarting Raptor several times in a short timeframe (the only two tests to involve more than two burns) Notably that adds up to only 100 so I miscounted somewhere but I don't want to recount. Note that the data set only includes tests that succeeded in producing two burns, perhaps there were more with the second firing aborted. And some of the "long duration" tests could be tests of two different things that just happened to be on the same engine less than 30 minutes apart. Assuming my code doesn't have some catastrophic error, there have been no middle-ring mission profile tests of Raptor since at least April 2022 when this data set starts. Now what I'm about to do is probably going to sound a lot like moving the goalposts, but I hope that my reasoning is sufficient. Upon a reinspection of the premise, generally we would expect major engine testing, such as a 3 burn test, to be completed before engines intended for flight are delivered to the launch vehicle. The first full stack was in August of 2021 with a vehicle at the time intended for flight (B4/S20 though it did not end up flying) and I think it had engines installed at the time, though I think they were shuffled around afterwards somewhat. But generally I would expect them to have the Raptor 1 testing done by this point in time. Tests of the first booster with Raptor 2 is a little closer, as the first engines were installed onto B7 in August of 2022 (I have not double checked the ship engine timeline). So that leaves a four month gap between the earliest time we can detect tests and the latest time we could have expected them to have tests done. And that latest time is generous, you would generally want to make sure that engine can do what is asked of it long before you start building 33 of them to put on a vehicle. I would anticipate that sort of testing having concluded far earlier. So now that I have reconsidered the problem, I don't think that we would expect to see the first 3 burn Raptor testing in this data set. Whether it happened or not is still an open question, but this kind of basic testing I now believe would have likely taken place before the earliest tests covered by this data set. Third parties, please call me out if this does not seem like a reasonable conclusion. I found no such tests where I initially expected to find some, and I thought up a benign reason why that may be the case. While I believe that I have done this in good faith, I am not 100% sure I'm not subconsciously starting with a conclusion and then trying to fit the evidence to it, as many of us are accusing Exoscientist of doing. If anyone can find a data set going back further, please let me know. I do, however, find it interesting that they never repeated that sort of test in the nearly three years since. We might see that sort of test with Raptor 3 in the future. What we have seen, however, is a lot of focus on the transitions between two stages of flight, especially in reaction to times when that transition went wrong on the previous mission. A lot of going from engine on to engine off to engine on again with various parameters, appearing to roughly correspond to liftoff --> boostback and boostback --> landing burn. In these burns, often times the burns are not to full duration. I think there is a benign reason for this and I would like to address this before it is brought up. Generally, keeping a rocket engine running isn't as difficult as starting one up or shutting one down. Still difficult, but there are a lot less things that can go wrong for a rocket engine in steady state operation than one actively making changes. If a regeneratively cooled rocket engine can fire for 30 seconds, chances are it can fire for 10 minutes (though this is not always the case - I believe the RL-10 operates at a thrust level that causes creep to happen, limiting its total cumulative firing time). So if you are specifically testing how to shut down an engine and then restart it, it is likely only necessary to fire the engine long enough for it to get into steady state operation. The dynamics of a shutdown after 30 seconds of operation are likely very similar if not indistinguishable from that of a shutdown after 3 minutes of operation, and they are already quite confident that Raptor can burn for 3 minutes just fine. They've even done a burn that was 14 minutes and 57 seconds long. If that is the case, then why waste the fuel, the time, and the noise pollution of a 3 minute test when a 30 second test works just as well for what they are trying to test? By the way, I did look up McGregor's city ordinances to see if anything there was influencing test duration. Nothing relevant stood out, but I had always wondered about that 14 minute and 57 second Raptor test. Why not go for 15 minutes, a nice round number? Well it turns out that there is an ordinance preventing tests of rockets over 500,000lbf (~226tf) for more than 15 minutes of a time, so that answers that question. Not related but an interesting tangent I found. TLDR: I checked the NSF data, I found no such 3 burn tests Exoscientist described, to my surprise. Upon second thought, I believe that if this testing was ever done, it probably occurred earlier in Raptor's development cycle. I would expect that sort of basic development testing to have happened long before any engines were delivered to flight vehicles, which would put those tests before the time at which NSF started collecting data. I did find a lot of interesting 2 burn tests that seem to correspond to boostback restart testing and landing burn restart testing, with a few clusters that seem to correspond to failures in flight. I may, however, to a certain extent, be seeing patterns where there are none. I still find it odd that SpaceX has never felt the need repeat those tests (assuming they were ever done) in the time since, but perhaps they like what they are seeing from the actual flights and haven't found a need. Alright, back to the job hunt.

That is JSON, there is also a CSV available: https://mcgregor.nerdpg.live/api This also keeps track spin primes (denoted by a duration of -1 seconds) and preburner tests (denoted by a duration of 0 seconds). A restart test would generally be detectable as two firings of the same engine type on the same stand within a time frame too short for them to have changed the engine around. Mostly agree, but I will stress that the author also strongly emphasized that there's a wide range of possible reasons for those oddities, and that there may have been too many interesting tests to mention them all. After searching for a while on YouTube, I ended up having to ask someone on Discord where the video of the 30+ firings test was. A test video not being easily findable on YouTube is not reassuring but it is not evidence that these tests didn't happen. Question #1 for you: when you say "I am dubious that [the burns] have been as pristine as portrayed by SpaceX" what do you mean? Are you saying that the available telemetry is being tampered with by SpaceX to project a false image, or that the engine-out indicators and video of the engine failures are not enough acknowledgement of their problems, or something else? I went and checked and they indeed did never do a post flight 4 update on their website. I am also curious as to the cause, but in my point of view, the most likely culprit is something regime specific. This was only the second time they have attempted to light Raptor in that environment (~1.5g, ~1atm ambient, ~0.71atm of dynamic pressure). Question #2 for you: Who are they giving this unwarranted assumption to? And I take it that the engine visibly exploding and the engine out indicator showing the engine has gone out, both on live camera feeds, is not enough to qualify as "mentioning" and doesn't damage the "impression of success" in your view. In that case, what would be sufficient for the general public and what would be sufficient for invested parties such as NASA and the FAA? I would bet all of my money that NASA and the FAA have a lot more data than we do. As I described in an earlier comment: When Raptor shuts down it ejects a large , low velocity ball of fire which tends to float upwards and quickly dissipates. By all reasonable assessments this is normal as it shows up in test firing videos. The landing burn features 10 simultaneous Raptor shutdowns, while the booster is transiting downwards and sideways through the air. Therefore we would expect a very large, low velocity ball of fire, which will be pushed upwards and to the side opposite the direction of travel by the airflow (a tad different accounting for the current wind speed and direction). We would expect this ball of fire to originate from beneath the engines at the time engine shutdown, and to then dissipate shortly after. This is exactly what we observed on flights 5, 6, and 7, though the flight 7 plume was the largest (or we simply got a better view of it) and flight 5 had an additional fire from a cause not yet publicly known for certain. Question #3 for you: What about the "normal shutdown plume" explanation is unsatisfactory for you enough to warrant the FAA stepping in?

Firstly, have you checked all of those thousands of tests to double check this assertion? Seeing as your last few posts have been confidently incorrect about things that are far easier to check (why the Delta IV sets itself on fire and if SpaceX showed the landing burn flame on stream) I'm guessing no. Here is the NSF data on each engine firing at the McGregor, Texas going back to April of 2022: https://mcgregor.nerdpg.live/api/json/testing I briefly considered writing a Python script to go through these and check but I will not waste another afternoon on you like that. You are welcome to do it yourself. The burden is on you to prove your statement correct. I will be very surprised if in their thousands of firings they have never done one mission profile firing. Secondly, we know for certain that they have done dozens of those tests. Even better, these tests have been done in conditions that perfectly match the vibrational, acceleration, and fuel inlet conditions of flight. Better yet, these tests were conducted with the full complement of engines and at the proper ambient and dynamic pressures. They're called the flight tests. Disregarding the "instead" part for now for the reasons described above. There's plenty of reasons to be doing that sort of test. Maybe they wanted a lot of data on how Raptor reacts to repeated startups and shutdowns, cycle testing basically. Maybe they're trying to test some weird engine out scenario that requires rapid restarts of other engines. Maybe (and this is my bet) they are looking at ensuring they could reliably restart after boostback. The time between MECO and boostback startup is similar to the time between the burns in the above tests. In all three of these scenarios this allows them to get the required data while taking up a small amount of manual effort, test stand time, and propellant. They could also just be stress testing it for whatever reason. They've been known to do that, they did a nearly 15 minute firing of Raptor a while back. Given that they have successfully done this in flight dozens of times I question your thought processes. I brought that particular test up as it was a good demonstration of how Raptor's large shutdown plume was a normal thing for Raptor, not to make any statements about reuse reliability. And you changed the subject yet again, posting an unrelated tangent and turning the subject right back to the Raptor reliability conspiracy. But because you insist, above I gave several possible reasons for the test. And if you're going to run thousands of tests, there's going to be some odd looking ones that might not immediately make sense. "I don't understand why this test was done, therefore this test was useless, and evidence that Raptor is unreliable" is a mind boggling way to think.

Update: I have FOIA requested the mishap report from Starship OFT 1. As this document has been requested many times, judging by my going through the request records, and it has not surfaced online yet (aside from the snippets Elon posted to Twitter/X), this is a request that is likely to be denied due to intellectual property concerns, but I thought I'd put my money where my mouth is and make an attempt. I will let you know if it goes anywhere.

You are welcome to, you know, just ask the FAA for information: https://www.faa.gov/foia

During engine startup, hydrogen is flowed through the RS-68s for several seconds to prevent anything becoming oxygen rich (i.e. catastrophically bad) during the startup sequence. Scott Manley has a good video on this: I'm not completely sure why the RS-68 is the only notable example of an engine that does that at liftoff. Surely there are other gas generator hydrogen engines. Might have something to do with its cycle. But in general, engines sometimes vent in strange and often engine-specific ways during engine startup and engine shutdown, which is often visible as a lot of fire. Here are some examples of flames after engine shutdown. The BE-3: The RS-25: The F-1 (not high quality but definitely there): I also looked at Merlin and RL-10, they don't appear to have particularly pronounced shutdown behaviors, so it is definitely an engine-by-engine thing. I believe there are also engines that run a purge with an inert gas either before or after ignition. There's a lot of ways to start up and shut down a rocket engine. Raptor breaks the mold a little as its shutdown plume is particularly pronounced. I am not sure why this is: If you need more to convince yourself that this is normal for Raptor, and that they can again fire the engine after an event like this, here is a time lapse of Raptor firing 34 times in rapid succession with <10 second cooldowns between firings, with a large fireball after each one: Unusually large, yes. But it appears to be how Raptor normally shuts down. (Note: The DC-X video I was able to find is too low quality to determine shutdown characteristics, the video of RL-10 test firings wasn't great either so I can't say for certain if the RL-10 has a pronounced shutdown fireball or not) Correct, but none of those rockets have engine shutdowns during their landing burns. Raptor's normal shutdown fireball is already massive, and the picture in question was taken just after ten of them shut down. As for why the flame was only on one side, I am 99% sure this is due to air resistance, as the booster was traveling sideways towards the catch tower and the flame would tend to be pushed behind. This is also why the flame is above the engines and not below them as the booster is traveling down (helped along by the fact that methane is less dense than air). Did you even watch the video??? And as we would expect from a transient shutdown plume from other videos of Raptor firing, the plume dissipates moments later: Don't get me wrong, I am also frustrated by SpaceX's lack of technical transparency. I would love to read through a 100 page report on the failure of flight 1. I want all the details. Though I think what we've gotten from SpaceX is still a little better than what we've gotten from other private US space companies, though I may being swayed by their top tier video coverage. But for some reason you always jump to a conspiracy without taking the time to think of plausible explanations or to even double check the basic facts you are basing your arguments off of.

Today, I spent all day optimizing the wrong thing! So I've been working on a multiplayer game in Python (visuals using Pygame) as an opportunity to learn stuff I haven't really had to learn thus far. This game involves an n-body integrator. It also involves separate "server" and "client" threads which share data over the network, and the host of the game will run both of them on the same machine (this has been the only configuration for testing thus far) and the players will run just the client (once I get around to actually testing with 2 connected machines). A minor focus early in development was trying to optimize the integrator to see how high of an "n" I could get. Python isn't exactly the most performant language, and the n body problem isn't known for scaling up pretty well. So I really didn't find it at all alarming when I got extremely low frames per second at an "n" of 200. Today I decided I was unsatisfied with that and I decided to rewrite the integrator with vectorization in hopes that it would improve performance. After I finished, I saw no perceptible difference in performance, much to my annoyance. That did get me more closely looking at all of the planets flying around, and they appeared to jitter. Sure enough, after running some performance tests, there were a few sections of the integrator that usually ran well but sometimes took 100x as long to run as usual. After way too long trying to figure out if there was something going wrong with my vector math or my list-matrix conversion, I learned that Python's "threading" library doesn't actually utilize multiple CPU cores like I thought it did. So sometimes the threads were stepping over each other in some very big ways as I had not done any time management/prioritization at all. The integrator didn't take that long to run, it started running, got interrupted for 20-80ms by the client, and then finished running. So I disabled the client for the time being to focus on optimizing the server, and voila! Instead of a tickrate so slow I could count each individual tick, I was getting an average of 164 ticks per second! But the print statements were visibly coming in way too slow for it to actually be 164 ticks per second (printing every tenth or hundredth tick I don't remember, but it was easy to tell). (note: I have not redone collision detection yet so this is not a perfect comparison) The only part of that loop that was not inside the performance timer was the part responsible for serializing the data and sending it to the network. So I ran the benchmarks, stared in disbelief, added some more prints because surely it couldn't be that bad, and - Jsonpickle (the library I am using for arbitrary serialization) was taking 50 milliseconds to serialize ~1700 bytes of data into a packet 133 kilobytes in size. All of that dramatic slowdown at higher planet counts? That wasn't the n body integrator choking due to nonlinear scaling (ok maybe it was with the earlier non vectorized version, I haven't actually tested it), that was the array of objects containing all of the planet data getting linearly bigger, taking longer to serialize. It looks like I'll need a new serializer. I used jsonpickle because it handles literally anything you throw at it (in this case a list of custom objects with a lot of attributes of various types, in addition to some other minor data) and only needs one line of code on each end. If there's not another drop in replacement that can also handle all of that, with that simplicity of use, but significantly faster, I'll probably need to do all of that myself. On one hand, yay! I found the problems! On the other hand, I spent all day optimizing something that didn't need it, all of the threading stuff will need a serious rethink, and I might have to get to write my own serializer. Edit: Upon closer inspection, each individual planet is at least 85 bytes by itself, and all 200 would be 17,000 bytes. I am not sure why Python is reporting the size of the planets array as 1600 bytes. So I apologize for the jsonpickle size slander. It is more of a factor of 8 size increase (likely less because overhead) than a factor of 80 increase. The factor of 8 might just be partially due to going to a string. So throwing that much data around might actually be expected. So now I have two jobs, firstly, make my own (likely binary and not string based) serializer and deserializer, as jsonpickle's time (if not size) is still atrocious and I'm nearly certain I can do better in that regard. Secondly, figure out how to send less data per frame as to not max out slower internet connections. I have some ideas: The client might not actually need all of the data (though if I rip it out, it will be more difficult to put it back in if it turns out I need it later once I add actual features and actual gameplay) The client definitely doesn't need all of the data every frame (currently I'm sending the color, radius, mass, and name 60 times per second, those don't change often). I could just send the important data (velocity, position) and then update the rest of it when it changes (hard) or just update 1% of the worlds each frame (easier but less good). The client really doesn't need that much precision as the server handles all of the math. 8 bytes each for x/y position/velocity adds up especially when I start adding non planet objects like ships, projectiles, etc. The server will still do the math with 64 bit floats (that might not be strictly necessary but I don't want to deal with making sure all of the math libraries accept the other non standard floats), but the results may be transmitted as a smaller (4 byte? 3 byte?), less precise data value for display to the players, converted back to float on the other end for ease of use. Easily cuts packet size in at least half.

Everything about a potential failure cause in the NSF flight 7 discussion thread (https://forum.nasaspaceflight.com/index.php?topic=61945.480) from around page 8 until Elon tweeted about the suspected root cause: Everything in the NSF flight 7 discussion thread after Elon tweeted about the suspected root cause, through like halfway ish through page 25, which is the current end of the thread as I write this: It seems to be a lot of speculation with the same amount of information as we have and a little more competence than we have, except for possibly some new information from the tweets from @DutchSatellites on Twitter/X . I am not sure how qualified this guy is. Scrolled back a little and didn't really come to any solid conclusions and I've already scrolled enough today. I asked on one of the spaceflight-adjacent Discord servers I am a part of if they had heard anything similar, or if they thought this guy was credible, and one person thus far has responded saying that this guy is usually credible but has no idea about this specific piece of information. It hasn't even been four days. I also expect that they at least know the general area (and possibly the exact area) by now but I wouldn't go as far to say that there is no doubt. Again with the whole "No doubt" thing. Maybe this is a me thing but I'm rarely so certain about anything. Have a little imagination. It isn't quite that cut and dry, during the suborbital test campaign the engine section looked like this: And in this configuration they were able to get this sort of camera view: I can't find any good and easily accessible pictures of the new arrangement besides this image from integrated flight test 1, but to my knowledge, the shielding they added is still present on the current generation of vehicles (someone I know recently affirmed this for my recent gimbal calculations), though I could be wrong: The existence of an enclosed space (between this shielding and the tank dome) tracks with the whole thing about an overpressure due to not enough venting causing all engines to fail (which I don't see a reasonable path towards occurring if there was no enclosed space enclosing plumbing related to each of the engines). Notably neither of these camera views are thought to still be available. The first one because the shielding blocks the view, the second one because the addition of the hot stage ring blocks the view (not that it would help much for anything besides stage separation and the couple seconds afterwards). This is the only camera angle in the engine bay that (at least one of) the Starships in the orbital test is/are confirmed to have (in space relight on flight 6): Which is quite lower in order to be able to peek through the shielding, and as such does not have as good of a view of the engine bay as the cameras did during the suborbital test campaign. They (nearly) certainly have camera angles we do not know about but we do not know how many if any are inside the engine bay, or above the engine shielding. Notably with those sea level Raptors in their own cubbies, it might be pretty difficult to image those engines at all, even from cameras inside the engine bay, unless you had like 6 cameras looking down into the cubbies, 2 per engine, along with internal lighting. And then more cameras for the rest of the engine bay. And who knows, they might have done that. Granted, they (nearly) doubtless have loads of sensors that aren't cameras over every inch (every square inch is hyperbole but you get the point) of the vehicle. But we do not know for certain that they have the same cut and dry visual confirmation that they had during the suborbital test campaign. They should not, and the current likely cause is in the new plumbing. We do not currently know the source of the leak for sure but we do know (unless of course SpaceX are lying to us in their official statements): The fuel feedlines for the vacuum Raptors were completely redesigned this flight The fuel feedlines (unclear if this is just Raptor Vacuum or also Sea Level Raptor) were redesigned to add vacuum jacketing And we have the following things that might have happened but I don't currently have hard evidence for: A lot was redesigned for Starship V2, additional propellant feed system tweaks are likely Starship V2 might be designed with Raptor V3 in mind, something on the vehicle side or the engine side might have to be done to "Adapt" the Raptor 2s to a ship expecting Raptor 3s if the interfaces of R2 and R3 are not identical. Guy on Twitter/X alleges that private insider sources say that it was the propellant lines A lot of direct and circumstantial evidence that the fuel feed system has a large percentage of new components. Raptor on the other hand, maybe they modified it a bit to adapt to the new fittings (which may or may not exist) (and they could (and IMO they would likely) have modified the vehicle instead of the engines). Apart from that, they are the same Raptors we have seen on previous flights - If they have leaked it wasn't major enough to get a mention in any report, and wasn't major enough to cause anything visually wrong with at a minimum flights 5 and 6. Again, we do not know for sure where the leak was, but there are many reasons why suspicion currently resides with the propellant feed system and not the engines. If it was the engines, then yeah, they've got to fix that. In that case, it is a good thing they're deep into development of Raptor 3 which, among other things, is designed to replace a large number of bolted joints (and therefore possible leak sources) with single parts, internal channels, and welded joints. Also like. This whole time I had assumed you were replying to other comments I had made about Raptor but I double checked after writing the above (though before the proofread and some edits) and you actually replied to my cost-per-flight comment that was unrelated to Raptor that I had posted 1. because I actually encountered someone claiming 389m per flight (though I now must say that I misinterpreted his words, he was stating that cost per kg parity with Falcon was likely to happen but anything beyond that was unpredictable, apologies for the public slander Anthonator00) and 2. in a (vain) attempt to disarm the quite heated political conversation that was going on at the time. While I will give you the benefit of the doubt - It is quite possible that enough of the political stuff got deleted, for you to go - "Steve tried to change the subject away from the leaks!" and tried to get me back on topic - You are not beating the "Tries to shove Raptor reliability conspiracies into every single conversation no matter how related or unrelated it is" allegations. "Hey, what's with all the politics, how about a nice conversation about approximate launch cos-" "HEY what if Raptor is leaking? What if people are talking about it leaking? It leaked before, they know what caused the leaks and they aren't telling us!" Is a little bit of an exaggeration but it adequately summarizes what I feel. If this continues I'm just going to stop replying. Right now I think the value of my analyses to the others in this thread outweighs the pain of feeling like I'm banging my head up against a brick wall every time you take 5 minutes to pose (often flawed) arguments that take 2 hours to deconstruct. But it is getting very close. Don't ask me what the NSF scuttlebutt is. It is right there. One google away. Go look at it yourself.

I'm going to steer clear of the current topic for hopefully obvious reasons (though I do have mixed feelings on it). I had a conversation with someone on Discord today about the sticker price of a Starship launch - As in, you can go to spacex.com and the sticker price for a launch on a reused Falcon 9 is currently 69.75 million dollars. There are extras that can push that higher, of course. But I was wondering what the sticker price for a standard LEO Starship launch on SpaceX's website will end up being when they finally post one (both in the short term and the long term). Specifically for the sake of comparison, a standard fully reusable cargo launch with no extras (refueling flights will probably be less due to no payload processing). Like on one side you've got the people thinking they will actually get to 2-3m. Then on the other side you've got the people that think that the reusable architecture is so complicated that Starship might eventually be able to get below Falcon 9's cost per kilogram (only maybe putting the sticker price below 389m for a 100t capacity Starship in the long term, more if the payload capacity grows). I find both figures insane. My current train of thought is that barring any major departures from the current concept, Starship's sticker price (once published) will never be more than the current Falcon 9 sticker price (69.75m) with it eventually falling to somewhere between 10 and 40 million dollars per flight (though admittedly that is quite a large range). Thoughts?

I will take a moment to acknowledge that there have been a lot of (thus far to my knowledge) unconfirmed reports of debris falling on land. If this is true then this is probably the most consequential incident Starship has had thus far.

If that's the one thing you took away from that post then you might need to read it again. It is not a reasonable position that Raptor is unreliable because on flight 1 none of the 33 Raptors got to the end of their burns, therefore Raptor is at 0/33 and had 33 engine failures. I took the widest possible definition of engine shutdown for the sake of argument and then pared that down to failures that were conclusively or likely the fault of Raptor by removing failures confirmed to be caused by something else. If I remember right I only ended up with a few actual suspected Raptor failures. If you are curious as to how I would rate this flight, to my knowledge, the current indication is that the upper stage engine shutdowns were all related to the fire above the engines (likely caused by leaks in the newly redesigned fuel feed system) because of that compartment exploding/bursting. The booster engine not restarting during the boostback is an open question. I think this is most likely the engine saying "Hey I probably can't restart given these conditions but I don't think I'm broken" and the flight computer decided to play it safe and not send the ignition command. This tracks with it being seen working just fine later. This is hard to classify as to my knowledge this hasn't really happened before, as having a vehicle with enough engines to do this with is a very new thing. However I must steel man this in your favor as we do not have any official indication, putting flight 7 at 58/59 until the time when we receive further indication. (emphasis mine as to what I'm currently responding to) I think you are misunderstanding the short/medium term goals of this program. Starship is not the product of a typical scenario, where a company needs to start flying customer payloads ASAP to start generating profit. They could have focused on delivery of customer payloads immediately. However here is a list of Starship's current launch contracts and launch plans: Confirmed contracts (note that some of the Lunar payloads are expected to rideshare): HLS and all of the test/flight/refueling launches that requires Astrolab's FLEX rover, to be delivered to the Moon, requiring refueling Superbird-9, a geostationary communications satellite to be launched to GTO by Starship, possibly with and possibly without refueling, that is unknown. Scheduled for 2027. Starlab LEO station, no earlier than 2028 Lunar Outpost's Eagle rover, to be delivered to the Moon, requiring refueling Other plans without (public) signed contracts yet: OffWorld's Lunar ISRU demo (to the Moon, needs refueling, though will likely rideshare with something else) JAXA's Lunar Cruiser rover (though does have a statement of intent from NASA specifying delivery to the Moon in 2032 via Starship, needless to say with refueling) Polaris 3 if that is still happening, requires ability to land on Earth VAST Haven-2 core is planned for Starship with no contract yet, this is going to be very late 2020s at best. If Starship does very well in the cost department, some of the other modules could switch from long-fairing Falcon Heavy to Starship. All of the internal Starlink Stuff, does not strictly require reusability but Starlink is banking on cheap launches so if they don't do this reusably it is very bad for Starlink All of the internal Mars stuff, requires refueling and the ability to land on Mars (I am also assuming here that refueling is not economical without reusability) The entirety of Starship's contracted and planned mission set that can be accomplished by an expendable non refuelable variant is... 3 missions. Superbird-9 (assuming expendable Starship can push it to GTO), Starlab (assuming it is selected for CLD), and one (though possibly more) module of Haven-2, assuming it is actually built. And they have somewhere around 2-3 years until they have their first relevant launch contract depending on when in 2027 they want to launch Superbird-9. For the sake of argument, I will point out that Superbird-9 was originally supposed to launch in 2024. No clue if the delay there is because of the satellite or because of the launch vehicle. But for the sake of Steel-Manning this, I'll assume Superbird-9 has been sitting finished in a Hangar since December 2023 and 100% of the blame falls on SpaceX. In that case, SpaceX missed out on a grand total of 1 commercial launch by not choosing to go expendable at first. To get to the point, SpaceX effectively has 2-3 years with little obligation besides getting re-entry, reuse, and refueling ready for all of its other launch contracts. And as such that is what they are doing. A rapidly reusable, cheap, and reliable heat shield has never been built before. From what I can tell, that is the long pole that is currently driving the schedule. It is a prerequisite for: Cost effective refueling at all High cadence refueling (generally required for boiloff sensitive missions, or if you want to do more than 1 moon mission per year) And therefore it is also a prerequisite for most if not all missions that require refueling, which is the majority of their current contract roster. Thus it makes complete sense why SpaceX has been focused on proving reusability/heat shield functionality while neglecting payload delivery. They do not want to build a payload delivery system and then retrofit in reusability. They want to build a reusable system and then they will use it to carry payloads. In that case, 10-12 and more flights to prove high payload delivery is completely acceptable, as these early flights are not looking to prove that, that will come later. Considering it took Falcon 9 until flight 33 to do full Merlin reuse, doing it in 15 would be amazing. Though let's be generous, they didn't even start attempting supersonic retropropulsion until flight 6, so 28 flights. I'm currently about 50/50 on whether they will wait until booster v2 to reuse a booster or if they are going to go full send and reuse the booster that was just caught. So there is a world in which this is <10. This I am less sure of. This demo must absolutely happen this year to protect against a stupid amount of delays in every other planned mission. However (and I could be wrong or maybe this person misspoke or maybe the person I got this info from is wrong), I think someone at NASA recently said that Ship V3 is going to be required for the refueling demo. If this is accurate, refueling could be a ways away, as it would shift pretty much all of V2 towards early catch/reuse/heat shield testing. This is one thing I am actually somewhat concerned about. Of the western(-aligned) rockets (as I'm unlikely to find anything about the Chinese rockets) to debut since 2020: Ariane 6 did a full duration static fire of the core but without the boosters, a configuration that results in a thrust somewhere near 10% of liftoff thrust in the 4 booster configuration, and is such, not a full up, full thrust, full duration test. Points for at least doing it with boosters, upper stage, and fairings attached though. I cannot find good sources but I think that "proper" sort of testing might have been done for the second stage. H-3 did not do full up, full thrust, full duration testing as far as I can tell. At best the core stage was fired for ~25 seconds without the boosters, though I cannot find any information about the upper stage. SLS did do a full duration test of the core stage, but without the boosters, and without anything above the core attached (if my memory is correct). This is about 25% of the liftoff thrust of SLS. Unsure if the ICPS had been static fired, but given that it has a lot of flight heritage there wouldn't have to be any SLS specific static fires. Vega C might count as its first stage as test fired, though horizontally, and not with the rest of the stages attached. But I'll give it a point. Firefly Alpha did at least a 42 second static fire of its first stage, If it did a full duration firing, it went under my radar. Starship does not do full duration static fires. New Glenn did a 24 second static fire. Vulcan to my knowledge never completed a full duration static fire of the core stage, only short duration static fires, and with no boosters. Might have missed a few and I definitely got lazy on checking upper stage tests. But it does not appear that this is the industry standard any more. When all up stage testing was done, it was typically done on sustainer type rockets, with a small to moderate percentage of the total liftoff thrust active. The rocket that gets the closest to the type of testing you desire appears to be Ariane 6. I don't see you dragging Vulcan or New Glenn through the mud for only doing partial duration partial thrust static fires on the launch pad like Starship does. There's more but I've spent enough time on this for today.

Sure, you can hurl a decent amount of mass to Mars with an expendable variant. Maybe up to 100 tons in a single lanuch if fairly optimistic numbers are used. However (assuming the goal is humans to mars) then you need a Mars lander, which needs a heat shield, RCS, engines, fuel tanks, guidance systems, power systems... Possibly aero surfaces too. Then you'll need a habitat for the crew, requiring a large pressurized volume, with enough space and power for life support systems, airlocks, elevators, and cargo... Huh. That sounds an awful lot like what you would do for a reusable LEO system. So the question now is "Why don't they bother making a custom lander for all of that stuff and skip it for LEO?" And the answer is because they are aiming for an out of the park home run, however wise or unwise that is. They don't want to get to Mars once, they want to make it affordable, pretty much necessitating reusability and orbital refilling and commonality between the Mars vehicle and their other vehicles. If the goal is payload to Mars per launch, yes, an expendable upper stage on modern-ish Super Heavy is absolutely the play, likely with a further third stage on top of that. The targets they appear to be aiming for are payload to Mars per dollar, and per-pad/booster/ship throughput. Now as for the Moon. You run into a lot of the same problems as Mars - You can get ~100 tons to TLI depending on what numbers you assume. Then you need to at that point have a vehicle with engines, fuel tanks, navigation, power... Though sticking with Starship is less solid than it is for the Mars example. Starship is very much not a Lunar optimized architecture and it shows. It was picked as it reused a lot of effort from internal SpaceX projects they were self funding, and it could therefore be shoehorned into the role of a Moon lander for a lower cost than clean sheet designs. I wonder if SpaceX will ever consider a ground up Lunar optimized architecture. It would likely look quite different from the existing vehicle.

Interesting tangent: Starship seemed to carry on just fine with this engine configuration for several seconds (Still accelerating enough to probably not be spinning) before ultimately failing. This surprised me as I was under the impression that Starship (the upper stage) had minimal to no engine out capability. I don't have perfect numbers, but I did shove my numbers into a spreadsheet and I came up with the following: Assuming my numbers are right, immediately throttling the two Raptor vacuum engines down to minimum and gimbaling to the limit of 10 degrees might be enough to cancel out the torque from the uneven engine distributions in this vehicle configuration. On the surface the math says if the CoM is more than ~21.9m from the base of the vehicle it should be stable, but the propellant will slosh towards the side of the vehicle with the engines in this case, which causes all three engines to produce less "vertical torque" and would beneficially reduce this number, by how much I am unsure. Admittedly my source is just some guy on Discord, but I'm told that Raptor can normally gimbal to 15 degrees, but that the current engine shielding limits that to 10 or 11 degrees. Interestingly, for future ships using Raptor 3, the full 15 degrees would be available and this puts the minimum CoM height at only about 15.8m, though future versions of the ship may have to limit their gimbals to avoid hitting the vacuum engine bells. I don't know if the resulting thrust (of roughly 30% of normal thrust) (though if the CoM is higher than the minimum you can throttle the Vactors up more than 40%) would be enough to get into orbit for any situation aside from very late in the upper stage burn, but I find it very interesting that Starship can (at least theoretically) survive under some conditions with only 3 engines running, all on the same side of the vehicle, only one of which can gimbal. Assuming I did my math right, of course, it has been a while since I took statics.