SpecTRe-X

Oh dear, I understand now. I had myself all turned around. I appreciate your patience and taking the time to iron me out!

I found that out when I tried using it after posting yesterday. I was able to fix it though, by using a dynamic scale height which I estimated by graphing the known altitudes/ATM values from the kerbin table in the wiki, then graphing my desired altitude. I found that if I slid it along the altitude line that when it lined up to the curve that I get a close enough scale height factor to use in the calculation (since the scale height appears to be nonlinear). Based on that, I was able to find the scale height and ATM value for my desired 10,833m altitude (which comes to about 5714 and .150 respectively). Of course, the above was rather pointless if I'm understanding you correctly because I need the density and not pressure. I was under the impression that the first number in the atmCurve table was atm pressure which told ksp what altitude was desired and then ksp looked up the density based on the input pressure for the altitude. It doesn't help that I've been trying to do this when I'm already tired but I've come across conflicting explanations of what the numbers in the atm and velCurve tables represent and what's worse is none of what I found was posted as "official", just findings of random forum posters. I'll have to come back to this after I've had some rest.

Thank you so much! It never occurred to me that it was a constant and not a placeholder. 1) That's what I had figured. 2) Right, but the curve table in cfg files uses the "atm" value to denote altitude for the atmCurve, from what I've read. If the equation I posted in the OP is still accurate then I can use that in a spreadsheet since I now have "e". (If it proves to be no longer accurate I'll definitely use that calculator!) 3) Yeah, I'm going to have to adjust that. I haven't even begun changing the velCurve tables yet, I wanted to get the atmCurve tables done first. Thanks for the help Red and Nathan! I could still use some insight with making the throttle controlled jet exhaust nozzle lighting effect work for both modes though.

I'm not sure if this is the right section so if this is posted in the wrong spot please move it. The forums seemed to change since my last posting lol. The other day a friend who plays KSP asked me to alter some files for him because he's squeamish about doing it himself. He told me what he wanted changed and to about where he wanted it performance wise. Basically he wants a more realistic version of the broadsword from the Mk IV system mod and a dual or tri mode Mk 2 TurboRam Jet ("screamjet") from the OPT mod. For the broadsword alterations I'm looking for a formula or equation to calculate specific ATM pressures for custom altitudes not listed here: http://wiki.kerbalspaceprogram.com/wiki/Kerbin#Atmosphere ; such as 32,500 ft. I found this equation Formula: ATM * e ^ ( -ALTITUDE / SCALE ) but the post didn't specify what "e" is supposed to be or if this even still works (I read that there may not be a simple equation for this anymore). I've spent the last ~5 hours searching here and google and found nothing that seems to make sense for this. For the Mk2 turboram, I can't seem to get the exhaust nozzle lighting to work for both modes. If I place it like this..... MODULE { name = ModuleEnginesFX engineID = TurboJet thrustVectorTransformName = thrustTransform exhaustDamage = True ignitionThreshold = 0.03 minThrust = 0 maxThrust = 650 heatProduction = 291 useEngineResponseTime = True engineAccelerationSpeed = 0.2 engineDecelerationSpeed = 0.4 useVelocityCurve = False flameoutEffectName = flameout powerEffectName = running_thrust engageEffectName = engage disengageEffectName = disengage spoolEffectName = running_turbine engineSpoolIdle = 0.05 engineSpoolTime = 2.0 EngineType = Turbine PROPELLANT { name = LiquidFuel resourceFlowMode = STAGE_PRIORITY_FLOW ratio = 4 DrawGauge = True } PROPELLANT { name = IntakeAir ignoreForIsp = True ratio = 9 } atmosphereCurve { key = 0 7000 0 0 } // Jet params atmChangeFlow = True useVelCurve = True useAtmCurve = True machLimit = 4 machHeatMult = 3.0 velCurve { key = 0 0.6 key = 0.2 0.8 key = 1.36 0.9 key = 2.0875 1.306206 0.558359 0.2083685 key = 2.474524 1.870126 1.621842 1.29743 key = 2.945652 2.160394 0.3836924 -0.04622887 key = 3.842887 1.940503 -0.2246427 -0.2246427 key = 6 1.5 key = 7.5 0 } atmCurve { //Airflow vs max thrust? key = 0 0 key = 0.005 0.3 key = 0.03469022 0.8916956 19.92897 0.5922443 key = 0.2 1 key = 0.3 1 key = 1 0.6 } } MODULE { name = FXModuleAnimateThrottle ThermalAnim = engine_light dependOnEngineState = True responseSpeed = 0.01 } I only get the throttle controlled lighting for the air breathing mode. If I place it anywhere else it is either always on or always off for both modes. My second question for this engine is: Is it possible to set a tertiary mode in the below module to allow for a LF/O closed cycle engine option alongside the turbojet and ramjet for use in an SSTO or would the tertiary setting not be recognized? MODULE { name = MultiModeEngine primaryEngineID = TurboJet secondaryEngineID = RamJet tertiaryEngineID = Closed-Cycle } Hopefully you guys can help me out with this, I've hit a dead end with the first two issues.

So after a bit of experimenting this is what I've come up with Running KSP in a VM linux resulted in usual CPU usage across 4 available cores, usual gfx card usage, good ram usage, and poor overall fps performance. I attribute the above to the low amount of ram that VirtualBox allows you to allocate for 3d acceleration. Running KSP in 64bit mod with the OpenGL command line flag resulted in usual fps and good ram usage though vehicles behaved erratically. Often times clipping into the launchpad/runway. Running KSP in 32bit mode with the OpenGL command line flag had similar results without as many clipping incidents. Ram usage was more saturating with KSP using around 34% (~5.4Gb) of available ram (16Gb) the system consumed ~22% - KSP. Played for 5 hours straight with no crashes or major glitches. I wanted to test with VMWare too but the program set you need to run a Guest on Host with virtualized passthrough (something they call vSGA) requires View which comes bundled with Horizon which would set one back just under $4,000 USD. All in all it was rather enlightening, though I'm not entirely sure KSP is worth the $30 investment at the moment even with the mods. Between the bugs and glitches I've seen combined with the lack of proper scaling and the maze of intermod compatibility one would need to sort through it's just a bit more than I'm ready to undertake just now. Perhaps if this game is ever finished and I'm still around I'll dust it off and see what's new. Until then I'll reset A:\ and scrub these loaned KSP files from my rig. If anyone has questions I'd be glad to answer, otherwise I'll see you on the other side, SpecTRe