[1.8+] Real Fuels

[Svm420]

29 minutes ago, NathanKell said:

v10.8.4

• Update propellant status info line during warp as well.
• Change background color of engine stack icon based on propellant stability (like parachutes).
• Add the tech required to unlock a config to the info tooltip for that config (for unavailable configs).

Very awesome QOL update thanks again can't like that enough  

[NathanKell]

@Svm420 

Btw is RCS/Tweakscale still screwed? I was never clear whether it was something on my end or on TweakScale's.

[Svm420]

3 hours ago, NathanKell said:

@Svm420 

Btw is RCS/Tweakscale still screwed? I was never clear whether it was something on my end or on TweakScale's.

AFAIK it is a real fuels thing, and it it affects all rescaled parts engines too. It doesn't crash like before, but breaks the engine gui when returning to the editor or loading a previously saved craft with a rescaled part. You are obviously better at diagnosing than I. Considering last time I thought it was RF and it was a TS that needed changes. Pretty simple to trigger just rescale a part with a  RF engine module and ModuleEngineConfig. Launch then revert to editor boom broken gui. LMK if you need more from me or if you want to do this on git. Thanks!

[NathanKell]

Ok, cool, I'll take a look, hopefully I'll remember this time

[gonzo98x]

Add the tech required to unlock a config to the info tooltip for that config (for unavailable configs).

 

Thank you so much for this Nathan! This has been my number one point of frustration in an otherwise amazing mod.

Edited February 29, 2016 by gonzo98x

[rozmetal]

Thank you for the propellant stability color change. No more firing ullage motors for a full 5-10 seconds just to make sure because I'm too lazy to leave IVA. 

[stainedsix]

i tried downloading the mod and have tryed through ckan and everything and when i try to change the fuel or open the gui it wount and it says nothing found

 

[NathanKell]

Are you by chance using the hacked 64bit version? Because there's no support for that, because it's buggy for most people.

[stainedsix]

On 3/1/2016 at 9:42 PM, NathanKell said:

Are you by chance using the hacked 64bit version? Because there's no support for that, because it's buggy for most people.

oh i am because im useing rss and it crashes all the time so ill try with no 64 bit thx

 

[dan2600]

love this mod, thanks for all the work on it.

 

Looks like I'm having the tweekscale issue as well. For me 2 things happen. I can build the ship, and set all the tanks and engines up with the GUI, but as soon as I launch all the resized engines default back to their original fuel settings (I'm using procedural fuel tanks, they keep their values). Once I go back to the VAB the guis are bugged and just display blank. 

 

 

[Svm420]

21 minutes ago, dan2600 said:

love this mod, thanks for all the work on it.

 

Looks like I'm having the tweekscale issue as well. For me 2 things happen. I can build the ship, and set all the tanks and engines up with the GUI, but as soon as I launch all the resized engines default back to their original fuel settings (I'm using procedural fuel tanks, they keep their values). Once I go back to the VAB the guis are bugged and just display blank. 

 

 

Known issue don't tweakscale any engines or RCS.

[Svm420]

@NathanKell

Would you consider some buttons to drain all tanks, fill all tanks, fill selected tank and drain selected tank? This would save me so much time doing various things drainI got and filling each tank which are not always in a convenient place to click, not to mention that  clicking to drag sometime several bars for various resources across multiple tanks isn't fun. I always finish by draining all tanks to be fueled on the pad, but then I remember I need to make a change to an upper stage and so I have to fill and empty them all again  . Maybe post 1.1 with the gui changes coming? 

 

P.s.

I have been loving the engine stability gui readout I.e. like parachutes. No more wasting time trying to click an engine on the dark side of the moon to check its propellant status only to have mechjeb wasting an ignition at best and staging at worse D:   Thanks!

[Charlie the Kerbal]

I am trying to modify MechJeb a bit to handle ullaging. So far I managed to get it fire RCS Thrusters forward for about 5-6 seconds prior to main engine start and it seems to be working fine. However this approach firing RCS regardless of stability of the propellant, and always for a fixed period which on some occasions may be too long or too short to stabilize the propellant.

How can I access ullage status of the current engine from MechJeb code ? Perhaps something I would figure out looking into ullaging code (I tried) but quite new to KSP code so a few quick pointers would help greatly.

Is there a part.ullageState or similar property that Real Fuels update ? And if yes, how can I pick the right part for the currently active engine ?

Many thanks

Charlie

[Autochton]

On a similar note, does RF's fuel stability support kOS?

[NathanKell]

@Charlie the Kerbal yes, there's a public string that tracks the ullage status. It also mentions pressure if you don't have highly pressurized tanks for your pressure-fed engine. The float that actually tracks it is in UllageSimulation, an object for which ModuleEnginesRF has a reference.

 

@Autochton uh...what do you mean?

[Autochton]

42 minutes ago, NathanKell said:

@Autochton uh...what do you mean?

Simply this: Is there a direct way to access the fuel state via kOS? Or do we need to estimate the time it takes to settle the fuel before lighting engines under the ullage thrust we have?

[NathanKell]

@Autochton I have no idea. That's up to kOS. My guess is they don't have special handling for RF's modules.

[Charlie the Kerbal]

45 minutes ago, NathanKell said:

Yes, there's a public string that tracks the ullage status. It also mentions pressure if you don't have highly pressurized tanks for your pressure-fed engine. The float that actually tracks it is in UllageSimulation, an object for which ModuleEnginesRF has a reference.

Any hints on where the string might be hiding ? All I can see in UllageSimulator is public double GetPropellantStability(), but that doesn't seem to be accessible from MechJeb (not being static).

[blowfish]

24 minutes ago, Charlie the Kerbal said:

Any hints on where the string might be hiding ? All I can see in UllageSimulator is public double GetPropellantStability(), but that doesn't seem to be accessible from MechJeb (not being static).

What you're looking to create is probably a separate compatibility DLL, like the FAR one.  The field is called propellantStatus and it's on ModuleEnginesRF, so to access it you either have to use reflection or build against RealFuels.

[Dunbaratu]

38 minutes ago, NathanKell said:

@Autochton I have no idea. That's up to kOS. My guess is they don't have special handling for RF's modules.

kOS has a generic system for getting its hands on the data that is displayed in the right-click menus of parts, under the principle that if somebody wrote a mod and allowed the user to witness the values on the part menu, then that probably means they don't mind a script getting its hands on the values too.  But things that are not displayed there are, by default, not exposed to kOS scripts because we can't exactly go around asking hundreds of mod developers which things they'd like to expose to kOS scripts and which they wouldn't.  (Just because it's "public" in C# terms doesn't mean a mod developer meant for the end-user to bypass the intended user interface to just change the value under the hood directly, or so went our rationale here.)

So we just use that as our generic design principle:  If the mod exposed the value to the user on the menu, we'll take that as permission to let the kOS users read it via the KSPField, and if the mod let that KSPField be settable, and it is currently enabled, then that also means the kOS script can edit the value (but only within the rules of that KSPField  widget - i.e. if it's a float field, kOS enforces that a script trying to change it gets the value clamped and rounded off in the same exact way the user interface slider would enforce.)

However, that generic system, due to its generic-ness, can be a bit wordy for a script to use (first get the part in question, then get the PartModule within the part, then get the field within the PartModule.)

Some other mod developers have gone out of their way to add AddOn modules to kOS to help it support their mod in a way that can bypass the generic partmodule methods, but it's not strictly necessary just to expose a few fields to kOS.  If all you want is to expose some fields, making them a visible KSPField on the rightclick menu should be enough.

 

[NathanKell]

Ok, cool. I don't have time to take on making such an addon, though I'm happy enough to help out anyone who does want to take it on. Right now just the string is on the right-click menu, which would make it a bit of a pain.

States are:

Very Stable

Stable

Risky

Very Risky

Unstable

Very Unstable

You can see that here: https://github.com/NathanKell/ModularFuelSystem/blob/master/Source/Ullage/UllageSimulator.cs#L195-L212

If the string is not one of those, you should ignore it (although if it's Feed Pressure Low, that means the engine won't work at all).

[Dunbaratu]

@Autochton - Here's something to get you started for making a kOS script query that field:

Caveat: I have NOT tested this at all - this is thrown together from examining ModuleFuelSystem's github page for a brief few minutes.  I haven't used ModuleFuelSystem myself so can't really quickly test if this is right:

// a bit of kOS code example:

// This assumes you already have a variable called 'thePart'
// which has been assigned to the part you're interested in
// querying for.

local propStat is thePart:GetModule("ModuleEnginesRF"):GetField("propellantStatus").

if propStat = "Very Stable" { print "do something here.". }
else if propStat = "Stable" { print "do something here.". }

// .. etc for checking the values NathanKell mentioned in the post above.

 

Edited March 6, 2016 by Steven Mading
added tagging of autochton's name

[Autochton]

9 hours ago, Steven Mading said:

@Autochton - Here's something to get you started for making a kOS script query that field:

[... code ...]

Gotta admit, my programming instincts are screaming for a more graceful way of performing that check. :-) But thank you for that, that means I can have engines light off at the right time. :-)

[Luc-maastricht]

I'm using this mod (which i really like) with Real scale boosters, but it doesn't liftoff. The engines start but it stays on the ground. Is there some sort of solution for this problem ?

[Astraph]

On 16.12.2015 at 0:08 AM, NathanKell said:

I *think* engines are OK now. @Svm420 reported an RCS issue I haven't had a chance to fix yet. Does require the latest development version of Tweakscale I think though.

Apparently the engines are still broken with TweakScale - I'm playing KSP 1.05 with most recent versions of RO and TweakScale availible on CKAN:

Any way to fix this issue without installing a clear copy of KSP? I don't really want to restart my career only because my 2nd most used engine got broken :/

EDIT: OK, I managed to fix it the dumbest way possible - reinstalled both RF and Tweakscale. I just hope other craft with tweakscaled structural parts did not revert to normal sizes ^^'

Edited March 12, 2016 by Astraph