ksp-ro / realfuels Goto Github PK
View Code? Open in Web Editor NEWModular fuel tanks and engines, with real fuels and realistic performance.
Modular fuel tanks and engines, with real fuels and realistic performance.
Otherwise MFT will override the part mass with its own: desired for tanks, not desired for combination tanks/engines.
Adding Community Resource Pack support, and making RealFuels CRP compliant, would help improve cross compatibility with other mods, and help prevent conflicts and errors. I am willing to port the RF resources to CRP if you are OK with it and willing to port to use CRP.
One should be able to set a default TL for engines, which will be matched as best as possible when one places an engine in the editor; it will not, however, change the GetInfo() messages.
If ModuleFuelTank is configured with volume = 0 then the associated part will have no thermal mass (part OR skin) and will immediately explode upon spawning.
It doesn't work anymore, not sure why. Have my install, everything works as it should, remove RealFuels 5.3, install RealFuels 6+ Engine Ignitor is broken, put 5.3 back, works just fine.
Hello.
I've had this issue for some time, and i finally know the minimal list of mods needed to reproduce it.
(Debian sid, KSP.x86_64)
Steps to reproduce:
Mk1 Command Pod
Launch Escape System
on top of Mk1 Command Pod
Launch Escape System
one stop downNot sure it's RF issue, but If RF is not installed, all works fine, so this looked like the best place...
After many git bisects, I've discovered that going from 8.2-pre to v8.2 causes my game to bug out attempted launch of an existing craft. When this happens we start off in space, there's no rever to launch or build, and hitting 'm' (map) takes one to the sun, and not the Earth. It's pretty messed up.
I'm guessing this is where things go wrong:
NullReferenceException
at (wrapper managed-to-native) UnityEngine.Component:InternalGetGameObject ()
at UnityEngine.Component.get_gameObject () [0x00000] in <filename unknown>:0
at ShipConstruct.SaveShip () [0x00000] in <filename unknown>:0
at Kerbal_Construction_Time.KCT_Utilities.RecalculateEditorBuildTime (.ShipConstruct ship) [0x00000] in <filename unknown>:0
at Kerbal_Construction_Time.KCT_Events.ShipModifiedEvent (.ShipConstruct vessel) [0x00000] in <filename unknown>:0
at EventData`1[ShipConstruct].Fire (.ShipConstruct data) [0x00000] in <filename unknown>:0
at RealFuels.ModuleEngineConfigs.SetConfiguration (System.String newConfiguration) [0x00000] in <filename unknown>:0
at RealFuels.ModuleEngineConfigs.OnLoad (.ConfigNode node) [0x00000] in <filename unknown>:0
at PartModule.Load (.ConfigNode node) [0x00000] in <filename unknown>:0
at Part.LoadModule (.ConfigNode node, System.Int32& moduleIndex) [0x00000] in <filename unknown>:0
at ShipConstruct.LoadShip (.ConfigNode root) [0x00000] in <filename unknown>:0
at ShipConstruction.LoadShip (System.String filePath) [0x00000] in <filename unknown>:0
at FlightDriver.Start () [0x00000] in <filename unknown>:0
CKAN manifest:
KSP found at /home/pjf/.steam/steam/SteamApps/common/Kerbal Space Program
KSP Version: 0.25.0
Installed Modules:
✓ AGExt 1.24a
✓ AJE 1.6.8
✓ AlternateResourcePanel 2.6.1.0
✓ Chatterer 0.7.1
✓ CIT-Util 1.0.4-unofficial
✓ CommunityResourcePack 0.2.3
✓ CommunityTechTree 1.1
✓ CrossFeedEnabler v3.1
✓ CustomBiomes 1.6.8
✓ CustomBiomes-Data-RSS v8.3
✓ DDSLoader 1.7.0.0
✓ DeadlyReentry v6.2.1
✓ DMagicOrbitalScience 0.9.0.2
✓ DogeCoinFlag 1.02
✓ EngineIgnitor-Unofficial-Repack 3.4.1.1
? EVE-Overhaul-Core 0.0.2014.11.25
✓ FerramAerospaceResearch v0.14.4
✓ FinalFrontier 0.5.9-177
✓ FinePrint 0.59
✓ FirespitterCore 7.0.5398.27328
✓ HotRockets 7.25
✓ InfernalRobotics 0.19.2
✓ Karbonite 0.4.4
✓ KAS 0.4.9
✓ KerbalAlarmClock v3.0.5.0
✓ KerbalConstructionTime 1.0.3
✓ KerbalJointReinforcement v2.4.4
✓ kOS 0.15.3.0
✓ KronalVesselViewer 0.0.4_0.25
✓ MechJeb2 2.4.0
✓ ModuleManager 2.5.3
✓ ModuleRCSFX v3.3
? NathanKell-RVE-Haxx 0.0.2014.11.25
✓ ORSX 0.1.3
✓ PartCatalog 3.0_RC8
✓ PlanetShine 0.2.2
✓ PreciseNode 1.1.1
✓ ProceduralDynamics 0.9.1
✓ ProceduralFairings v3.10
✓ ProceduralParts v0.9.20
✓ RealChute 1.2.6
✓ RealFuels rf-v8.2
✓ RealismOverhaul v7.0.3
✓ RealSolarSystem v8.3
✓ RemoteTech v1.5.1
✓ RemoteTech-Config-RSS 0.0
✓ RP-0 v0.16
✓ RSSTexturesDDS8192 1.0
✓ SCANsat v8.0
✓ ScienceAlert 1.8rc1
✓ Service-Compartments-6S 1.2
✓ ShipManifest 0.25.0_3.3.2b
✓ StageRecovery 1.5.1
✓ SXT 19
✓ TACLS v0.10.1
✓ TACLS-Config-RealismOverhaul v7.0.3
✓ TechManager 1.5
✓ Toolbar 1.7.7
↑ TweakScale v1.44
✓ UKS 0.21.3
✓ UniversalStorage 0.9.4
✓ UniversalStorage-KAS 0.9.0.14
✓ UniversalStorage-TAC 0.9.2.7
✓ USITools 0.2.4
Legend: ✓ - Up to date. ✗ - Incompatible. ↑ - Upgradable. ? - Unknown
I haven't tested this with new craft, the only other craft I've worked with ( "Science Reentry I" in the save ) also causes the game to bug out.A
For the time being I'm reverting back to 8.2-pre.
Many thanks,
~ Paul
This has been giving me a hard time: engines fail to ignite, or ignite and immediately shut down, even though the fuel is supposedly "very stable".
After some messing around, I suspect that the status display isn't too reliable. In all situations where this bit me, the ship was under no or negative acceleration, so it's reasonable to assume that the fuel wouldn't be where it's supposed to be. Doing the right thing, using either high-pressurized tanks or ullage, solved the issue of engines not igniting.
So the problem seems to be that propellant is reported to be "very stable" in situations when it isn't.
I have encountered this bug which happens every time I reload a craft in which the procedural part SRB has a lowered propellant level.
On craft reload (save/load, or scene change) the SRB has a increased burntime (i.e. a smaller exhaust).
ps. I'm not sure if this is more of a bug of Real Fuels or Procedural Parts... If you think it's needed I'll submit the same report to PP.
This is my first git-issue post ever, so let me know if this is not the correct way to do this. Thanks!
[LOG 18:54:10.981] RF GUITanks exception System.ArgumentException: Getting control 2's position in a group with only 2 controls when doing Repaint
Aborting
at UnityEngine.GUILayoutGroup.GetNext () [0x00000] in :0
at UnityEngine.GUILayoutUtility.DoGetRect (UnityEngine.GUIContent content, UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options) [0x00000] in :0
at UnityEngine.GUILayoutUtility.GetRect (UnityEngine.GUIContent content, UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options) [0x00000] in :0
at UnityEngine.GUILayout.DoButton (UnityEngine.GUIContent content, UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options) [0x00000] in :0
at UnityEngine.GUILayout.Button (System.String text, UnityEngine.GUILayoutOption[] options) [0x00000] in :0
at RealFuels.ModuleFuelTanks.GUITanks () [0x00000] in :0
KSP Ver: Winx86 0.90.0.705
Problem: Unable to open up command pod tweakable menu using right click
Mods Installed:
Real Fuels v8.4
TAC Life Support v0.10.2b
(I also realised I left fragments of the RasterPropMonitor stock pod patch in, but I doubt that effects anything)
Step to recreate:
Create new game, open up VAB or SPH and select a manned command pod and attempt to right click.
Output log: https://www.mediafire.com/download/1dnachv6061h45c/output_log.txt
Win10 64bit, KSP 1.0.4 64bit with RF v10.2(need to be checked again, see comment below)(seems that x32 also has the problem)
steps to recreate the issue:
1 remove the Tweakscale module remover(if any) in RF folder. Install Tweakscale.
2 pick an engine(for example, one with 100kN thrust), add to the craft. Tweakscale it.
3 check the RF GUI. Everything looks fine(thrust becomes 800kN). MechJeb also seems fine for TWR.
4 Launch. Engine's thrust come back to the orignal one.(in this example, 100kN)
add TLs for tank dry masses
ProceduralParts ProceduralSRB module uses this function via reflection. Seems like there is something odd going on. Maybe a stack overrun? RF recently had some major changes right? (ullaging?) Is there something I need to take notice of/change from a PP perspective?
In the previous version, when creating a TANK with a specified amount in it, the utilization and everything else was used if that specific resource was defined in the TANK_DEFINITION. Now it doesn't...
For example...if I have a type = ServiceModule, then TANK{name = ElectricCharge, amount xxx, maxAmount xxx}. Before, since utilization = 100 in the ServiceModule TANK_DEFINITION, then utilization would also be 100 in my tank...NOW, utilization = 1.
At least this is my guess.
Checkbox in tank GUI so I can for example:
I noticed this with KW Rocketry but also a couple squad engines during more testing. All KW Rocketry engines, the Squad S3 KS-25.4 "Mammoth", and Squad LFB KR-1x2 "Twin-Boar" are being displayed on the Fuel Tanks tab instead of the Engines tab AFTER real fuels is installed. Before Real Fuels they are on the correct tabs. The two squad parts I can understand since they have small tanks built in but the KW engines do not.
All mods were installed via CKAN. I checked "KW Rocketry" and "Real Fuels" boxes. I did not check any "suggestions" but let it pull in the dependencies.
Testing was done on a stock 32-bit KSP install on Win 7 x64.
.ckan file of installed mods: https://www.dropbox.com/s/4sc45pgyzfdkxn1/kw-rocketry-engines-in-fuel-tanks-tab-modlist.ckan?dl=0
KSP.log here: https://www.dropbox.com/s/np49haxwjdzagiw/KSP.log?dl=0
Output_log.txt here: https://www.dropbox.com/s/lomx475xzmbu21u/output_log.txt?dl=0
Let me know if you need further details. I'm highly technical but not a coder. I love what you have done for KSP and want to help in any way I can.
.
The name DepU235Rods
is extremely misleading, and U235Rods
is mostly misleading, as discussed on IRC.
They are used in RO to model reactor fuel rods and (spent and new), and the spent stuff is not depleted uranium: it contains plutonium, a right mess of actinides, and it is typically still more enriched than naturally-occuring uranium.
Change to SpentUraniumRods
respectively UraniumRods
, (we probably don't want to go too far into the specifics of the kind of fuel yet: while UO2 is frequent, SNAP-10A used UZrH).
At the moment, 1.0.4, all hypergolic engines seem to need ullage kicks, though the engines are hypergolic on pressurized tanks.
Before I can add an MFT patch to B9, I need cost implemented.
To get you started, these are the values I beat out of the stock parts:
Since the cost of the resource must be accounted in the .cfg instead of being added afterwards like it would be sensible to do it one were not an idiot, volume*unitCost must always be present in the added cost.
Its only used in career when not using a tank to its full capacity, at which point it is removed.
As you already have technode binded techlevels which define engine efficiency, why not to make a next step? Force earliest T1 rockets to use hydrogen peroxide + methanol for example. And every next techlevel will enable more advanced and effective fuel mixes.
Just an idea.
I recently tried your mod out and found an overwhelming amount of things in it, and it was still missing some of the fuel types I needed. I had an idea for this really. Several ideas actually.
2.5. This is going one step further, and letting you configure resource densities, mass, types, if transferable and all that jazz right there in the game configuration thing and maybe even manually adding a new one to the list, like if you're missing ArgonGas, I can just type the exact name "ArgonGas" and it will see it from then on. Another option to add is "Fuel can share a tank" which would be a true or false type thing, the only one that can share is Liquid Fuel and Oxidizer.
So I had some combination of parts that would instantly overheat. Your classic KSP 1.0.4 heat bug.
No problem, I think, that's what "ignore max temperature" is there for.
This works, until the heat spreads to the engines. Then the engine internals overheat and go boom.
I know that 1.0.5 supposedly solves all heat issues. I'd still suggest that mods should honor the heat cheat.
For stock KSP, two engine types, or selectable fuel sources, is just fine since there are only a few fuel types, but once mods are thrown in and things like Real Fuels, Karbonite, Kethane, etc are taken into consideration, being able to add more engine\fuel types per part could help reduce part count, help in making more engines viable for use in resource mining ships, and would be a very helpful feature for Module Manager patches designed to integrate mods with one another.
Thanks and I hope you consider this.
When I install real plume with stock configs after installing real fuels with stockalike configs, the engine ignitor features disappear (it will let me ignite engines infinitely under all conditions). It doesn't show the fuel state or the ignitions remaining.
Reproduces always. Tested with Swivel and Reliant engines.
This also installed (as dependencies):
P.S. Love this mod!
Plztofixk?
Issue is when an engine is taken to 0 throttle and then increased above 0 the engine remains off and can only be re ignited by shutting the engine down in the Rclick menu setting throttle above 0. Finally quicksave and quickload, and activate the engines again and they re ignite. If throttle is not set above 0, or engines aren't actually shut down the method fails. This is with the latest solver engines dll
engine igniter (the mod) had bits to show the data in RPM screens
this seems to have taken over the ignition bits with EI looking dead
perhaps add the bits to interface with RPM and take over same screen?
Fix it.
I'm having the same symptom as the no flames with realplume issue, even though I'm using smokescreen. I've been playing a lot with all my mods, so to make sure it's not just me, I tried this on a fresh install, a new game + a full reinstall of all my mods. only the rhyno engine seems to have a flame.
I do see a little bit of smoke at takeoff though, then nothing.
Kerbal version:
1.0.4
List of installed mods (ckan export)
{
"kind": "metapackage",
"abstract": "A list of modules installed on the default KSP instance",
"name": "installed-default",
"license": "unknown",
"version": "2015.08.19.01.27.15",
"identifier": "installed-default",
"spec_version": "v1.6",
"depends": [
{
"name": "xScience",
"version": "4.8"
},
{
"name": "MenuStabilizer",
"version": "1"
},
{
"name": "ModuleManager",
"version": "2.6.7"
},
{
"name": "DiverseKerbalHeads",
"version": "1.0"
},
{
"name": "TextureReplacer",
"version": "2.4.8"
},
{
"name": "KIS",
"version": "1.2.2"
},
{
"name": "AnalogControl",
"version": "1.6.1"
},
{
"name": "ProceduralFairings",
"version": "v3.15"
},
{
"name": "CrossFeedEnabler",
"version": "v3.3"
},
{
"name": "ModuleRCSFX",
"version": "v4.1"
},
{
"name": "RFStockalike",
"version": "v2.1.8"
},
{
"name": "RealFuels",
"version": "rf-v10.5.1"
},
{
"name": "CommunityResourcePack",
"version": "0.4.4"
},
{
"name": "SolverEngines",
"version": "v1.9"
},
{
"name": "ModuleAnimateEmissive",
"version": "v1.9"
},
{
"name": "ModularFlightIntegrator",
"version": "1.1.1"
},
{
"name": "ConnectedLivingSpace",
"version": "1.1.3.1"
},
{
"name": "MechJeb2",
"version": "2.5.3"
},
{
"name": "RCSBuildAid",
"version": "0.7.2"
},
{
"name": "ProceduralParts",
"version": "v1.1.7"
},
{
"name": "FilterExtensions",
"version": "2.4.1"
},
{
"name": "KAS",
"version": "0.5.4"
},
{
"name": "Toolbar",
"version": "1.7.9"
},
{
"name": "KerbalEngineerRedux",
"version": "1.0.18.0"
},
{
"name": "KerbalJointReinforcement",
"version": "v3.1.4"
},
{
"name": "FilterExtensionsDefaultConfig",
"version": "2.4.1"
},
{
"name": "NMSG",
"version": "1.3"
},
{
"name": "FerramAerospaceResearch",
"version": "2:v0.15.4.1_Goldstein"
},
{
"name": "EngineLighting",
"version": "1.4.0"
},
{
"name": "SmokeScreen",
"version": "2.6.9"
},
{
"name": "DockingPortAlignmentIndicator",
"version": "6.2.0"
},
{
"name": "HullcamVDS",
"version": "0.50"
},
{
"name": "KerbalAlarmClock",
"version": "v3.4.0.0"
},
{
"name": "UKS",
"version": "0.31.6"
},
{
"name": "FirespitterCore",
"version": "v7.1.4"
},
{
"name": "USITools",
"version": "0.4.2"
}
]
}
Test case: put any vessel with a LR89 engine on the pad and try to launch.
Comparing their stats in RO_FASA_Atlas.cfg, I find barely any difference in their IGNITOR_RESOURCEs: one requires 0.5 electricity, the other 0.50, but that trailing zero is not the problem -- I tried.
In the present, i need to remove Modular Fuel Tanks because it mess with the cockpit and crew LS tanks. (Stock, B9, ALCOR). Removing everyone of then, letting me with no life support at all.
I think this need a fix, to regain compatibility.
A way to go back to a tank_def or part override defined values, for tanks that don't have multiple types defined.
Freezing up on "
MissingMethodException: Method not found: 'PhysicsGlobals.get_SkinInteralConductionFactor'.
" ^
the variable I think it is trying to find is "SkinInternalConductionFactor"
^
While it's a nifty feature in some ways that the tank setup GUI detects what kinds of engines you have and gives you the option to configure the remaining volume to suit, does it take that much space to just leave that button there always along with a similar button for TACLS? Depending on how you build your ship it's not always obvious to the editor that a tank will be used by your chemical engines, I've had to attach radial engines to tanks to get access to that button and it's a bit silly. Similarly 2-3 buttons to give you a mix of the TACLS resources would be nice (consumables, all, waste).
If you have default fills for a tank, or have RESOURCE nodes in your part, then those resources will appear in the tank in flight mode, or if you reload a craft in the VAB even when you haven't used those resources.
Tangentially, all the tank definitions are getting saved with the part into the persistence data. There's not a lot of use for it there. Might as well just pull the tank defs from the part and from the tank type.
Ok, my last description wasn't clear enough to go on. My fault, let's try this instead. In v6.0 and 6.1, unlike previous 5.3, if a person sets up a default tank quantity, it now removes settings otherwise set before. I'll walk you through what I mean
In RealFuels/Resources/RealTankTypes.cfg, sets up types of tanks (Cryogenic, ServiceModule, Balloon, etc.) within that are default specifications for each type of substance that is capable of being added. So say "Jet" type tank only allows certain fuels, while "Oxy" only contains certain oxidizers. When a part is specified to be type "Jet" (w/o any tanks defined), then only certain fuels are available in the GUI of the VAB. Now these tanks set up within a type (Jet, Oxy, Cryogenic, etc) also set up it's utilization, whether it's pressurized, boil off, etc.
Before, a person within a parts config file, could simply set the volume of tank say 50, set the type of tank (ex. ServiceModule), then add a tank of say ElectricCharge, with a quantity of 4032. Now because because it's utilization for ElectricCharge within a ServiceModule type tank was already set to 100 (previous paragraph), since utilization was not set in the parts config file, it used that value set before. Same goes for boil off, or pressurization. So under the same part config file an additional tank of MMH could be set with a quantity of 9.68, it would already be pressurized via the "RealTankType.cfg" TANK_DEFINITION of ServiceModule.
NOW, if a person defines a tank within the parts config file...that is the only thing it uses, so a tank of ElectricCharge instead of a utilization of 100 as defined before, defaults to 1. A tank that was pressurized as defined before, is no longer pressurized.
End result, my ServiceModule type tank with a volume of 50, now breaks the part because instead of ElectricCharge having a volume of 40.32 as it should (and did before), now has a volume 100x that of 4032. that tank of 9.68L of MMH that should have been pressurized to feed an engine, now fails because the MMH tank wasn't pressurized in the parts config file, even though MMH is pressurized in the "RealTankType.cfg" file TANK_DEFINITION.
ModuleManager 2.6.7 will now call any static method with the signature ModuleManagerPostLoad() ( or the same instance method on any active MonoBehavior instance) when the game database is reloaded (or loaded for the first time). Implementing this method in MFSSettings would allow the tank definitions to be reloaded without restarting the game. It would also simplify loading since the load check in ModuleFuelTanks would no longer be necessary. MM calls this method right before loading parts, but right after loading resources, so the correct pieces should be in place when they need to.
it will be reset to null, etc.
Well i seem to have found a major issue with using realfuels with tweakscale.
Using latest tweakscale, realfuels, MFI, and dev version of solverengines
Windows 7 64bit KSP 1.0.4 32 bit outside program files folder
Steps to reproduce.
Hope that helps! :)
I noticed that MFT places a dll into the TweakScale folder. This file is prone to vanishing when someone deletes the TweakScale folder to do a clean update of the mod. It would be more robust to place the dll with MFT.
Maybe you can even do without an extra dll, I had a report from someone who probably lost the dll and wrote a config instead:
http://forum.kerbalspaceprogram.com/threads/110899-WIP-TweakScale-Development-Thread?p=1782006&viewfull=1#post1782006
I'm also confused that TweakScale includes a config for realFuels but not for MFT. Shouldn't both mods need the same treatment?
TWEAKSCALEEXPONENTS
{
name = RealFuels.ModuleFuelTanks
basemass = 3
basemassPV = 3
totalVolume = 3
volume = 3
fuelList
{
amount = 3
maxAmount = 3
}
}
As it says on the tin, offset part cost by this amount.
There's something screwy with how the ModuleRCSFX and ModuleEngineRF are interacting.
When I have an engine that has both sets of modules (for example, the SpaceY orbital manuvering systems, which include throttable thrusters and RCS), sometimes after editing the engine settings the RCS settings don't respond - clicking the button fails to change the fuel. Clicking the second "Show GUI" Button opens the configure window, but I can't select other fuel types, nor change the Tech Level.
However, If I select the first Show GUI Button, then select the second Show GUI Button, and finally Hide the first Show GUI button, I can then configure the RCS Thrusters. It's like there's something in the GUI for these components that gets confused.
To reproduce the issue, create an engine with a ModuleRCSFX module, a ModuleEngineConfigs of type = ModuleRCSFX and a ModuleEngineConfigs of type = ModuleEnginesRF.
There may be a larger issue around the fact that we end up with two "ModuleEngineConfigs" in the persistent save file but the "type" is not persisted? How does the mod know which ModuleEngineConfigs modifies the RCS module and which modifies the engine module?
Also, even after doing my workaround, I have found that it seems that it doesn't apply symmetry properly to the RCS engines - Only the one engine actually gets the right fuel for the RCS thrusters. A simple remove / re-add fixed that.
Science? Funds? Foozballs?
Exit area of the nozzle is an important property that can be used for lots of calculations by RF or other plugins, and it would be great to have it here in RF as a central place.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.