ddahlstrom

I believe and understand what you're saying; but just remember that this statement is only valid for FFB games. For EVERY non-FFB game (including BS in non-FFB mode--which is the way I have resorted to play it), slop will persist unless Logitech does something about it. Or is it Logitech's intent that this HOTAS is only targeted for best use with FFB games specifically programmed for it? If so, that's a pretty narrow target.

This largely reflects my feelings too. Here's a reprint of the review I posted to Amazon.com a couple days ago... The G940 is a potentially great product that is difficult to give a *star* rating to. The reason is that your experience with it is going to depend hugely on what games you use it with, what your expectations are, and how patient you are. If you are using this stick on a game that is programmed to use FFB effects and these effects have been programmed "correctly" (i.e. programmed in a manner specifically specified by Logitech for this stick), then you will probably have a wonderful experience. The trouble is, very few games are programmed to take advantage of this yet. So even though I believe the hardware on this system is top notch and capable of very high precision, its hard to know what will work well and what won't right now. FSX with the FS Force add-on evidently works great, for example, but other recent games such as DCS: Black Shark have poor FFB performance on this stick (other FFB sticks are said to be much better). Another very common issue with this stick is "slop", which is seen in many FFB games (including Black Shark), and is exhibited in EVERY non-FFB game. Basically, this means that the center 10 to 20 percent of travel in the middle of this stick has almost no center spring effect. This is a nasty, nasty issue that can evidently be overcome through software (either Logitech's for non-FFB games, or the game makers for FFB games), but to this date Logitech has not yet addressed this in non-FFB mode and this remains an unresolved issue for many FFB games. This is why, if you are expecting a great FFB experience out of the box, it will depend on games you own, whether the "slop" is an issue for you, and how patient you are to wait for Logitech and game makers to fix these issues. I have heard that other Logitech FFB stick have similar issues, but one thing they need to know loud and clear is that when you introduce a serious HOTAS product with this kind of price tag, issues that aren't a big deal in a lower-end stick are just not acceptable in a product targeted at more "serious" use. I purchased my first FFB stick (an MS FFB Pro) about ten years ago and it's amazing to me that the industry still doesn't have its act together. I enjoyed that stick for quite a while, but I stopped using that stick many years ago when I went with a full HOTAS setup, which up until now had no vendors offering a FFB solution. I had high hopes for the G940, but so far they are not yet met. I do have to say that the stick does offer other features that are quite nice and which overcome the FFB deficiencies fairly well for me. I am also going to hold out for improved software as Logitech is providing some strong hints that future revs of their profile software are going to offer some big improvements. Hopefully, this will be enough to push this stick to a solid 5 star rating.

My personal experience is that it is not resource hungry at all. There is a pretty big difference going from the 3 to the 4 and a less substantial difference going from the 4 to the 5. With that said, the 5 with the Track Clip Pro is the best thing out there. The two things that you want in BS is a wide tracking angle (to take best advantage of the 6DOF), and perhaps most importantly, a high resolution--which translates into a very steady view (really important for use in the virtual cockpit). When going from the 3 to the 5, the improvement in stability for me went from barely useable to almost flawless. The 4 is obviously somewhere in between, but better than the midpoint.

Since it sounds like you're doing things right, I'm just throwing a few less likely things out. 1. Did you use a non-friendly editor like notepad to do any of your editing? 2. Are you using v.1.0 of BS or 1.01? (not sure whether this makes a difference, but I know it works in 1.01)

Nice. I just tried putting my secondary monitor (virtually) under my main monitor, and this does in fact work! I now see the comms menu in my main menu again. After recalculating resolutions, screen dimensions, and the ABRIS and Shkval positions, everything appears to function properly in the TP screen. Like you, I have lost the control window, but that's not a big deal. Fortunately, I don't seem to lose any framerates by doing this (I'm using just two monitors). The only weirdness is having to move my mouse cursor down to get to my side monitor.

Thanks. One more question. How are folks dealing with the comms menus. When using two monitors, the comms menu ends up on the second monitor, but I can only see a small fragment of it overlaying the ABRIS. The rest is obscured. Are there any work-arounds for this?

I agree that this should be an option; however, after using pedals for a while I realize that there are genuine advantages to wanting to trim the rudder, even in FFB mode. My suggestion is to simply implement a variant of the 1.01 style trim. In other words, in FFB mode, when trim is pressed, the cyclic should immediately lock into its new physical position and remain controllable, while the yaw should be immediately locked into its current virtual position until the pilot recenters the pedals. Once the pilot centers the rudders, yaw control will be unlocked. It's simple, and preferrable IMHO to blocking rudder trim altogether. In some ways it might even be most strongly benefical to users of twist sticks or rockers since those devices tend to be more difficult than pedals to hold in a precise sustained position over time (I know, having used both extensively in the past).

If you're using a twist rudder or rocker, it is likely that the effect of the yaw shift kicking in immediately is somewhat reduced by the small movement needed to bring it back to center. When using pedals however, the greater distance magnifies the effect. Either way, trim does work different in FFB mode. It's up to the individual to decide whether it works well enough for them.

Syntax looks fine so far, and I can read the source, so I think I'm ok. I just wanted to make sure that I wasn't missing some tool to assist in doing this. Basically, what I'm trying to do is create an 800x600 design that does not incorporate the ABRIS and Shkval. I would also like to have this work in client mode, so I can use it on a small touchscreen panel PC that I have. I will likely also remove any of the keyboard emulation switches since I understand these won't work in client mode (I guess you'd need some kind of touchbuddy-like server app to handle those--or wait until ED supports them over the network, right?).

On the contrary, it works quite different. There are two non-FFB modes and one FFB mode. In the original 1.0 non-FFB mode, you press the trim, then must recenter your controls (cyclic & rudders) in about 1 second before the trim locks in. In the new 1.01 non-FFB mode (which I prefer), after you press the trim, the simulator will wait for as long as it takes until you center your cyclic and rudder. I like this because it takes the guess work out of knowing exactly when trim locks in and seems to avoid "bumps" upon trim lock. People who have sticks that do not center precisely will sometimes report trouble with this mode since the sim may not detect that they have centered their controllers and so appears to have locked-up their controls (the G940 does this). I find that adding a bit of deadzone in the offending controller (either cyclic, rudder, or both) can cure this. With all this said, FFB trim is quite different when it comes to the rudder. In FFB mode, when you hit the trim button, your cyclic will instantly lock in its new position (good), but the revised virtual rudder center position will also be locked in instantly (bad)! In other words, you don't get the 1 second grace to move the rudder to center before trim locks in, nor does the simulator wait until you get your rudders centered before it adjusts your yaw. You can see this by observing the controller window (Ctrl-Enter I believe). As soon as you hit trim in FFB mode you will see your rudder position slide over immediately. This is especially noticeable if you are currently holding the pedals in a highly deflected position. While one can try to get used to immediately centering the rudders upon trim activation, I could just never get consistent performance, and unless your pedals are almost centered to begin with at the time you activate trim, it is almost impossible to get them centered fast enough not to induce unwanted yaw. For me, this is what completed my write-off of FFB mode in BS. Hopefully, we'll see a patch, but until then, the 1.01 style trim actually works very nicely.

DickDastardly or Gadroc, how are you folks editing your layout in touchpal.xml? Do you use a tool or is everything hand edited right now?

Ok, I figured it out. There was a little more to it. I don't really claim to know what I'm doing. I read a lua (sorry, Lua) tutorial today, and now know enough to be really dangerous. I guess I was thrown by the coroutine stuff. Your hint suggested that I didn't need it. What I ended up doing was taking the stock export.lua supplied by the TouchPal project and adding three lines. 1. Add this to the end of LuaExportStart(): g940socketsetup()2. Add this to the end of LuaExportAfterNextFrame(): g940leds_AutopilotTargetingMode()3. Add this to the end of the file: dofile("./Config/Export/G940leds.lua")Then, inside G940leds.lua, I changed 'c' to 'd' in the g940socketsetup() function. This was needed since TouchPal calls the socket 'c'. Finally, I refactored g940leds_AutopilotTargetingMode() to get rid of the coroutine stuff and the internal loop (since we're now calling it on every frame). function g940leds_AutopilotTargetingMode() local MainPanel = GetDevice(0) local bankhold = get_argument_str(MainPanel,330) -- Lit button local pitchhold = get_argument_str(MainPanel,331) -- Lit button local headinghold = get_argument_str(MainPanel,332) -- Lit button local altitudehold = get_argument_str(MainPanel,333) -- Lit button local flightdirector = get_argument_str(MainPanel,334) -- Lit button local autoturn = get_argument_str(MainPanel,437) -- Lit button local airborne = get_argument_str(MainPanel,438) -- Lit button local forwardhemisphere = get_argument_str(MainPanel,439) -- Lit button local groundmoving = get_argument_str(MainPanel,440) -- Lit button -- Create a string with flightdirector on the autopilot buttons for use with DCSAddRedIfGreen local fdstring = "0.00.0" .. flightdirector .. flightdirector .. "0.00.0" .. flightdirector .. flightdirector d:send("DCSSetGreen=" ..autoturn..forwardhemisphere..bankhold..pitchhold..airborne..groundmoving..headinghold..altitudehold..";DCSAddRedIfGreen=" .. fdstring..";") end With these changes, TouchPal and G940LEDs now run in perfect sync. Dave

I have a G940 and after a month of stuggling with it in Black Shark, I've gone back to non-FFB trim using the 1.01 style trim. As Gadroc also alludes to, there is considerable slop in the center (in both FFB and non-FFB modes), but at least in non-FFB mode you can set a deadzone to compensate. I use 15% deadzone on both the x and y axis on the stick and also on the rudder. If I don't do this, the trim doesn't always recognize when I've centered my controls. A secondary problem with FFB trim is that it almost always induces unintended motion in the aircraft and rarely permits you to lock the attitude exactly where you want it. Non-FFB trim avoid most of these problems. The G940 hardware is evidently capable of being very precise, however, the games it is used with (evidently) must be carefully programmed to take advantage of this precision. In FSX, for example, I don't notice any of the slop evident in BS. For non-FFB mode we're apparently stuck with the slop in the stick until Logitech does something about it. I guess what I'm trying to say is that when it comes to the G940, Black Shark isn't exactly it's killer application.

I'm interested in doing the same thing, but haven't tried it yet. I would think that the client would need to know the ip address of the server right. I took a quick look in the source, and with my limited cs knowledge I *think* the client is just binding with the loopback ip 127.0.0.1.

I've been trying out TouchPal, but can't get both it and the G940 LED software to work together (they both customize export.lua). I've tried simply merging them together and removing anything in common, but it just results in lockups. Is there anyway to get both of these to play together nicely?

Can some one give me a hand. I'm so close to getting this to work. 1. I have a 1920x1200 main monitor and a 1024x768 secondary monitor on an nVidia 8800 GTS 512 (latest drivers). I am running Windows 7 x64 and BS 1.01. I've set up TouchPal according to the instructions (and am pretty confident that I have it configured exactly as it should be). 2. If I run BS in Full Screen mode, TP shows up correctly on the second monitor and functions properly. The ABRIS and Skval do not show up, but this is expected in full screen mode. The desktop just shows through the ABRIS hole. No problem yet, just an observation. 3. Now, if I proceed to setup multi-monitor mode using all the instructions in the preceeding thread, the following happens. When DCS loads, it presents a splash screen. This screen is stretched across both monitors. When BS starts, I see both the ABRIS and Skval displayed on the second monitor in their correct locations; however, I don't see TP. Instead, I just continue to see the DCS splash screen in the background. Alt-tabbing out permits me to bring TP back to the front where I can actually see the ABRIS and Shkval in their proper locations and even interact with the buttons. But as soon as BS gets the focus again, the splash screen again gets sandwiched in between TP and the ABRIS/Shkval and I can no longer see any of the buttons. Has anyone seen this? Any ideas on how to fix it? Edit: I just noticed that a very similar (perhaps the same) issue has been logged by someone else on the Google code site as issue 4 (http://code.google.com/p/touchpal/issues/detail?id=4).

I'm also interested in the answer to sinelnic's question. As far as the position of the HUD goes, your explanation is very interesting. So you're suggesting that the drivers are the issue here. Your experience with the VR920 makes that seem reasonable. However, it also seems that it should still be possible for ED to make a tweak to the rendering that would have the HUD render in a more "standard" way (it's not only the nVidia drivers that fail to render this correctly, the iz3d drivers do the same thing). Of course, that doesn't mean I wouldn't welcome a driver solution too.

I downloaded and installed these last night, and made a comparison with the nVidia drivers. I found no issues having both these and the nVidia drivers installed side-by-side, as long as they are not bot active at the same time. I haven't actually measured frame rate yet, but the iz3d drivers actually felt more performant than the nVidia drivers. This was a surprise since I figured that nVidia might have an advantage being so close to the hardware. But both work very smooth at 1680 x 1050 on my 8800GTS512 (without the stereoscopic effects turned on, I normally use 1920x1200). For anaglyph glasses use, the iz3d driver seems to have more and better options than the nVidia Discover driver. One nice thing is the ability to choose among multiple types of colored glasses, not just red/cyan. In fact, there are two choices for red/cyan, one is the default, the other is "optimized". When viewing with my nVidia Discover Anaglyph glasses (red/cyan), the default setting looked at first similar to the nVidia driver, but then I noticed that the HUD was completely invisible to the left eye as well as parts of the ABRIS. This was not going to work. However, when using the "optimized" red/cyan view, things were greatly improved. The view is significantly brighter, I could now see the HUD out of both eyes, and overall color was much better; much better than the nVidia drivers in fact. Greens in the landscape were green, and blues lost their shimmer, and were thus much cleaner. I really, really liked this mode, but alas! there was some pretty serious ghosting going on. I tried with another pair of darker glasses, which got rid of some of the ghosting, but it also dampened the color as well. Anyway, going the anaglyph route always involves a tug of war between color fidelity, ghosting, and glasses. These new drivers least provide a way of seeing another option. I have a suspicion that I will probably end up sticking with the nVidia driver since, despite the more muted colors, the display is quite bright with virtually no ghosting. With that said, these iz3d drivers are very welcome, especially for ATI users. They seem to be easily as fast as the nVidia drivers and provide some nice options.

Well I just received my official nVidia Discover glasses. They were 10 for $10 with free shipping from http://store.nvidia.com/DRHM/servlet/ControllerServlet?Action=DisplayProductDetailsPage&SiteID=nvidia&Locale=en_US&Env=BASE&productID=148411500 These are definitely better than the two old pairs of anaglyph glasses I had been experimenting with (one red/blue and the other red/cyan). On my 24" color calibrated LCD monitor, ghosting is now almost undetectable. Color is slightly improved and the image also seems to be somewhat brighter. As for the latter, what I think happens is that because these glasses completely cover the eyes (on me, they sort of wrap flush with my face), there is fuller coverage of the eyes and less light leakage from the sides. I think this helps the eyes adapt better and compensate for the lower brightness. The bottom line is that I am now enjoying playing BS in this mode even more. For what is essentially a $1 upgrade, I'd say I got my money's worth. With regard to the issue about the cannon sight in the HUD, I've found that zooming way in while targeting helps considerably as the parallax distortion can be confined to within the sight's diameter (I have the zoom axis assigned to a wheel). It's a pretty good work-around. Of course there is still the issue with the pulsating helmet sight, but it's more of an annoyance than a practical issue. Anyway, hopefully we'll eventually see ED address these eventually.

Request: Fine tune 3D Vision support. Request: Fine tune 3D Vision support. I recently found out about the "free" 3D Vision Discovery mode in my nVidia driver after reading a couple other threads about it. http://forums.eagle.ru/showthread.php?t=46349 http://forums.eagle.ru/showthread.php?t=45677 This permits the use of cheap anaglyph glasses for true stereoscopic 3D in DCS:BS. Even with the downsides associated with these kinds of glasses, the effect is very impressive and very immersive. At first I didn't think I'd actually play the game this way, due to side effects of the colored glasses; but dropping the resolution just a tiny bit gives me very smooth frame rates. I've also mentally overcome the color issues for the time being (just think sunglasses...or that Spielbergy, muted-color look :-). In any case, its good enough to make me think about eventually upgrading to the real 3D Vision hardware when they finally support at least a 24" monitor; but in the meantime I'm actually pretty happy playing around with the colored glasses. Alas, after using this for a few days, I've noticed a few anomalies. Others have pointed these things out too, but now that I've noticed them myself I'd like to make a formal request of my own to ED. The stereoscopic effects are really close to perfect; but a few nagging issues remain. If these could be cleaned up, I'd be a real happy camper. * Improve the focus distance of the HUD * Fix the "pulsating" helmet sight * Fix rendering of clouds * Improve the focus distance of the mouse cursor (which hovers too far above the cockpit) I'm sure others might have some things to add to this list, but I don't think there are a lot of them.

Wow. Thanks for pointing out this "hidden" feature. I knew that the nVidia drivers supported their 3D Vision hardware, but didn't realize that it supported red/blue glasses out of the box. I happened to have a pair in my desk drawer and turned the feature on, and found the effect to be unexpectedly good. Actually, I'd say it was better than the experience I had a couple years ago with a pair of eDimensional shutter glasses that I ended up returning. Alas, I don't think that I'll be doing much actual gameplay with this as the image is dark, colors are off, and frame rate is bad. But its a good preview of what's possible. I'm sure the real 3D Vision hardware helps a lot. Has anyone tried BS with a full 3D Vision setup? What's your experience?

Finally gave this a try today. I'm on Win7 x64, and it works great. I was a bit confused at first as my buttons lit up like a Christmas tree in all sorts of colors and states, and didn't react to changing the states of the AP or TM. However, changing coroutine.create to g940leds_AutopilotTargetingMode solved that, and now it does exactly what I was hoping (guess I need to play with g940leds_example to see what that actually does). This is an excellent little utility that finally pumps some real value into this formerly dormant feature of the G940. Oh, and one small request. Would it be possible to have the lights be turned off upon exiting the led app--or better yet, upon exit of BS. Right now, after I exit the lights remain in their last state, so I restart the application briefly to shut off the lights, then exit again.

Actually, the x36/35 combo is quite nice for DCS:BS. I don't know about XP, but under Vista and Windows 7 it works great. You can even do shift functions easily with the modifier keys in BS. I recently replaced my old Saitek with a G940, but with the exception of more buttons, I think my in-game control with the old Saitek was actually better.

Hmm. I don't seem to have drift. But regardless, how are you folks managing to hover hold and use the mini-stick to steer the Shkval at the same time? Even if my mini-stick seems to be working technically, I find that that I can't reliably push it around for any length of time without inducing cyclic movements that end up upsetting my hover. Consequently, I find that having the Shkval slew command on the throttle's POV seems easier.

I think mine is working "perfectly". At least I haven't had any issues yet. Here is how I solved my own drift issue. * First, make sure your mini-stick is calibrated. * Leave all the Logitech profile settings for the mini-stick at defaults. * In the BS internal controller config, assign the Shkval horiz & vert axis to the mini-stick. * Go to the Axis Tune panel for the horizontal axis. Push the mini-stick left and right, then center it. If you do this multiple times, you will probably notice that center does not always land in the same place. This is why it drifts. To correct for this, increase the deadzone in the panel until the red dot always lands on the horizontal (deadzone) line when you release it. For me, this put me at a 20% deadzone. * Do the same for the vertical axis. Although I didn't need as much deadzone here, I increased it to 20% also to keep the two axis in balance.