Gadroc

Locking switch are ones when you have to pull on them to be able to switch positions. They are used for things you really don't want to accidentally toggle.

Been slaving away off and on. I have all the gauges on the front panel up and working now. Also some new switch graphics. Over the next week I to completely finish the front panel and start working on the right console.

I would say sometime between now and December 3rd. I have a few more items I need to finish before releasing it. I don't know how much time I'll have to work on it over the next few days with the holiday, but there is enough time the next week to complete them even if I can't get it done this weekend.

The screen shot in my last build update is the evolution of that original software. The front panel is design for 1920x1080 21" to 23" touch screen. That fits all gauges and controls that are on the real front panel (except for the circuit breaker panel). In my cockpit I use a 23" acer touch screen for the front panel and a Sony 46" LCD TV for the main visuals.

I actually suspect it is looser by design. If it took the same pressure to toggle as those on the base there is no way you could toggle it with your pinky with out moving your hand from the throttle. Also more pressure would probably cause you to change throttle settings when you toggled it.

Just up the road in Columbus.

I have also been working on my front console for DCS A-10C. Here is a screenshot of how it looks so far. All the gauges are functional but I still have to create the fuel gauge, flaps and apu gauges. In addition there are some new graphics for the ADI and HSI to match the A10, currently just using the F16 versions as stand ins. Lastly I need to increase the font size on the engine gauges so they are more easily readable. The Navigation Mode and TISL panel are place holders just make sure I can get everything to fit. The last thing layout wise is to free up a little space for the Fire Control and Gun / NWS indicators. We should be going into Beta with helios over the next few weeks, so you guys can play with these tools yourself shortly. Subtracting my time working on Helios source and DCS integration it only took a few hours to put this panel together and bind it to DCS.

Well I got my UMC prototype setup finally. While my last tubs where nice looking they where not angled correctly for the screens causing poor viewing angle for the 10.4" screens. I could barley see what was on them. The ACES II is also MUCH nicer on the eyes. With the UMC I have moved to a 15" behind control mounts on each side and of course I have the hog installed. In addition the 23" center panel screen is now on a articulating arm. This allows me to get the center panel much closer and also push it back for much easier entry and exit of the pit. The table in front holds my 46" LCD TV for the external visuals. It will get replaced with a wall mount sometime early next year. I have plans to move the 15" screens to be forward to the front of the control mounts giving right and left front aux consoles and add replace them with 23" touch screens for the rear consoles. I have also attached a picture of my controller bone yard. These are all the controller's I've amassed in the last year and a half.

You can not add instruments to a separate display with out third party software (see Lock On Virtual Panel, Black Shark Virtual Panel, Falcon Gauges, SimMeters and Helios as examples). You can add another camera view which points at the instruments, but it will move as you pan and zoom the main camera as well.

Yes this is correct. The majority of the data sent across the wire is replaced with new data in the next packet (compass heading, altitude, air speed, etc) as the value is always changing so there is no point in error checking for lost data. Lost switch flips could be problematic, but since there are no real lives at stake and like you said most people will be using the loopback or lan there is small chance of actually loosing the packet. So adding connection semantics would be wasted CPU and development time.

It sends a packet when ever it has data that's changed. If that argument doesn't change it doesn't send that argument again until it get's a reset command ®. This technique allows you to start and stop your client at any time. With TCP you have to start in the right order and it becomes messy to keep track of connects and disconnects all the time. In addition UDP allows us to broadcast and have several different clients listen to the same stream of data.

Here is my export.lua which I've now tested and it works with A-10C beta 3. To configure it modify the top these lines: // Host and port which we will broadcast and listen on host = "127.0.0.1" port = 9089 // Arguments to watch and send updates gArguments = {[76]="%.4f", [77]="%.4f", [300]="%.1f"} The scripts sends out UDP packets of the format argid=value argid=value ... argid=value The first value pair is a simulation id which is a unique id generated at the start of the mission. The script only sends out data when it has changed and uses the format specified in the gArguments table. It listens for response UDP packets with one of two command structures: R Cdeviceid,buttonid,value If it receives R it will reset the cache and send all current argument values. Any new client listening for the UDP outputs should send an R to ensure they have accurate data. C executes a performClickableAction on the associated device and button. Export.lua.zip

The Hog is connected to that metal base by four screws. You can easily remove the base and fashion a different mount. You can also potential rotate the hog so the plate the narrow end of the plate is front to back. This may give you the clearance to mount it up higher.

That looks pretty much the same as Black Shark. Anything that is pulled as an "argument" in any of the other lua files (clickabledata and main_panel_init) is pulled off device 0.

I was ripping out the Black Shark specific code last night and didn't get a chance to test with WH before wife quality time box kicked in. That sucks if those are missing!! I'll let you know what I find.

I had problems with setcommand in Black Shark as well and ended up using device.performClickableAction for everything. What do you want GetIndicator for? All of the indicators should be available via the GetDevice(0):get_argument_value(argid) setup. You just need to dig through the main_panel_init file and get the right argument id which triggers them to light up.

Yes. I'll post it when I've tested it.

Yep. I was happy with my Q9550 running at 3.9 until I got my 5870 and didn't see the improvements I thought I should over a 275GTX. Ended up replacing the Q9550/P45 combo with a 930 / X58 and noticed a huge jump pretty much all round, especially in FSX. Mind you that is with a stock 930 as I havn't found the need to OC yet and it takes a good amount of time to dial in and stability test.

Thanks for posting that. I'm converting my BS scripts over tonight and you probably just saved me an hour or so of frustration!

Wow! EtherealN you have much patience. Here in the US the E8600 and i7 950 are roughly equivalent in price (actually you can get the 950 for $90 cheaper than the E8600). In no circumstances would I EVER recommend someone get an E8600 system unless they can not replace an existing socket 775 motherboard. Check out the benchmarks and you'll find the 950 beats the E8660 in every one (in many cases even games by a large margin) even though the E8600 is .3Ghz faster. The fact that he can run his C2D at 4Ghz means nothing when an i series chip will do more work and run games faster at a lower clock speed. Ghz != performance when comparing across different chip architectures. To the original OP. Don't go to the forums where Vault get's his advice he is just spouting non-sense.

I have not tried the china vision products so can't say one way or the other. The price definitely looks attractive especially for the larger screens, but a few things make me nervous. 1) They don't specify what type of touch screen it is (4/5 wire resistive, capacitive). Based on it being stylus / finger it looks resistive. 4-wire touchscreen are much more likely to stop functioning due to scratches than 5-wire or more. 2) Don't know what type of touch screen controller chipset it's using, so I don't know the capabilities of the driver. Can it support multiple screens? Can it support multiple touch screens at the same time? Does it use Windows 7 native capabilities or mouse emulation and does it support screen rotation? If you find out answers to those items they might be good deals, although I would also double check stats on the LCD itself (viewing angles, brightness and contrast). I have it on my to-do list to type up a touch screen buyers guide, I'll try and get that done this weekend and get into why I ask each of those questions above.

Sorry about the delay. I've been sick a couple weeks and other things have kept me off the boards as much as I would like. Basically Helios is drag and drop for this... aka Drag "Push ABRIS Button 1" DCS action list onto "Button 1 Pushed" trigger from the direct x controller. It should be MUCH simpler than all the scripting everyone has to do today. I have attached two screenshots showing bindings for Touch Screen controls to Falcon and one for a joystick to DCS. The desire is to replicate this ease of functionality with other physical input types like PHCC and OpenCockpits. Once I have the Beta underway (targeting end of the month to start), I will be ordering some OpenCockpit cards to start experimenting with. I can't say for certain how exactly we'll implement that integration yet, but I hope to keep the simplicity you see with the bindings of the touch screen controls and direct x controllers.

That's not true at all. You can use other software to interface between the LUA export functions and DirectX controllers just like you use the SIOC software to interface between OpenCockpit controllers and the LUA export functions. People shouldn't be afraid to start with a joystick emulation board as it is much easier to start with than the OpenCockpit solutions, as you can start mapping directly inside DCS and later add software to do more advanced things. That being said the rest of your argument is valid around cost per switch, and ultimately it will take the same skill sets to work either to their full potential.

Unfortunately there are really no "cheap" small touch panel solutions. I would expect to be spending $200-$300 for a 7" - 10.4" touchpanel. There are a couple off the shelf vendors that are common (Liliput and Mimo). You can also buy a LCD Panel, VGA Board and touch screen panel and build you're own case or buy a touch screen panel and add it to an off the shelf monitor (all options which will still run you $200-$300 if you don't already have some of the parts). Be sure you read up on the limitations of USB displays (no 3D acceleration so will not work with in game graphics, etc). Before deciding to pick one up.

Baal, This is true with all FFB joysticks. None of the axis tune options work correctly with FFB joysticks... Deadzone does not travel with the new stick center when trimmed and curves / saturation mess up the FFB trim.