[1.8+] Real Fuels

[allenby]

Apologies for the noob question, but what variables (other than tank type) affect the in-game rate of cryo-fuel/ox evaporation? Are they just constant?

I'm trying to imagine scenarios where I use cryogenic fuels on interplanetary missions, but need to know if there are practical ways of mitigating boil off.

[PrecastCrane02]

That might be your problem. Many mods disable themselves when run on the windows 64bit version because it is deemed inherently unstable and nobody wants to debug issues that they have no control over. If you want to play with it, that's totally chill - but unless you can reproduce your issue on the 32bit version, modders will react somewhat frosty to your pleas for support. .

With the 32bit version it does work. But I really want the avp pack. Is there a way to get realfuels to think I'm in 32bit?

[Starwaster]

Apologies for the noob question, but what variables (other than tank type) affect the in-game rate of cryo-fuel/ox evaporation? Are they just constant?

I'm trying to imagine scenarios where I use cryogenic fuels on interplanetary missions, but need to know if there are practical ways of mitigating boil off.

What affects boiloff is part temperature. That's the internal temperature which is not the skin temperature.

For mitigation I suggest the Heat Pump mod. It actually used to be a part of Real Fuels until it was dropped. I modernized it for KSP 1.0.4 and released it as a separate mod. It comes with one radiator part and it removes heat from whatever it is attached to and sends it directly to the radiator's skin for rejection. (it incorporates both active cooling and insulation; whatever part it is attached to is treated as insulated)

http://forum.kerbalspaceprogram.com/threads/128502-Heat-Pumps-for-Real-Fuels-v1-0-BETA-RC1-7-12-2015

[dlrk]

Has the Tweakscale bug been resolved?

[Svm420]

no not yet

[allenby]

What affects boiloff is part temperature. That's the internal temperature which is not the skin temperature.

Thanks. I'm just wondering about how the boiloff rates are determined in a given game state. I noticed the temperature and loss_rate variables under TANK_DEFINITION. I'm guessing temperature means boiling point, and loss_rate is the amount subtracted (or a multiple of the amount) when part_temperature > boiling point. Is that correct? I'm just trying to get a sense of calculating boiloff losses for planning purposes.

[Starwaster]

Thanks. I'm just wondering about how the boiloff rates are determined in a given game state. I noticed the temperature and loss_rate variables under TANK_DEFINITION. I'm guessing temperature means boiling point, and loss_rate is the amount subtracted (or a multiple of the amount) when part_temperature > boiling point. Is that correct? I'm just trying to get a sense of calculating boiloff losses for planning purposes.

It depends on how much higher the part's temperature is than the boiloff temperature. Temperature delta = part temp - boiloff temp. loss amount = loss_rate * temperature delta per second. (actual loss is implemented per physics frame so loss_rate * delta * fixedDeltaTime)

If you can read code then this is relevant:

https://github.com/NathanKell/ModularFuelSystem/blob/34e5474c350c27a459404c07caa6be7d3865b83f/Source/Tanks/ModuleFuelTanks.cs#L329-L354

Technically, this implementation is wrong because part temperature (as of KSP 1.0) includes any resources, which means that the tank contents would already have exceeded boiloff for the entire contents with explosive results. Heat loss due to boiloff is implemented but it doesn't seem to have much impact. Probably because actual loss rate is independent of heating rate. At some point that needs addressing and I think Nathan has some ideas about it but I'm not sure what they are. (my own idea about it is that it should be based on incoming heat flux; with loss being calculated each frame based on how much heat gets through so that both loss and cooling (due to vaporization) are concurrent rather than disconnected as they currently are.

[nalfz]

I'm having some pretty vicious issues getting RF and tweakscale to play nicely. I've looked through the thread back 20 or so pages and it looks like I'm not the only one but I didn't see this specific one get reported

Tweakscaling an engine causes me crashes in almost 100% of circumstances

I'm on linux x64 and using the stockalike RF configs

So far I've been able to produce this bug in a number of ways, all 100% reproduceable, at least on my end

1. Grab a pod (I used the mark 3 cockpit)

2. Grab an SRB (I used the small thor one from KW rocketry, but I've tested it with stock ones and it still happens)

3. Pop the srb down next to the pod but don't attach it

4. Tweakscale it up a size

5. Try to attach it with symmetry

The game crashes at this point (screen freezes, and then the game closes a few seconds later)

Attaching the SRB without symmetry is possible, as is attaching the SRB with symmetry before tweakscaling it, and then tweakscaling after, but in both cases these cause crashes when I attempt to launch the craft

This also happens in exactly the same way with any other engine, not just solid fuelled ones

When I reload KSP and try to load the craft file, that crashes the game too

Less reliably, I've also had this happen without symmetry involved at all

1. Grab a decoupler as the root part

2. Stick a tank under it

3. Stick an engine on that

4. Tweakscale the engine

5. Save that as a subassembly

6. Create a new craft

7. Pick a pod

8. Click on the subassembly

The game crashes in the same way doing this

I've actually been able to launch with tweakscaled engines on rare occasions (all without symmetry), but I have absolutely no idea why

Sadly a 5m S-IC from KW rocketry ain't putting me on the moon any time soon :/

Here's the last 300 or so lines from the Player.log for the first problem. I'd up the full file but it's ~70mb and I'm in australia so the upload could literally take several hours

Let me know if there's any other bit of the log you need. I've got it saved

I'll try to get the second log but my KSP load time is horrifying so I might be a while

[Svm420]

We know tweakscale is broken with this mod. Maybe though if we get enough posts about it Nathan will put in big red letter in the OP that it is an issue. Don't use tweakscale on RealFuels engines

[Parmenides]

Download ok again thanks

[nalfz]

We know tweakscale is broken with this mod. Maybe though if we get enough posts about it Nathan will put in big red letter in the OP that it is an issue. Don't use tweakscale on RealFuels engines

Like I said, pretty obvious everyone's having problems with it

I didn't see that specific issue reported and I know from my experience modding that issues don't get fixed if no one reports them. No harm in mentioning it

[codepoet]

I am looking into a problem with attitude control for mechjeb when using ROV and it has lead me here. Briefly the problem seems to be related to ModuleEnginesRF::EngineIgnited returning true once and engine has stopped burning due to the throttle being reduced to zero. I will start having a fiddle with the code to see if I can diagnose and fix it, but if anyone else here who knows the code can jump in and fix it faster, do please do so. I see I might end up in EngineSolver, and I know nothing about that/ I have posted mechjeb related details on the mechjeb thread.

ETA I can make mechjeb behave the way I want it to by setting EngineIgnited=false in places where ModuleEnginesRF::ingnited is set to false. However that messes up the re-ignition code, so I am unsure how to proceed. It looks as if the RF code assumes that ModuleEngines::EngineIgnited has a different meaning to ModuleEnginesRF::ignited. Is this the case, and if it is, how can I get MechJeb to work out if and engine is ignited without it having to have knowledge of the ModuleEnginesRF class which would create a hard dependency?

Edited August 10, 2015 by codepoet
more info.

[chrisl]

I've apparently been posting this on the wrong thread. Didn't realize that RealFuels now had the old engine ignitor/ullage stuff built into it. I'm playing a new RO/RP-0 game and I've been running into a problem with igniting most of the early AJ-10 and Agena upper stage engines. The problem is, the right-click information window will tell me "Propellant: Very Stable", whether I'm firing ullage or not, but when I activate the engine, 9 times out of 10 it will flame out with a notice similar to "Vapor in fuel line".

The only ways I've managed to reliably work around the issue are to either ignite the upper engine before the lower stage engine has completely burned out, or to fit my upper stage with a couple "Separation Motor (small)" SRBs and fire those for a second before trying to ignite the upper stage engine. These work arounds are fine during the early stages when my upper stage engines can only be ignited once, but I'm getting to the point where I've got multiple restart upper stage engines and I can't (and should need to) fit tons of small SRBs.

Using RCS seems to fail pretty much every time. Doesn't matter how long I burn RCS or how powerful the RCS thrusters are. Before activating the RCS, the information panel says "Propellant: Very Stable". It'll continue to say that no matter how long I have my RCS thrusters going. But as soon as I activate the engine, it'll switch to "Propellant: Very Unstable" just long enough for the ignition to fail, then go right back to reporting "Propellant: Very Stable" again.

I hate to turn off ullage and/or limited ignitions because I think they really add to the realism, but if I can't reliably get the engines to ignite, I don't have much choice. Is there any way to correct this issue without turning ullage off in the RealSettings.cfg file?

[max_bma]

Hi. I have a remark about the level of volume of the tank Second stage - S-IVB (Saturn IB) - 13,000 is not enough to enter the LEO 21 tons, with the engine J-2 (LH2/LOX)

@PART[FASAApalloLFTJ2]:NEEDS[!RealismOverhaul]:FOR[RealFuels]

{

MODULE

{

name = ModuleFuelTanks

volume = 13000

type = Default

Edited August 11, 2015 by max_bma

[westamastaflash]

When I load a quick save i made in atmo while running engines, I get the "vapor in feedlines" message! anyway to change this? Sometimes quicksave is only way to get around the stupid launch clamps showing up later in flight bug.

[01010101lzy]

Got an issue with ignitors.

I had my spaceship tested several times without any problem, but today I found the engine very difficult to ignite. RCS makes no effect on the engine status (unstable, unstable, unstable), and the RCS thrust is extremely low (in most times they could have a acceleration of 3m/s2, but now it has only less than 1m/s2). I tried to stable the fuel by spinning the ship, it worked, but it came back to unstable in less than 1 second after I stopped. What's the problem?

Playing on KSP 1.0.4, with the following plugins: Toolbar, USI Tools, AJE, Better Boyancy, DRE, EngineGroupController, FAR, FireSpitter, FMRS, Hangar Extender, GlowStrips, KF, KJR, Kopernicus, KSC Switcher, MJ, MFI, MRF, NF pack, Persistent Rotation, Persistent Thrust, PF, QuickScroll, RC, RF(v10.5), RealPlumes, RSS, RT2, RMM, SmokeScrn, SolverEngines, TCA, TimeControl, Trajectories, TweakScale, TweakableEverything, ModuleManager.

- - - Updated - - -

Engine configs are the newest Stockalike configs.

Edited August 12, 2015 by 01010101lzy

[zzz]

I'm try to make sort of KIDS for my self, is this way is legit or I mess up things?

@PART[*]:HAS[@MODULE[ModuleEnginesRF]]:final
{	
	@MODULE[ModuleEngineConfigs]
	{
	 @CONFIG,* 
	  {	
	    @IspSL *= 0.6
	    @IspV *= 0.6	
	  }					
	}
}

It seems to works somehow, but I'm not sure what I'm doing and is I'm doing it right.

Edited August 13, 2015 by zzz

[chrisl]

I've apparently been posting this on the wrong thread. Didn't realize that RealFuels now had the old engine ignitor/ullage stuff built into it. I'm playing a new RO/RP-0 game and I've been running into a problem with igniting most of the early AJ-10 and Agena upper stage engines. The problem is, the right-click information window will tell me "Propellant: Very Stable", whether I'm firing ullage or not, but when I activate the engine, 9 times out of 10 it will flame out with a notice similar to "Vapor in fuel line".

The only ways I've managed to reliably work around the issue are to either ignite the upper engine before the lower stage engine has completely burned out, or to fit my upper stage with a couple "Separation Motor (small)" SRBs and fire those for a second before trying to ignite the upper stage engine. These work arounds are fine during the early stages when my upper stage engines can only be ignited once, but I'm getting to the point where I've got multiple restart upper stage engines and I can't (and should need to) fit tons of small SRBs.

Using RCS seems to fail pretty much every time. Doesn't matter how long I burn RCS or how powerful the RCS thrusters are. Before activating the RCS, the information panel says "Propellant: Very Stable". It'll continue to say that no matter how long I have my RCS thrusters going. But as soon as I activate the engine, it'll switch to "Propellant: Very Unstable" just long enough for the ignition to fail, then go right back to reporting "Propellant: Very Stable" again.

I hate to turn off ullage and/or limited ignitions because I think they really add to the realism, but if I can't reliably get the engines to ignite, I don't have much choice. Is there any way to correct this issue without turning ullage off in the RealSettings.cfg file?

I'm still looking for a way to correct the problem with ullage. I know there probably isn't anything I can do about it mis-reporting "Propellant: Very Stable" when the propellant isn't stable at all, but I am hoping there is a way I can fix it so that RCS thrusters count as ullage. I've read that a vessel in orbit only needs to produce about 0.001g of thrust (less then 0.01m/s2, right?) for a few seconds in order to settle the fuel so even early game RCS thrusters should be able to produce plenty of thrust. I have to figure since the small separation motors are able to keep the fuel stable, the problem is related to the g forces being produced but I'm not sure if there is a setting in the RealSettings.cfg that controls that.

[westamastaflash]

I have similar trouble sometimes I can't even ignite engines when I have SRB ullage motors running for several seconds, and it says "Very Stable"... Seems to happen usually when the physics is slowed down (less than 1x frame rate - the "T+" indicator is yellow)

Edited August 14, 2015 by westamastaflash

[Svm420]

Hey Nathan I am trying to set up limited throttling to all engines based on tech level and type. However the patch I am applying doesn't limit the minimum throttle. Here is the code I am trying. Is there some other way to go about this? Thanks!

@PART
[*]:HAS[@MODULE[ModuleEngineConfigs]:HAS[#techLevel[3],#engineType[L+]]]:FINAL
{
  @MODULE[ModuleEngineConfigs]
  {
    @CONFIG,*
    {
      @throttle = 0.75
    }
  }
}

[Laie]

I have similar trouble sometimes I can't even ignite engines when I have SRB ullage motors running for several seconds, and it says "Very Stable"...

I find that ullage helps, you just have to have enough of it: in space, the most puny RCS will suffice if you run it long enough, in extreme cases it may take ten seconds or more. But at 10km alt and transsonic speeds, your ullage motors need to provide enough thrust so that your net accelleration after drag is still positive. On 2m rockets, I had good results with 2-3 of the radial separation motors.

It also helps if you crank the decoupler force all the way down to zero or don't decouple and ignite at the same time. That sudden impulse seems to be counter-productive.

[Cronus425]

Is there any way to turn off the ullage and ignition limits or do I just have to use an old version of the mod forever?

[NathanKell]

Apologies for the delay on fixing interaction with TweakScale. I was away for a bit, and remain quite busy. I'll get to it, but no promises as to when.

Same with the ignition/ullage stuff. It's even tougher because I have never encountered the issue myself (when it says Very Stable but is lying).

zzz: depends on what config set you're using. If you're using something that uses techlevels, that will work. If not, you need to work a bit harder (modify the keys in the atmosphereCurve in the CONFIG). RF does support global static Isp SL and Vac multipliers though, so if you're writing (or can have someone write) a very simple plugin that just sets them, that will work too.

Svm420: @ works only if the value already exists. Use %

(Also, try using 1.0 for everything, and instead modifying the techlevel throttle settings in REALSETTINGS)

Cronus425: Yep, you can set them both to false near the bottom of RealSettings.cfg

[NathanKell]

codepoet: what exactly _is_ the behavior you intend for MechJeb? If an engine is set to engineIgnited = false (but it's staged), then MJ won't compute delta V for it. That's why I leave it set to true, so you get to see dV even when your engines are at 0 thrust.

[codepoet]

codepoet: what exactly _is_ the behavior you intend for MechJeb? If an engine is set to engineIgnited = false (but it's staged), then MJ won't compute delta V for it. That's why I leave it set to true, so you get to see dV even when your engines are at 0 thrust.

I believe that from MJ's perspective the problem arises from the fact that the engine has fixed thrust (or should that be a minimum thrust other than 0) So I believe the MJ code ends up using that minimum level of thrust for some torque calculations even when the engine is "off". This is not a problem when not using RF because there is a check to see if the engine is "ignited", however when RF is installed that changes (I think).

My initial thought was that it was a problem in MJ, however the MJ code does a whole bunch of other stuff in the relevant area that I do not understand so I am hesitant to point any fingers. Similarly there is more going on with RF that I know about as well.

Nathan, I would be grateful if you were to have an exchange with Sarbian to decide what the best way forward is. Please let me know if I can help with more details to reproduce the problem.

Edited August 22, 2015 by codepoet