Gadroc

Helios is now donation ware. Pay what you feel it's worth.

The Gadroc folder should be moved to your My Documents\Helios\Images folder. The downloads page for that profile explains what to do with the scripts. They are not strictly necessary. They configure DCS to display the RWR, UHF Repeater and a few other displays to the right area so they show through Helios.

LOL. I'm deathly afraid of the wife community getting together at some point and hunting some of us down.

I don't use keyboard bindings in Helios to do this so I can't confirm exactly, but they where a little wierd using the lua script as well. Although 1.1.0.7 did make them better.

Lol. No the direct opposite in fact. Hawgtouch is almost a direct copy of Helios and an earlier piece of software I wrote called TouchPal. Both of these where written due to touchbuddy no longer being actively developed. There is also a long history of gauges software before LOVP, BSVP and many others for other sims.

1) Start the profile editor. 2) Select Add Interface from the Profile menu, Select DCS A-10C from the list and click OK 3) Double click on the monitor you want the gauge on in the preview in the upper left window 4) Find the gauge (ex: IAS) in the toolbox drag it from the toolbox onto the monitor window in the center of the screen. 5) In the binding window select the input tab to bind inputs of the gauges 6) Expand the Interfaces and then DCS A-10C in the Triggers list 7) Find the appropriate trigger (ex: IAS -> airspeed changed) and drag it onto the binding point (ex: set airpseed) Repeat as necessary. You can also do steps 1-3 and then cut and paste from an existing profile.

Deadman, You're knowledge is valuable, please don't disengage. It is really hard to judge tone and intent via text alone. I know at times I have mis-interpreted some comments as snide before when they where not intended that way. For those posting your work it is important that you state what you are going for. There are many different goals for personal cockpits. There are those who are aiming for a dimensionally accurate panels and some who are designing them to fit the space they have. Some strive for intense accuracy down to the color of the back lighting. If you are not clear and post something that is close to accurate it stands to reason those who have additional knowledge on accurate will assume you want it and chime in. We as a community are limited in the knowledge that we each have. There is not absolute source of information and blueprints for us to work off of. If we do not try and pool our knowledge it will take forever for us to accomplish anything.

I've started to compile a list of the switch types and possible alternatives for my A-10C cockpit build. I'm sure many of you are doing the same and hopefully we can combine a consolidated list to make it easier for everyone. In addition it's hard to tell exact switches from the ingame cockpit sometimes, so I'd love to get some feedback from those of you that have some hands on or real panels. Here is my current list is here. Currently I only have the AHCP panel there but will add more as I go through the panels. I'll also update it with any additions or corrections posted here.

It's hard to explain to people who have not used it what the difference is, but once you've flown with a setup like that it's REALLY hard to go back.

This is exactly the role Helios was designed to do. It's first application was the glass cockpit side of it. Some aspects of Helios around the trigger/action mechanisms are more complex in order to support some of the scenarios where you have a mix of physical pit interfacing along side touch screen and gauge rendering.

Ok. You need to understand the difference between argument and action. Argument number is the ID you use to look up current state of that switch in the simulation. You never modify it directly. You could roughly think of argument as the variable name you use to look up the data. You always lookup arguments based on the Main panel device. Action is the ID of the function used to tell the simulation a button or switch was pressed. Think of action as the method you call to modify the value of the argument. The value you pass in to the action will be processed by the action and the simulation will decide how to change the argument. You call the action on the device which that switch belongs to. Hope that helps.

Actually it might not scale as well as you think. The packet overhead on an Ethernet frame will dwarf the actual data you send in this context and you'll be sending it several times per second. On a big beefy PC with all it's ram and 100Mbit to Gigabit ethernet this is no big deal (and many times it doesn't even hit them for loopback). It may be more difficult for an 8-bit microprocessor with 2MB of ram especially after you realize there are well over 300-400 digital inputs to poll and hundreds of LEDs to drive in a full cockpit. This is all theory until someone gets a full setup up and running.

Yes this is true. Lock-on exposed far more data to the lua export than BlackShark and A-10C which allowed for "cheating" to know where everyone was. This lead to several public dog-fight Lock-On servers to prevent modifications of the Export.lua.

If all you are doing is DCS helios works just fine over a network. Just set the IP address on the DCS config screen to that of your remote PC. All DCS bindings will work across the network. What does not work is keyboard. The bindings concept is a little steeper curve than touchbuddy, but there is alot more that can be done. Newer versions in the works which will have full support for network client/server type modes. If you have any questions on how to get something done just post over on the SCSimulations forums and I or someone else will help you through it.

Hannibal... Download Helios. All the bindings are built in. It does everything touchbuddy does.

Double check the stats on that 12" monitor, while possible I doubt it's really 1920x1080 native resolution. Be care of vendors that say can accept up to 1920x1080. What they are really saying is the video board can down scale from resolutions that high down to the LCDs native resolution. Verify that 12" monitors native resolution and it will probably be at max 1280x720.

You're not going to find that kind of resolution on a monitor that small. That's 200 DPI nearly three times the average. It's nearly "retina display" quality from the iPhone 4. And again your not going to find a 5x5 square LCD display they just don't make them for general consumers. You'd have to look at having it custom made or buying the real military parts which will cost you several thousand per screen.

You're not going to find 5x5 monitors for a reasonable price. They are pretty much industry / military only. Your best bet is an 8" 4x3 monitor. These are the ones I have. You will need a vga board and power supply to go with them.

Very nice!

Helios is donation ware. There should be a donate button on the control center or you can go to the http://www.scsimulations.com homepage and donate there. If you are missing the donate button on the control center you're not running the latest Helios. Download it from the link in my sig.

"C:\Program Files\SCSimulations\Helios\HeliosControlCenter.exe " -d "Helios" -t Just like that.

Hey Mule, Make sure before copying the MFDs into your new profile that you already have added the DCS A-10C interface. Do this by clicking Profile -> Add Interface from the menu. Select DCS A-10C. You will see a set of options make sure to click the "Setup DCS A-10C" button. This establishes the connection between Helios and DCS. Now copy and paste the MFDs out of my profile and they will retain the bindings from my profile. You may also want to try adding "-t" to the command line of the Helios shortcut to try disabling the special handlng for touchkit. You may be encountering a bug with it. If that is still not working make sure if you are running DCS as administrator you have to run Helios as administrator and vice versa. Here are links to my two profiles: Single Screen Three Screens

I've setup an area over at scsimulations to work on a common hardware solution. I'm calling it Eos and I want to make it an open standard for how to interface panel control boards to the computer. I'm prototyping the initial interface board right now and working on getting firmware ready for it. I also have a working framework for quickly building out IO Boards based on a bare bones Arduino board. I will be putting up a subversion system with a library for bus communications, LED dimming, Stepper control and more as it develops. I'll be documenting it as a API for hardware interface on the computer side (Raw HID protocol) and a set of wire standards for communicating between interface and controller. It's still early stages but I will be fleshing it out and posting my current schematics and eagle files shortly. Eos Description Eos Forums

Jasper, The point is FPGAs are WAY overkill to use just to mux a bunch of digital i/o channels. That board is $90 for still having to add several IO Expander chips to. You can do the EXACT same thing with a ATMega or PIC chip based board for 1/3 of the cost. In addition for LED outputs you'll have to be very careful about power management to not run a huge amount of current through the system.

Absolutely no question in my mind that's true (speaking in context of out of the box mass produced kit). Now before anyone jumps on me about cost you also absolutely pay for every bit of that designation.