FSFIan

In addition to a steady-state current rating (typically 20 mA), most LEDs have a higher peak rating (e.g. 40 mA) for a given duty cycle. In other words, if you are using LEDs in a matrix, you are allowed to operate them with higher currents because they have time to cool off again in the time their row is not being driven. This can compensate for (some? all? of) the loss of brightness caused by being on only a fraction of the time. Check your LED's datasheet. If you are worried about brightness, do your caution lights need to be brighter than your 7-segment displays? And if you do need more brightness, wouldn't it be easier / more cost-effective to go with a different type of LED instead of a more complex circuit and PCB layout?

You are right, the close parens needs to close the call to mist.getAvgPos instead of trigger.action.smoke. I need more caffeine.

Lua is telling you that it encountered an error in line 1. The error was which means Lua was expecting to see a closing parenthesis but reached the "end of file" without finding it. Count the parenthesis in the code example. Note that the number of open and close parens does not match. Add a close parens to the end, problem solved :) trigger.action.smoke[b]([/b]mist.getAvgPos(mist.makeUnitTable({'[g]myGroup'}), "Orange")[b][color="red"])[/color][/b] EDIT: relevant xkcd (see what you did to that poor parser?

Which error message are you getting?

I tried, that function is not available in the mission scripting environment. The ME also generates what looks like snippets of Lua code at the top of a mission file which apparently are not being used anymore -- changing them has no effect. This may be related to the disappearance of the "compile.lua" file. Interestingly, searching the DCS installation directory for any files that include the string "a_do_script_file" or the regex "a._.d.o._.s.c.r.i.p.t._.f.i.l.e" (to account for possible UTF-16 encoding) only yields the "me_trigrules.lua" file. Adding a trigger.actions.doScriptFile function would be great (I guess it wouldn't be too hard to implement). In general, I would like to see the DCS scripting system grow more powerful -- give it access to the warehouse system, more granular control of unit AI (especially ground units), make dynamically added units first-class citizens (no more "player XY killed building"), and allow Lua to dynamically add, remove and modify (change waypoints) player slots in a running multiplayer mission. I can only hope that ED will dedicate some time to scripting improvements after EDGE comes out.

If you have not already, take a look at DCS Witchcraft (link in my sig). It provides an interactive Lua console that allows you to execute Lua snippets in a running mission and get the results. See this thread for an example of how to use it to interactively try out new functions. To debug your error, I would probably have looked at line 613 in mist.lua, noticed it was looking for "newGroup.units" instead of "newGroup.unitsTable" and then used the Lua Console to quickly confirm that this solves the issue.

Note that this solution will most likely only work in single player mode. IIRC the mission is not extracted to a temporary directory in MP (because the "mission planner" stage does not exist).

According to the Arduino site it is 200 mA per ground pin. Since the DIP version of the ATMega328p has only one VCC and one GND pin, that is also 200 mA for the whole chip if your Arduino board uses a DIP package. The surface-mount packages have more VCC and GND pins, so if I interpret that correctly they can sink and source a total of 400 mA as long as it is properly distributed over the I/O pins. The Mega can apparently deal with up to 800 mA. However, these are absolute maximum ratings, i.e. Atmel guarantees that as long as you stay below that, your chip won't fry. For reliable operation, you may have to take other factors (such as heat dissipation) into account, I have no idea if that can be a problem here.

+1 I'd suggest making it very clear that any electronics and software support you provide only happens as a courtesy. Do it in a publicly accessible forum to reduce the amount of repeated questions. Also, this way anyone can take a look for themselves should someone accuse you of having bad customer support. The point is that you have to defend yourself against the very small, but possibly very vocal minority of your customers who are morons and/or trolls. You need to feel free to ignore those individuals without fearing that they could destroy your reputation, otherwise they will suck up all of your time. Once you start supporting a setup that involves Export.lua like Helios, DCS-BIOS or similar, there are just so many things out of your control (different antivirus and firewall software, possibly broken because of malware infection or someone who thought that installing three firewalls would make his PC "more secure") that you cannot make any guarantees.

How exactly are you setting up the radio transmission? I seem to recall that there was a transmit power setting, maybe you have set that so high that distance does not matter.

Watch for the basics. If you had a 20x2 display, that would be all you need. Each CMSP line is exported as a 19-character string (e.g. "CHAF FLAR OTR1 PROG"). To fit that on a 16-character display line, we can ignore the spaces at (zero-based) positions 4, 9 and 15, so you get "CHAFFLAROTR1PROG" instead: void onCmsp1Change(char* newValue) { lcd.setCursor(0, 0); lcd.write(newValue[0]); lcd.write(newValue[1]); lcd.write(newValue[2]); lcd.write(newValue[3]); lcd.write(newValue[5]); lcd.write(newValue[6]); lcd.write(newValue[7]); lcd.write(newValue[8]); lcd.write(newValue[10]); lcd.write(newValue[11]); lcd.write(newValue[12]); lcd.write(newValue[13]); lcd.write(newValue[15]); lcd.write(newValue[16]); lcd.write(newValue[17]); lcd.write(newValue[18]); } DcsBios::StringBuffer<19> cmsp1Buffer(0x1000, onCmsp1Change); void onCmsp2Change(char* newValue) { lcd.setCursor(0, 1); lcd.write(newValue[0]); lcd.write(newValue[1]); lcd.write(newValue[2]); lcd.write(newValue[3]); lcd.write(newValue[5]); lcd.write(newValue[6]); lcd.write(newValue[7]); lcd.write(newValue[8]); lcd.write(newValue[10]); lcd.write(newValue[11]); lcd.write(newValue[12]); lcd.write(newValue[13]); lcd.write(newValue[15]); lcd.write(newValue[16]); lcd.write(newValue[17]); lcd.write(newValue[18]); } DcsBios::StringBuffer<19> cmsp2Buffer(0x1014, onCmsp2Change); That's because there are so many different things you might want to do with string values that it does not make sense to generate example code for all of them: display them on a LCD character display with a HD44780 compatible controller, which can be connected in several different ways (4-bit parallel, 8-bit parallel, over an I2C I/O expander) display it on a graphical display (while the HD44780 chip has set a de-facto standard for how to control a character display, graphical displays tend to feature a greater variety of controller chips) display only a part of it (as in the above example) display it on a 7-segment display (for example the UHF frequency), which again may be connected to an Arduino in numerous ways Therefore, for string values, you get a piece of example code that calls a function every time the value changes. You need to put your own "glue code" into that function to actually do something with the string value. In most cases, that function is very short because you can find an existing Arduino library that does the bulk of the work and already knows how to talk to whatever hardware you have connected (in this case the LiquidCrystal library).

You could also ignore the DCS warehouse system entirely. When a player tries to cheat by loading ammo that is not supposed to exist (yet), simply kick them out of their plane back to spectator mode by deactivating their aircraft group. If you are nice, you can give them a warning message first and only despawn once they actually take off.

I doubt that any vendor will build a USB 3.0 HID device. Building a USB 2.0 or 1.1 device is cheaper, and there is no human interface device that would require the new SuperSpeed mode of USB 3.0. USB 3.0 ports are supposed to be backward-compatible. If they are not, that is a bug in the USB 3.0 controller, not in the USB 2.0 or 1.1 device. With 16 analog axes and 64 digital inputs, you will either need to use two commercial USB interface boards or program your own firmware for a USB-capable microcontroller (or one that bit-bangs USB with the V-USB library and the help of a few resistors and diodes) to appear as a "composite device" consisting of two joysticks with 8 axes and 32 buttons each. You could present a 16-axis, 64-button device to Windows and it might work in DCS, but a lot of applications (including the Windows Control Panel as far as I know) only support up to 8 axes and 32 buttons in a single device. This limitation is the reason that the commercial boards are also limited to 8 axes and 32 buttons.

Is there a way to do the same with ground units, that is tell a ground unit group to only attack a specific subset of enemies?

Sounds like a great way to set things up. I assume that you can set up two batch files to stop and start the service whenever you want to upload new firmware to your board. How does this setup handle unplugging and replugging the board?

Get an Arduino Leonardo (I got mine for 10 EUR shipped locally from Germany, Chinese knock-offs start at $7.31 right now). Then follow this example (also has a link that lists what code to use for the function keys).

You have mistyped "witchcraft" in your DO SCRIPT action. It is also case-sensitive. The line "[C]: ?" just means that this particular function in the stack trace is implemented in C, so there is no name to display.

It also works with the Steam version (exact same setup steps). Are there any errors in your dcs.log? Any firewalls or antivirus programs that might interfere with the (localhost) network connection between DCS and the node.js server?

Can confirm. I made a mission with a red unit transmitting on 32 MHz FM and a blue unit transmitting on 35 MHz FM. Added a red and a blue A-10C, both could only receive the transmission of their respective ally. You should report this as a bug. Possible crude workaround: use trigger.action.radioTransmission instead, that seems to be independent of any coalition or unit. You'd have to do it with a short audio file (and loop = false) and regularly re-trigger it to make it follow your target vehicle around.

True until you want to do things like button matrices or displays, which the Arduino library does not support out of the box. As far as I understand it, there is no problem, just the need for confirmation that yes, to do these things you have to learn how to write Arduino code.

Take a look at this thread.

You will probably have to wait for the planned overhaul of the Arduino library internals for something like that to work. When I wrote the current version of the Arduino library, I simply did not consider what would happen once people connected multiple things that take some time to update (like graphic LCDs or MAX7219 chips) as opposed to the near-instant toggling of a LED output pin. I just assumed that there would be one Arduino board per panel. Now several people seem to try to connect as much stuff as possible to a single Mega 2560 to avoid having to deal with multiple Arduino boards (which I admit does not have an elegant solution either at the moment). There is nothing wrong with that, but it requires an Arduino library that is designed to deal with it. Together with Gadroc, I have already come up with an architecture for the Arduino library that should solve these problems. Unfortunately, my programming time right now is severely limited so I probably won't be able to work on this for a few weeks.

The same will apply to DCS-BIOS, it's a setting in the multiplayer server. Try playing on different servers.

Yes, it is. You have discovered my secret master plan. You get a few switches and LEDs up and running within an hour using copy&paste. Then you want to do something more advanced like using a display or a button matrix. At that point, I have already tricked you into putting an Arduino board on your desk, so you might as well play around with it. Once you start writing your own Arduino code, you can never stop thinking of even more things you can build outside of your simpit -- just ask WarHog :devil_2:

The import protocol is described in the DCS-BIOS Developer Guide: Let's look at the "0" button on the CDU as an example. The control reference in "advanced" view has the following to say: To push the button, send "CDU_0 1\n" by calling sendDcsBiosMessage("CDU_0", "1"). To release the button, send "CDU_0 0\n" by calling sendDcsBiosMessage("CDU_0", "0"). The connect-serial-port.cmd script that comes with DCS-BIOS expects to communicate with your Arduino at 500000 bps. The default mode of the serial monitor in the Arduino IDE expects 9600 bps (but it can be told to communicate at up to 115200 bps). When the speed that your Arduino is transmitting at does not match the speed your PC is receiving at, the serial communication will fail.