CyBerkut

http://forums.eagle.ru/showthread.php?t=40877&highlight=Producer.cfg ;)

Such things are moving, greasy targets. ;) I say that because the hardware capabilities keep changing so rapidly. With Intel / AMD / nVidia / ATI all keeping their hammers to the anvils looking for the next edge on their competitors, the magic ratchets up faster than a WoW junkie mainlining Mountain Dew and HoHo's. I'd say that in at least some of the areas that matter to flight simmers, the OS / software has difficulty keeping up with the hardware. For instance, DCS:BS, as amazing as it has been already, is not yet able to capitalize on the massive memory that we can supply to it on our hardware. As for publishers/authors decisions... well, some of that is going to trace back to where they are coming from. Most are understandably going to make (hopefully) good business decisions and the bottom line will largely be in the driver's seat. In some other cases, you may get a situation where the author(s) are more interested in pushing the envelope to see what they can create, and the sales of product (if applicable) may largely be a means to keep funding the development of something that they truly love. X-Plane may be more like that... Fortunately, it appears to be common practice to make many features (especially in graphics) optional, which lets people sacrifice some bells and whistles to make the program run well enough to be tolerable on whatever hardware they have (within reason). It *IS* indeed hard to tell where things will go sometimes... but ain't it fun?!? ;)

Flyby, I'm not going to hold myself out as some sort of expert on the subject. I would *expect* that the new memory controller arrangement to give us better performance. It may not be something that is readily apparent in all of our *current* flight sims, since we have some limitations (such as only using a single core in XP, and non 64 bit applications that don't access as much memory as a 64 bit app could...). Of course, then one has to look at whether their purchasing decisions will be for the current software / OS only, or with an eye toward what is reasonably expected in the not-so-distant future. Folks go at that from different perspectives. If one is just trying to get the most 'bang for the buck' for the current applications, then they might very well go with a Core 2 Duo or Core 2 Quad, with an eye toward overclocking the cheesewhiz out of it. That can make a lot of sense to someone who doesn't have much cash to throw at it now, and especially so if they expect to have more discretionary cash later on when they are likely to build a new rig (as in having killer job prospects after finishing college). I say this because (on the Intel side of things), the newer chip series use a different socket / motherboard. To further complicate things for some flight sim enthusiasts is a cruel choice between Win XP to allow horizontal & vertical display spanning, or Win Vista / Win 7 to get access to multi-core affinity performance increases. Some of us take a longer view on the hardware decisions for whatever reasons. In my case, the spousal unit (aka the Chief Financial Officer) is understanding enough to be supportive of a new desktop purchase, but it will probably be the only one for at least a few years. As such, I'm attempting to be patient, save up more overtime, and go big with an eye toward expandibility / upgradeability later (incremental changes / additions are easier to get CFO approval for than complete computer replacements). For me, making the jump to the newer chip socket / motherboard makes sense. As for i7 vs i5 vs i3, I don't see a good reason to go with anything less than an i7 (for me). I'm currently leaning toward a model from CyberPowerPC with a water cooled i7 that is "factory overclocked". No doubt it would be cheaper to figure out more things for myself, but the plethora of selections to make creates many opportunities to get it wrong (and end up with something that doesn't work as well as I want it to). As I said, I'm not an expert on the memory changes. As I understand it, the nehalem arrangement yeilds much better memory data transfer rates (or at least the possibility for it). That should allow for better sim performance, if not now then at least in the next versions around the corner.

An article of possible interest: New Intel Core i5 chip surfaces on retailer's Web site http://www.computerworld.com/s/article/9136298/New_Intel_Core_i5_chip_surfaces_on_retailer_s_Web_site?source=CTWNLE_nlt_dailyam_2009-08-06 Flyby, the Nehalem design based processors (including the i7) include the memory controller inside the processor. IIRC, the preceding design's memory controller was affected by the "Front Side Bus" clock speed.

Yes, I'd start with a driver update/reinstall, as that is fairly painless. If that doesn't nail it, then uninstall/reinstall the SST software. Before moving on to anything more drastic (ie. DCS:BS or Windows reinstall), I'd recommend that you go into "question the paradigm" mode... as in the assumptions/conclusions that everything is setup properly. Feel free to post screen captures of anything relevant (ie. the DCS Options screen(s) showing the controller setups). The above is not intended as slam upon you. Many of us have had a problem at some time or another that we were staring at, yet could not see/recognize. A fresh pair of eyes can sometimes spot things... Good luck!

dnnzed, are you using Saitek's SST software to assign the keystroke(s) to the button? If so, which version of SST? Have you checked the DCS:BS Options screen for the controllers to see if you have any conflicts?

Nice to hear from you over here! I forgot about that being the shop. I can see why the clients love it. I think it's a trip! I actually have a lot more time playing MechWarrior than I do flight sims, so the mech pit definitely caught my eye when scoping out those forums. Maybe some day we'll have a mech game with 6 degree of freedom, 3D click-able pits... Oh BTW, "gaudy" is a relative term. The aircraft sim pits usually tend to be painted a bit less flamboyantly (and we all know how conservative that Triigger is :megalol: ) ... on that mech pit, it works! :thumbup:

Oh sure, gloat about it... :D

Trigger, you're killing me... If having sufficient space is the issue, weatherize that enclosure, and hang it off of that elevated deck you had in an earlier picture... :D Kind of similar to what this guy did with a mech pit inside his garage (but less gaudy): http://www.simpits.org/forum/index.php?t=msg&th=144&start=0&S=53f644c8a9ffbe22d1070568242eb254 I bet your RC Helicopter flying neighbor would love it! ;) And just think, eventually, you could have a KA-50, an A-10, a AH-64 and ... all hanging off your deck. :pilotfly:

I don't think anybody can argue about you needing help... ;) That is some very nice work there, Trigger! :thumbup: Soldering on those connectors with the pins so close together will severely test anyone's patience. :disgust: Ribbon cable can indeed be fragile. The nice thing about it though is you can use good quality crimp on connectors and save yourself a lot of soldering hassles (at least on one end). And like many things, some ribbon cables are more robust than others... Another way to go is to keep an eye out for bargains on pre-made cables of sufficient length. Cut the cable the appropriate point(s) along its length, and then you just have to strip back the cable on the cut end(s) and solder to your switches, etc. If you get cables with a male on one end and a matching female on the other, it can save you a LOT of soldering.

Mark, any chance we could eventually see Force Feedback Rudder Pedals? I realize that it probably looks like a small market for that, but in a sim like DCS:BS, it would really make the trim functions work like they should.

Yes, it should be easy. Other people have hybrid HOTAS systems working, so it shouldn't be an issue. The degree of complexity will largely come down to whether you want to use the controller settings built into DCS:BS, or utilize Saitek's and/or Logitech's interface software. Any combo should be do-able, provided you take adequate care to avoid conflicts. Good luck!

I can see merit in the OP's post, but I have to say that I think it would be a mistake to _switch_ DCS to a monthly subscription model. Games that succeed with that approach largely have a different dynamic at work in their communities. I don't play WoW, but I hang out on a Teamspeak server where many of my team mates are into WoW. While I can only stand to listen to them going on about obtaining their "enchanted pants" or whatnot, for a short while, I think I have been getting the drift. They enjoy the leveling up, acquisition of new objects and abilities, and making their team of disparate abilities work. The flight sim community can have some parallels (the teamwork), but the acquisition of "stuff", and leveling up are not really the focus with sim'ing. Personally, a subscription fee (instead of buying the program outright) would also push my WTF button. While I have team mates that are into WoW and Eve Online, I avoid those largely because of the monthly fees. I probably wouldn't like WoW that much any ways, but Eve Online would probably suck me in for a few months. I do see a potential spot for a subscription service in the DCS universe though... If someone (ED/TFC or some 3rd party) had a server system with a persistent 'world' that had a truly dynamic campaign, that could justify a nominal subscription fee (maybe $5 per month) as a value-added, optional service. It would need to have good enforcement against cheating, Team killing, etc. It should probably do whatever can be done to promote the social networking aspects of online gaming. Obviously, new content is desirable where feasible... however, I think content (weapons/aircraft) largely falls within the purview of the sim authors (maps and missions would seem to be feasible for 3rd parties though, as they appear to be now). The DCS series software would have to have the hooks, import and export functions to support a stand alone server running a "world" where pilots could connect, get their mission assignments, fly them, affect the status of the war (depending on their success or failure, etc.), and have their record tracked. I don't know the internal workings of the DCS software, so I can not know what is feasible and what is not. I would say it would be a worthwhile goal to design an option where our DCS client machines could handle most of the same things they do now, but off-load the campaign heavy-lifting to a dedicated server. I assume the dedicated server would have to know enough about flight dynamics and the characteristics of the various planes / weapons to referee the action, but I would think that it's graphics needs would be somewhat simplified, and that there might be other aspects that it could be stripped down on. With the increased horse power available now, and improvements upon the bubble system approach utilized in F4's campaign, it *seems* reasonable that a good campaign server could be created by someone. I have no idea whether ED/TFC would be willing to risk relinquishing that much to a 3rd party. I *think* it would be possible to make the necessary numbers/formulas available without adversely affecting their Intellectual Property rights (but I don't *know* that). Maybe it would require licensing and/or Non-Disclosure Agreements. None of the above is to suggest that ED/TFC should remove the campaign play / multi-player support that they have now. That is rightfully part of their fine product, and there is no reason to subtract anything from it. Providing hooks, etc. could just open up another dimension to the piloting community, where potentially someone else does the heavy lifting on the elusive and challenging "dynamic campaign". Someone might find it more feasible to implement in a different programming language(s) and/or game engine. It could end being a Linux app, or Windows app, or ..., or even multi-platform. As long as the data is flowing back and forth properly, we DCS pilots won't care. Just food for thought. ED/TFC are doing a fine job with a product that is remarkably polished in its initial release. The upcoming patch looks to be very comprehensive, and responsive to the user community. I don't find fault with that, or whatever they choose as their business model.

Well, it is a FFB joystick, so I would say it isn't aimed at Saitek's X-52, but rather at what Saitek supposedly has coming next... http://forums.eagle.ru/showthread.php?t=43031&page=2 (or perhaps more accurately, to fill a niche that hasn't been filled yet... an FFB HOTAS, which also happens to have a split throttle and includes rudders). It would be nice if someone came out with well made FFB rudder pedals. I suppose the manufacturers don't see enough of a market for that, though.

I'm not tellin' !!! :blush:

OK, I guess he prefers to be his own guinea pig. Either that, or he just doesn't like you. :P He is indeed a very smart fellow! Except for the 'trying the hint' thing the first time around, you're not too shabby yourself. :thumbup:

Trigger, do you ever communicate with Leo Bodnar (other than buying boards from him)? I seem to recall reading somewhere that he did some super wham-o-dyne FFB steering wheel project. Maybe he has some alpha or beta version FFB boards that he'd love to use you as a guinea pig on! ;)

Actually, I think you have it right. I wasn't thinking about your wise penchant for switching to hall sensors. Presumably, the circuit boards take the same voltage range of input for positional information as usual. That ought to allow you to do your hall sensor conversion. That being said... I would think that switching to hall sensors (necessitating the removal of the input pots) would largely negate the improvement on resolution that you were seeking by going with 2 FFB steering wheel PCBs. For potentiometer input based steering wheels, better resolution on newer models probably largely comes from using potentiometers that have more turns for a given resistance range. But then, your hall sensor conversion may very well give you better resolution in and of itself (which could be true whether you are doing a MS Sidewinder FFB 2, or using 2 steering wheel PCBs...). Of course, if the newer FFB steering wheels have finer control signal outputs to the motors... then you could still realize some improvement. Has your head exploded yet? :D I only have the single Saitek Evo FFB joystick at this point, so I can't test multiple FFB inputs simultaneously. I know that setting one of its axis to be the rudder input worked fine, so the software seems capable of keeping the axis signals straight. In seem to recall that you did some satisfactory testing with multiple FFB devices already... As for the patch and FFB curve use, I wasn't looking for that specifically when I first browsed the posting of the readme file. I'll have to give that a closer perusal when I can give it more time. :)

I couldn't say whether that is true, or not. I think the plethora of password protected servers is largely a natural response to some bad apples ruining the fun for others by team killing. Right now, as far as I know, the best tool for dealing with that problem (other than password protecting the server) is Acedy's server scripts. Any tools / features that further that effort could eventually open up some more servers. Getting some sort of user account scheme (ala some gaming networks) in place could help. IP blocking alone is not enough, as IP addresses can changed.

:thumbup: Sounds like a "keeper", Deigs! ;)

Semi-educated guessing here... I would think that you could use two FFB steering wheel PCB's to handle the X & Y axis signals... but it may very well require some work arounds that negate the potential advantage of increased resolution. I haven't followed the racing wheel controllers closely, but I seem to recall seeing some of them turning well in excess of 360 degrees. If you are using PCB's from a wheel that turns that many degrees, you may be looking at some serious gear ratios to get it down to the limited movement used by a cyclic (or joystick). It may be feasible to make the conversion electronically instead. On the other hand, the gearing down (or gearing up, depending on how you look at it) might be useful to get more torque. Trigger, I know that you are no stranger to gears, and I'm not saying they are necessarily a bad thing to add in, but it does introduce the possibility of mechanical slippage... which would reduce precision, and could feel "sloppier". I paused from writing this to attempt to quickly look up how many degrees of movement the Saitek R660GT had. I thought I had read somewhere that it was 270 degrees, but I can't find anything definitive with just a quick search. You would think manufacturers would list that in their specs. Ugh. Any ways, so far I have no experience with FFB wheels, so take the above for what it is worth. I still have plans on the back burner to eventually meld a FFB sterring wheel (probably a Saitek R660GT) to my old Thrustmaster RCS pedals to make a custom FFB rudder control. That would merely be a case of mechanical hacking (I hope) with the device simply looking like a Saitek R660GT to the computer. My electronics training was U.S. Navy circa 1975 (and not the latest and greatest stuff at that time, since they went with the time tested, tried and true approach to equipment selection). What you and Alex are doing is great, and looks promising. :) If I tried to figure that stuff out, I'd probably have a anneurism and stroke out... :book: :huh: :cry:

Trigger: http://www.saitekusa.com/prod/cyborgcommand.htm It is a Saitek Cyborg Command unit. You can see it on Saitek's main site as well, I just can't get to it while on the employer's network... :music_whistling: I started on a project like this after seeing the pics of Urze's. You'll notice that Urze took the hat switch out of the movable thumb rest portion, and moved it to where the "10" key is. You have to make the hole bigger for it to fit through, and modify the keyboard membrane switch so that the "10" key won't activate any more. (I put electrical tape under the clear plastic membrane, if I remember correctly.) I know Urze's early models had a hand brake lever, but he did away with that on the later model. It appears that he took the switches for the "15" and "16" buttons, and mounted them on the underside of the stick (where the brake lever would be). Those switches are on the same small circuit board as the hat switch. I used a buddy's dremel tool to cut the board to separate them. (You may want to map out the hat switch contacts/conductors before making the cut, as it would be easy to get the hat switch oriented incorrectly in the main unit if you don't.) I bought a bicycle hand brake and brake caliper set to cobble up the collective brake with. (The one I bought actually is designed to operate two brake calipers, so I can just adapt the second cable connection to operate a switch instead). I haven't implemented it yet, but my plan was to turn the brake caliper pads from facing inward (toward where a tire rim would be) to facing outward. Then, just position two flat surfaces, one to each side of the collective stick, for the pads to push against when the brake handle is not being squeezed. The surfaces/brake caliper pads need to be adjusted so that the pads are clear of the surfaces when the handle is squeezed, allowing the stick to be raised/lowered. Not as spiffy as some other solutions, but it should be able to be done without mauling the Saitek X-52 throttle. ;)

Has anyone asked Balu about it? He's a member of these forums.

This thread might give you a lead... http://forums.eagle.ru/showthread.php?t=29716

Great news, Hitman! May it be lucrative, and as long-lived as you want. :thumbup: