saabstory88

Thank you for brining this to my attention. I am going to work through the B9 pack first, then hopefully I can make this the next priority. There is absolutely a way in Module manager, to run a routine after MFT runs, which searches for all MFT tanks, and adds the Cryogen module. The B9 pack is taking longer than expected, but maybe by the weekend, I can have a fix for this issue. Again, thank for letting me know, I didn't realize MFT had been forked from RealFuels.

Do you mean Firespitter FSfuelSwitch, or Modular Fuels? Modular fuels has been rolled into Real Fuels, and is obsolete. See: http://forum.kerbalspaceprogram.com/threads/52780-Modular-Fuel-System-Continued So no, this does not work with RealFuels, as this is sort of meant to be Real Fuels Lite. Having two would be redundant. As to the FSFuelSwitch issues... I am working on B9 with regular config switching as an interim, but I will be deploying a .dll, maybe in the next week or two, to do further FSfuelSwitch operations automatically.

Apology for the double post, but I thought it would be useful to throw in the values that I have been using, for reference. RESOURCE_DEFINITION { name = LiquidO2 density = 0.00652 unitCost = 0.75 flowMode = STACK_PRIORITY_SEARCH transfer = PUMP isTweakable = true } //LiquidH2 replace with LiquidHydrogen //Methane replaced with lqdMethane RESOURCE_DEFINITION { name = Kerosene density = 0.00474 unitCost = 0.1 flowMode = STACK_PRIORITY_SEARCH transfer = PUMP isTweakable = true } RESOURCE_DEFINITION { name = Hydrazine density = 0.006 unitCost = 0.5 flowMode = STACK_PRIORITY_SEARCH transfer = PUMP isTweakable = true } RESOURCE_DEFINITION { name = Aerozine density = 0.0075 unitCost = 0.5 flowMode = STACK_PRIORITY_SEARCH transfer = PUMP isTweakable = true }

I was imagining about 1/4 the cost of stock liquid fuel, or 0.2 funds per unit. Methane is a relatively cheap fuel, much less than cryogenic rocket propellants. If we look at the cost of LiquidHydrogen, from the CRP table, it is currently set at 0.5 funds per unit. I think this would not be outrageous to set it at this price. I am personally using this as a ISRU resource. It has lower ISP than other fuels, and is pretty abundant here on Earth, so we would imagine it is on Kerbin as well. Thoughts?

Not to bump, but just an FYI, I am currently sitting down to tackle B9. This will take a while. Thanks!

I should have posted back sooner. Without changing anything, a recompile solved the issue. I don't know what happened. Would love to know what the issue was. Also, thank you very much for the simplified code, I will attempt to implement this immediately.

If you are playing near stock, with only KW, and this Mod, you don't need texture compression for the game to run. This still has plenty of variety to do all sorts of challenging missions. I do all of my testing on OSX which I believe (I could be wrong) has the highest unity overhead. If you are getting crashes, I would be useful to know if is a memory leak, or something breaking either in my code, or with others. If you could post you log to the dev thread I maybe be able to help you.

You are not intended to do either of those things, This is supposed to be a challenge. The procedural parts works because they also have tech limits. You are not supposed to be able to just put any tank on any engine, or to be able to use all things interchangeably, that is literally half the point of the entire mod, to make things harder. This is not meant to be something that gives you a bounty of new items, which can do all things, but to make you have to make choices about what you use on your missions.

Right now, when a tank is created, a cryogenic module is attached. If you leave it off, liquid cryogenic materials will vent. This is based on tank mass. Also, you can choose to run the refrigeration loop, which consume electricity based on tank volume. A large 5meter KW tank can take as much as 500 electric charge per second! Smaller tanks will consume much less electricity.

Read the description. It is designed to play well with career mode and stock and near as stock(kW) parts. Yes, I am speaking to the game play aspects, not chemical composition. Hydrazine and Aerozine are not handled by the boil off code. When you install the procedural parts pack properly, as listed in the readme, you will see that you can now select the proper fuel mixture for any given engine, using procedural parts. Procedural parts are integrated into the tech tree properly, so it will not break your career. Furthermore, you can always use tweakscale to select different engine sizes for a given fuel.

Correct. I am working to improve the varieties of engines it can configure, and what tech tree nodes it looks at to generate these configs. Eventually I will get to the point where a .DLL handles all this with higher logic being applied, but for now, this approach works fine with most parts mods. This approach is also not destructive to say, Near Future, because it does not filter by their fuel types. I know thy B9 is going to require a custom config, but this method already works flawlessly with KW rocketry, and for the most part AEIS. This is just the first stable, playable, version. It will continue to be improved.

I have not checked agaislnst the latest B9 release. Now that it is out, I will make that my next priority. Because it was in development, I had not yet compiled against it. This should be an exception *most parts mods use normal tank layouts.

Nope. No engine configs needed! It should find most engines automatically.

Good catch on the Vernor ISP. My normal engine replacement doesn't handle it because it's not an engine module. I will push an update for this soon. Yes, engine ISP max is determined by the fuel type for simplicity. It does not replace the atmospheric ISP though.

The tanks and fuels should be automatically detected and replaced. It is likely that it will generate these tanks as LH2/LOX tanks, however, if it does not find these, it will simply leave the stock contents alone. I am still doing some other compatibility checks before I tackle the B9 behemoth for full integration. If you do try it out, I would love to hear back how it breaks, although I will get to it. The reason that the Jet engines use Kerosene, is because Jet fuel is basically Kerosene. I wanted to try to limit the types of fuel, and give everything a dual purpose, just for balanced gameplay. This may not make things better for the fuel flow in aircraft, but it won't make them worse.

This does not conflict with KSPI. KSPI i integrated into the CRP, so the fuel type is the same. The point of this is to be a simpler version of RealFuels which does not need special configuration files, and does not rely on modular fuels. This is not for RSS (the engines do not scale their TWR). This is meant to add just a little more complexity to the regular sized Kerbal system, and set up the basis for future ISRU. Again, the masses and costs of the fuels are balanced to Kerbal standards, not to STP as with RF. This is why NathanKell's description of this mod as "NEARFuels" is spot on. It's not full stop Ferram, it's just a little bit easier. That being said, for people who like the 6.4x Kerbal rescale, this Mod plays very nicely. Starting to imagine a full "RSS/RO lite" down the road.

Are there any immediate plans to assign a cost to LqdMethane? It would greatly help my particular mod, due to the fact that I am using it in launch stages, and the whole thing is geared towards career. It's not totally game-breaking, because liquid oxygen is expensive, but it would be nice to have some cost associated. Thanks!

Greetings! I am having a small issue with HigherLogic.LoadedScene. I want to make sure that my plugin does not function while the EDITOR is open (Well, and the SPH for that matter, but one at a time). Here is the code. The plugin continues to drain fuel even when in the VAB, so I know it is at least executing past the first IF. Reversing this and putting the code in an ELSE statement, also does not work. void FixedUpdate() { if (HighLogic.LoadedScene != GameScenes.EDITOR) { if(isActive) { float offsetMass = part.GetResourceMass(); float calcedECLoss = (chargeRate * TimeWarp.fixedDeltaTime * offsetMass * 2.0f); float chargeLoss = part.RequestResource("ElectricCharge", calcedECLoss); //print("NEAR Fuels!! chargeLoss: " + chargeLoss); } else { float boilOffOne = (rateOneRate * TimeWarp.fixedDeltaTime * part.mass); float boilOne = part.RequestResource(resourceOneName, boilOffOne); float boilOffTwo = (2.0f * rateTwoRate * TimeWarp.fixedDeltaTime * part.mass); float boilTwo = part.RequestResource(resourceTwoName, boilOffTwo); //print("NEAR Fuels!! chargeLoss: " + boilOne); //print("NEAR Fuels!! chargeLoss: " + boilTwo); } } } } Does anyone have any suggestion about how to proceed?

Initial release thread: http://forum.kerbalspaceprogram.com/threads/92642-0-24-2-More-Fuel-Types-%28aka-NEARFuels%29-VER-1-0 The release thread should be for general feedback and comments, all issues should be posted here.

Greetings, This is the first release version of More Fuel Types (or NEARFuels, as NathanKell put it). This pack should be stable enough for the general public, but I really need more feedback to hone it in. The whole thing has been a fun Labor Day Weekend project. This is a total fuel overhaul, designed to adapt to new mods, and to lack the need for specific engine configs. It has basic boil-off simulation, with the ability to use electricity to store your fuels for long periods of time. Major note from dev thread: As I have seen that there are a variety of fuel systems and tech trees, the eventual goal of this project must be to compile all of the config settings logic into a .dll so massive, that it will have appreciable gravity. The end game here must be to use this, to analyze parts on a per part basis, determine if mods are involved, and adjust settings procedurally. There is really no other way to do this. Truly, I invite people to come help on this project, because if I am left to my own devices, it may take till 0.26 to do such a thing. But this is really what needs to happen. Code needs to be written, which identifies what a part is FOR, what properties it HAS, and what dependencies it USES, and create a procedurally crafted modded config file for EACH PART. This must be the only way forward. I will continue development of the current setup for at least the next week, to make it play nice with most major mod deployments which include fuel dependencies, but then, I will be moving to the juggernaut .dll development only. Now that's out of the way... Disclaimer: This mod is meant to present a challenge, and to force you to make choices. This is not a pack of wonder fuels. Not all engines will be able to run on all things. This is INTENTIONAL. If you want more variety with no extra challenge, there are plenty of mods which can provide that. If you took a look at Real Fuels and thought, "maybe a simpler version would be nice", then this mod is for you. If you have a compatibility question, or want to know what I am adding next, please check the dev thread at the bottom. Also, some Squad parts are still broken . What this Mod is: -Add more fuel types to the game, to create a more dynamic experience -Integrates new fuel types as you progress through the tech tree -Creates issues with storing cryogenic fuels long term -Cryogenic storage systems, which consume electricity to refrigerate fuel -Works perfectly with KW Rocketry -Searches for engines and fuel tanks (even from mods*) and adjusts them accordingly -Full Procedural Parts integration -Sets up the groundwork for a better ISRU model -Integrates with the Community Resource Pack, so it won't break your mods -Is ready for full ORS compatibility *some parts mods use dependencies for tank switching, this is still a WIP Fuel Types: -Liquid Oxygen/Liquid Hydrogen - High ISP, but difficult to store -Liquid Oxygen/Methane - Lower ISP, but can be created in CO2 atmospheres (ie. Duna) -Liquid Oxygen/Kerosene - Lower ISP, but Kerosene is also Jet Fuel -Hydrazine/Aerozine - Lower ISP, but is inert, and Hydrazine can be used as Monopropellant -Liquid Hydrogen - This is now the only fuel type needed for NERVA engines -Hydrazine - This is now MonoPropellant -Liquid Oxygen/Solid Fuel - Thanks to Procedural Parts, procedural hybrid engines are now implemented. Higher performance, and higher price than simple solid boosters. Who to thank: AncientGammoner, NathanKell, Swamp Ig, and all the contributors to procedurals NathanKell specifically, for both helping me through the first steps with MM, as well as Real Fuels, which in no small way inspired me to write this (as well as his other work) RoverDude, for guidance on CRP Dr. Robert Zubrin, for further inspiration And most of all, those who have downloaded, tested, and commented, as they have shown me the way forward. Change Log: V1.0- First release! V1.1- Rebalanced boil-off and refrigerant numbers to take mass into account. This is a massive gameplay improvement, as a full orange tank takes nearly 120 ec/s to refrigerate! VAB and SPH still bugged though... V1.2- CRP now included on KerbalStuff Download V1.25- Boil-off code patched V1.3 Tentative B9 compatibility update! Download Materials: Source included in download. Here are the packages required for the mod: 1. Procedural Parts: http://forum.kerbalspaceprogram.com/threads/70676-0-24-2WIP-Procedural-Parts-Parts-the-way-you-want-em-0-9-18-Aug-6 2. ORS. This now includes the basics for ORS based Methane production on Duna: http://forum.kerbalspaceprogram.com/threads/64595-Open-Resource-System-(ORS)-Mod-Resource-API-version-1-1-0 3. The More Fuel Types Mod and ProceduralParts configs: http://beta.kerbalstuff.com/mod/133/More%20Fuel%20Types%20%28aka.%20NEARFuels%29 3.1 Manual Installation of 3 .cfg files for B9: You must manually copy three configs, included in this pack, to their listed B9 folders if you want to use those engines. MM does not have a good way of dealing with multi-mode engines yet. 4. CRP, on which the mod is now dependent (included now in above download, for those finding this on KerbalStuff alone): http://forum.kerbalspaceprogram.com/threads/89568-Community-Resource-Pack-WIP 5. This REQUIRES module manager if you don't already have it: http://forum.kerbalspaceprogram.com/threads/55219-Module-Manager-1-5-6-%28Jan-6%29 WARNING: This mod might break your saves! What to do after: Please, post, comment, suggest, and contribute! I need all the help I can get. I would love to be able to edit this to say "We need all the help we can get". If nothing else, test it out, and tell me what breaks. Dev thread: http://forum.kerbalspaceprogram.com/threads/92433-WIP-0-24-2-More-Fuel-Types-Adapts-to-new-mods-no-engine-configs-needed License: CC BY-SA 3.0 US: https://creativecommons.org/licenses/by-sa/3.0/us/ This is to comply with the license which applies to Procedural Parts. They have not endorsed this mod, but still, thanks guys!

Thank you kind sir, I was looking for just such a thing. I will let you know how it works for me.

I have been trying to debug an error, which seems to be caused by a FusTek .dll, which, from what I have read, is now deprecated. The following items are from the Unity player.log. PartLoader: Compiling Part 'CMES/Aero/BC-003/part (2)/PC_InflateHeatshieldL' (Filename: /Applications/buildAgent/work/d63dfc6385190b60/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KSP(50805,0xa18961a8) malloc: *** mach_vm_map(size=8388608) failed (error code=3) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug Receiving unhandled NULL exception Obtained 65 stack frames. Stack frames omitted. Missing method .ctor in assembly /Volumes/D DRIVE/KSP_osx_CRP/GameData/CMES/Hab/Plugins/FusTek_Sumghai.dll, type System.Runtime.Versioning.TargetFrameworkAttribute The class System.Runtime.Versioning.TargetFrameworkAttribute could not be loaded, used in FusTek_Sumghai Can't find custom attr constructor image: /Volumes/D DRIVE/KSP_osx_CRP/GameData/CMES/Hab/Plugins/FusTek_Sumghai.dll mtoken: 0x0a00000d I'm not sure how the new version of FusTek resolves this, although apparently they have moved to firespitter for some things. I will attempt to troubleshoot this further, but I figured I would put this out there in case anyone has a quick answer. A search for this FusTek_Sumghai.dll in this thread revealed nothing, but I admit I may have missed reading something. Thanks!

Good call. Something was showing a memory access violation in the player log. A sudo purge (I'm on OS X) cleared the issue. I can now no longer reproduce the issue. Thank you very much for the guidance. A fresh install confirms this. This was a transient issue, and has not yet showed itself again.

The net effect using this with say, TAC life support, is that the resources defined in TACs resource config conflict with those in the CRP config. This is what module manager, and unity, appear to be reporting in the log file, which I can post when I get home along with the reproduction steps. This results in nothing being loaded into the VAB (or the game for that matter) besides aerodynamic parts. I don't know if it is my Mod causing this, but deleting the TAC life support resource configs, from the TAC folder, solves the problem entirely. I have not modified the CRP folder contents or structure in any way. I will note, that I am using MM 2.3.1, which I have not seen deployed in any major mod packs. I acknowledge this couldbe an issue.

Having deployed the standard CRP, I have found that any existing resource definitions from the constituent mods(TAC, etc..) tend to break the game. Is there a fix which can be deployed for this, or do people intending to use CRP bear the responsibility of deleting these files manually?