FSFIan

Why would that be a problem? In theory, you could take care of getting the export data to all of those panels with a single USB-to-serial converter (TX line connected to all boards in parallel). Now that converter chip obviously is not designed for a fan-out of 58 over long wires, but wouldn't a few non-inverting buffer ICs take care of that? The DCS-BIOS export data stream is just an efficient way to represent writes to a block of memory, so it lends itself to memory-mapped I/O. We can set aside some address space for "private use", so you can program your boards to change their configuration value(s) when data is written to a board-specific address. Would that fit your requirements? Wouldn't a multi-master-capable protocol that does collision detection (instead of collision avoidance by passing a token) be a better solution than polling? Collisions will be very rare because a pilot only has two hands, and most of the time one of those is on the flight controls. In the typical case, at most one Arduino will have anything to say at a given time. Of course this will require improving the current potentiometer handling code to reduce random jitter. If I was designing a simpit professionally, I would probably just connect all boards to a single CAN bus (using a microcontroller with built-in CAN support to keep costs down) and be done with it. Using Arduino boards, I think the way to get the job done with minimal resources is to use several USB connections to the host PC and connect small groups of boards with I2C to reduce the number of USB connections by a factor of three to five. When I read that, I see a lot of money being wasted on Raspberry Pis and RS-485 transceivers. That said, my brain is hardwired to think within the confines of a university student's budget, so maybe I'll see that differently in a few years.

Client slots are available in single player (although I don't know what happens if you have both Client slots and a Player slot).

I2C with 30+ panels won't work because of the electrical limitations of I2C alone. I2C was originally designed to communicate between chips on the same circuit board. I did some theoretical calculations once which said that you start out with 8 m of allowed wire length on your I2C bus and lose 0.3 meters for each device that you connect (assuming Cat5 cable). To guarantee reliable operation, you should stay way below that. I think it may be possible to build a complete cockpit with three I2C buses (left console, front dash, right console), but I am not an electrical engineer. I am a software guy who doesn't even build his own simpit, so take everything hardware-related I say with a grain of salt or two. The I2C transmission speed is pretty slow, but a human will only operate one control at a time anyway. The export data stream doesn't go over the I2C bus -- you simply connect the TX line from your USB-to-serial converter to several Arduino boards at once. That's also a source of possible signalling problems, especially over long wires (i.e. another reason why 30+ boards on a single bus won't work). You will require external power for at least some of the panels (servos, backlighting, lots of indicator LEDs...). I recommend to use an old PC power supply -- even new they are cheap because they are mass-produced, and they provide you with lots of oomph at 3.3V, 5V and 12V.

To connect the I2C bus, you need these connections: SDA to SDA SCL to SCL SDA via pull-up resistor to Vcc SCL via pull-up resistor to Vcc There are a lot of tutorials on using I2C with Arduino on the internet that explain this in greater detail. Yes, you need different code to make the boards talk -- that has been provided in the I2C master/slave template sketches. On the chainduino: looks expensive. It would be cheaper to give each Arduino board its own USB connection to the PC (including the cost of additional USB hubs). I have started a comparison on the Warthog Pit wiki.

According to the pygame docs, those keys should be K_LSUPER and K_CAPSLOCK. I assume this is not a pygame problem (try running your program on another PC, for example locally on your DCS machine). On the RasPi, open a terminal, type "xev" and press return. (You might have to install xev using the package manager). The xev program ("x events") will print all input events it receives to the console. With the input focus on the xev window, press the keys. On my linux laptop, the output looks like this when pressing the left windows key: KeyPress event, serial 33, synthetic NO, window 0x1a00001, root 0x7e, subw 0x0, time 280767109, (570,155), root:(571,156), state 0x0, keycode 133 (keysym 0xffeb, Super_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 33, synthetic NO, window 0x1a00001, root 0x7e, subw 0x0, time 280767205, (570,155), root:(571,156), state 0x40, keycode 133 (keysym 0xffeb, Super_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False If that says L_META or something (Alt key) on your system, the error / misconfiguration is outside of pygame (and you might want to google "Xmodmap").

Just search eBay for "Arduino Pro Mini", apply "Buy It Now" and "Price + Shipping, Lowest first" filters and pick the first hit. Here's an example. Make sure to get a matching USB-to-serial converter as well, e.g. this ($0.88) or this ($1.58, has a DTR pin so you don't have to press the reset button manually when programming) or this ($1.65, includes / is built into USB cable).

In my first experiment, I used shift registers to read all nine encoders and did not have a problem. Unless you are building a motor controller or add some kind of gearing to turn the encoders really fast, I wouldn't worry about losing the occasional step.

You can determine these values by reading the "clickabledata.lua" file under Eagle Dynamics/DCS World/mods/aircraft/A-10C/Cockpit/Scripts. At first a few educated guesses are required, but after a while you start to recognize patterns. You could also look at A10C.lua in DCS-BIOS. For example, the master arm switch looks like this in clickabledata.lua: elements["PNT-TMB-AHCP-MARM"] = {class = {class_type.TUMB,class_type.TUMB}, hint = _("Master Arm"), device = devices.AHCP, action = {device_commands.Button_1,device_commands.Button_1}, arg = {375,375}, arg_value = {0.1,-0.1}, arg_lim = {{0.0, 0.2},{0.0, 0.2}}} device_commands.Button_X is defined as 3000+X, devices.AHCP is defined as 7 in the A-10C's devices.lua. In DCS-BIOS, it looks like this: defineTumb("AHCP_MASTER_ARM", 7, 3001, 375, 0.1, {0.0, 0.2}, nil, false, "AHCP", "Master Arm TRAIN - SAFE - ARM") Device ID 7, command 3001, valid argument values go from 0.0 to 0.2 in steps of 0.1.

3. There is no "glass cockpit" software that uses DCS-BIOS yet. Gadroc is thinking about adding DCS-BIOS support to Helios in the future. 4. Yes, there is only one Export.lua. However, (a) you can write an Export.lua file in a cooperative way so it can be loaded after another one and not step on its foot, which allows several programs that rely on Export.lua (such as Helios, DCS-BIOS and TacView) to work side by side and (b) an Export.lua file can check which aircraft is being flown and adapt its behavior accordingly, so it does not try to export A-10C data when you are in an F-15.

If you are going to make many panels, you are going to have to decide on a way to work with multiple boards anyway. (Either use one USB connection per board, or have groups of boards where only one talks to the PC and connects the others via a bus like I2C). The Pro Mini clones look like the best price/performance ratio. They are also small enough so you can hide one behind each panel. This means the wiring will be less of a mess and you can easily pull a single panel for maintenance. EDIT: disregard that, the Mega is actually on the same page price/performance wise as the Pro Mini boards if you add the cost of a USB-to-serial cable for each Pro Mini. So the more important reason to go for the Pro Mini is that you will have pretty much one Arduino per panel, so it's easier to test on its own.

Cargo objects are kinda broken right now -- you can spawn and transport them, but scripts fail when trying to determine their current position so you have no way of knowing if a cargo has been dropped off at its destination. So I guess CTTS will not work completely in current DCS versions until ED fixes that. Otherwise, I don't think there have been any DCS updates that have added any significant functionality to the scripting engine. I guess most scripts that can be written with a reasonable amount of effort within the current scripting engine have been written.

If the current Helios version writes to the correct directory, this should not be neccessary, as you should have write access to your own user profile.

If you haven't already, check out DCS Witchcraft (link in my sig). Its Lua Console lets you iterate much faster than coding in the mission editor. Have a syntax error in your code snippet? Correct it and try again within five seconds instead of waiting a minute for the mission to load again. This post illustrates how I use it to speed up the creation of Lua scripts for DCS.

DCS-BIOS will work with any Arduino board. See the DCS-BIOS Hardware Buyer's Guide (work in progress). The most inexpensive option with the best price/performance ratio are the chinese Pro Mini clones. The Mega is interesting if you want to have a lot of I/O pins on a single board without doing more advanced stuff like using shift registers or I/O expanders. But for the price of one Mega board, you can get several Pro Minis that will, in total, have more I/O pins. The other thing I like about the Pro Minis is that they are so cheap that you can stock a bunch of them, and if you do accidentally fry one it's only $3 down the drain ($5 if you manage to fry the USB-to-serial converter as well).

The correct location is: %USERPROFILE%\Saved Games\DCS\Scripts\Export.lua If you copy the file that Helios creates under your DCS: World installation directory (can't remember the exact location) over there, it should work.

This could work for bombs, but guns may be a problem because you only get a "firing started" and "firing stopped" event -- AFAIK the individual bullets are not separate objects in the simulation world, but I may be wrong here. In addition to trying to eliminate the bombs, you could detect people firing their gun within a certain distance of an airfield and simply destroy() their player aircraft so they get kicked back to spectator mode and have to hop into a new plane.

If I were in your situation, I would either map everything through Helios or buy a $5 Arduino clone and use DCS-BIOS.

Executing a piece of Lua code from the DCS Witchcraft Lua Console has the same effect as executing it from a DO SCRIPT trigger action. In addition, if the code returns a value, it will be displayed in the Lua console. This thread has a good example of witchcraft-assisted problem solving. For further questions, please open a separate thread in the Mission Builder's Corner. Let's keep this one focused on squashing this particular bug.

I posted results of some further testing in this thread. The cargo object is spawned into the game world and some methods such as getName() and getDesc() work, but most fail with an "Object doesn't exist" error. The cargo object can also not be enumerated with world.searchObjects(). StaticObject.getByName("MyCargo").id_ has an object ID, but StaticObject.getByName("MyCargo"):getID() returns 0.

I did some further testing on this in the DCS Witchcraft Lua console. I hope that by looking at which methods work and which don't, someone at ED who knows the implementation can narrow this down. DCS Version: 1.2.14.36041 The reason for the trigger not working seems to be that getPosition() on a cargo object fails with an "Object doesn't exist" error (see below). First, let's spawn a cargo object (code adapted from this mission): local cargo_gid = 10000 local cargo_uid = 11000 local cargo_name = "MyCargo" local cargo_x = -317783.8125 local cargo_y = 19.547994613647 local cargo_z = 635431.625 local newCargo = { ["groupId"] = cargo_gid, ["category"] = "Cargos", ["type"] = "Cargo1", ["unitId"] = cargo_uid, ["x"] = cargo_x, ["y"] = cargo_z, ["canCargo"] = true, ["mass"] = 400, ["heading"] = 0, ["name"] = cargo_name, ["dead"] = false, ["country"] = "USA", ["shape_name"] = "ab-212_cargo", } coalition.addStaticObject(country.id.USA, newCargo) This places a cargo object named "MyCargo" near the Kutaisi airport tower. The following Lua snippets all raise an "Object doesn't exist" error: return StaticObject.getByName("MyCargo"):getPosition() return StaticObject.getByName("MyCargo"):getVelocity() return StaticObject.getByName("MyCargo"):getCategory() return StaticObject.getByName("MyCargo"):getPoint() StaticObject.getByName("MyCargo"):destroy() The following are snippets of Lua code (bold) and their return values (italic): return StaticObject.getByName("MyCargo"):getName() "MyCargo" return StaticObject.getByName("MyCargo"):isExist() false return StaticObject.getByName("MyCargo"):getDesc() { "attributes": { "Buildings": true }, "category": 4, "displayName": "", "life": 0, "typeName": "" } return StaticObject.getByName("MyCargo"):getLife() 0 return StaticObject.getByName("MyCargo"):getID() 0 return StaticObject.getByName("MyCargo"):getCargoDisplayName() " 400 kg" return StaticObject.getByName("MyCargo"):getCountry() 99 return StaticObject.getByName("MyCargo"):getCoalition() 2 return StaticObject.getByName("MyCargo"):choosingCargo() 1 -- trying to enumerate the cargo object -- (does not work, code is correct because -- a radius of 3 found the Huey I had landed -- next to it) local cargo_x = -317783.8125 local cargo_y = 19.547994613647 local cargo_z = 635431.625 local objects = {} local volume = { id = world.VolumeType.SPHERE, params = { point = {x = cargo_x, y = cargo_y, z = cargo_z}, radius = 2 } } local function handler(object, data) objects[#objects+1] = object end world.searchObjects({0,1,2,3,4,5}, volume, handler, nil) return mist.utils.tableShow(objects) {}

Helios does not care about the display size. However, you should go with 1920x1080: there are some absolutely amazing Helios profiles available for download, and those are made for 1920x1080 resolution the "full HD" resolution is where most of the offers are, so that's also where you find the highest competition and the best bang for your buck I selected my touch screen by price alone. I got a Hanns.G HT231 23" touch screen (1920x1080) for about 250 €. The "5ms fast response time" is marketing speak (measured grey-to-grey instead of black-to-white I guess), so when I scroll a web page for example, high-contrast contours like text become noticeably blurry. At that price point, that was to be expected. But that does not matter for a Helios panel -- most of the content is static anyway and you are not going to play a first person shooter on your MFCDs.

Please post specific questions that you would expect such a system overview to answer. "System overview" can mean many things, from a pretty useless diagram like this Switches <--> Arduino Board <--> USB cable <--> DCS computer to something that includes so much detail that you can only read it if you already know everything it might be able to tell you. Also, by "start with a system overview" do you mean we should start writing one or do you mean specifically that the first chapter of the User Guide should be such a system overview? We tried our best to make sure that the User Guide does not assume any prior programming knowledge and very little electronics knowledge. It is intended to take a lay person from where they are to their first functioning switch panel. If you still have questions after reading through that, please ask away -- it can be difficult to anticipate every possible newcomer question if you have designed the thing (in my case) or you have already used it for a while (WarHog).

Switch your reference documentation to "Advanced" view to see the RotaryEncoder code snippet. The "Simple" view will try to guess the "most appropriate" input interface to use and hide all the other options. Most of the controls support the fixed_step interface ("DEC" and "INC" actions) that allows you to connect a rotary encoder even if it makes no sense at all (e.g. push buttons). The reason CodeToad does it in a more complex way is because he wants to have advanced features like turn acceleration and menus. For the simple case where one step of the rotary will always result in the same command to the sim, DCS-BIOS has you covered. I don't have a proper simpit ;) Don't have the time, money or space (dorm room) to build one right now. DCS-BIOS was created because I wanted to help WarHog using Arduino boards with DCS and I didn't like the existing approaches at the time for various reasons. I wanted an open-source implementation that had an export protocol efficient enough to export the complete cockpit state over one serial connection, hid away all DCS implementation details like argument numbers, and was documented well enough so others could use it.

I reproduced the "not working in MP" behavior. For what it's worth, I have posted it in the bug reports forum.

The official scripting docs describe the getFuel() method as follows: In multiplayer, this only works for the aircraft controlled by the host. For aircraft controlled by other players, it will return the fuel state that the aircraft initially spawned with.