Starwaster

And knowing is half the battle!

Latest version lets you choose between black and white for certain parts. But... SpaceX Falcon 9 is no longer all white. Block 5 uses black for the legs and interstage and for what I think are systems tunnels (the tunnel that protects wiring and piping)

@Barzon Kerman I think what we're talking about here (at least at first, early days) is just using the second stage to test technologies and concepts that are going to go into the BFR. Eventually that should turn into some sort of second stage recovery system too, I hope.

@Vas You mention a number of times in your post about proof and realism. Historically, rocket engine tend to have hard finite limits on restarts especially Even SpaceX with its reusable Merlins are not infinitely restartable and that's why they lost the center booster on the Falcon Heavy: The booster ran out of TEA-TEB and could not re-ignite the two side engines and overshot the barge and crashed hard into the ocean. As @Crashonaut says, rockets that use hypergolics are inherently restartable though even they have limits in the range of 10s of thousands of restarts. We don't model that and just assume that they are infinite. (the actual limitation on such motors is actually due to wear and tear so not within the scope of RF) That's just cold hard reality. We don't model every aspect of reality that would affect engine restart capability and are therefore have to abstract things down to the level of assigning a hard ignition limit. The motor either has a limited number of ignitions or is infinite. You can talk about proofs all you want but what you need to do is increase your level of knowledge about how rockets in the real world work. They ARE limited as to restarts, especially in the early years (50s-60s) which is the time period that RF focuses on. If you don't like that you have a number of choices ranging from not using RF at all to writing patches to remove ignition limitations from your personal installation. Edit: Other choices are possible such as writing up a patch that tries to model things by assigning every ignition resource that is appropriate on a per engine basis. This includes things such as electricity (for spark plug ignited engine such as the J2), TEA-TEB for engines that use pyrophoric ignitors and finally pressurants. (literally gasses that pressurize the tank. J-2 theoretically could have been restarted infinitely but required its tanks to be pressurized prior to each firing. In the case of the Saturn's S-IVB this meant including enough pressurant for 2-3 restarts. Most missions only required two though there was at least one that involved a third restart). It would be up to you to research the engines you want to patch and determine what resources you want to include based on how realistic you really want things to be. If you're serious about wanting your engines realistic then these are the things that have to be considered on a per engine basis. Consider those things and maybe you'll start to understand why engines get configured with hard limits. Again, it's about abstraction.

Then you don't have the latest version. Completely delete all traces of the mod and download from https://github.com/StupidChris/RealChute/releases/latest

Looks interesting ...

I don't think they're actually planning on the tanker version having extra tankage... they might instead be relying on it having less mass to carry to orbit. And therefore it will have more of its standard propellant load to dispense to another BFS... Which if you think about it, extra propellant is going to be a lot heavier than the crewed version. Its mass fractions would suffer badly.

While you're at it, could you take a look at the RCS transforms? Roll to starboard (or was it port...?) is off-axis by 5-10 degrees. It's most easily seen and verified using RCS Build Aid. It's as if one or more of the transforms is askew. (RCS Build Aid displays the transforms but whatever is wrong isn't easily seen by the eye so it's off by a very small amount, just enough)

It really wouldn't.

Indeed

No. Just make it like any other propellant and trust the player to place storage tanks sensibly. If they don't want to then don't make them.

No.

You guys, you know that Realism Overhaul consists mostly of configs and a number of third party plugins. For KSP 1.4.5 everything but FAR is updated so just install the individual components separately minus FAR (or with FAR if you feel like trying one of the unofficial compiles). It *IS* doable, you'll just have to do without CKAN if you were hoping for an automated RO install. It might suck but it's doable.

Soooooooo..... Soon then?

@name ^= :$:NoLift: That's regular expression text munging. Read about it here: https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Syntax (search for text regexp) for other examples of ways you can mung the text.

Don't patronize me. Maybe I don't WANT to close within 10 meters on the rendezvous

Huh, I didn't know that was still a thing. That sounds weird that it would take 8 days to rendezvous and dock though maybe that's because I don't know all your circumstances. (or maybe MJ did eat all your snacks!) I don't use the auto rendezvous myself... If they're both in Kerbin orbit, I just set up a Hohmann's transfer then set up to fine tune to within 100-200 meters. If they're not quite in the same plane but not too far off, fine tune will take care of it as long as they aren't too far off. If it's Mun or Minmus then I enter into a higher orbit than the station or ship I'm docking with and Hohmann transfer as above.

What.... did MechJeb eat all your snacks, drink all your water and breathe all your oxygen?

I don't think so but.... I don't really remember. I have my crew mass overridden because there was a time, pre-1.3.1, that it did. (though I was told by Squad that was impossible) I keep forgetting to change my crew mass back so I'm not sure how it's affecting 1.3.1

The reason the mass per crew is so high is because of the EVA suit mass. Suits are heavy. As to the per part issue, it's supposed to be an editor only issue that doesn't affect the in-flight mass.

It would help to know what the error was you saw (that's why we ask for logs) instead of having to guess. But there are a few things wrong here that can be addressed. In all three examples you did not put a @ in front of TESTFLIGHT. Also, TESTFLIGHT is a (supposed to be) named node so you need to either specify which TESTFLIGHT you mean (@TESTFLIGHT[name]) or do @TESTFLIGHT,* to patch all of them. (failure to use @ means you are ADDING a new TESTFLIGHT node instead of patching any) Also, don't use :BEFORE. Use AFTER[zTestFlight] or :FINAL to ensure that your patch occurs after the ones that are adding the field you want to remove. And, your last patch is missing a ] so it needs to be @PART[*]:HAS[@MODULE[ModuleEngineConfigs]:HAS[@CONFIG[LR91-AJ-5]]]:Final

You will probably have to scale up payouts... I scaled up Funds and Reputation by x4 and Science by x1.2. (What would have been Funds payouts will mostly map to rep but there were some that did not hence the x4 Funds) I think these multipliers work well but it will be subjective for your personal experience; YMMV.

Thank you to the person who just sent me some money! I picked up the DLC now

Do they stay extended if brakes are released?

That's better.