[1.8+] Real Fuels

[regex]

Hi guys, running with Win64. Can I get the .dlls to v5.3 please? I've tried the unfixer. dual booting Linux is impracticle for my setup. I just need working .dlls for version 9.1 for Win64. Thanks!

The current version of Real Fuels is 9.1 for KSP 0.90, I have no idea what v5.3 is supposed to be about.. Also, this mod hasn't been updated for 1.0.2, please be patient.

[pditty8811]

The current version of Real Fuels is 9.1 for KSP 0.90, I have no idea what v5.3 is supposed to be about.. Also, this mod hasn't been updated for 1.0.2, please be patient.

Perhaps I should be more clear. I'm using KSP x64, which does not exist post v0.90. I would like a Real Fuels .dll that is compatible with Win KSP x64 v0.90. If someone has such a thing that would be great. When I load v0.90 it gets stuck on loading "proceduralSRBRealFuels". I've tried the unfixer but that does not help, or perhaps I am unfixing the wrong .dlls.

Thanks.

[Cerebrate]

Yeah, that's not the sort of problem the unfixer will unfix. It does one thing and one thing only, which doesn't address any of the issues that may cause actual mod-x64 problems, which in turn is why it exists as a for-experimental-use-only crack. And having said that, may I now take a moment to remind you - and, indeed, anyone else passing by - of this part of the x64-unfixer documentation:

"Also, if you patch their mods, the original authors of those mods can't support them either, and if they supported them on x64 in the first place, this tool would be unnecessary.

Anyway, DON'T SEND THEM SUPPORT REQUESTS FOR VERSIONS YOU'VE PATCHED, OKAY? THIS IS A USE-AT-OWN-RISK TOOL."

I put that in there for a reason, m'kay.

(And if you want to debate that reason, please start a new thread or PM me, because part of that reason is to not clutter up devs' threads with x64 wibble they don't want. I won't be respondin' further here, to that end.)

-c

[pditty8811]

Yeah, that's not the sort of problem the unfixer will unfix. It does one thing and one thing only, which doesn't address any of the issues that may cause actual mod-x64 problems, which in turn is why it exists as a for-experimental-use-only crack. And having said that, may I now take a moment to remind you - and, indeed, anyone else passing by - of this part of the x64-unfixer documentation:

"Also, if you patch their mods, the original authors of those mods can't support them either, and if they supported them on x64 in the first place, this tool would be unnecessary.

Anyway, DON'T SEND THEM SUPPORT REQUESTS FOR VERSIONS YOU'VE PATCHED, OKAY? THIS IS A USE-AT-OWN-RISK TOOL."

I put that in there for a reason, m'kay.

(And if you want to debate that reason, please start a new thread or PM me, because part of that reason is to not clutter up devs' threads with x64 wibble they don't want. I won't be respondin' further here, to that end.)

-c

Thanks for your kind words. I'll be sure to come to you if I need any further help with unfixer and getting RF to work with Win x64.

[regex]

Perhaps I should be more clear. I'm using KSP x64, which does not exist post v0.90. I would like a Real Fuels .dll that is compatible with Win KSP x64 v0.90. If someone has such a thing that would be great. When I load v0.90 it gets stuck on loading "proceduralSRBRealFuels". I've tried the unfixer but that does not help, or perhaps I am unfixing the wrong .dlls.

You'll probably have to compile it yourself. I doubt NathanKell would be willing to do that given that he's added checking routines to all the DLLs he manages and I most certainly will not since I refuse to support Win x64 issues.

One thing you might want to try, though, is checking the log file for any problems with a Module Manager script, I've had hangs when it can't find a resource.

[jrandom]

You'll probably have to compile it yourself. I doubt NathanKell would be willing to do that given that he's added checking routines to all the DLLs he manages and I most certainly will not since I refuse to support Win x64 issues.

Oh hey, this is relevant to my interests! I'm going to be attempting to make a Linux partition this weekend for x64 Kerbal -- will I also need to compile plugins like this (when they're ready for 1.0x) and manually disable the 64-bit check, or do they only check for 64-bit Windows operation?

[regex]

Oh hey, this is relevant to my interests! I'm going to be attempting to make a Linux partition this weekend for x64 Kerbal -- will I also need to compile plugins like this (when they're ready for 1.0x) and manually disable the 64-bit check, or do they only check for 64-bit Windows operation?

Compatibility checkers historically only ensure that they disable on Windows machines; Real Fuels (and most other mods) works just fine on Linux x64. Mod authors will generally support Linux x64 because it isn't a complete pile of random crashing, errors, and grief.

[jrandom]

Compatibility checkers historically only ensure that they disable on Windows machines; Real Fuels (and most other mods) works just fine on Linux x64. Mod authors will generally support Linux x64 because it isn't a complete pile of random crashing, errors, and grief.

Fun fact: The only reason I even have a Windows machine is my Mac is too old to run single-thread kerbal physics for non-trivial ships at anything but horrible framerates. I went out and bought a gaming laptop just for KSP. Had I known at the time that KSP ran on Linux, I never would have cursed myself with Windows 8.1.

[Warshawski]

I like 8.1, myself. It's not 7, but it's good enough given that I couldn't acquire 7 for my new build.

To each her own.

I'm looking forward to seeing this in 1.0.2! I'm having a ball in .90 with it right now - why on Earth did it take me so long to discover this?!

[Maeyanie]

Fun fact: The only reason I even have a Windows machine is my Mac is too old to run single-thread kerbal physics for non-trivial ships at anything but horrible framerates. I went out and bought a gaming laptop just for KSP. Had I known at the time that KSP ran on Linux, I never would have cursed myself with Windows 8.1.

You can install and run most Linux distros on a USB stick. Boot and load times aren't great, but it saves having to worry about repartitioning your hard drive and all that, and you can get a good enough one for around $10 these days.

[jrandom]

You can install and run most Linux distros on a USB stick. Boot and load times aren't great, but it saves having to worry about repartitioning your hard drive and all that, and you can get a good enough one for around $10 these days.

I spent a huge chunk of today trying to get linux to dual-boot on this thing, but it's an MSI laptop with an uncooperative BIOS, and its USB transfer speeds are ridiculously slow. I have some Windows-only software at the moment, so I can't wipe the laptop and have it just be a linux machine.

So I did what any professional software dev with no car and no other major financial responsibilities and a cat as his only dependent would do -- ordered a new built-for-linux laptop. (This MSI thingy was getting a bit long in the tooth anyhow. Wasn't exactly state-of-the-art when I bought it two years ago. Makes for a useful Amazon Prime media center, though.)

[FreeThinker]

When you'll start working on it - PM me. Will do what I can to help. Realism is great, as it gives game more challenge and thoughtfulness. And stock "ISRU" extraction of mean-to-be-hydrocarbons from crust everywhere gives me a butthurt.

Notice for KSPI, I just added CO2 Electrolysis, Water Gas Shift and Reverse Gas Water Shift. I intend to add more usefull ISRU processes and make it more generic and general use

Edited May 11, 2015 by FreeThinker

[curiousepic]

I may have something at some point in the future (I scrapped a lot of it because I realized I was going terrible out of scope) but it will mainly concern itself with processes and equipment that a realistic lander could carry. Massive refineries and 3D printing are completely out of the question for anything I do, as well as (probably) complex hydrocarbons. Collecting life support essentials and simple fuels (methane, LOX, LHyd, nitrogen, argon) will be the name of the game.

I assume this would encompass mining water from asteroids as well? It would be interesting to contend with H2O in both its states now that we have a more detailed thermal system.

[regex]

I assume this would encompass mining water from asteroids as well? It would be interesting to contend with H2O in both its states now that we have a more detailed thermal system.

I haven't really started designing this yet, and I'm not entirely sure I'll get around to it (note the qualifier in my previous post), but yes, water from asteroids will be A Thing if I do. The exact processes will probably be abstracted to a converter/extractor/heater with a collector of some sort. Alternatively, you simply punch a drill into an asteroid and get water (assume the drill heats it up, runs it through a filter, and pumps it into a tank). Aside from dedicated converters (Sabatier, reverse water-gas shift, etc...) the collector will most likely abstract the interim process because having a "holding resource" is stupid, IMO. Honestly, we'd need "holding resources" for all the asteroid types, Martian ice, Martian regolith, etc... and that just gets out of hand fast. And if we're going to abstract down to "regolith" then we might as well deal away with the holding resource to begin with. Besides, the more interesting part of ISRU is converting the water into other products.

[NathanKell]

Some notes on RF v10.0 (forthcoming).

RealFuels is about to get a lot real-er. To do that I refactored both AJE and RealFuels to depend on the same base class, SolverEngines. It borrows AJE's approach, where there's an engine solver that takes current flight conditions and reports the thrust and fuel flow. In turn ModuleEngines/FX is replaced by ModuleEnginesSolver (or by an engine module that derives from that). As it stands, the solver for rocket engines isn't really doing much, just replicating the existing behavior of engines. In time it will include its own ullage simulation, support for handling different engine cycles, correct calculation of Isp from area ratio, chamber pressure, and propellants, etc.

One note: ModuleEnginesSolver derives from ModuleEnginesFX. That means that engines that don't have EFFECTS nodes won't have FX. This isn't an issue for RO because we're replacing all engine FX anyway, but for RF Stockalike you might want a fallback config (or just require Hotrockets). An example fallback config is here although it could be improved to use MM variable support to pull the oldstyle FX name instead of just using two presets.

[Senshi]

Can't wait for RF (and AJE). I tried KSP 1.x without it, and it's just too bland and easy...

A more open technical approach probably is a good thing (albeit a lot of work?), even if we as the "end user" won't notice much difference, I expect .

[Wuwuk]

Some notes on RF v10.0 (forthcoming).

RealFuels is about to get a lot real-er. To do that I refactored both AJE and RealFuels to depend on the same base class, SolverEngines. It borrows AJE's approach, where there's an engine solver that takes current flight conditions and reports the thrust and fuel flow. In turn ModuleEngines/FX is replaced by ModuleEnginesSolver (or by an engine module that derives from that). As it stands, the solver for rocket engines isn't really doing much, just replicating the existing behavior of engines. In time it will include its own ullage simulation, support for handling different engine cycles, correct calculation of Isp from area ratio, chamber pressure, and propellants, etc.

One note: ModuleEnginesSolver derives from ModuleEnginesFX. That means that engines that don't have EFFECTS nodes won't have FX. This isn't an issue for RO because we're replacing all engine FX anyway, but for RF Stockalike you might want a fallback config (or just require Hotrockets). An example fallback config is here although it could be improved to use MM variable support to pull the oldstyle FX name instead of just using two presets.

Limit of ignitions in AJE/RF?

[Senshi]

If limited ignitions will be added, please make it optional. Not everyone likes that extra challenge. I like it in my "hardcore RO" setup, but not in my more lenient Kerbin-scale game.

[smartdummies]

In time it will include its own ullage simulation, support for handling different engine cycles

This sound like EngineIgnitor is being incorporated into RF

[Maeyanie]

If limited ignitions will be added, please make it optional. Not everyone likes that extra challenge. I like it in my "hardcore RO" setup, but not in my more lenient Kerbin-scale game.

Even if there isn't a built-in "off switch" it would be easy enough to disable with a tiny ModuleManager config file.

[FireFaced]

I'm tempted to download the RF repo and test it for myself. I probably shouldn't.

[angelatthetomb]

FireFaced, I've been using it since yesterday. It seems to work rather well with the old .9 Stockalike engine packs. No major problems so far.

[Cerebrate]

FireFaced, I've been using it since yesterday. It seems to work rather well with the old .9 Stockalike engine packs. No major problems so far.

Hm. Which version of the stockalike pack are you using? When I try to use it (2.1.4) with my build of 10, KSP freezes during loading when it gets to the LV-N, unless I edit the config for "nuclearEngine" out of the Stockalike_Squad.cfg and remove Squad_NTR_modularEngines.cfg.

-c

Edited May 14, 2015 by Cerebrate

[NathanKell]

RF v10 uses CRP for resources, so you need to change the configs of any engines that reference the old NTR resources (U235Rods etc) to the new ones (EnrichedFuel and DepletedFuel IIRC, but check CRP).

[Cerebrate]

RF v10 uses CRP for resources, so you need to change the configs of any engines that reference the old NTR resources (U235Rods etc) to the new ones (EnrichedFuel and DepletedFuel IIRC, but check CRP).

Thanks muchly!

(Having checked CRP, I note for any passing readers that it's "EnrichedUranium" and "DepletedUranium".)

-c