[1.8+] Real Fuels

[NathanKell]

Remove Tweakable Everything, then try again and post the log. I know you said Tweakable Everything wasn't the problem, but it *is* what's showing up as the problem in the log.

[TeeGee]

Remove Tweakable Everything, then try again and post the log. I know you said Tweakable Everything wasn't the problem, but it *is* what's showing up as the problem in the log.

No this problem occured when I did a fresh install without Tweakable everything. I just reinstalled it because it wasn't the problem. When I installed stockalike with real fuels is when it started.

[NathanKell]

I get that, as I said. But as I said, Tweakable Everything is what is showing as causing errors in the log. To make the log clearer, please do as I ask.

[TeeGee]

Removed tweakable:

https://www.dropbox.com/s/zxxvt2572ajuwmk/output_log%28without%20tweakable%29.txt

I don't think it's real fuels per se, it might be a conflict with something else though.

Edited June 1, 2014 by TeeGee

[NathanKell]

Thanks!

Hmm, ok. What I'd like you to do is launch hit ALT-F12, go to Database. Find a solid booster that gives you trouble, and tell me what's in its config.

Edit: check the Stockalike RF Config thread. Raptor831 has an update.

[TeeGee]

Thanks!

Hmm, ok. What I'd like you to do is launch hit ALT-F12, go to Database. Find a solid booster that gives you trouble, and tell me what's in its config.

Edit: check the Stockalike RF Config thread. Raptor831 has an update.

Yeah I already applied that update, it didnt work.

[NathanKell]

Then please do the first part of the post...

[TeeGee]

Like this?

[TeeGee]

SOLVED on stockalikes forum!

THANKS FOR YOUR HELP!! I truly appreciated you taking the time to help me solve this problem!!

[NathanKell]

Changelog:

v6 \/

*Updated plane parts (C7, Firespitter) to have B9-esque levels of resources. No more magic volume-disapppearing tricks when fuel tanks become fuselages.

*Massive improvements from swamp_ig, for integration with Procedural Parts and other mods, and UI improvements.

+Switchable tanks

+fixed symmetry bug

+(optional) tweakable utilization

+Better integration support

+loading fixes

+Display GUI from tweakables

+SI units

*taniwha: show version on GUI

*support more Firespitter parts

*Update to ModuleManager v2.1.5

*Sandworm: support HGR tanks

NOTE: At this point it is recommended to switch from StretchyTanks to Procedural Parts (if you have not already done so).

[Azimech]

Great! Thank you very much! Downloading now!

[Woopert]

Is RSS_Resources.cfg still required with Realism Overhaul / Real Solar System?

[swamp_ig]

Ok have released a new version of RF Download it here

NathanKell is away this weekend and there were a couple of bugs that couldn't wait.

Should fix the issues with SRBs, and with phantom tanks appearing. This will also cut down on the amount of guff in the save and craft files.

Obviously as I'm not NathanKell, I can't update the OP, will have to wait for him to get back...

Edit: I just found another issue I wasn't previously aware of - alt-click cloning doesn't work too well. Will get onto that.

Edited June 7, 2014 by swamp_ig

[RedAV8R]

Is RSS_Resources.cfg still required with Realism Overhaul / Real Solar System?

No. RSS_Resources is NOT required now. In fact it needs to be removed from the RedAV8R folder of RO or not good things happen.

[Sandworm]

I just noticed one of my files released with realfuels. That's cool with me, but that version is missing some stuff. So here is a more complete version also covering engines.

https://www.dropbox.com/s/f3vqmm0vs5p4hdl/HGR.cfg (replace the HGR.cfg in your refuels directory)

Recent Changes...

Added nosecone tank. (Kerbal engineer doesn't read it properly, something to do with labels I assume.)

Added support for service modules.

-Both have 1000 ElectricCharge and MMH/N2O4 tanks added by default

-SoySvcMod engine supported

Future wants...

-Default O2/Water/Food tanks for service modules.

-Default monoprop for service modules?

[Padishar]

Added nosecone tank. (Kerbal engineer doesn't read it properly, something to do with labels I assume.)

I've been meaning to look into this (well, the same issue with the nosecones that hold fuel in some other mods) for a while but keep forgetting about it. Are your nosecones also "module = Strut"?

[swamp_ig]

Why would nose cones be a strut? Must be some horrid hack...

[Guest]

Likely just copypasting ancient nosecone configs. In days before module system, they were (like all structural parts) "struts".

[Raptor831]

Does the ModuleHybridEngines work with ModuleEngineFX? I'm doing a proof-of-concept on getting bi-modal NTRs into the XLS for the stockalike configs, and I can't seem to make it work. I even ran through the standard RF bi-modal LV-N line by line to compare, and the only thing of note I noticed that was different was the ModuleEngineFX. In-game none of the RF menus work, but the part hover lists the current (correct) fuel config and the correct modes. Also, logfile spams this error when the engine is attached in the VAB:

(Filename:  Line: -1)

NullReferenceException: Object reference not set to an instance of an object
  at RealFuels.ModuleEngineConfigs.SetThrust () [0x00000] in <filename unknown>:0 
  at RealFuels.ModuleHybridEngine.FixedUpdate () [0x00000] in <filename unknown>:0

It's certainly possible I'm just doing it wrong, so please let me know if that is the case.

Here's the applicable part of the config:

@PART[ltby5000]:FOR[RealFuels_StockEngines] //LtBY 12K
{
 @mass = 0.2
 @maxTemp = 2828

 @MODULE[ModuleEnginesFX]
 {
  @maxThrust = 12
  @heatProduction = 291
  @atmosphereCurve
  {
   @key,0 = 0 960
   @key,1 = 1 429
  }
  !PROPELLANT[LiquidFuel] {}
  !PROPELLANT[Oxidizer] {}
  !PROPELLANT[MonoPropellant] {}
  PROPELLANT
  {
   name = LiquidH2
   ratio = 100
   DrawGauge = True
  }
 }

 MODULE
 {
  name = ModuleHybridEngine
  techLevel = 7
  origTechLevel = 7
  engineType = N
  origMass = 0.2
  configuration = LiquidH2
  modded = false
  runningEffectName = run_ltby
	thrustVectorTransformName = exhaust
	exhaustDamage = True
	ignitionThreshold = 0.1
  CONFIG
  {
   name = LiquidH2
   maxThrust = 12
   heatProduction = 291
   PROPELLANT
   {
    name = LiquidH2
    ratio = 1
    DrawGauge = True
   }
   PROPELLANT
   {
    name = nuclearFuel
    ratio = 0.00000000001
   }
   IspSL = 1
   IspV = 1
   throttle = 0

   ModuleEngineIgnitor
   {
    name = ModuleEngineIgnitor
    ignitionsAvailable = 0
    autoIgnitionTemperature = 800
    ignitorType = Electric
    useUllageSimulation = true
    IGNITOR_RESOURCE
    {
     name = ElectricCharge
     amount = 0.12
    }
   }
   }
  CONFIG
  {
   name = LiquidH2+LiquidOxygen
   maxThrust = 98.4
   heatProduction = 291
   runningEffectName = run_ltby
	thrustVectorTransformName = exhaust
	exhaustDamage = True
	ignitionThreshold = 0.1
   PROPELLANT
   {
    name = LiquidH2
    ratio = 1
    DrawGauge = True
   }
   PROPELLANT
   {
    name = nuclearFuel
    ratio = 0.00000000001
   }
   IspSL = 0.6941
   IspV = 0.6941
   throttle = 0

   ModuleEngineIgnitor
   {
    name = ModuleEngineIgnitor
    ignitionsAvailable = 0
    autoIgnitionTemperature = 800
    ignitorType = Electric
    useUllageSimulation = true
    IGNITOR_RESOURCE
    {
     name = ElectricCharge
     amount = 0.12
    }
   }
   }

 }
!MODULE[ModuleEngineIgnitor] {}
 MODULE
 {
  name = ModuleEngineIgnitor
  ignitionsAvailable = -1
  autoIgnitionTemperature = 800
  ignitorType = Electric
  useUllageSimulation = true
  IGNITOR_RESOURCE
  {
   name = ElectricCharge
   amount = 0.12
  }
 }
 !MODULE[ModuleAlternator] {}
 !MODULE[ModuleGenerator] {}
 !RESOURCE[nuclearFuel] {}
 !RESOURCE[nuclearWaste] {}
 MODULE
 {
  name = ModuleAlternator
  OUTPUT_RESOURCE
  {
   name = nuclearFuel
   rate = -0.000000000000000001
  }
  OUTPUT_RESOURCE
  {
   name = nuclearWaste
   rate = 0.000000000000000001
  }
  OUTPUT_RESOURCE
  {
   name = ElectricCharge
   rate = 0.6
  }
 }
 MODULE
 {
  name = ModuleGenerator
  isAlwaysActive = true
  OUTPUT_RESOURCE
  {
   name = ElectricCharge
   rate = 0.3
  }
  OUTPUT_RESOURCE
  {
   name = nuclearWaste
   rate = 0.000000000000000001
  }
  INPUT_RESOURCE
  {
   name = nuclearFuel
   rate = 0.000000000000000001
  }
 }
 RESOURCE
 {
  name = nuclearFuel
  amount = 1
  maxAmount = 1
 }
 RESOURCE
 {
  name = nuclearWaste
  amount = 0
  maxAmount = 1
 }
}

[Sandworm]

Likely just copypasting ancient nosecone configs. In days before module system, they were (like all structural parts) "struts".

I worked out the problem, at least in relation to HGR parts. It wasn't a strut thing. They were listed as "part". Fuel crossfeed was disabled in the nosecones. KER's math probably stops when it runs into a part without crossfeed thinking it has hit a decoupler between stages. So when I enabled crossfeed it started working properly. This was also an issue with the HGR service modules. So if you have a nosecone-type part that isn't working with KER, check for a "crossfeed=False" line in its cfg and try changing it to True.

[NathanKell]

Raptor831: ModuleHybridEngine (note, no s) should work fine with ModuleEnginesFX. I wrote it to do so; I'm confused why it doesn't. When I get home (sorry! Tuesday!) I'll look into it.

However, though I think I have a failsafe for when this is lacking, it's good practice to add, in your MEC or MHE module, type = $ENGINEMODULE (ModuleEnginesFX in this case). See if that helps.

[Padishar]

I worked out the problem, at least in relation to HGR parts. It wasn't a strut thing. They were listed as "part". Fuel crossfeed was disabled in the nosecones. KER's math probably stops when it runs into a part without crossfeed thinking it has hit a decoupler between stages. So when I enabled crossfeed it started working properly. This was also an issue with the HGR service modules. So if you have a nosecone-type part that isn't working with KER, check for a "crossfeed=False" line in its cfg and try changing it to True.

Ahhh, ok. When I rewrote the KER simulation code I attempted to duplicate the fuel flow rules worked out by Kasuha but it appears there is a flaw in them (relevant KER code). Specifically, rule 3 says that a part with crossfeed disabled will return an empty list of parts (but will provide fuel via fuel lines coming into it by rule 2). If your nosecones do actually provide fuel when set to crossfeed=false then this rule must be wrong in some way (not surprising this has been missed if no stock parts are set up like this). It sounds like some more experiments will need to be done with modified parts that contain fuel but have crossfeed disabled...

However, I guess that having a fuel tank with crossfeed disabled doesn't really make a lot of sense so it probably does make sense for your parts to be changed...

[Raptor831]

Raptor831: ModuleHybridEngine (note, no s) should work fine with ModuleEnginesFX. I wrote it to do so; I'm confused why it doesn't. When I get home (sorry! Tuesday!) I'll look into it.

However, though I think I have a failsafe for when this is lacking, it's good practice to add, in your MEC or MHE module, type = $ENGINEMODULE (ModuleEnginesFX in this case). See if that helps.

It appears that adding type = ModuleEnginesFX did the trick. Worked as expected then.

[amo28]

Wondering if anyone else is having issues with the RF 6.x release. 5.3 worked fine for me, but with 6.0 and 6.1, every modular tank shows me "This tank cannot hold resources". The log shows this "Unable to find tank definition for type "ServiceModule" reverting.", however the tank definitions do load earlier in the log -- it only shows unable to find when actually compiling the parts.

Again, RF 5.3 works fine for me -- even just dropping the RF 5.3 dll into an RF 6.0 install works fine.

Should note that I'm using Linux x64 client. Hoping I'm not the only one seeing this.

[RedAV8R]

Wondering if anyone else is having issues with the RF 6.x release. 5.3 worked fine for me, but with 6.0 and 6.1, every modular tank shows me "This tank cannot hold resources". The log shows this "Unable to find tank definition for type "ServiceModule" reverting.", however the tank definitions do load earlier in the log -- it only shows unable to find when actually compiling the parts.

Again, RF 5.3 works fine for me -- even just dropping the RF 5.3 dll into an RF 6.0 install works fine.

Should note that I'm using Linux x64 client. Hoping I'm not the only one seeing this.

Yes, this is a known issue, they know what is happening and how to fix it, they just haven't got it yet. Be patient.