NathanKell

One change RF makes leads to both those things. When using RF, like in real life, when your Isp lowers due to be in atmosphere, it is your thrust that decreases, not your fuel flow that increases. Thus, since fuel flow is constant, vac burn time and atmospheric burn time will be the same. A loooong time ago, I added support for this in MJ, which is why they are shown as the same; I also added a "SLT" column to show your sea level TWR. Click "all stats" in the dV stats window to make it appear. The regular TWR column and the Max TWR column show your vacuum TWRs. MechJeb calculates burn time directly from the engine's stats, so it should be correct (within, say, a second of correct?). J_Davis's config is newer. J_Davis is currently redoing all the stockalike engine configs; what's in the second post is only a lightly-updated version from before .23, and does not use all the new toys RF v4 adds, and does not attempt to really rebalance engines (in particular, it leaves the original mass alone, whereas J_Davis is freely altering it when necessary).

What normal/lightning bug? Also, lightning? As in zap?

https://www.dropbox.com/s/mtelvbwg143sea5/SV_patched.zip Here's some changes, and set for Real Fuels. Masses work out; I changed the node sizes for RO standards, and moved the fairing node apart for symmetry (also the nodes on the S-IC, so the F-1s can be mounted in symmetry). I have also altered the F-1 to use RF and to use careo's ExsurgentEngineering SmarterGimbal, so it can be used for roll control. With those changes I can easily get a reference 100t payload into a 500x200 orbit with about 40,000 liters of propellant remaining in the S-II. A couple suggestions: 1. Make the J-2s independent models. This will allow roll control on the S-II (like on the S-IC) if they use an improved gimbal. Also it will let you reuse it on the S-IVB, and in any other things. 2. Make a second decoupler part for the top of the S-IC, so that the S-II interstage can be left attached to the S-II on separation. Give it some solids for ullage thrust (you already modeled them), put the decoupler at the top, and make sure the collision mesh is only the ring so the engines can fire through. That will match how it worked and provide ullage control for the second stage ignition.

Aw, thanks! The issue is that KSP operates by volume ratio whereas in real life the ratio is given as a mass ratio. You have to divide the propellant masses by their densities to get the volume ratio. Rest assured that by mass the ratio *is* indeed 1.93 There's a calculator on the Volumes page of my calcs sheet (post 2 in RF thread) if you want to play around / check figures.

Awesome--I've been so tempted tor request this on your other thread, but you said you weren't going to do it there, so I didn't want to bug you. I'll be using this *so* much!

xZise: The actual resource amount in a tank, and its max amount, are not rounded; if they were it would break compatibility with Stretchy. What I was referring to was the display per resource when there's available volume (i.e. "Tank can hold xxxxx units (yyy.yyy tons)")--that is rounded.

As long as the pod stayed below ~1700C it should be fine. Remember, Kerbin is a third the size of the Moon so it makes sense reentries are gentle. And yes, if a part is physically blocked by another part, it will count as shielded.

That's easy: open the real_engines_stats file and search/replace the following: change all throttle = to throttle = 0 // and change all name = ModuleEngineIgnitor to name = DISABLEDModuleEngineIgnitor

pretty sure you mean 36 *tons* dry (Although my references mostly say 39t dry) And, actually, this mod is an INT-21, so...dry mass would probably be higher. But Piwa is making the S-IVB, so best to leave S-II at ~36-39t dry. Piwa, I'll try tomorrow with a ~100,000kg reference payload, and real stats.

I'm with Kitworks. They all look pretty good, but you're right that #1 looks good for a 1mx2m tank but bad for an order-of-magnitude-larger tank...

Actually, I retract my statement; doing a bit more looking it appears I had bad data on Tiny Tim. My Wren-Fat Albert is actually underpowered, which, combined with its higher drag means markedly worse performance than the real WAC Corporal and Tiny Tim. Heh, you know what it was? This was a pre-RF craft, so the separatrons had 1/4 the fuel they should have. I fixed the tank but forgot about the boosters. Even without that though, I was able to replicate real performance with a second booster and a slightly lighter sustainer (higher dV, but also higher drag).

Yup! Wren is a pun. WAC->WRNS Assuredly, though stability may be an issue. Though Frank may go straight for putting it atop a Granite, once Germany retakes the lead in the next post... EDIT: Also, this is a darn sight higher-performing than the WAC Corporal+Tiny Tim; I've just assumed that a similar tech-level war's requirements would lead to a similar kind of solid fuel booster (although a much larger one in this case; Tiny Tim had a 500lb bomb and about 1/4 the solid fuel this does IIRC), and a similar doctoral student would have a similar project, just more resources at his disposal ITTL (though his sustainer, with a larger payload, has 100m/s less dV). Here's a real WAC Corporal (sorry for blue; should be yellow/black, I know. And for some reason it shows 12kN when the cfg says 6.7 as is proper. Doesn't change the stats though.)

HoneyFox: Ah, right, you're doing it as a parasite, not as as separate module. Regarding roll control: you could just flip sign based on which side of CoM it's on, right? (And yes, I've seen parts with separate transforms for thrustTransform and gimbaltransform. Presumably the latter is the parent, the former the child.)

ssgavin1250: interesting find! I'll fix the display. EDIT: try reinstalling. They *should* round in the latest RF. Still getting the issue?

Agathorn, HoneyFox: it uses (or doesn't use) whatever LazarasLuan originally assigned, and/or Scripto23 changed in the realism patch for it. HoneyFox: why use the transform's local axes, other than "down"? And note the thrust transform *isn't* always the same as the gimbal transform--sometimes there's a separate thrust transform from the model used to represent the gimbaling part of the engine. Re: local axes. This is exactly the issue with dtobi's mod: some engines have flipped local axes for the gimbal. So why not use *vessel* axes as the basis for the non-down axes? That would avoid any issues in exporting.

Thanks. Yeah, this is going to span everything from 0.3m sounding rockets (this one was 0.5m, though) all the way up to 10m+ SHLLVs (assuming I make it that far). If you want to feast your eyes on some of those super-heavies, though, check out the RSS subreddit where Ferram and others have been posting some glorious monstrosities. Also: cookies remain unclaimed.

ssgavin1250: for ease of cross-work with MFT, the realfuels dll is once again named ModularFuelTanks.dll. So yes, you should have one, and only one, ModularFuelTanks.dll and it should be in the RealFuels/Plugins folder.

HoneyFox, have you considered manually gimbaling the thrust transforms themselves, rather than gimballing the gimbal transform name? That way engines with multiple thrust transforms could provide gimballed roll control, which would be _excellent_. Useful for any multiple engine mount.

Look at the Tools and Applications subforum of addon releases. It certainly is fine.

@PART[*]:HAS[@MODULE[ModuleScienceExperiment]] { @MODULE[ModuleScienceExperiment] { @name = ModuleResearchExperiment } }

Well, 4.3 sure works fine without KSPI on my end. Make sure you're actually using 4.3, and not using any mods that change the RAPIER, and not using any kind of patch that converts the SABREs into using the new MultiModeEngine. EDIT: Ninja'd. I looked at the source; it's because Fractal is directly setting the part's temperature, and that can go over DRE's limit quite easily. It's probably scaled to a maxtemp of 3600 and the original heatProduction values, not the halved ones DRE uses.

Uh, no? It's a realism patch. :]

If you get the models in krag's bin format and disable PQS, then these could be used in PF, yeah.

Yes, the realism patch for FASA (post two of Realism Overhaul thread, link in sig).

Well, since I don't touch heat dissipation that's surprising, but certainly it's possible there's a weird interaction.