KungFuCharlie

I think we are confusing terminology now. My point is that you never trust that a programmer implemented something properly and you cannot always trust that the method someone chose to implement is the best one for the job. But none of those really matters in the context of this discussion anyway. I did not say or imply that writing LUA code or an external program was a bad idea. Well, if I did say that then I did not mean it in the context it was taken. There is a time and place for LUA and external programs. In fact, even with a fancy microcontroller system you still need to code something on the PC to interface with the device. Well, maybe... you might be able to use a generic HID driver but I think that will limit you drastically. Not sure, haven't hacked into the HID drivers in a long while. But then again we all have our own opinions on what is "right" and "wrong". And I am sure my opinion is biased on my education and experience which is why I believe a micro-controller based solution is definitely the way to go for a distributed simpit environment. Sure, the learning curve is a little more steep but in the end there are a lot more benefits.

Good call. There used to be a software application to do this same thing that was used by FPS players. Cannot think of the name now but I know it is outdated (unless they've released new updates).

52nd Virtual Fighter Wing The 52nd Virtual Fighter Wing is an online virtual squadron loosely based on the real 52nd Fighter Wing. The virtual wing is made up of the 22nd Virtual Fighter Squadron (F-15), the 23rd Virtual Fighter Squadron (Inactive), and the 81st Virtual Fighter Squadron (A-10). Currently the 23rd VFS is inactive until another aircraft becomes available or there is enough interest in the MIG-29 platform. Pilots in the 52nd VFW tend to be simulator enthusiasts that like as much realism as they can get. While we do goof off from time to time, the bulk of our virtual flying is either training or flying combat missions. We are recruiting for both the 22nd and 81st. We are also looking for other squadrons that would like to fly together. Squadron: 52nd VFW (22nd VFS, 23rd VFS, and 81st VFS) Language: English Homepage: http://www.52ndvfw.com Online Activities: Training / Combat Missions / Campaign Development Activity: Evenings (US Eastern Time) Forum: http://www.52ndvfw.com/comms/ Communication: Ventrilo Status: Re-Activated June 2010

It's not a bug... it is an undocumented feature. :megalol: If all you are worried about is DCS: Black Shark then you are absolutely correct. Likewise, if you're going to build a whole new interface for future games and / or build a screaming fast PC for every new generation of games that come out then you're also correct. But it would really suck if you design your simpit interface with the idea that you've got plenty of computing power and next year your kicking yourself in the butt because your simpit lags out the latest game you're trying to run. I know that even that is a little over the top and "dire" as you put it. :music_whistling:But you should never design for today's technology because by the time you're done that technology will have advanced a few generations. If you're going to put all the time and money into a simpit, make sure it will last you a few years so you can enjoy flying it instead of ripping it apart to make upgrades so it will work with the new stuff. And if my dire nature happens to get someone to pick up a few engineering books, learn some cool stuff, make some even cooler stuff, and post pictures and HOW-TO's for the rest of the community to learn from... Hell yeah!! :joystick:

You should really consider hosting this on Google Code or one of the many other open source management sites. I was actually going to start working on a server mod this weekend so I will take a look and possibly start contributing to this one. :)

Crisco and I started the 52nd VFW back up. We have a few VFS operating under the 52nd similar to how the real 52nd FW operates... the 81st VFS for the A-10 aircraft and the 22nd VFS for the F-15 aircraft. Although the real 22nd FS is a F-16 squadron but we blurred it a little. :) The 23rd VFS is currently inactive until another aircraft becomes available or there is a desire for MIG-29 in the 52nd. Seeing as how the real 52nd is based in Germany and Germany has MIG-29's.... its not that far of a stretch of the imagination. :D You can take a look at our website (http://www.52ndvfw.com) but it is extremely bare right now. By that I mean I got it online a few weeks ago and haven't had the time to skin a WordPress theme or get the forums fully set up. But I will get on that this weekend if there is interest. :) We are also on during the evenings (eastern US time) flying in our server (52nd VFW). Stop in sometime!

I think that is the best way to go myself. The design that I had worked up has a single master card which plugs into the PC and multiple slave cards that talk to the master via a bus (I2C or CAN). Each slave would have a few jumpers to set its ID. When the master sends data up to the PC, the PC software just looks at the configuration script to see what the data means. This kind of layout makes it easy to extend the simpit without having to plug more than one thing into the PC's USB bus. But out of sheer laziness I will probably end up buying a few cards instead of designing my own. Too much work for something this simple. :)

Agreed. A few more lines. :megalol: Seriously though, so long as you're not running large loops and functions each frame then you should be OK. It's always good to break things down into 1Hz, 5Hz, and 10Hz functions and maybe even have multiple functions of the same timing that run staggered. Thus you end up with an average load instead of spikes at certain cycles. Agree with you 100%. When I upgraded my graphics card a while back my frames didn't improve at all. After I upgraded my CPU they skyrocketed. Fancy video card doesn't always mean great performance. :doh: I started to disagree with you but after re-reading what you wrote I have to agree. You had the proper exclusions (additional screens) in there. :thumbup: I am sure you know about ways to abstract it enough that you can minimize the number of times you have to do that once you've got the project to a stable state. And if you do it right the reflashing part is as simple as turning it on and letting the bootloader handle it.

By making that assumption you have already made a huge mistake. If programmers do things right then a lot of QA engineers would be standing in the welfare line instead of making bank each year. There would be no need for beta testers. I could go on but I am sure you get my point. And I know I am taking your comment to the extreme boundary of your point but that was, in effect, to make another point. Now take into account we are all addressing our comments towards a person who is new to all of this and you can pretty much say, for a fact, that the programmer (new programmer that is) isn't going to do it right. Not until at least revision 100 or so. :) All of that being said, I agree that you do have to do a lot to impact the processor. It's also pretty easy for people new to interfacing with devices to create wait conditions or deadlocks that will. You don't have to do a whole lot to impact memory though. Even salty programmers get memory leaks from time to time. Add a GUI to make your key mappings and you're using more memory. Program it in JAVA and you'll be shot, er, I mean, you'll use even more memory.

My .02 on the subject... LUA can do a lot. It can also significantly decrease the performance of the sim. Similarly, running a program on the same PC as the sim to read in signals and trigger the proper keystroke (like joystick software) adds additional load to the CPU. It might not be of any significance to many but if you are trying to squeeze every bit of power for your sim, then these are not good ideas. If you can do the processing externally with a microcontroller then that is usually the best solution. The microcontroller then sends a signal via USB to a driver that has a very small memory footprint to convert the signal into a keystroke command. HID drivers already do that for you. So now you have all the intensive state machine code running on separate hardware that does not impact the performance of the sim at all. The learning curve to do something like this can be moderate to extremely high. If you don't have the digital design skills or have no interest in learning them, then you can get a pre-fab board like Phidgets, Arduino, etc and all you have to do is write the embedded code. That is much easier than it sounds if you've already got a grip on programming and even easier if you already know C or ASM. If you don't, then go to Radio Shack or jump on the internet and order a microprocessor starter kit that comes with a board, some sensors, and a book with lots of examples that teaches you how to interface with each of the sensors. You can get a kit like this for under $75 USD. Again, just my 2 cents on the topic coming from my experience in computer engineering.

Another thing to think about when buying a video card is what mother board and CPU you have. Some hardware just runs better together. I was an ATI fan for many years. The last few computers I've built I went with NVidia though. At the time I switched NVidia had much better cards. Then ATI balanced it back out. I haven't paid much attention since I got the 9800GX2 a few years ago to know which one is on top now.

Anyone have an easy way of debugging LUA scripts in FC2 besides looking at the generated error in the log file? I remember back to my Crysis modding days that we were able to output a lot of useful information to log files but I cannot remember how we did that now. Might have been a special feature contained in CryEngine2. Its just getting annoying having to launch and close FC2 over and over until I get it right. :P

I have a 280GTX from EVGA and extremely happy with it. I get great frame rates and never see any stuttering until I start recording video in real time with FRAPS. I used to have a 9800GX2 from EVGA which is essentially two 9800 GTX cards in one package SLI'd internally. My single 280GTX out performs the 9800GX2. So instead of getting two 9800GTX's, I recommened stepping up a line to the 200 series GTX cards. They are pretty cheap these days. I also recommend buying directly from EVGA. My 9800GX2 died on me (small possibility that it was my fault...) and when I contacted EVGA, they said they would replace it even though my warantee had expired a month before. Since they didn't have any 9800GX2's, they upgraded me to the 280GTX for free. I was very happy with their customer service and will buy my stuff from them until that changes.

To answer the question, at least in part, there was a threat back in the opening stages of OEF but from what I understand now it is not a problem. Of course it wasn't really a problem back then either... we would fly two Hornets above the threat range of the shoulder launches SAMs the Taliban had with two more Hornets trailing by a few miles. When the Taliban would fire off a few at the lead planes, the trailing planes lazed them with our FLIR pods (Marines don't get the good pods like the AF does) and drop a LGB on the launch site. After awhile the Taliban figured out that we were above their threat range so they started launching them from the tops of mountains. What they failed to comprehend is airspace is 3D and we just started flying our bait at higher altitudes.

Not sure on the AI side of things but I had both wings knocked off the A-10 a few days ago and stayed in the air for another 5 minutes. Not enough control to land it that way though. So be it a visualization thing or a flaw in the flight models, something weird is present under certain conditions.

I was having the same problem after updating to the patch and doing the "Check for Game Updates" worked for me.

I feel the need to echo what many others have said... amazing work!