Gadroc

Shilka, There are several examples of how to do this on the forums. Check some of my back posts as I explain how to read the clickabledata.lua files to get the information you need.

I don't think Export.lua is included in the security checks by default. It was a problem that many servers added it once FC2 came online with BlackShark. People started writing competitive missions and started to think of Leavu as a "cheat" and they started enforcing stock Export.lua to export scripts. Since A-10 doesn't really have a air to air capability I doubt we'll see the same problem until DCS "Fighter" comes out.

Helios only modifies one file which is Export.lua. This is required to extract data from the sim and do direct integration back in. If the server includes Export.lua in the integrity checks it will fail. You can use Helios with out the Export.lua but all gauges will be disabled and you will have to bind all buttons and switches to keyboard emulation instead of direct to simulator. Hawgtouch I believe is similar to running Helios to with only keyboard emulation, although some posts from Cleartouch indicate he's adding Export.lua integration.

Is the virtual cockpit in DCS wrong? I could have swore it had an incline on the throttle as well. I inclined mine just the same.

TrackIR is also needed for vertical tracking. Nothing besides a full cave type video setup will remove the need for TrackIR in a military aircraft simulator. They have bubble canopies and you need to check your six. That being said I have turned down the yaw axis on my TrackIR significantly. The fish eye / aspect ratio is not as bad as WynnTTr makes it sound, but you still need to be able to look back. Cheat is a very strong word. It's no more so than TrackIR vs non TrackIR or HOTAS Warthog vs no HOTAS. Keep in mind that the size of the pixels is the same as a single 46" TV and what is displayed on the front primary screen is the same as with out the two side ones. If I'm scanning for targets it's with TrackIR like before, I'm just more likely to catch things like smoke or tracers out the corner of my eyes.

Actually I don't think its far off. I'll measure the MFDs tonight but they should end up near 5" across on the tv screen if it's 1:1 size. I may have had it zoomed in a little bit in the picture, which is sometimes required to read HUD / see targets on the ground.

LOL... One would think, but I still caught alot of flak for this. The old marriage adage "What's hers is hers and whats yours is hers..." not far off the mark. I was barley able to get by with this only because I was spending money made by the hobby. I still had to make budget amends by adjusting future spending money from my personal account to hers. In grand scheme of pit building this is actually not very expensive though. 46 TVs can be had for as low as $550 if you catch the right sale (and are willing to wait 3 weeks for ship to store). I'm driving them with a video card (5870 Eyefinity 2GB edition) which is fairly cheap (by video card standards) now a days. 3 x 46" TVs = $1800 - $2400 1 x 5870 2gb or 6950 2gb = $200 - $250 2 x Single Link DisplayPort - DVI = $60 That's less than $3000 for the display system. Compare that with a good projection system and it's not bad at all. Have you seen how much real panels and switches go for. I need to put together the actual cost/benefit of doing this route with touch screens and put it in front of the wife. Of course that's about like the argument that I bought an non essential item on sale and therefore I saved money.

Quick video of the new setup in action.

Not yet. It's still in the plan. I'm working on finishing the KA-50 gauge pack then I'll be focusing in 1.5 which will include more hardware support.

Moved the photo should work now.

Been a while, but I just made a nice little addition to my pit. :music_whistling: I joined the ranks of widescreen simming with a couple extra 46" tvs. Got it all hooked up tonight with enough time for a test flight with the SCS crew. I have to revamp my DCS snapview defaults and tweak my track ir settings now. Running it off a i7 930 with a 5870 2GB all stock speeds for now. I'm getting 30-45 FPS through out the flight.

Also be careful because most TVs above 60hz don't actually accept incoming signals above 60hz... they create the extra frames with blur filters. While this smooths out motion video it introduces frame lag for video games which is bad.

Not at all. I use a 46" TV in my pit and I sit about two arm lengths back from it. Once you dial in the snapview to have the right head angle it's perfect. I believe it's pretty close to actual size. I would never use a TV as my primary web surfing or coding monitor due to the reasons LawnDart has articulated, but they work great for gaming displays.

Very nice! Can't wait to get a few more things done so I can go back to working on some more of mine.

I have a model back 27" iMac. You can only expect moderate performance due to the video cards available (and they are NOT changeable). While I love my macs, gaming/simming on them is not for anyone who like eye candy. The best video card you can get on the iMac is a ATI 5750 (mobile edition) and that is on a computer with a display resolution of 2560x1440. That resolution is higher than most people run with much more powerful graphics cards.

As far as I can tell the stop actions are sent when the user releases pressure on the switch. This let's DCS know when the user has stopped clicking and let's the simulation make a decision as to whether to move the switch back. It used on the magnetically held switches as well as momentary switch positions. class = {class_type.TUMB, class_type.BTN}, arg_value = {1.0, 0}, arg_lim = {{0.5, 1.0}, {0,0.5}}, action = {device_commands.Button_6, device_commands.Button_7}, stop_action = {0, device_commands.Button_7}, stop_value = {nil, 0.5}, use_release_message = {false, true}} } For the example you give you have to look at a few other lines to know what to do. Notice that it has two different classes. Left click is TUMB or switch which interprets the arg_value differently than the right click which is treated as a BTN or button. In this scenario when the switch is left click it triggers the thumb class which will trigger button 6 and add the arg_value to the current value and clamp it to the arg_lim. Ultimately in this case left clicking toggles between 0.5 and 1.0 (show behaviors between things are inconsistent). In the case of the right click it will trigger the button class and trigger button 7 which will use the arg_value as the absolute value. In addition the stop action will be triggered when the user releases the mouse button which will trigger button 7 again but this time use the stop_value. To emulate this with SIOC you will have to be able to trigger a different action when exiting the up position vs the down position. So when the switch goes into the up position you need to ultimate call device(x).performClickableAction(3007, 0) and when the switch leaves the up position device(x).performClickableAction(3007, 0.5). Then when the switch enters the down position device(x).performClickableAction(3006, 1) and device(x).performClickableAction(3006, 0.5) when the switch leave the down position. There are other switches where your stop action is a different button than the regular action.

Sorry. Last two nights I have not been able to make it down to man cave. I will be down there tonight and dig up my notes.

These whe fun ones to figure out. I'll try and type up the logic on how to read stop actions tonight after work.

I'm also cooking up a Arduino based solution. I'm planning at this point on a Mega88 setup using V-USB as an interface to the computer then run a RS-485 bus to expansion cards. Although you could probably substitute a network shield instead of the USB. I've got the circuit's down and laid out for: 1) A stepper card (can control up to 5 steppers run by EasyDriver boards. (3" x 2") 2) A general panel board with 32 digital inputs (common ground and no diodes necessary) and 16 PWM outputs (which can run either individually dim-able LEDs or servos). (3" x 3") All boards are laid out with DIP chips for easy soldering, but they are packed tight. Each panel has a 12v barrel jack and two connections for the RS-485 buss to be daisy chained. Also they are designed to use the Arduino 328/168 chips and have ICSP and Arduino serial headers. I have all the parts to start prototyping the board with a bread board and start working on the firmware. Well except for the RS-485 driver (slaps forehead I ordered the SIOC version which may come in handy later). Once I finish prototyping I'll post of the eagle files under the appropriate licenses.

PanelBuilder how are you managing the PCBs when doing that? Are you manually wiring everything or making a PCB per panel? If per panel are you etching them yourself or where are you getting them done?

I've been mucking around with electronics the last few days. I've been debating between Arduino and building my own PIC based boards. I'd like to have each panel independent, but the cheap Arduino's only have 14 I/O pins which is not enough to run a panel. If I end up doing a PCB it ends up cheaper to just design my own PIC based PCB. How are you dealing with this?

The things missing in A-10C are the exact same as BlackShark which is LED/LCD text displays. Hopefully they can come up with a way in A10 which gets back ported to the assume patch to Black Shark for compatibility.

We are using it as well, adds a lot to the immersion!

That very much depends on the rest of your hardware. What kind of video card to you have? What motherboard do you have? Are there open PCI-Express slots? Give us a run down of your current hardware and I'm sure there are plenty of folks with suggestions.

Wow... that's a lot of wires to solder..... *sigh* I'm not looking forward to that. End result looks good!