Redchrome

I got an ASUS nVidia GTX 750 Ti Strix vid card with 2GB VRAM. Had some troubles getting the system to boot with it at first (seems to have been a BIOS bug that somehow requires two monitors to be plugged in, at least the first time the hardware is booted -- weird). Installing the drivers was easy. Getting them to work required some fairly extensive Linux admin knowledge and googling. Now that I have them working tho... WOW! So this is what KSP is supposed to feel like! I never realized how much it sucked to have physics rendering everything at half speed. As a point of reference, the base game - no mods - running at 1600x1200 with the texture resolution turned all the way up takes about 1.5GB of VRAM (as reported by nvidia-smi). Once my 4k monitor arrives next week I'll get to see how well that works.

I have to agree. Just for the exercise I did a rendezvous last night without DPAI and wow does it suck by comparison. Thanks to docking many times with DPAI my docking skills are much improved, but it still really sucks to have to eyeball things rather than know your velocity vector and alignment precisely.

I just found this. This is great! Thanks for posting this stuff. I'd write it differently myself of course, but that's the nature of stories. What did you use for the Celestials' capsule and station? You write in the prologue that: I would be amused to discover that the Celestials are using a very different definition of 'government' than the other entities. Then again, each social group has its own ideas about what constitutes a 'government', so the Koviets and the Easterners will have different ideas from the USK. Now that the USK has (had?) a satellite monitoring the Easterners, they're more likely to detect Celestial rocket launches and other things. Regardless of what we see in James Bond movies, it's really hard to keep rocket launches secret.

Thanks for linking to that. Reading through it also explained why when I'm clicking through the available docking ports (in DPAI) for a given target, if I click too quickly the game engine stops focussing on the selected target.

I did some experimentation on my Linux box, and found a few things: * The box has graphics built into the mobo. It's the crappy kind where the GPU 'steals' RAM at boot time for video use. The BIOS allowed me to experiment with different amounts of VRAM allocated. * With 64MB VRAM, KSP was remarkably playable. Running a FurMark test got a whopping 5 FPS but that test is a lot harder than KSP. It's the same performance I get on my iMac with 256MB VRAM (but a crappier processor). * Even with relatively tiny amounts of VRAM, I could still load much nicer textures on the Linux box compared to the Mac. Maybe this is because the built-in GPU is hitting RAM no matter what, so it doesn't matter how small the VRAM is. * In some ways I actually got worse performance when allocating more VRAM - the CPU spent more time in a wait state when using 1GB VRAM (about 80%) when compared to 64MB VRAM (about 60%). I haven't looked at the debug console to see if I could tell any difference in render rate. * I found while watching 'top' that the CPU was spending most of its time in a 'wait' state. Definitely wasn't waiting on disk or networking tho (disk activity measured with dstat). * Digging through old computer parts I found what turned out to be a 10-year-old Radeon X700 with 256MB VRAM. Ubuntu 14.04 automagically sets up the drivers and DRI for it (which still shocks me considering how much trouble that was years ago). FurMark performance is truly atrocious and the driver doesn't even render the test image correctly, but the CPU is barely working and isn't waiting on anything, so the wait times on the built-in graphics must be for data transfers through the CPU from the GPU to RAM (ow!). So yep, a nice shiny new graphics card should give a nice experience. Now if only I can decide on a monitor...

That's a great idea! Just as long as the keys indicated actually reflect the keybindings (I've remapped several of my keys for rotation and translation to something that makes more sense to me), and the direction things will move in (when dealing with the negative velocity vector indicator it sometimes moves opposite of the way the positive velocity vector indicator would move).

Exactly. Or if you're way off-axis and the indicator doesn't appear to move when you push the keys. Or you screwed up and you're not actually thrusting in the direction you mean to, but you don't have an indicator of this. I know the code may not be trivial, but it's just a suggestion. Even a limited implementation indicating "yes, the velocity vector is moving, and in this direction" would be helpful at times. Here's a mockup of an indicator showing the velocity vector moving downward. Of course the problem is that as one gets closer to the target and (hopefully) the CDI lines are near the center, things get increasingly crowded there and the movement indicator isn't as helpful because movement will be much more apparent than it would be when one is way off-centerline. Some suggestions I have would be to make the movement indicator larger/brighter when: * thrusting longer * farther off-centerline * there is less apparent movement I do not know which of these would be the best tho. It would probably be confusing to implement more than one, but I could be wrong. Some play testing would be necessary.

Here's some mockups of an idea I had about indicating the direction of translation thrust. The line of dots is sort of reminiscent of rocket exhaust. My idea is that the dots would appear when the thruster was activated, but otherwise be absent. Suggestions, and correction of any misunderstandings or misstatements is welcome. Here's the simple case. One thruster pushing the velocity vector roughly in the direction of where the CDI lines cross. Here's two thrusters in parallel doing the same thing. The following image indicates that there are two thrusters at a 90 degree angle to each other, but the sum of their vectors points roughly towards where the CDI lines cross. I don't know how the RCS thrusters work internally to the game engine, but here would be a way to represent one thruster applying a lot of force, and one thruster applying a little.

When docking two craft in orbit, I will often switch between them and target them at each others' docking ports. With a space station this isn't really meaningful, but with smaller craft it can help. I don't know how you store information, but couldn't you have a file (separate from the persistence.sfs) that says "this section is for this ship, which is using this object as the control reference point and is targeted at that reference point or object"? I.e. just use tags in your separate data file which reference objects in persistence.sfs? That would be sensible and cool. Your logic could go something like "the object used as the control reference point is a Clamp-O-Tron Sr. port, so we should first look for other Clamp-O-Tron Sr. ports to dock to; then Recycle Bins; then other varieties of ports". I can conceive of wanting to target an incompatible docking port, just to use it as a reference point. (I doubt this will happen often, but one should account for this corner case). Yay! I'll have to mock something up to be clear, but what I mean is that the display could show which direction (up, down, left, right) RCS thrusters are actually firing. Say for instance you have a ship which only has thrusters pointing 'up'. One could conceivably still dock such a ship by rotating it around its axis so the thrusters point in whichever direction one wished to translate away from. However, without knowing exactly which way the thrusters are pointing, it's difficult to judge exactly how far to rotate the ship. The more common use case of this is when you have a relatively heavy ship with relatively weak thrusters. You push the keys to fire the translation thrusters, but there's no apparent movement, possibly not for some time. Why not? Did you forget to turn on RCS? Did you forget to take yourself all the way out of timewarp? Do you have a pair of thrusters firing 45-degrees away from the direction you wish they were instead of one thruster firing exactly the direction you want, such that the efficiency is reduced? Are you pushing the wrong button? Do you just not have working thrusters in that direction? Or is your ship just so heavy it takes a long time to get any indication of response, especially if you're very far off the axis of the port? Some sort of immediate visual feedback saying that 'yes, the thrusters are firing and in the direction I want' would be really helpful at times. This sounds familiar from my student pilot days, but I never got far enough to have to worry about doodads like that. Ah! Thank you! That all makes much more sense now. Your response has been very helpful! Thank you again!

One thing I've seen several times, and found quite frustrating, is that sometimes when switching ships while docking the DPAI will 'forget' which target it's supposed to be referencing. I'll be trying to approach the Recycle Bin for instance, but then I switch away to the space station the Recycle Bin is docked to in order to make sure the bin is activated, and when I switch back to the ship I'm trying to fly into the Recycle Bin I find that the DPAI is now targeting some other docking port. If I don't notice this soon enough, I start wondering "why is my distance to the target different all of a sudden?" and start lining up again until I realize what's going on. I haven't paid enough attention to notice whether it tends to take compatible docking ports or not. I'm typically doing this on my space station which probably has 20 ports or more, of all 3 sizes. Also, there's no really clear documentation readily findable which explains all the symbols. I still don't know what the red crosshairs mean. I guess it means I'm on the 'back side' of the port I'm targeting. I would guess that the green crosshairs are like some kind of virtual 'rays' emanating from the targeted port (i.e. when you're in line with the port, the green lines are centered), but when I'm way off to one side of the port (CDST low, DST high) I would expect at least one of the crosshairs to be up against the side of the indicator window, but I don't think that always happens. The tool seems to be really good when one is within a certain angle relative to the axis of the targeted docking port, but I'm still confused about what it's telling me when I'm way off to one side of the port. If possible it would be really cool if there were some kind of indicator showing which way your thrusters are pointing. This really affects thrusting efficiency, and some (crappy) designs of ships don't even have RCS ports for all directions. If you're flying 5-ton capsules around this isn't so noticeable, but when trying to dock 80-ton tankers you need all the help you can get. It would be nice if there was a readout for velocity relative to the DST indicator. Comparing that to the CDST value would give some idea how fast one is moving laterally. Thanks for your patience, for reading this, and for a great tool. I put some money in your tip account.

I'll need to look for that. Thanks!

Glad to help!

Or, like the Real World, you could make some types of fuel transferrable and others not at a certain tech level. NASA has been doing microgravity transfers of monoprop/storable/hypergolic fuels across docking ports for some time. Cryogenic fuels are an entirely different matter. So make ports able to transfer monoprop happen comparatively early in the tech tree, ports capable of moving LF+O should come much much later. Especially if coupled with a mod that required ullage rockets or advanced pumping technology to light LF+O engines in microgravity, this would make it sensible to build interplanetary ships that run on monoprop. Note that the Apollo CSM & LM ran on hypergolic fuels, and the planned Apollo Venus flyby mission would have run on hypergolics after leaving Earth orbit.

Cool. Thanks for the advice.

I looked at the source code at https://github.com/taniwha-qf/Extraplanetary-Launchpads/blob/master/Source/BuildControl.cs and found this line (searching for 'Idle'): [TABLE="class: highlight tab-size-8 js-file-line-container"] [TR] [/TR] [/TABLE] [COLOR=#A71D5D]Public[/COLOR] [COLOR=#A71D5D]enum[/COLOR] [COLOR=#795DA3]State[/COLOR] { Idle, Planning, Building, Canceling, Dewarping, Complete, Transfer }; [TABLE=class: highlight tab-size-8 js-file-line-container] [TR] [/TR] [/TABLE] So I tried editing the persistence.sfs file and setting the state to 'Complete'. I was then able to finalize my build! So the problem seems to be solved for now.

I started building a craft (using EPL 4.5.0 on OSX), and I'm pretty sure the build finished, but when I went to check on the status I discovered the UI window was mostly blank! I tried updating from EPL 4.5.0 to 5.0.1, but got no relief. Some googling found this, which isn't exactly the same: https://github.com/taniwha-qf/Extraplanetary-Launchpads/issues/38 and this: https://github.com/taniwha-qf/Extraplanetary-Launchpads/issues/35 which isn't quite the same either but gave me some hints where to look in the persistent.sfs file. I discovered this section: MODULE { name = ExLaunchPad isEnabled = True PadName = flagname = Squad/Flags/orbs state = Dewarping paused = False KACalarmID = baseMass = 0.5 EVENTS and the "state = Dewarping" looked suspicious. Based on the discussion of issue #35 above, I set "state = Planning" which does seem to restore the UI. Unfortunately my build progress is gone! What are the possible states for the dock? I now know of Dewarping, Idle, and Planning. How do I set it to show my ship as having finished the build but not yet finalized? Can we make this a troubleshooting suggestion in the first post of this thread? - - - Updated - - - That's a nifty idea. That makes me think I should look into KerbalStats. Btw, I really like the blue workshop! Kudos to whomever designed that. I'd like more space station parts designed the same way.

Ok. Thanks for the information! This also makes me think why the VAB is so slow to render my models sometimes -- there's kerbals walking around in it, and they need to be rendered as well.

I don't have hard numbers to back this up yet, but it seems like when I use the spherical tanks vs. cylindrical tanks the game becomes slower to render. The frame rate doesn't seem to change meaningfully, but the game feels choppier. Maybe there's more triangles and angles of the triangles relative to the light, for the game engine to calculate compared to a cylinder?

Thanks for the terminology lesson. I like learning new words and you made my day.

These are nice tweaks, and much appreciated. I used FlightDefFreeCam for a while but gave it up because I found I'd rather have my camera be in Chase mode by default. Maybe that's because I'm doing mostly orbital rendezvous and no landings, or because I'm still not sure why there are 4 different camera modes and what they all do. It would really be nice to have some little indicator somewhere showing what the current camera mode is.

Thanks! I may give that a try if I feel a need for those girder segments.

I did a PRAM reset using the instructions here: https://discussions.apple.com/thread/6623697 it didn't help my Window Server CPU-usage problem (not related to KSP) the last time I tried it, but others have said multiple attempts may help. At any rate, after the reboot the demo version started normally, and I turned down the Pixel Light Count and Shadow Cascades to 0.The demo game seemed really snappy compared to the full version, even with full texture resolution. Played for a bit and it was much more responsive than I was used to for the full version. Shut down demo version normally. Restarted full version. It seemed to hang, but when I switched it out of fullscreen mode using the menu at the top, it seemed to continue loading. At the main menu, I switched it back to 1/8th res textures and Pixel Light Count and Shadow Cascades to 0, as well as AA to 2x. Rendering was somewhat slow, as before, but playable. I switched to the Activity Monitor, and it showed KSP only using ~30-40%CPU (at least when playing with small craft, I haven't tried this with my big station yet). This makes me think it's VRAM starved. So I can play KSP again. (Hilarity ensues) I'm just going to have to be careful of setting the graphics too high.

On a lighter note, Will Kerman was caught on camera late at night after getting an experimental rover stuck while 4-wheeling in the Administrator's pond, and using the winch to get himself free. Related to this, it is rather annoying to not be able to retract a winch all the way if it's not oriented in the same direction as the local gravity gradient. I hope a newer version will fix this. Dangling hooks have a habit of snagging on things under the rover.

It's an Apple box, so reinstalling drivers is nontrivial. Also, why would a dying GPU yield artifacts like headless kerbals and floating rocks? The funky colors I can understand, especially since a reboot is necessary to 'fix' the problem (at least temporarily). I downloaded FurMark and ran it, getting <10FPS with the FurMark test when using hardware rendering, and 0 FPS when using software rendering, so some hardware rendering is working. I haven't done enough comparisons to know what's good numbers and what isn't. I may go to an Apple store with this, and see what they say. This machine has the Yosemite bug that makes the Window Server process eat more and more CPU over several days until you restart it, so if I can get that fixed while checking for GPU problems it would be great.

I've been frustrated by display bugs all day, such that when I set my graphics settings too high the game crashes with colorful squares and stripes on screen. However, I think that's a separate issue which has simply been exposed by this problem I found. In ~/Library/Logs/Unity/Player.log I find this entry: To put it in context, this is the head of the Player.log: Here is one of my full Player.log files. I don't know how long this has been going on. When I was running the KSP 18.3 demo, it ran quite happily fast, but when I bought 0.25 it was suddenly dog-slow unless I turned down the textures to 1/8th res and ran full-screen. I had no clue about what behavior *should* be like, so I figured this was normal for software becoming more complex, and with all the people complaining about low frame rates I figured my computer was just slow. I do not yet know how to find my KSP frame rate. Last time I looked at the debug console, it showed that the game was running at about half-speed (so 2 seconds real world time for 1 second game time). KSP version is Kerbal Space Program - 0.90.0.705 (OSXPlayer) Steam BETA (as reported by KSP.log). System is OSX 10.10.1, 3.06GHz Intel i3, 256MB VRAM, 12GB RAM. If you ask I'll send my .spx file from System Report. Some Google searches show a few other reports of similar problems for Unity games, and my understanding of Player.log is that it's for the Unity game engine rather than KSP itself. So this is sort of outside the scope of this forum. Could someone direct me on how to debug this further, and/or suggest a resolution? Is this a bad interaction between this OSX version and Unity? - - - Updated - - - Sorry about the double "[support - OSX]" tag in the header, I'm used to putting those in by hand in the trouble ticket system at work and didn't know the drop-down tag menu would do it that way. - - - Updated - - - I happen to still have the KSP 18.3 demo version installed, and so I started that up. I note that in the resulting Player.log, there's no mention of 0MB VRAM. When I was playing the demo (in the past, I haven't played it today because I crashed it), things seemed much faster than the current version. So this makes me think the current game engine is breaking on my system somehow. I note that it still crashes with the same headless kerbal and floating rocks I've seen at times today with my regular install, which makes me think Unity is fscked up somehow.