[1.8+] Real Fuels

[Agathorn]

It means: Scripto assumed that there's a transform named "thrustTransform" in the engine model...

Usually this name is used for engine's gimbal but there might be exceptions. There might be one more hierarchy out there with a different name... who knows? (the modeler of course)

So apparently I was getting a little confused on which engine was which.

So to be clear, original SpaceX:

engine cluster, no ModuleGimbal

main engine, ModuleGimbal

vacuum engin, ModeulGimbal

Scripto's changes:

engine cluster, ADD ModuleGimbal

main engine, no change

vacuum engine, no change

I'm guessing that is why the main cluster has no gimbal because despite Scripto adding the module for it, the base engine cluster just doesn't have it. Wasn't built with it. I have a post in Laz's thread though so waiting to hear back on that for sure.

In either case though I think the ModuleGimbal is just the stock KSP gimbal system right? So _should_ work with your Gimbal system HoneyFox. I suspect the 6 engine without gimbal, combined with the very limited gimbal range of the 3 that do have it, just isn't enough to do anything.

I still find it odd though that on a smaller lighter craft, using roll gimbal (when enabled on the two outboard engines) causes yaw instead.

[HoneyFox]

So apparently I was getting a little confused on which engine was which.

So to be clear, original SpaceX:

engine cluster, no ModuleGimbal

main engine, ModuleGimbal

vacuum engin, ModeulGimbal

Scripto's changes:

engine cluster, ADD ModuleGimbal

main engine, no change

vacuum engine, no change

I'm guessing that is why the main cluster has no gimbal because despite Scripto adding the module for it, the base engine cluster just doesn't have it. Wasn't built with it. I have a post in Laz's thread though so waiting to hear back on that for sure.

In either case though I think the ModuleGimbal is just the stock KSP gimbal system right? So _should_ work with your Gimbal system HoneyFox. I suspect the 6 engine without gimbal, combined with the very limited gimbal range of the 3 that do have it, just isn't enough to do anything.

I still find it odd though that on a smaller lighter craft, using roll gimbal (when enabled on the two outboard engines) causes yaw instead.

Ok. so Laz only add gimbal module to the main engine (i guess you mean those three engines) ? Then you can check the ModuleEngines of the main cluster and check the name of its thrust transform(s). If they are the same, it should still work.

Yes, ModuleGimbal is the stock gimbal module.

If it causes yaw instead, you might need to rotate these two outboard engines for 90 degrees along its thrust vector, OR, invert the values of the Roll Coeff H/V (if you set H to 1.0, V to 0.0 before, you need to set H to 0.0 and V to 1.0)

[NathanKell]

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.)

[HoneyFox]

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.)

Well i can, but that's even trickier... what axis should i judge then?

After a brief thought on this, i think it needs Vector.Cross(rollAxisVector, vectorFromEngineToCoM) to get a third vector that indicate what direction of force we need in order to roll the vessel, and then take that vector's x & z components as yaw/pitch input.

[Ralathon]

Would it be possible to get engines that default to the highest tech level available instead of the lowest tech level? It doesn't really make sense that they would use 1945 era quality with a fully unlocked tech tree unless you manually upgrade them all. Since there are (currently) no downsides to upgrading engines I find it hard to imagine a situation where you want them at anything but their highest tech level.

[xZise]

[...]They *should* round in the latest RF.[...]

What do you mean with "round"? I'm using RF 4.3 (and not Strechy*) but when I automatically configure my tanks the amount is never an integer. I don't think that is a problem but I'm just curious what you do mean with "round".

Would it be possible to get engines that default to the highest tech level available instead of the lowest tech level? It doesn't really make sense that they would use 1945 era quality with a fully unlocked tech tree unless you manually upgrade them all. Since there are (currently) no downsides to upgrading engines I find it hard to imagine a situation where you want them at anything but their highest tech level.

Yeah that would be nice. But also when you have a rocket and later researched higher tech levels that it (semi-)automatically updates all tech levels. Maybe someone has perfectly calibrated the thrust/efficiency so that the flight path with a higher tech engine wouldn't work. So maybe you can show a confirmation when a craft loads in the VAB/SPH and it detects that engines can be upgraded. (I don't know if that is possible with KSP)

Fabian

[HoneyFox]

What do you mean with "round"? I'm using RF 4.3 (and not Strechy*) but when I automatically configure my tanks the amount is never an integer. I don't think that is a problem but I'm just curious what you do mean with "round".

Yeah that would be nice. But also when you have a rocket and later researched higher tech levels that it (semi-)automatically updates all tech levels. Maybe someone has perfectly calibrated the thrust/efficiency so that the flight path with a higher tech engine wouldn't work. So maybe you can show a confirmation when a craft loads in the VAB/SPH and it detects that engines can be upgraded. (I don't know if that is possible with KSP)

Fabian

Round here means... removing the fractal part of a number and increase the value by one if the fractal part is equal or larger than 0.5...

Well, Mathf.Round() function or Mathf.RoundToInt() function... whatever you like.

[Scripto23]

I will admit I just added that gimbal module in with the hope that it would just *work*. When I get home today I'll be able to test things out and help with this whole roll issue.

Though if it makes anyone feel better, SpaceX has had a lot off issues with roll on the Falcon 9 as well. The first time they attempted a soft landing of the first stage, the 3-engine relight went well, craft reentered, single-engine relight went well, but then roll started to exceed control of the ACS (which is a cold gas Nitrogen system) and fuel was centrifuged away from fuel lines meaning the single engine flamed out and the whole thing slammed into the ocean. In other flights there were a few other minor incidents with the rocket rolling, but nothing that prevented completion of the mission.

Also if you haven't seen it yet here is

[Agathorn]

Wait they plan on landing EVERYTHING? I didn't know that. I thought the plan was only for the first stage to land. Amazing. I can't even express how amazing Elon Musk is to me for really wanting to continue to push human advancements in space, now that the government has stopped caring.

Scripto is it possible the the stuff in KSP right now is off on fuel amounts? I've yet to be able to get the first stage back down without running out of fuel long before I hit the ground.

[Agathorn]

Ok. so Laz only add gimbal module to the main engine (i guess you mean those three engines) ? Then you can check the ModuleEngines of the main cluster and check the name of its thrust transform(s). If they are the same, it should still work.

Yeah the "main" engine, is the MErlin 1D, of which there are 9 in the first stage. 6 come as one in the cluster, and you manually place 3; center and two outboards.

I checked on the engine cluster and the thrustTransform is what is used for, well the thrust transform, and that is the same transform Scripto references for the Gimbal.

[Scripto23]

I know right! I think the future of spaceflight is very bright

Actually, if anything the fuel amounts/masses are probably on the "easier" side of things. I believe part of the issue you might be having is that SpaceX claims a reduction of about 20-30% in cargo mass in order to spare enough delta V to reuse both stages. What I've been doing is separating the first stage with about 700-750 delta V left in it (which without all the mass of the second stage/cargo on top it, translates to something like 2000 delta V for use in landing), then use RCS to flip the craft 180, burn using three engines until horizontal velocity is around 700m/s in the OPPOSITE direction to which we were initially traveling, flip 180 again so the engines are facing forward, then shut down the 2 of the 3 remaining engines and just wait until our trajectory takes us in for a landing. The weight of the engines on an almost empty core will keep the craft pointed correctly for the remainder of the descent.

For second stage it is a bit more complicated. At the moment I'm working on creating 4 small Draco/Super Draco like thrusters which will be used in landing (like in the video) because the vac engine isn't optimized for atmo, doesn't have deep throttling capability, and the tremendous amount of thrust would tear the stage apart IRL if you tried to use it to land.

[NathanKell]

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.

[xZise]

Ah okay I got worried, because it doesn't show them rounded when you auto configure the tanks (It doesn't look nice, but it works so it's fine ).

Fabian

[Agathorn]

They are rounded. Rounded doesn't mean an integer. It just means it is rounded to an accuracy less than what its maximum accuracy is.

3.14 is the commonly known value of PI, which is not an integer, but is of course rounded off, since the actual number is.. well we don't know the full accuracy, but its much more than 3.14

[xZise]

They are rounded. Rounded doesn't mean an integer. It just means it is rounded to an accuracy less than what its maximum accuracy is.[...]

Okay I usually think of a hole integer when somebody says they rounded a number. And as I do much in Java (where Math.round() return integers) I was thinking of it. Of course you could round to a specific decimal place.

But I have another question: Can't MechJeb calculate the deltaV/burn time correctly or is my setup wrong? I mean in theory it should be no problem for it, as it knows how many fuel for an engine is available it should know what type of fuel. And that actually does happen, because when your tanks are filled with the incorrect fuel it does show a burn time of 0 s. It even shows the same burn time for atmospheric and vacuum flight (afaik in stock the burn time in atmosphere is lower because it burns more fuel).

Fabian

[Agathorn]

But I have another question: Can't MechJeb calculate the deltaV/burn time correctly or is my setup wrong? I mean in theory it should be no problem for it, as it knows how many fuel for an engine is available it should know what type of fuel. And that actually does happen, because when your tanks are filled with the incorrect fuel it does show a burn time of 0 s. It even shows the same burn time for atmospheric and vacuum flight (afaik in stock the burn time in atmosphere is lower because it burns more fuel).

Fabian

Do you mean the dV information in the read outs, like when building? Those work fine for me. In fact its the only part of Mechjeb I use mostly.

Though I have noticed the TWR display is often wrong in the VAB and gets smaller on the launchpad, which is odd.

[xZise]

Do you mean the dV information in the read outs, like when building? Those work fine for me. In fact its the only part of Mechjeb I use mostly.

Hmmm, when I attach an engine I can see the maximum consumption in "action group mode". When I now divide the amount in the tank with that value I get a different (I only got lower) value. Of course I compared only one resource but auto configured the tank. I guess I'll test if my calculation is correct. And if I understand that correctly RF changes the behaviour of the engines in such a way, that the burn time is always identical and does not depend on the pressure (like stock does; in RF the Isp doesn't change the amount of fuel burned but instead the thrust get which might explain your second paragraph).

But it is really annoying when MJ gives you 30 s burntime instead of 8 s. Might it be because of engine config? I'm using the stockalike from J_Davis (not linked in the 2nd post). I tested it with the MJ 2.1.1 and the newest dev version.

Though I have noticed the TWR display is often wrong in the VAB and gets smaller on the launchpad, which is odd.

I have to do the calculations, but this might be, because the thrust (and not the fuel flow) depend on the pressure and maybe MJ calculates the thrust in vacuum? I've never looked to closely at that value so I don't know if that happens on my system too.

And I got another question about the stockalike config linked in the 2nd post: Is J_Davis version basically an older revision? Or is J_Davis' completely different and both versions aren't comparable.

Fabian

[Starwaster]

Do you mean the dV information in the read outs, like when building? Those work fine for me. In fact its the only part of Mechjeb I use mostly.

Though I have noticed the TWR display is often wrong in the VAB and gets smaller on the launchpad, which is odd.

Sea level thrust correction is built into the plugin. Thrust on the pad will always be smaller for Real Fuels.

If you have another thrust corrector plugin you should remove it when using RF.

Clarification: Rehash for any readers unware: Stock thrust behavior is to increase fuel mass flow based on current Isp which varies according to atmospheric pressure. (Isp is lower at sea level and reaches its max value in vacuum) Correct (real life) behavior is that thrust is reduced whereas fuel flow generally remains constant unless the engine is throttled. Real Fuels keeps mass flow constant and reduces thrust when in atmospheric pressure conditions.

Edited January 23, 2014 by Starwaster

[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).

[Agathorn]

But why would MJ show one TWR value in the VAB and then immediately after show another, much lower value, on the launch pad?

I pretty much have to remember to build my rockets to have about .15 or .2 TWR higher than I want because that is about what they all lose according to the MJ display when I move to the launch pad.

MJ is showing a value in both cases, but they are different.

[ialdabaoth]

But why would MJ show one TWR value in the VAB and then immediately after show another, much lower value, on the launch pad?

Because MJ in the VAB is computing TWR based on vacuum Isp, and on the pad it's computing based on sea level Isp.

Remember that changes in Isp are (in the real world) supposed to change thrust, not fuel flow - stock KSP does this wrong, and MJ is following stock KSP's assumptions in the VAB.

[NathanKell]

Agathorn, in my post I just mentioned that MJ *can* display sea level TWR in the dV stats panel. Click the All Stats button to make it show up. Now you don't have to guess. As I said, in the dV stats panel, TWR and Max TWR are calculated for when the engine is in vacuum, SLT (sea level TWR) is calculated for when the engine is at sea level.

The "max thrust / TWR" in the *vessel* stats panel shows what is *currently* true about the engine, and in the VAB the engine "counts" as being in vacuum, whereas on the pad, it is obviously at sea level.

[Agathorn]

The "max thrust / TWR" in the *vessel* stats panel shows what is *currently* true about the engine, and in the VAB the engine "counts" as being in vacuum, whereas on the pad, it is obviously at sea level.

Ahh gotcha. Thanks guys. That's cool, I didn't know the VAB was in vacuum. Nifty trick those Kerbals did.

[xZise]

[...]MechJeb calculates burn time directly from the engine's stats, so it should be correct (within, say, a second of correct?)[...]

I have to test it later and give you exact values, but if I remember correctly I calculated a burn time of 8 seconds and MJ showed something of 30 to 40 seconds. It did however showed a lower burntime when I reconfigured everything to hydrolox which has very high fuel volume consumption. So it does something correctly. I also have been checking only the burn time as this is pretty easy to do: You get the amount of LH2 in the tank and divide it with the amount of LH2 used by the engine (You are displaying that in X and X/s, where X is the same but arbitrary volume unit, aren't you?).

I might check deltaV but it calculated about 7 km/s for the second stage with only two FL-T800 Fuel Tanks (hydrolox) which doesn't sound reasonable, and I didn't got into orbit and not because of lack of thrust.

Fabian

[NathanKell]

Agathorn: the VAB, ignoring the art, I consider something like a giant blackboard where the rocket is sketched out. So of course they'd use the optimal environment for all engines.

xZise: They're not arbitrary volume units anymore. In RF they're liters. [For gases, liters at STP.] Also, the Engines GetInfo() that display propellant use per second is wrong, because it's an unoverrideable part of the original engine module and doesn't realize that its thrust will be lower at sea level so its fuel flow won't be any higher than in vacuum (it display "max" fuel flow, i.e. fuel flow at sea level). To get correct max flow in liters per second, multiply those numbers by SL specific impulse and divide by vac specific impulse.

Well, 7km/s is reasonable if you only have like 150kg of payload. Remember your rocket equation: dV = ln(gross mass / dry mass) * Ve (which is Isp in seconds * 9.81). So if you have a gross mass of, say, 2.5t, a dry mass of 0.5t, and an Isp of 450s, you get ~7.1km/s dV. (150kg for payload, 100kg for tankage, 250kg for engine)

Edited January 23, 2014 by NathanKell