SpecTRe-X
Members-
Posts
11 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by SpecTRe-X
-
atmCurve formula for 1.0.4
SpecTRe-X replied to SpecTRe-X's topic in KSP1 Gameplay Questions and Tutorials
Oh dear, I understand now. I had myself all turned around. I appreciate your patience and taking the time to iron me out! -
atmCurve formula for 1.0.4
SpecTRe-X replied to SpecTRe-X's topic in KSP1 Gameplay Questions and Tutorials
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. -
atmCurve formula for 1.0.4
SpecTRe-X replied to SpecTRe-X's topic in KSP1 Gameplay Questions and Tutorials
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
-
Yeah, only 50 mods lol So what kind of graphical glitches are we talking about when running KSP in opengl?
-
Sorry, I meant to type driver and not drive. I'll go back and fix that now. I Do have a UEFI bios but haven't fooled around with the secure boot option yet so that's not a big concern. Kamuchi, I actually installed ubuntu 14.04 inside virtualbox earlier today quite painlessly while I was waiting for my mobo waterblocks to arrive. I build my own rigs and rigs for a certain segment of others so I know how to at least format and partition drives in windows . That being said I have a small drive I can blank and install ubuntu on if I absolutely need to dual boot. I'd also cut all my other drive connections, both networked and local, before doing so, as I usually do, just to be safe. I also don't run multiple partitions on the same drive so that takes care of that. I'm fairly anti-steam so I'd go through the KSP store. It's my experience that games bought through steam need steam running/installed to work which makes steam the drm. I don't know if that's the case with KSP but having access to only one version seems silly anyway. I found that out earlier today myself. I hadn't had a chance to look for a bypass to that though as I had my main rig apart to install some new waterblocks. I haven't worked with VMware in a while but if I recall correctly it didn't have 3d acceleration, or at least it wasn't user-toggled. Actually radeon/amd consumer graphics cards do allow for VM passthrough provided you can make it work via Xen or KVM and Qemu. Nvidia consumer cards don't have this option/feature however. As far as Quadro cards, which do allow passthrough, you're only looking at spending $5,000 on something like the K6000. That's not even a motorcycle so you are exaggerating just a bit lol. Ya I saw a thread or two while looking for virtualbox that had people talking about that kind of setup. Turns out very few actually manage to get the passthrough working and that's after a boat load of DOS style command line editing of config files and troubleshooting/bypassing code bugs and glitches. Something I'm not willing (or able as I'm running 3 nvidia gtx 470s) to do. Anyway, I'm a tinkerer so I'll be trying KSP in virtualbox anyway just so I can see the results myself. It's a character quirk so don't take it personally . I will have to see about a vram workaround though since I think that's the bulk of the issue in a VM environment. My friend was also kind enough to lend me her account so I'll be able to test all this shortly
-
True, but I'd presume there is a way to manually go in and remove the line or two of code that disables 64bit mode. I even think I saw one or two OPs say that they would provide 64bit version on individual request so there is certainly a way. It's just a question of if it's a worthwhile boost in ram savings.
-
I've never used a mac before so I didn't know what the deal was with that, I just wanted to point out I wouldn't be switching to one regardless lol. I did try using active management, or maybe it was the switcher, I don't recall, and it helped slightly but not enough. I know that to game inside a VM, which is to say linux running inside virtualbox running on win7, won't be epic but as long as the cpu can push the data I'd think it would be ok. I thought I read that ksp was more cpu bound than gfx bound anyway. I know that virtualbox has a cpu thread/core allocation slider and 3d acceleration but I don't recall if it had controls for VRam. Can any of you say if running ksp in windows with the opengl flag helps with ram use or not, I'm just curious to know either way. I actually didn't have any issues with crashing on the 64bit build in Dxd mode aside from the ram crash at 3.9Gb. Sadly I finished up with my friends rig earlier today and am reluctant to ask to borrow her credentials to test on my own rig, hence all the questions. I don't really have an issue running linux Steve, I just don't care much for dual boots. I've used them before and always hated it, the switching is just so tedious. So if I can get away with a linux VM to run it on 4 threads and the only real thing I'll be worried about is the gfx performance with acceleration. I may just have to break down and ask my friend to lend me a copy. If I have to buy my own for testing, is it $30 for the game and you get to pick whatever version you want after or do you buy the OS specific version and that's it? Also, what kind of driver* issues if any do I have to worry about if I go the dual-boot linux route? Again this is all much appreciated.
-
I posted in a thread already but haven't flat out asked this so I figured the best place to do such was in a separate thread. A friend of mine let me play her copy while I had her computer on the bench for an overhaul/upgrade. I didn't care much for it initially but then I found the mods and saw the realized potential, sort of. The problem I keep running into is a lack of memory addressing ability, or so I believe. It seems that regardless of her 16Gb of ram the game doesn't seem to use more than 3.9Gb without crashing even with the 64-bit exe. In the thread I commented in someone suggested that running KSP with an opengl flag would save ram. My actual question however is this: Is there any version, on any OS, that uses more than 4Gb of Ram without crashing? It's not like I'd switch to MacOS but I'd be open to running a VM of Ubuntu to play this game modded out. Thanks for your time and I look forward to your replies, SpecTRe
-
Wait, so are you telling me that if I run ksp with a OpenGL flag that I can run the game loaded with mods and not have to worry about it crashing when it hits 4Gb of ram usage?! If you are, I may just kiss you!