lordkrike

Would you be interested in getting help from the community to support it? I didn't see a github link.

Getting this thing off of the runway is a feat of aerobatics, and my only "landing" recovered only the cockpit and a wheel. But it goes fast! And on a single, standard jet engine! My engine and intakes look funny because of Ven's part revamp. They're the stock basic engine and intake.

I got a craft to mach 2.07 using the basic jet engine. I'll post some pictures in a moment. Minimizing trans-sonic wave drag is really, really important.

Good to hear. Thanks for your hard work!

Cybutek - just throwing it in there; thanks for your hard work. Looking forward to the patch.

Classes are determined by the Kerbal's name. You can't change their name without potentially changing the class. The same thing always happens even if you edit your persistence files directly. As much as I want Pokey Kerman to be a pilot, he will always be a scientist. Basically, it's not a bug, it's a feature.

Jeb says he really likes the sounding rockets as they are. It took 16 SRM-S. I think perhaps the issue is that they have realistic TWRs (nothing else in Kerbal really does) and that Kerbin is so extremely small compared to earth that orbital velocity is just so much lower. Edit: that is, of course, presuming one thinks there is an issue. I think they're fun as-is.

I've encountered the exact same bug. Do you use RealChutes, by any chance? If so, try deleting Stock_RealChute_MM.cfg from GameData/RealChute/ModuleManager. RealChutes has a bug that causes this exact issue with stock chutes. Deleting the MM config for them in the RealChutes folder fixes the issue, but reverts them to stock behavior. If this is the case for you, just stick to using the RealChute parachutes.

64-bit software does not inherently have higher-precision floating point arithmetic. At the moment, KSP uses 80-bit floating point arithmetic, which is standard double precision. Most CPUs are optimized to do that sort of computation very quickly, despite the weird bit size and without regard to the operating system's bit-size architecture. tl;dr you'll have more memory space, maybe, but that's really the only advantage. edit: ninja'd!

Your dropbox appears to be nuked already. Could you please rehost somewhere else?

Fractal: There is something pretty wrong with the emissives for the Small Radial Radiator and the Radial Radiator. I was wondering why my recently purchased laptop was chugging along when I checked the output_log.txt to find hundreds of thousands of this line: The file gets huge, because for every frame it has a small radial radiator or radial radiator in the flight scene it throws this... well, not even sure it's really an error. But it's specifically those two radiators (I imagine they share the same emissive settings). All the other radiators work just fine. When I load up a craft with one of those in flight it just does this and slows my laptop down by quite a bit. My output_log.txt was up to 50MB. 50 MB of that line over and over again. :-)

That is precisely why KSP uses a local reference frame for loaded objects. As for objects on rails, their motion is determined by a time-dependent function, and will be unaffected.

Thank you. That sure was irritating trying to track down the issue.

@WaveFunctionP: I got very tired of seeing the typos in the part descriptions, so I've submitted a pull request that should mostly fix the random capitalization, misspelled words, and funky grammar. :-) Oh, and the "partical bed" reactor is now a pebble-bed reactor. It also correctly names the gas cromatograph experiment. I was confused as to why "measure magnetosphere" was coming up twice on my craft.

Alright, thanks to Raptor I updated the .cfg file. I've set up a new release for anyone out there that is interested. You can get it from Raptor's github here. Note that the atmospheric stuff is very untested, but the converters should work just fine. Changes for v0.1.2: Included atmospheric resource configs. Refinery split into three modules: Refinery C produces hydrocarbon-based bipropellant fuels and LOx. Refinery N produces nitrogen-based bipropellant fuels and N2O4. Refinery H produces LH2 and LOx. Distillery split into two modules: Distillery MON produces mixed oxides of nitrogen. Regular distillery produces everything else. Chemical production ratios tweaked. If you're out there and using this, please give us feedback!

Just a modulemanager config. I can put a :NEEDS[RealFuels] in there just to be safe if you like.

Cool beans. I just wanted to make sure adjusting them was kosher.

I have noticed that for Karbonite's atmospheric resource definitions every key has the same name of "AtmosphericKarbonite". Is that for a particular reason, or is it a bug? Also, I am curious as you how you feel about RealFuels' 1L as opposed to 5L volumes, and how they affect unit densities. Basically anything using this pack that uses RealFuels would need to adjust all of their densities to keep everything to the same scale.

I also fixed the atmospheric karbonite issue. I think. Haven't tested it, but it should work, and if it doesn't it probably won't break anything. Famous last words.

Fair warning: I'm a mathematician, not a chemist. But sure! @Raptor: Unfortunately, LibreOffice Calc is just not as good as Excel. It won't let me leave line breaks inside cells that I edit (but the ones you did in Excel work just fine -- thanks, Obama). Everything just ends up looking like a giant one line mess. It should end up looking like this: (I added a tiny bit of error checking) I wrote up a file to add the necessary cloned parts. Didn't take long. I'll push it along with the new spreadsheet, but if I change the recipes themselves it will look like hot garbage. Hopefully you can just copy and paste what's above. That same first line should also work for column C if you change the 250s to 125s. Oh, and I also quadrupled the energy cost for making liquid hydrogen. As always, it can be adjusted as needed. Edit: I'm not sure why it's adding a space in the word "distiller". I swear it's not here in the raw. Dobbel Edit: Thoughts on changing the shortname of Kerosene from Kero to RP-1?

Also, I found the molecular structure for this stuff pretty interesting. It looks like it would be a pretty terrible fuel, though.

Sarbian - When will the pony arrive?

Thoughts: The distiller should not be able to produce any cryogenic chemicals (liquid oxygen, liquid hydrogen, and liquid methane -- note that liquid ammonia, while technically moderately cryogenic, has a pretty reasonably high boiling point). The thought process is that it could potentially capture the gas, but has no means to cool it enough to change it to a liquid state. As far as splitting the distiller's menu, we could have one distiller version that produces specifically MON. I like that split because MON isn't terribly useful except for niche realfuels settings and it could also be justified by having the equipment to get precise mixtures of nitrogen oxides. For the refineries, we can't do a cryogenic/non-cryogenic split, or you end up with a somewhat useless refinery that can produce kerosene but no LOx. If it can produce LOx, it can produce at least liquid methane (though potentially not hydrogen). I think a better way to split them is into nitrogen and carbon based fuels. So, one refinery would produce: Aerozine Hydyne MMH UDMH Liquid Ammonia Of course, this still runs in to the issue that you would need a distillery to produce N2O4, so we could also allow that to be produced here. The other refinery version would produce: Kerosene Syntin Alcohol Liquid Methane LOx With liquid hydrogen being the man out. It can either have its own, special refinery (to illustrate the difficulty of cooling hydrogen to cryogenic temperatures) and not be allowed as a byproduct at all, or just be tacked on to both other types of refinery. Personally, I prefer the idea of having it be its own thing. Also, sorry, with the new release of interstellar I'm taking a break from RealFuels. I'll keep working on this because I find it fun, but I won't be doing much testing. I won't change anything until there has been some discussion, obviously. Edit: You can see an example spreadsheet here. I don't want to do a pull request until I'm sure we're on the same page. Reverting is a PITA in my opinion.

It seems you removed the .xls from the repo all together. Edit: Derp, nevermind. I see you moved it.

I mean, it works, but we may want to work on this... If you want to keep all of the options, we will have to split the refineries/converters into separate machines - for example, one refinery does hydrocarbon bipropellants, and a second copy does nitrated bipropellants. I'm not even really sure how to split the menu for the distillery. If we're removing some, there are a few less useful candidates there. Hydrocarbons + N2O4 are top of that list (not matched to their oxidizers), followed closely by the O2 + hydrocarbon options (if you're topping off your tank with fuel you won't care when you move to top off your oxidizer that it gives you yet more fuel that you can't store anyway). The H2 + O2 = H2O2 and hydrolysis modules aren't terribly useful at the moment and at present nothing uses MON. A combo we may want to consider adding is kerosene + HTP. There is at least one engine in your pack that uses that combination. Also, the fancy modulemanager config for removing oxidizer and liquidfuel and monopropellant doesn't work. I switched back to just removing the 1st and 0th index modules from anything with a USI_Converter.