NathanKell

That is correct, they are, in effect, [I]nearly as efficient as the optimum bell for a given pressure, at any pressure[/I]. Which is precisely what KSP does, and apparently is enough to offend the "no! that means equal efficiency everywhere!!!" crowd. :]

just remove isVisible = False from the IntakeAir entry in GameData/Squad/ResourcesGeneric.cfg if you don't like it. That said, that display showing 0 is *not* indicative of you being likely to flame out from insufficient intakes. In fact, the only case it will not be 0 is if you have [I]more[/I] intakes than you need. (Not a bad position to be in, true, but the bar being at 0 isn't necessarily a worry anymore). The reason the change was made in 1.0.5 was because I quite totally rewrote the intake module, so the info displays for it *do* make sense now, including flow rate.

Sure. [url]http://answers.unity3d.com/answers/508835/view.html[/url] is what I based the excel formula off, IIRC You need to set up the keys on either side of your desired value, and your desired value. Then add some columns to calculate the in-between values, and then calculating the final value should be fairly simple. Note that for a given key = x y z w that's time, value, inTangent, outTangent respecitvely.

Pecan: Again, it depends on the air density. If the air density in the bow shock, when combined with the air temperature, leads to a lower radiation temperature than your own vessel, you will be a net loser of heat via radiation. If not, you will gain heat. Note that in real life it's only on lunar-level reentry speeds that you gain significant quantities of heat through radiative flux; for LEO reentries you'll keep a negative (i.e. outflux > influx) radiative balance due to your thermal control system quickly heating up to 1800+ K. Srpadget: Yep, same deal in KSP. If the bay's closed, all that will happen is you radiate heat...into the bay part itself. :]

set kPaThreshold = (desired threshold for intake starting, in kPa) like, say kPaThreshold = 0 (this goes in the MODULE).

How the heck is RealPlume modifying part sizes? It's an FX mod!

yeah, no. Modifying the readme doesn't change your KSP, it changes what CKAN _thinks_ your KSP is. Please don't try to ask for support for hacks like that.

I don't know much about ions, tbh, better ask someone better informed. :) Monoprop is presumably hydrazine. IIRC that's what I based its specific heat off. SolidFuel is going to be something like HTPB as binder, probably.

Guess what guys: the aersopike ingame _does_ match theoretical aerospike performance. It removes [I]nozzle losses[/I]. It does not magic away [I]physical laws[/I], like when the atmosphere pushes back at you, you generate less thrust. Period. End. The aerospike is modeled, ingame, to have very nearly the chamber pressure of the Mammoth (and now the Vector). That means it has nearly as good sea level Isp as them. But it [I]also[/I] has nearly as good vacuum Isp as the Poodle. And it loses very little Isp, in comparative terms, at Eve's surface (5 atmospheres of pressure), something that can be said for no other engine.

RO has had offset capsule CoMs for...basically ever. It uses the plugin asmi wrote for BobCat for his Soyuz, more or less.

The plasma shockwave is only towards the bow, and even there it's at [I]very low density[/I]. Recall that radiative flux depends on the solid angle of the object radiating (from your POV), and despite the air at that altitude being very hot, there just isn't very much of it so the solid angle is, err, sparse. Many, many RV designs rely on radiative cooling. Now, as to radiators in bays: that won't work too well, because they'll just radiate into the bay, so there will be no net gain or loss of heat.

And as I said before, engines flame out long before that, so it doesn't matter, and at 36km the resource _is_ indeed effectively not present (36km Kerbin -> 45km Earth -> 150,000ft). You can of course tweak the minimum threshold, in the module, if it will make you feel better to have intakes producing a trickle of a resource no one can use. :)

[quote name='KerikBalm']I don't assume its linear, its just a presentation of the fixed points specified in the .cfg file, its easier to read with lines connecting the data points, than to just look for similar color and shape symbols on a scatterplot. Also I wasn't sure how to use the tangent, and for the graphing program I have that can graph equations rather than just data points... I don't know how to have it only graph specific intervals using different equations. I suppose I could have looked up how to use the tangents, used the graphing program to generate data points, and then graphed those in excell... but I was too lazy as noted by Right, its enough to get the jist of it. If someone wants to put more work in, and do the graphs including the tangents, I'd be interested in seeing the results... because they would be more accurate of course.[/QUOTE] I would definitely suggest evaluating a few more points. indeed it's very possible to write the evaluator as an excel formula. Here's the Panther in Wet mode, for an example. You can definitely see how the linear interpretation can severely over- or underestimate peformance. [img]http://i.imgur.com/P9nobGC.png[/img]

Debug Toolbar->Physics->Aero->Show Aero Data will show you the areas and coefficients for each drag cube face, on the part right-click menu.

Well, if you wanted to make the densities match up, you'd change the density of Oxidizer to 0.00725 and the density of LiquidFuel to 0.0045 and then make all tanks hold only 85.1064% each of the LF and OX they currently do. That would standardize on 5 liters per unit of LF and Ox, and keep total wet:dry ratios (and total wet masses) the same as they used to be. And yes, it is hypergolic and storable, which would explain why reignitons aren't a big deal and why nothing boils off. Note that, interestingly enough, a volume ratio of 55:45 does actually lead to a correct mass mixture ratio for NTO/Aerozine (with the above densities)!

So would everyone. Problem is you can't, because it's not consistent. :P

Yes, when I woke up in the morning three weeks ago my overriding concern that day was [I]I must break Chaka.[/I] Curses, my evil plot was revealed! ...oh wait.

As I said privately, I will say publicly: AFAIK 1.0.5 is using exactly the same Unity version as 1.0.4, and neither I nor (AFAIK) anyone else changed how KSP handles colliders. I'm as mystified as you are as to why this is only an issue now, although it certainly is, as I mentioned, indicative of something that was a problem before but that Unity let you get away with for whatever reason.

Those warnings are about colliders, not meshes per se. If you're using your visual mesh as a collider, well, that's bad practice before and it's bad now. Notice it says hull. Not mesh, hull.

Syntax is identical, just replace ModuleRCSFX with ModuleRCS.

Asking for help Here's our 1.0.5 checklist. Assistance would be greatly appreciated. https://github.com/KSP-RO/RealismOverhaul/issues/671

RSS is not out for 1.0.5 yet If you're trying to install it into 1.0.5, that's your problem right there. mole55: As the readme states, you unzip the textures zip and merge GameData into your KSP folder (i.e. merging its contents with your current GameData, so by the end, your GameData folder includes, in addition to whatever it already did, the new folder RSS-Textures).

RO isn't out for KSP 1.0.5 yet.

As has been stated quite a few times, the Isp stats, and the specific heats, are reflective of NTO and Aerozine 50. The densities are not, but they're grandfathered in.

You really need to use the tangents. Your graphs are shaped all wrong from not including them, you can't just assume it's linear... See http://forum.kerbalspaceprogram.com/threads/93332-INFO-KSP-floatCurves-and-you-the-magic-of-tangents and http://answers.unity3d.com/questions/464782/t-is-the-math-behind-animationcurveevaluate.html