CyBerkut

Well, that picture shows 2 things set up for Joy X and 2 things for Joy Y. I see they are for "different" controllers (due to the Logitech arrangement of 3 devices), but perhaps that is still the source of conflict. Do the throttle and pedals have other axis available to choose from?

And are you sure you are not inadvertently editing the game mode settings for real mode play, or vice versa?

Bucic, if you cast a vote in a category, it will then show you the current results for that category, even if you revisit the link (from the same computer).

Ah, OK. Well if it does work, you have a low cost solution. Just watch out for unintended consequences.

Well... the obvious question comes to mind... Is it programmable? If not, what is your plan to make it a useable input for DCS:BS? [it looks like a fairly standard add-on number keypad, so I presume it would conflict with your main keyboard if you're thinking of just changing key designations in the DCS:BS options...) I'm sitting here feeling like I'm missing something.

- Console-ation: Control the aircraft of your choice with a Wiimote, and tell everyone "It's the ONLY way to fly!!!" - X-Box Jox: Show the world that nobody, but nobody does it better than Micro$oft... - Hip Hop Bomb Drop: Start the burners heatin' and put down the beatin'! No 'hood is safe when you go medieval on their azz. Crank up da' rap, then blow up their crap! Fo Shizzle! Bonus: Soon to be interoperable with Grand Theft Auto, for multiple modes of mayhem!

It's a shame that DCS:A10C isn't on the most anticipated list... :( (kind of a missed opportunity...)

Or, perhaps the other way around... :shocking:

I remember Urze having a blurb up on his (now defunct) Leftside Limited website about running TouchBuddy on a PocketPC. That is a different (probably less demanding) kettle of fish from displaying Abris (or Shkval) though.

It's easier to think outside the box, when you are *actually* outside the box. ;)

Interesting setup. Very nice! Could you have used a USB mouse on one of those cat 6/USB connections to center one screen, and then switched around connections to then center the other one? Would the changes stay in effect if you temporarily disconnected a USB display (for the mouse) and then reconnected it?

In this thread: http://forums.eagle.ru/showthread.php?t=37979&highlight=FreeTrack+Wiimote This post in particular: http://forums.eagle.ru/showpost.php?p=633913&postcount=4 Note: To update information about myself in the above post. I have purchased a TrackIR 5. It appears to work well, but I haven't really spent much time with it, or actually flying DCS:BS, as I'm currently holding off until I get a new gaming desktop, and some other things done. In that same thread, Sharkster64 posts multiple times about another alternative, Cachya. It uses a webcam, and instead of building a point model, it uses a paper triangle target that you can print out. One downside is that you will need to be playing with enough ambient light in your room for the camera to discern the target. You still have the CPU load of using a USB webcam, but it is reported that you can run Cachya on a different machine over your LAN, which would take the processing load off of your main gaming/siom machine. I haven't stayed up to date on the latest and greatest with FreeTrack. When I bought the TIR 5, the only method to get roughly comparable tracking FPS with the current FT was to use a Wiimote as the camera. Earlier versions of FT would work with earlier TIR cameras, but then Natural Point asked them to quit including TIR support in future versions of FT. There was some talk over in the FT forums about possibly using some camera for the Sony PS3, but I never followed up to see if somebody got that working. In a different thread, 'Winder made this informative post: http://forums.eagle.ru/showpost.php?p=682547&postcount=28 Another post I made later, which better reflects my growing weariness with the Bluetooth startup routine, etc.: http://forums.eagle.ru/showpost.php?p=649570&postcount=4 Hope that helps you in some way. :)

robinhood, what camera are you using with FreeTrack? A USB webcam, a Wiimote, or ??? A USB webcam will impose a processing load on your CPU. The Wiimote processing load is zero, or VERY close to it... with the tradeoff of having to mess with Bluetooth, and either changing batteries or making an alternate arrangement. You can search on older posts I have made in other threads for more detailed coverage of that subject.

LOL! If you can handle the Internal Revenue Code, then lua is probably within your reach. It's bound to be more logical. (You might want to get it all worked out before 1/1/10 though...) ;)

Gadroc, you're thinking like a coder, and sobe is probably thinking like an end-user. This magic you folks have conjured is a bit mystifying to us mere humans at times. ;) Seriously, it can be a bit intimidating, as it is a lot to wade through. sobe, the short answer to the first part of your question appears to be, "Yes." The answer to the second part appears to be, "do things the same way as before the enhancement". My understanding is that we are still not going to want to put the ABRIS or Skhval displays on the client machine(s) though. Those would not run well over than LAN, correct?

Well, proper immersion can mean different things to different folks. Other folks might put more emphasis on having higher resolution to make reading labels easier. Others might make the bottom 3 screens touchscreens and find that reaching to the left and right to flip switches located closer to where they would be in relation to the seat to be more immersive. As for the mess, I imagine his goal is to clear up at least some of the faults you listed (ie. "repeating or wrongly scaled parts"). As for hemispherical projection, here is another possible way to go: http://www.fighterops.com/forum/showthread.php?t=7965 To each his own.

Panzer, I voted for realism... but I did so because I largely agree with something you wrote in another thread. That being that balance can be addressed by mission design. I do think that balance is very important. Coders can certainly have an effect upon that, but they don't have exclusive control over it. Realism (talking about aircraft fidelity here), on the other hand, is much more in the hands of the coders, with less opportunity for the mission designers to tweak/adjust.

Thanks, Case. It really is your proposal, just fleshed out with what might be a way to get there. As mentioned by someone previously, these issues also have a potential impact on the DCS series down the road. I think we all want to see an optimum arrangement achieved. We, the multitude of users, look at this with varying levels of priorities... Realism, balance, performance, functionality, mod-ability, etc. E.D. has to weigh everything out and balance that along with the bottom line.

I think this more nuanced concept has merit, as it doesn't necessarily leave the folks with home built cockpits, etc. completely out in the cold. I don't know how feasible it would be for E.D. to implement with the current export .lua file system. It occurs to me, that perhaps E.D. should examine the possibility of splitting the current client export.lua file (hope I got that right) into several files that would allow a more granular approach, which could enable a more selective control at the server. Perhaps something like: cockpit_export.lua For handling status of switches, lights, etc. ownship_export.lua For handling datalink of the user's position data target_export.lua For handling datalink of detected target position data The server could then enable just the first one, to allow folks to use their homebuilt pits, TouchPal, TouchBuddy, LOVP, BSVP, etc., without enabling data linking. OR, the server could enable the first two, to allow data linking without target sharing occuring over the data link. Enabling all three would open up the whole ball of wax. The above is meant to illustrate the concept, not necessarily the particulars of how it should actually be divided up. I realize that it would require E.D. to re-write some of the core code. Whether it is worth the effort versus the estimated benefits to MP play is better judged by those in the know. It would also have fallout on the 3rd party side of things. Homebuilt pits, TouchPal, TouchBuddy, LOVP, BSVP, etc., would all be affected, and need to tweak their code to reflect the new file structure. As a potential benefit though, they could potentially see more MP servers that allow their use online. CB sends

Yoda, would it be feasible to make part of the code locked (perhaps compiled, and that section of the code not open source), while making the parts that enable folks to make instrument panels, etc. open? Basically, put a notification handshake to the Lockon Server in the compiled part, along with some indispensible portion of code that would not be easily recreated by someone else (of bad intentions)... OR, similarly, make the underlying wizardry of LEAVU closed/locked/compiled (with a hard-coded handshake to the LO server), with some sort of SDK for folks who want to make instrument panels, etc.? Just trying to think of something that could address the concerns being expressed by some on here. I realize the above (especially the second version) may not be trivial to implement. If it's not feasible, so be it. If it is feasible, maybe it is worth considering. --------------------------------------------------------------- Personally, I think it will ultimately come down to E.D. doing something in FC2, as the reality is (however distasteful it may be to some folks) that if Yoda can develop it publicly/openly, someone else of bad intentions could develop essentially the same capabilities privately. Yoda's open source approach offers the possibility that everyone could end up on a level playing field, even if it does mean that some other folks will have to step up and develop the user interface parts for other aircraft platforms. Folks, if Yoda just stopped right now, and threw the code away, the community would still have the possibility looming over its head of someone else developing a similar capability and NOT sharing it with everyone. THEN you really would have an imbalance, and one that would not be easily corrected. Like it or not, Yoda doing this in an open manner is a good thing. E.D. can see it, the community can see it, and one would hope that some folks will use the tool to do equally cool things for the other aircraft. CB sends

robinhood, you have to run DCS:BS in windowed mode to accomplish getting that displayed cockpit up above, correct? I think you may be pretty much hosed (at least for the time being), given your disparate collection of monitor sizes. You may still be able to gain some minor improvement via settings tweaks, but I wouldn't expect anything truly significant. NOTE: I am NOT an authority on ATI / Eyefinity. I could be wrong about something(s). If so, I apologize, and will happily accept correction(s). Some potentially useful links: ATI's web site: http://www.amd.com/us/products/technologies/eyefinity/Pages/eyefinity.aspx ATI's Eyefinity tech brief: http://www.amd.com/us/Documents/ATI_Eyefinity_Technology_Brief.pdf A good review of ATI cards, etc.: http://www.anandtech.com/video/showdoc.aspx?i=3679&p=1 You'll notice in the review (3rd link) that the HD 5970 has quite a bit more capability than the 5870 or 5850 offerings. As of that writing, the HD 5970 is the only card that ATI has enabled Crossfire Eyefinity support for in the drivers. Based on that, my *guess* would be that you would see some improvement by going to a 5970 as the primary card. It should be emphasized, I don't KNOW that is the case. One of the things that may be contributing to confusion, or at least less clarity, is terminology. We should keep in mind that ATI uses the term Eyefinity to essentially name the technology, not a particular mode of operation. In ATI's own words: Eyefinity has the capability to run monitors in "Display Groups" and/or as "Extended". My understanding is that to run multiple monitors in a "Display Group", they must be the same resolution, and have the same orientation. I get the impression that you are running with all 6 monitors as "Extended". If you had 6 (same resolution) monitors with DisplayPort connections, running off of one of the (not yet released) 6 DisplayPort version cards, you could theoretically run DCS:BS in full screen mode spread across those displays in a 3 across, 2 vertical array, and probably get acceptable frame rates. As you have discovered, DisplayPort figures prominently in ATI's development of Eyefinity. I don't know how promising an outlook you have with trying to go the three card route with non-DisplayPort monitors. By the way, have you looked at SoftTH at all?

Have you ever seen the Statue of Liberty? It's copper. Oxidized copper... Copper is the true secret to stealth technology!!! All that stuff about angles and special paint/coatings is just a smoke screen to hide the truth! Muhahahaha!!!... Must go now, I think that is the FBI pulling up outside... :helpsmilie:

It is certainly too early to condemn the Saitek X65F to oblivion, as we haven't seen its quality and useability yet. A lot of the criticism about it not being FFB is fair though... Saitek ran a poll in their forums, and the overwhelming response was for an FFB HOTAS. From the community's perspective, this choice to go with an FS HOTAS came out of left field, and was a disapointment. People are entitled to that disappointment, especially in light of the existence of DCS:BS, where a well implemented FFB would really enhance use of the sim's trim function. I can see how an FS design could appeal to the decision makers over at Saitek. Saitek has taken a lot of guff over the pivoting mechanism / centering spring design utilized in current sticks, etc. Getting rid of that probably looks good to them. The FS design *could* be very robust. While I understand that some folks are really interested in replicating the aircraft controls as closely as possible, I can be reasonably satisfied by what works well (whether it duplicates the aircraft's controls, or not). The human mind can be very adaptable (well, *some* human minds can... ;) ) so it is entirely conceivable to me that a good FS stick could work well in many sims for aircraft that don't have FS sticks in reality. For instance, I suspect it will work fine for the upcoming DCS:A10C sim, for folks that want it to. I'll agree that FFB may have some inherrent compromises, but I don't recall MS Sidewinder FFB2 users complaining about that stick being as bad around the center for DCS:BS. Software/drivers seem to be the key. With word-of-mouth (ie. forums, etc.) being so important in marketing, you would think that Logitech would be parachuting at least one programming wizard into E.D.'s offices to help make the G940 work better in DCS:BS, etc. @ Baksie (the O.P.). My advice would be to wait. Take some time to assess your wants and needs about how to control your sims. Is it realism that rings your bell? (If so, which of your sims does the realism matter most in?) Do you want the stick to move a significant distance, or do you think your mind would adjust to a Force Sensing stick that has a 1/4 inch (or so) of throw? Do you want/need a LOT of hats/switches/rotaries, etc.? Were you happy with your X-45? Would an X-52/X-52 Pro serve your needs well now? Did you like your CH Pro pedals, or do you want something with a different spacing or feel? Are you open to physically modifying your equipment, or do you prefer to use them as they come out of the box? What is your budget limited to? How long can you stand to wait before acquiring something to replace your current equipment? The answers to all of those questions could factor in to your decision(s). I suspect Viper's suggestion of buying a low cost stick for now would be a good idea for you. Good luck!

The possibility had occurred to me as well, if one wants to resign oneself to using one of the non-FFB work-around control schemes. I imagine a motivated individual could acclimate to it, and that someone who wanted to use the stick's twist (also force sensing, as I understand it, so little movement on that axis, if any) instead of pedals could do that as well. That would seem to offer a quick way to get rudder input back to center, too... I still think a *properly*implemented* Force Feedback stick and rudder pedals would be much better for DCS:BS, but so far it appears that you still have to roll your own to approach that. For a non-traditional approach to controlling the Black Shark, the X65F could be quite good. Saitek's front man over on their forums certainly seems to think so, FWIW. Time will tell.

Well, Panzertard, based on your avatar, I can see why you might aim for the butt when going for a headshot... :music_whistling: