GregP

PeterP to the rescue once again -- and yes, I'd already tried that but didn't realize the lack of 32 meant 64. So am I indeed running 64! Thanks.

Compared to the folder structure that my A-10C install has, my BS2 install has a 'bin' folder with an exe but does NOT have the 'x86' folder that A-10C has. I read that the install will automatically detect your OS's version and install the appropriate exe, but now I'm not sure if it did it correctly. So how can I tell?

Update: the Cougar's been sold. Sorry to everybody else who was interested.

You're running EIGHT screens off a single GTX 580?!? Holy crap!

I should note that I've had it running under Windows 7 64-bit Professional for more than a year now with no problems; the worst that ever happens is it loses the calibration, or can't find the firmware, and I have to re-flash it. But AFAIK, that's a general Cougar problem and not specific to Win7.

OK, PeterP, I tried your suggestion and it does indeed work. The only downside, of course, is that the center picture doesn't use the entire screen height, but we knew that beforehand. I've posted pictures of the before and after outcomes below. I can finally read the info bar on the left and everything's lined up (it doesn't appear so in the picture because of the perspective, but when I'm sitting in front of the monitors, they're lined up). Thanks! BEFORE: AFTER:

I recently bought a HOTAS Warthog after 10 years of faithful service from my Cougar. I'm going to miss it (I had almost begun to think in Foxy code after all that time) but I finally decided the Warthog was worth the investment since DCS is my primary flight sim these days. So now it's time to sell my Cougar. I pre-ordered it from Amazon way back in 2000 or 2001, whenever it came out, I can't quite remember. Over that time I've put well over $800 worth of mods into it, including: - IJ's original Uber Cougar 'center play removal' mod - Evenstrain's original gimbals + Hall Sensor mod - CubPilot's HS1 throttle mod (just last summer, when I noticed some spiking in my throttle's response) I have never tried a Cougar with any of the newer mods, so I can't really comment on how they compare. What I can say is my Cougar has a completely equal resistance in all directions, with no center or side 'notches' perceptible whatsoever (a HUGE change from the default retail version). To be honest, I actually even like the feel of it slightly more than that of the Warthog. I've taken very good care of my Cougar over the years, always keeping it protected by Cougar Covers when not in use. Also, for a few years I didn't put much time into flight sims, so it was rarely used during that time. None of the lettering is faded or scratched, and there are no scratches anywhere on the entire HOTAS. I never encountered the broken speedbrake switch problem that people seemed to have early on, and all the buttons and axes work just fine. And the remaining pots (ANT, RNG, microstick?) seem to be doing fine, not showing any spiking that I can detect. So, given the total of over $1100 that I've put into this HOTAS, and the great condition it's in, I think asking $275 shipped within the lower 48 is reasonable, especially given the likely costly expense I'll incur shipping this beast. HOWEVER, if you live in the DC/MD/VA area and want to just come pick it up, I'd be happy to do say, $240. While I am of course looking to offset the cost of the Warthog by selling my Cougar, I'm also motivated to see it end up in the hands of someone who will really use it, as it's got plenty of years of use left in it.

How are you using the Warthog? Are you loading a profile through either the TARGET GUI or Script Editor first? That config line I posted would be used in a TARGET Script Editor profile. If you're not doing either one of those, your friction slider may not automatically show up as mappable within DCS. At a minimum, you'll need to start up the TARGET GUI and make sure your friction slider is mapped as a valid DirectX axis. So bottom line is -- although a lot "just works" by simply plugging in the Warthog and starting up DCS, I don't think the friction slider is one of them, and requires some manual setup steps outside of DCS first.

Joker73, I struggled with this for awhile too; the problem was that directly binding the axis in-game caused the zoom function to be unstable whenever I moved the friction slider. Try this instead: KeyAxis(&Throttle,THR_FC,0,AXMAP2(LIST(0,40,60,100),Zoom_in_slow,0,Zoom_out_slow)); It creates a band from 40-60% of throw that does nothing, but 0-40 zooms in, while 60-100 zooms out. Works fine for me.

One other helpful detail that I discovered is that I didn't need to explicitly bind the TDC slew functions to the unshifted state in TARGET -- rather, you can assign the axes in-game: they'll work as TDC slew when in-cockpit, but will 'turn off' when you go to an external view. Doing this has now given me smoother TDC slewing than when I specifically bound the TDC slew functions to the axes in TARGET (as shown in my first post).

Got my answer here, by the way.

Fish, that's an amazing video, nice job. Care to share your VAC and TrackIR profiles? You seem to have MUCH smoother and more versatile TrackIR panning than I'm able to get. Also, I'm curious about your default cockpit view: I'd love to be able to see that much of the cockpit when flying, but don't you find that you can't read the HUD because your eyepoint is too far back?

With Foxy on my Cougar I used to have the TDC Cursor mapped to the microstick's unshifted state and mouse control on its shifted state, but I can't find any analogous way to do this with the Warthog's Slew Control. From the TARGET Script Editor manual I figured out that I could use the following to do slew control: KeyAxis(&Throttle, SCX, 'o', AXMAP2(3, HOTAS_slew_left, 0, HOTAS_slew_right)); KeyAxis(&Throttle, SCY, 'o', AXMAP2(3, HOTAS_slew_up, 0, HOTAS_slew_down)); But from what I understand, using 'KeyAxis' prevents me from using the 'MapAxis' command that would let me assign the shifted state to mouse control. Is there some 'mouse command' (but one that is not an axis like MOUSE_X_AXIS) that I could use in another KeyAxis statement? Anybody have any ideas?

I've extensively searched this forum, AND yes I've seen the FAQ entry about maximum RPM for the engines, but I think I still have a question that has not been answered: I noticed that when I go to max power on takeoff (even just using the keyboard), my Fan RPM reads just slightly over 80% while my Core RPM reads just under 94%. I know that max Fan RPM on takeoff is supposed to be 82%, but what Core RPM should I be seeing associated with that? The manual say that normal operating range for Core RPM is up to 98%, but I can't get that high ... is it because I can't even get Fan RPM up to 82%?

Serial #: 09323 Location: Washington, D.C.

While there are numerous ways to do this, Hender mentioned the simplest and most accurate method here: From p.312 of the 1.1.0.9 manual: "TAD Copy, system action OSB 17. This function is only displayed if a symbol has first been hooked. If a symbol is hooked and OSB 17 is pressed, the hooked symbol will be created as a new mission waypoint in the CDU." Although I have to admit, I'm not completely clear on how 'hooking' a TAD object (TMS Fwd short) is different from setting it as SPI (TMS Fwd long) -- it seems like the same thing. Perhaps the difference is that 'hooking' it cues the EGI to allow you to create a new waypoint based on that point, whereas just making it SPI does not.

I use Fanatec's ClubSport Pedals (intended for racing, but work well with DCS) as follows (note that this requires the pedals to be plugged into the PC directly, rather than thru the Fanatec wheel): LeftRudder: Joy_RZ Slider,0,100,50,0 RightRudder: Joy_RX Slider,Invert,0,100,50,0 Wheelbrakes: Joy_RY Slider,0,100,100,75 I got this setup from somebody else on this forum, but I've forgotten who...

FYI this discussion has continued in the Input Controllers forum: http://forums.eagle.ru/showthread.php?t=77788

Yup, admin on both. With further testing I now realize that it's not just my X-Keys: my Saitek Pro Flight Throttle Quadrant is doing the same thing: chorded assignments work fine in Windows, but once in-game, they all get cancelled. If only I'd made a backup of 1.1.0.8, so that I could confirm whether or not it was 1.1.0.9 that caused this!

Months ago I built a profile from my X-Keys Professional that replicates the UFC and parts of the CDU, and it was working fine; but ever since I installed 1.1.0.9, it seems that all of my key presses on the X-Keys, although they seem to work correctly outside of the game, suddenly don't work in-game anymore. In particular, all of the chorded keys get deactivated, e.g. if I have a key bound to UFC "2" (LCTL + LSHF + 2), when I press the key in-game, all I get is a "2" generated, which causes the LAAP Path Hold switch to be activated. I'm using the latest Macroworks3 (1.0.3.2) so I don't think an outdated version is the problem; has anybody else had any weird X-Keys behavior since installing 1.1.0.9?

Sure, I could move the center monitor up and make the problem easier ... but that is exactly why I have this problem: I don't *want* to move the monitor any higher. :) Not just because I'm stubborn, but because my current eye-level when I sit in my chair is slightly above the center of the screen; if I move the monitor up another inch or two, I'm going to really be looking upward at my monitor, which I don't want. And I don't have any way to lift my seat up, either, unfortunately. So that's why I say my center monitor is fixed in position; and since my right monitor can't be moved down (it's already basically resting on the desk, with only a small riser under it), it seems I'm stuck.

Ah, well, if you're on vacation, then sure, give it a try! :) Here's my config.SoftTHconfig: [main] renderResolution=5430x1080 nonlocalFormat=RGB16D keepComposition=1 smoothing=1 debugD3D=0 zClear=1 vsync=0 tripleBuffer=0 screenshotFormat=bmp dllPathD3D9=auto dllPathDXGI=auto dllPathD3D11=auto [overrides] forceResolution=0 antialiasing=0 processAffinity=0 FOVForceHorizontal=0 FOVForceVertical=0 [head_primary] sourceRect=1355,0,1920,1080 screenMode=1920x1080 [head_1] ; Autodetected as \\.\DISPLAY2 at NVIDIA GeForce GTX 580 devID=1 sourceRect=3350,0,1280,1024 transportResolution=1280x1024 transportMethod=auto noSync=0 [head_2] ; Autodetected as \\.\DISPLAY5 at NVIDIA GeForce 8400 GS devID=2 sourceRect=0,0,1280,1024 transportResolution=1280x1024 transportMethod=auto noSync=0 [head_3] ; Autodetected as \\.\DISPLAY6 at NVIDIA GeForce 8400 GS devID=3 sourceRect=4630,0,800,480 transportResolution=800x480 transportMethod=auto noSync=0 [head_4] ; Autodetected as \\.\DISPLAY7 at NVIDIA GeForce 8400 GS devID=4 sourceRect=4630,480,800,480 transportResolution=800x480 transportMethod=auto noSync=0 And here's a[n admittedly poor] picture of my setup where you can see the alignment difference between the side and center monitors: If there's anything that'll get me more FPS in DCS, I'll give it a try. Thanks!

I think I didn't explain it adequately -- by 'image mismatch', I meant that I'm trying to squeeze 1080 vertical pixels into the 1024 that my display actually has, and so even tho the info bar would now appear at the bottom of all monitors, a point-for-point comparison between the L/R monitors and the center monitor would show that the images don't match as you move down from the top (currently, the tops of all my monitors are aligned, with the L/R bottoms being about 25 mm above the middle monitor's bottom bezel). Wow--rereading the above I'm not sure that explanation helped clarify it at all. :) In other words the L/R monitors' images are compressed vertically compared to the center monitor's image and so as your eye moves from the center monitor outward, you notice a discontinuity in the vertical position of say, the canopy frame. If I want to keep everything proportional and I can't move my L/R monitors down such that all 3 monitors' lower bezels are aligned ... my only choice is to just leave things the way they were and give up on seeing the info bar.

A quick, simple answer -- thanks again, PeterP! I tried that and you're right, that does it. Problem is, of course, that my images don't line up across the 3 monitors. Ideally I'd just physically lift/drop my monitors such that their bottoms line up, and then I could just cut the 56px off of the top of the L and R monitors ... but unfortunately my current setup makes this minor change extremely difficult to implement. Thus my only real choice would be to deal with the image mismatch across monitors, and in the end, seeing the info bar isn't as important to me as having a consistent image across my monitors, so for now I'll just forget about the info bar. Thanks for the quick answer though!

I'm hoping one of the guys who've developed the multiplayer and comms menu mods will be able to solve this one too -- I run a 3-monitor config with smaller left and right monitors. The info bar (when in external views) never shows up properly because my L/R monitor heights are 1024 whereas my main monitor is 1080, i.e. the info is being shown outside my viewable area at the bottom of the left monitor. I can see the gray info bar on my center monitor, but I presume all the text is either over on the left monitor or on both the left and right monitors. I've looked through the FUI folder and don't see anything related to the info bar. Has anyone else come across it?