GregP

Updated my post above with overclocking results.

UPDATE: Added overclocking results. Well guys, I just built a new system last night and ran some quick tests, and am excited to share the results. I've done what I think is as close to an apples-to-apples comparison as is possible, and I'm amazed at the performance bump I'm seeing. I ran these tests under Windows 7 Professional 64-bit and DCS Warthog Beta 4 64-bit. Using Method 1 from the instructions (here), I "sysprep'ed" my existing Windows install and simply moved it to the new build with no problems at all, a Windows first for me, saving countless tedious hours of program reinstallation. This should minimize the differences between the OS configuration on my old and new systems, making a direct performance comparison all the more meaningful. Old system: Core 2 Quad Extreme QX6800, stock 2.97 GHz overclocked to 3.47 GHz eVGA nForce4 680i SLI eVGA GeForce GTX 470 SC 8 GB DDR2 PC2-8500 (1066 MHz) New system: Core i5-2500K, stock 3.3 GHz overclocked to 4.6 GHz Asus P8P67 Pro eVGA GeForce GTX 470 SC 8 GB DDR3-1600 PC3-12800 (currently running at 1333 MHz) My standard framerate tests use FRAPS in a simple 'sitting on the runway' mission I created and then a 1-minute framerate record in the Litening pod training mission. I also run two different video configurations for testing: a single monitor at 1920x1080 and 3 monitors with SoftTH for a total resolution of 4630x1080. A caveat with these two video configs, though, is that FRAPS will only display the framerate for the left or right monitor when running 3 screens; given that these tend to be rendering at higher rates than the central monitor (I believe this is simply the way that SoftTH works) the results below appear to show the unexpected result that I get higher framerates when running 4630x1080 than I do when running 1920x1080. This is not actually the case, it's just that I can't measure the central monitor's FPS with FRAPS nor with DCS's built-in framerate counter as it doesn't seem to be working. As such, it makes more sense to look at framerate percentage changes rather than raw numbers to get an idea of the performance increase I'll see. So far I've been able to push it up to 4.6 GHz without much work, and I have a feeling I could probably safely get it to 4.8, but there may not be much additional payoff. In-game graphics settings: Textures: High Scenes: High Civ Traffic: Low Water: Medium Visibility Range: High Heat Blur: On Shadows: Medium Cockpit Res: 1024 MSAA: 2x HDR: On TSSAA: Off Clutter/Bushes: 250m And here are my results: Sitting on runway: Old 4630x1080: 39 1920x1080: 24 New, stock 3.3 GHz 4630x1080: 48 1920x1080: 43 New, o/c to 4.6 GHz 4630x1080: 52 1920x1080: 49 Litening pod training mission: Old 4630x1080: 39 1920x1080: 27 New, stock 3.3 GHz 4630x1080: 52 1920x1080: 46 New, o/c to 4.6 GHz 4630x1080: 57 1920x1080: 60 So basically I'm seeing an incredible 25-74% framerate increase (25-33% increase in the configuration that I actually run) going from my old system to the stock 3.3 GHz of the i5-2500K, but when I crank it up to 4.6 GHz I'm seeing an insane 33-122% increase (33-46% in my actual config). Of course, the "FRAPS only measuring outside screen framerate" issue makes it hard to tell if the the percentage increases at 4630x1080 are being measured on the same scale as those at 1920x1080, but either way, I'm quite happy. Bottom line: woo-hoo!

So far the only two unmapped unshifted keys I've found are 'i' (key command PDF says this is for HOTAS Coolie Switch Down, but that's a typo, it's actually 'j' in-game) and 'F8'. If you have pedals, you can unmap X and Z (left and right rudder) too.

Just wanted to add a note regarding my experience doing this in Beta4. Even after setting UseDefaultSnapViews = false in View.lua and copying the config lines in the OP into SnapViews.lua, DCS seemed to not use these settings (perhaps because I also had EnableSnapViewSaving=true in View.lua?). What I had to do was set UseDefaultSnapViews = true and then copy the OP lines into SnapViewDefaults.lua, and then everything worked perfectly. Only thing I had to change was the viewangle parameter (65 degrees on the MFDs), as I run a 4630x1080 triple-screen SoftTH config.

Wow, what a timely thread, as I was trying to solve EXACTLY this problem -- using my racing pedals as rudder and wheelbrakes in DCS. In my case, I wanted to do this because my CH Pro Pedals have been replaced in my cockpit with Fanatec Clubsport Pedals, which are much heavily and harder to move, making switching them out depending on whether I'm flying or racing a real PITA. I had puzzled over how to get them working for days now, and then came across this post. Problem solved! In my case I used the clutch and accelerator as left and right rudder, and the brake as wheelbrake (setting the left rudder axis to 'slider' with deadzone 0, saturation X 100, saturation Y 50, and curvature 0, and then right rudder axis to same but also 'invert', as shown in link above) and it works perfectly.

Good point; I overgeneralized based on my own experiences. What I should have said was: If, like me, you have two different video cards, not in SLI, being used to run 3 monitors, selecting any of the '3 monitor' options in DCS will not automatically span your view across all 3 monitors, nor will using the above guide do it. All it will do is put the MFDs on the side monitors. You'll need to use SoftTH to get the view spanned across all 3 monitors. If you have two Nvidia video cards in SLI or a single GeForce 295 -- which has 3 display outputs -- you can use Nvidia Surround to get the view spanned across all 3 monitors. If you have an AMD/ATI Eyefinity-capable card, you can use Eyefinity to span across 3 monitors. I think that just about covers it. :)

This is a very helpful guide, thanks. But I just wanted to point out to new users that the multi-monitor support in the game does not allow you to span your view across three monitors; rather, it lets you place the MFDs on side monitors or duplicates your view on the side monitors. To span across three monitors, you'll need to use a hardware solution like TripleHead or Kegetys' excellent SoftTH, a software solution. I'm using the latter and it's working beautifully in Beta 3, aside from an issue where the default zoom in way too far zoomed in. In the normal cockpit or external views, this is not a problem as you can simply zoom back out, but when trying to view MFDs full-screen, you'll be too far zoomed in with no way to zoom out. Hopefully this will be fixed in a future beta (because it was not a problem with Beta 1).

OK so a quick googling doesn't bring up anything obvious ... link? EDIT: Found it: http://www.scsimulations.com/index.php/

Having exact same issue (blue screen and empty SnapViews.lua), except that I can't get new snapviews to save at all.

A whole lotta reads but no replies ... I'll make it a very simple question: has anyone had success with saving cockpit angles?

EDIT: My bad, I just discovered this is a known issue via the beta forum.

Awesome! Looking forward to trying it out. Thanks Snacko!

I've got my Cougar programmed to do a 'zoom HUD' view (hold down KP0 and then KP5) when I press one of its buttons. I've noticed, though, that the laser designator pipper sometimes refuses to stay on the HUD, sometimes sinking off the bottom of it, no matter how much I try to slew it upward. It occurred to me to try a different 'zoom HUD' method by just zooming in (KP*) and slightly panning my view up to the HUD -- and when I do this, the pipper always stays on the HUD. I took some comparison screenshots of what can be seen through the HUD using both methods, and clearly, the line of sight is different: KP0/KP5 keeps the nose instrumentation booms out of view, while KP*/pan up brings them in to view. This leads me to believe that the latter provides a higher angle LOS relative to the centerline (i.e. looking more downward than the former method) and probably a bit higher in position, too; which, based on the effect on the pipper than I'm seeing, is exactly what I'd expect -- I would think that a higher angle looking downward through the HUD would tend to keep the pipper on the HUD more often than when your view is looking more straight ahead through the HUD. So the KP0/KP5 'zoom HUD' function seems to not be working correctly. Anyone else experienced this, or know how to fix it? I'd really rather not give up the handy KP0/KP5 combo, as it's a very convenient 'one HOTAS button press' shortcut. Using the KP0/KP5 method, which screws up the pipper: Using the KP*/pan up method:

In general JoyX would be roll, JoyY would be pitch, so throttle should be JoyZ or one of the other axes with 'Z' in it. Sure would have been nice to have an "in-GUI" axis tester, though, so you don't have to go into the game to see if you've set it up right.

Great video, guys, and I just had to comment on how awesome that "letters with flares" trick is ... I actually yelled out "NO WAY!" just now while watching it. :) Pretty impressive.

My guess would be "PND PER HOUR", i.e. pounds per hour, which may simply be a mistake by the designers instead of writing the more common "LBS PER HOUR". I'm pretty sure that aviation fuel is usually referred to by its poundage rather than its volume (gallons).

Have you checked within FC2's "Axis Commands" to make sure everything's set up correctly? In Black Shark, I have to set the pedals "JoyY" to "wheelbrakes" (although I'm pretty sure FC2 does not have this option) and "JoyZ" to "rudder". If FC2 doesn't have a wheelbrakes axis option, then just verify that JoyY is not assigned to anything.

Ditto--got mine from GoGamer yesterday and it was well worth the money: nice hard cardboard covers, very sharp and clear text and figures, nice quality paper. Holding this thing in your hands, it's completely understandable why companies simply cannot afford to include printed manuals like this in the box. Thanks for the effort in putting this together, ED!

Crap! GoGamer gets some back in stock but now I'm stuck at work for another seven hours and GoGamer's blocked here. :(

So - anybody have any comments on the sections added beyond what's in the digital version that comes with the sim?

You're trying to use Ultramon and multimonitor together? Oooo .... very bad. That's like Ghostbusters crossing the streams. :) Actually I'm not certain it's a problem, but would definitely guess so. Ultramon essentially takes over all multimonitor functions from Windows, right? So I'd assume that means BS cannot interact with the multiple monitors the way it expects to. I'm out of touch with ATI cards - is it not possible to run two monitors at different resolutions and spread your desktop across them? In other words why are you using Ultramon? I'd suggest temporarily disabling Ultramon and giving that a try. Sounds like you've read enough about running multiple monitors to know that BS creates a 'phantom' third monitor no matter what you do. But cypher1312's Phantom Monitor Fix can sort-of make that go away, so that BS is effectively rendering a smaller resolution (2 mons instead of 3) - however, I'm not sure but that may require that what would be your right monitor be the phantom one, i.e. that you put Shkval/ABRIS on left and main on center.

Under Vista in windowed mode with the Phantom Monitor Fix, I get Instant Actions framerates of about 50 with the following config (left 17" at 1024x768 with Shkval and ABRIS under DickDastardly's Touchbuddy profile overlay, center 37" at 1920x1080, right 22" nothing): [b]DD_ShkABR+Cam+Phantom.lua:[/b] Description = 'Shkval & ABRIS on the left, camera on the center' Viewports = { Center = { x = 1024; --(the width of your leftmost monitor) y = 0; width = 1920; --(the width of your primary monitor) height = 1080; --(the height of your primary monitor) viewDx = 0; viewDy = 0; aspect = 1.77; } } Shkval = { x = 17; y = 17; width = 486; height = 306; } ABRIS = { x = 589; y = 161; width = 366; height = 447; } [b]options.lua[/b] ["graphics"] = { ["multiMonitorSetup"] = "dd_shkabr+cam+phantom", ["color"] = "32", ["heatBlr"] = 1, ["scenes"] = "high", ["water"] = 2, ["fullScreen"] = false, ["visibRange"] = "High", ["aspect"] = 1.7777777777778, ["textures"] = 2, ["shadows"] = 2, ["display_mode"] = { ["avi"] = { ["bpp"] = 32, ["resolution"] = "640x480", ["full_screen"] = false, ["aspect"] = 1.333333333, ["height"] = 480, ["width"] = 640, }, -- end of ["avi"] }, -- end of ["display_mode"] ["effects"] = 2, ["haze"] = 1, ["lights"] = 2, ["height"] = 1080, ["resolution"] = "1920x1080", ["civTraffic"] = 0, ["width"] = 2944, }, -- end of ["graphics"] } -- end of options

Native is 1280x1024, but in order to have bigger buttons in DD's touchbuddy profile, I lower it to 1024x768.

Heh ... yeah ... well after splurging on the critical parts of the setup, some of the infrastructure has to be low-budget. :)

Yes, and they're easier to get working than you might think. Last month I bought a cheap 17" HP LCD from Tigerdirect ($90 US after rebate) and a 17-inch touchscreen overlay off of eBay ($90), so for less than the price of the CH MFP, I had a bigger and more versatile touchscreen. Installation couldn't be easier: pop the front bezel off the LCD, slide the overlay in there, put bezel back on, connect USB cable up, run the included calibration program, and you're good to go with touch-buddy. Here's a picture of my current setup; not quite as cool as Polecat's :) but still nice: 17-inch touchscreen using DickDastardly's excellent touch-buddy profile for ABRIS/Shkval, 37-inch center LCD, 22-inch LCD monitoring my computer to make sure it doesn't melt down while I'm flying. :) I found that pushing the ABRIS/Shkval to the right LCD [rather than on left touchscreen] didn't add much to the experience and dropped framerate too much.