Starwaster

"Put it in a box of rice": Advice often given to people whose mobile phones (or some other electronics) have gotten wet in the hopes that the rice will absorb all the moisture from the device and allow it to eventually be salvaged. Mods: Most of these were installed automatically as dependencies for Realism Overhaul. There's not much else in here that wasn't install as part of that package because this installation is for testing Real Fuels boiloff changes in an RSS environment, so it's intentionally sparse.

Then I don't know what to tell you. I just installed TAC through CKAN, made a Mk1 pod like you had, tank on top, fuel cell on that. launched and then right clicked fuel cell and click activate Maybe you should try putting it in a box of rice. Or maybe it's time for logs and ModuleManager.ConfigCache files.

@Wallygator Stupid question time. Did you try turning it on?

I'll install TAC and check it out.

Part b_cockpit_qs has a field in there called textureQuadname, which isn't a valid field for Part. In fact, that looks like something that belongs in a flag module. Example: MODULE { name = FlagDecal textureQuadName = flagTransform } Might be an incorrect animation name. Do the part's animations work? (All animations referenced by the animation module need to be configured correctly and valid in order for the animation code to render all DragCube's for each animated state) Part needs to have a proper collision mesh created in the Unity editor. If we have a mesh for that or can convert its .mu file and reexport, we can load it into the editor and have it try to rebuild a new convex mesh for both of those parts..

Yes they were. You don't get that message if they didn't deploy. And Mach 2.9 is too fast.

Not much to tell, several times a week someone would post a pages long treatise on what was wrong with the game (in their view) and how to fix it. This was back when it first launched. Back when the internet was just going mainstream even! Friend of mine paid $200 to score a beta disk off of someone. Fun times... fun times.

This reminds me so much of those "DEVS READ THIS NOW! I KNOW HOW TO SAVE ULTIMA ONLINE! HERE'S WHY!" that were so entertaining back in the day...

You're missing TAC Life Support which is a requirement because the fuel cell needs TacGenericConverter module. There's no fallback to any other generator or converter that I can see in the repo. (which sounds like it would be a good idea to me since not everyone wants ECLSS mods installed, but what the hell do I know)

I think (to some extent) that you're overthinking things a little. A lot of what you're saying could be realized through config changes. The actual code that would be needed wouldn't be terribly tricky and would amount to maybe 2-3 lines of code. (Plus a little more code to read the config changes that would be necessary to assign boiloff byproduct) Aside from what's already been discussed I think maybe a lot more of it is through FC draw than boiloff. I made a test craft roughly equal to what you had in your example though with half the LH2/LOX and after 12 days I still had 90L of hydrogen. Which is still a bit high but not to the extent of what you're seeing. Maybe I'll know more after you've tried the debug plugin I sent you.

@Oromis Well I've had a few bits of revelations here. I'm comparing all this to Apollo for a baseline and a few things occurred to me. One of which is that fuel cells don't use oxygen or hydrogen in liquid form. They use it in gaseous form. IRL, as the tank contents boiloff, they're kept (at 900 PSIA for O2 or ~240 for H2) either in the tanks themselves or in a surge tank. So that boiloff is likely to end up in the fuel cell instead of being wasted. (in fact, only SOME of the heat came from heat leakage. The rest of it came from an internal heater and the tank fan motor) Conceptually, liquid->gaseous conversion doesn't exist in Real Fuels as propellant is boiled off. It's just gone - though there was some discussion awhile back of maybe converting the boiloff into gaseous resource but there just wasn't a big enough demand to make it a priority.

There's a lot of errors in your log leading up to that crash, more than I'd expect from a pure stock installation. (though even in stock you can have errors) Before anything else you should verify your installation through steam. In Steam right click on Kerbal Space Program and click properties. Then click on the Local Files tab. Then click the button that says 'VERIFY INTEGRITY OF GAME CACHE...' It will take a few minutes. If any files are bad it will download and reinstall them. Bad doesn't necessarily mean corrupt either, there could be some files that didn't get updated for some reason.

You can apply it to big tanks but you shouldn't if your goal is realism. The SM tanks were modeled after Apollo's LH2 and LOX SM tanks and they're somewhat complex affairs: double walled vacuum bottles mounted on shelves inside the SM compartment. Additionally, thermal conduction is limited because of reduced contact area and some amount of radiation. There are practical limits as to size from an engineering and cost standpoint. None of those limitations are conceptually present in Real Fuels so there's no enforcement on size limits so there's nothing stopping you from making launch stages using service module tanks. IRL it would be impractical and costly at best and for very large stages maybe impossible. (I can't imagine doing something like that on a Saturn V scale) I'm not sure what the effect of that would be. I don't think PP shape has an effect on surface-surface conduction which is the only heat transfer when those service module doors are closed. (I think radiation is either non-existent or reduced for cargo bay contents. I can't remember actually)

Still working on the alternate configs for MFT/RF but it seems like there's still a lot of parts unaccounted for (with all the old-new additions)

Use a Service Module tank instead. Those assume vacuum bottles and/or vapor cooling.

I'm going to say just one thing on the whole renaming issue so I'll just leave this here, and I'm not trying to start any argument or anything but I just feel that this needs to be said. In game design you should never do anything without purpose, and that purpose should be well understood with a specific end result that is more beneficial to your end goals than it is detrimental. And while it is true that there is no guarantee of updates not being save game breaking, that shouldn't itself be a reason for making that change.

If that's the purpose, one could always latch onto manufacturer or use some other method

I'm not sure I understand the reasoning there; it's never been necessary before. I've been writing configs for RF practically forever and that sort of naming scheme has never been necessary or even of particular use.

I don't think the affected files were part of an actual release.

Use XSI instead. It's no longer being developed but you can still find downloads for it and it's got an interface closer to other modeling packages that are not-Blender You'll have to export it to something Unity understands which isn't hard. XSI supports Collada so it can export to anything. http://www.moddb.com/members/varsity/downloads/autodesk-softimage-mod-tool-75

@stali79 Bad news. When you added OPT_ to the name of every part (a move BTW that is save breaking, FYI) you also did it for everything else that had name = such as MODULE names, some animation names, science module experiment names, *GUINames, etc etc etc. ... And it could also break some of those things where case sensitivity matters since it looks like it also changed the case

Only one as far as I can tell but I'll go look at them again.

@stali79 Bah! Ok, there wasn't anything wrong with the animation names it was only the case sensitivity issue with things like animationName, startEventGUIName, actionGUIName, etc etc. So I've got most of the animations working again. I think there's a few more parts I need to go look at though. Will do a PR later

Ok here you go. Just stick a MODULE named ModuleFindAnimations in any part you want to grab the animation names from (actually grabs the default clip name from each animator which is the same as what gets passed in animationName for just about anything in KSP that uses animations. CAVEAT: It's supposed to reveal ALL animations but it's missing in some cases. I suspect because what I'm thinking are separate animations are actually separate clips on the same animation and I'm only grabbing the default clip. (which is usually what you want) Example Usage https://www.dropbox.com/s/hnbmr1po2cst3pz/FindAnimations.zip?dl=1 Source code below in the spoiler. This is public domain so do whatever the heck you want with it. If you find it changes your life and you win at Life and stuff because of it then remember me and say a kind word about my dear departed Melificent, etc etc.

Can't yet. It was late I cobbled that together and I forgot that the function I was using is returning something different than the animation name... After some sleep and coffee I remembered how that works. Gotta figure something else out.