FSFIan

You need to break down your problem into smaller sub-problems: How do I add an entry to the radio menu? How do I spawn the RPG troops at a specific location on the map? How do I figure out the location of the APC? At that point, "how do I spawn the RPG troops near the APC" is just a generic programming problem (take the APC coordinates and add some small offset). Please take a look at the second post in this thread, where I described the process I go through when I want to find out how to do something in a mission script. It will teach you how to use two important resources: 1) The reference documentation for MiST and the Simulator Scripting Engine on the hoggit wiki -- that tells you which functions you have to work with 2) The Lua Console in my DCS Witchcraft project -- that allows you to try new code snippets within a few seconds instead of spending one or two minutes waiting for DCS to reload your mission You'll want to look at mist.dynAdd, the Group and Unit classes, and the trigger.action.* functions that have "otherCommand" in the name (those refer to the commands in the F10 "Other" radio menu). Another thing that can often help is to find a mission that does something similar to what you want to do and look at their code. Please don't take this the wrong way, but the cynic in me reads that as "I can't be bothered to read the documentation, so please do all the work for me, and in the future I still plan to continue asking questions that could mostly be answered by reading the docs instead of trying to solve the problem myself first". I do understand where you are coming from, especially if you were unaware of one or more of the resources I linked above. I promise you that once you get used to the process of "scan the docs for interesting functions, then play around in the Lua Console to see how they work", you will be able to solve a lot of these smaller problems in less time than it would have taken to get an answer on the forums (or even write up the question). And even when you fail, you get to post much better questions, because they will say "I tried X, expected it to do Y, but Z happened", and you can use a specific subject line for your thread so the eventual solution is easier to find for other people who have a similar problem in the future.

I haven't updated this in quite a while and I guess that even if moving units still worked, saving would fail because of changes in the mission file format in 1.5. You may be interested in this thread instead.

I think I know how to look into this and fix it. In Export.lua, you don't get the CDU text as a single string. Instead, you get a table of key-value pairs, where parts like the "FPMENU" page title and the "D5/B1" label in the top right are separate entries. You then have to piece the complete display contents back together from these snippets, so you have to know where they go based on their key in the table. I extracted most of the mapping of keys to display locations from the CDU indicator Lua files with a Python script, but the results did need a few manual corrections. Guess I just need to add a few more. Can you post your code and a mini build log (e.g. the type of display used) in a separate thread? I'd be interested to see which graphics library you are using and which process you used to get from the in-game texture to a font that your graphics library can use. Is that a 320x240 display? Looks great! @Exo7: I will add support to use the Mega as an RS-485 slave in the future. It's not a big change, I just need to find the time to test it. I am a bit busy with university right now.

I can't be sure because you did not post the complete devices.lua and I don't have access to my DCS computer to check right now, but I'd bet $10 you are using the wrong device IDs. Don't trust the comments, read the code! IIRC the counter() function is defined like this at the top of devices.lua: local count = 0 local function counter() count = count + 1 return count end That means that the first device ID will be 1, not 0. You should also watch out for places where the numbering in the comments skips one or two digits. Doesn't happen in the M-2000 devices.lua, but I have seen it for other aircraft (e.g. UH-1H). The Lua interpreter does not care about misleading comments, the truth is in the code :) If you add one to all the device IDs you have tried, it should work.

LoGetSelfData() definitely works in multiplayer. The important difference between SP and MP here is that in MP, there exists a state where the game is unpaused AND you are not in any aircraft (spectator mode!), so LoGetSelfData() returns nil. If that causes your Export.lua to shit its pants to the point that it does not start working again once you actually are in an aircraft and LoGetSelfData() works as expected, you have an Export.lua that will only work in SP. If your Export.lua handles that case gracefully, it will work fine on any multiplayer server (unless it also relies on LoGetObjectByID() or LoGetWorldObjects()). If you can't get it working, post the contents of your Export.lua here and I'll take a look.

If the "Allow object export" checkbox is not checked, the functions LoGetWorldObjects() and LoGetObjectByID() will be disabled in the Export.lua environment (because they can be used to get information, such as the current position, about any unit in the game). Everything else still works, including the stuff that software like Helios and DCS-BIOS relies on. The only program that relies on LoGetWorldObjects() that I can name off the top of my head is TacView. Your simpit will work fine on public servers, regardless of whether they enable object export or not.

When I first played around with what would eventually become DCS Witchcraft, I had a code snippet that allowed me to spawn a vehicle at a relative position to some other object. I experimented with spawning a tank at different distances in front of my A-10C (to ensure they would be spawned where I was looking). Then I took off and spawned things near my A-10C while in flight. When I spawned them in front of me, I would collide with them soon after and explode. I figured out that by spawning them a certain distance behind me, I would briefly hear them scrape against my A-10C and they would then stay in mid-air. I think that was followed by spawning some red smoke in the same location and trying to get a guns kill on a stationary airborne target :D Can't remember whether I killed one or they dropped to the ground as soon as the first bullet hit though.

As far as I know, when spawning ground units, DCS does not expect an altitude at all, so MiST will ignore whatever altitude you specify in your vec3 anyway. I think what happens here is that you spawn the infantry unit at the precise moment that the pilot ejects. DCS will cast a ray from an infinite height down at the ground and spawn the unit whereever that ray collides with an object (in your case, that is the plane that your pilot just ejected from). That's how I built the HMMWV Archway in the image below. You can either try to delay the spawn by a small amount of time and hope the aircraft is out of the way by then, or you can issue a movement order (a small distance in any direction will do). IIRC the unit will drop back to the ground as soon as it starts moving.

Genau wie er: einfach ignorieren. Ob der Wert für value_up, den du ignorierst, nun existiert oder nicht, sollte egal sein :)

Sorry, that was an oversight on my part; I forgot to change that part of the documentation. Use the IRQSerial sketch as a template. If that does not compile (because you are using some Arduino board that doesn't have a ATMega328 or ATMega2560), use DefaultSerial instead.

It's the same for the Arduino boards. The barrel connector is for an optional external power supply, in case you make a circuit that draws more than what USB can supply or if you want to run your Arduino-powered thing without connecting it to a computer. If no external power supply is connected, the Arduino boards will draw their power from the USB cable.

Why spend $58 when you can grab one or two $5 Arduino Leonardo clones from eBay or AliExpress and then use this instructable to turn them into joysticks? I am not saying Desktop Aviator are charging too much for their product. $58 is just the cost of producing small quantities for a niche market and taking the time to properly document everything and do customer support. Being located in the US doesn't help with labor costs, either. $5 is what you get if you can produce thousands of boards in China and ship them worldwide to the hobbyist/maker market, and don't have to take the time to do software support for your customers (the seller's responsibility ends as soon as the pre-flashed LedBlink example works; and if it doesn't because the unit is DOA, they'll just ship you a new board instead of having to spend time on troubleshooting). If the controls you want to map in DCS work with the Desktop Aviator board and you want a truly plug and play solution, there's nothing wrong with spending $58 on that. But if it turns out you have to do some tinkering anyway, you might as well save money in the process.

I assume you mean those 16x2 or 20x2 character LCDs with a HD44780 compatible controller. Yes, you can connect several of those to the same Arduino. If memory serves, you need five wires that are shared between all displays plus one "enable" line per display. And even if you notice later on that it can't handle that many for whatever reason, throwing another $3 Arduino clone at the problem is probably easier and cheaper than going with a single large display.

Released DCS-BIOS v0.5.0 and the DCS-BIOS Arduino Library v0.2.0. There have been some changes from previous versions. The baud rate for serial communication is now 250000 bps. You should adapt your old sketches to the new version of the Arduino library and reflash your boards. Using the new version of the Arduino library is a bit simpler, because all communication code is now provided by the library by default. You can select which variant of that code you want by defining a preprocessor macro before including DcsBios.h. Here's the new MasterCaution example: /* use '#define DCSBIOS_DEFAULT_SERIAL' instead if your Arduino board * does not feature an ATMega328 or ATMega2650 controller. */ #define DCSBIOS_IRQ_SERIAL #include "DcsBios.h" DcsBios::Switch2Pos lampTestBtn("LAMP_TEST_BTN", 10); DcsBios::LED nmspIlsLed(0x1112, 0x0020, 13); void setup() { DcsBios::setup(); } void loop() { DcsBios::loop(); } By defining DCSBIOS_IRQ_SERIAL, we select the new interrupt-driven communication handling. You should always use this if possible (it only works on ATMega328 and ATMega2560 controllers). For other Arduino-compatible boards, you can define DCSBIOS_DEFAULT_SERIAL to fall back to the standard Serial class. You need to call DcsBios::setup() and DcsBios::loop() from your setup() and loop() functions respectively. RS-485 support is included, but not documented yet beyond what I had mentioned in the DCS-BIOS discussion thread in post #194. As always, please create a new thread for any questions and use the DCS-BIOS Discussion thread for general comments. This thread is meant as a low-traffic thing for people to subscribe to and is reserved for release announcements of DCS-BIOS related software.

The MAX7219 supports up to 8 rows and up to 8 columns, so it cannot do a 4x12 matrix. However, just because the LEDs are physically arranged in a 4x12 configuration does not mean you have to do the same electrically. For example, you could split the physical columns in the middle and make a matrix with 8 columns and 6 rows like this:

Warum passiert das? Dazu muss ich ein klein bisschen ausholen. DCS-BIOS sendet die Daten in zwei-Byte-Blöcken (also je 16 Bits) an den Arduino. Dabei versuchen wir die Daten so effizient wie möglich zusammenzupacken. Die Auslenkung eines analogen Zeigers wird mit einer 16-Bit-Zahl übertragen, um genau genug zu sein. Es wäre aber eine riesige Verschwendung, für den Status einer einzelnen LED 16 Bit zu belegen. Also benutzen wir dafür nur ein Bit. Wenn so ein 16-Bit-Block an Daten am Arduino ankommt, muss er es verarbeiten. Dazu gibt es intern eine Liste aller Klasseninstanzen (DcsBios::LED, DcsBios::ServoOutput, etc), die sich für sowas interessieren; die bekommen jeweils die Gelegenheit, diese Daten zu verarbeiten. Die LED-Klasse holt sich z.B. das für sie interessante Bit raus und setzt den GPIO-Pin entsprechend. Während diese Verarbeitung läuft, landen weitere Daten, die vom PC reinkommen, in einem Empfangspuffer, anstatt in zwei-Byte-Blöcke zerlegt zu werden. Wenn dieser Zustand zu lange anhält, ist der Puffer irgendwann voll, weitere Daten werden ignoriert und die Software ist nur noch verwirrt. Die Daten für die 48 Caution Lights in der A-10C liegen in drei aufeinanderfolgenden 16-Bit-Blöcken. Wenn die in schneller Folge aktualisiert werden (z.B. weil du auf SIGNAL LIGHTS TEST drückst oder weil DCS-BIOS auch ab und zu Daten sendet, wenn sie sich nicht geändert haben, damit man ein Panel auch später noch anschließen kann), dann landen bei deinem Sketch relativ viele Daten im Empfangspuffer, denn für jeden der drei Datenblöcke interessieren sich jeweils 16 Instanzen von DcsBios::LED. Auf dem Boden geht das noch klar, weil sich so gut wie nichts ändert. Ein gesamtes Datenupdate von DCS-BIOS, was ca. alle 30 ms gesendet wird, passt komplett in den Puffer, und wenn das komplett empfangen wurde, hat der Arduino alle Zeit der Welt (ca. 25 ms), um den Puffer wieder leerzuarbeiten. In der Luft (oder schon beim Rollen auf dem Boden) sieht das anders aus. Es gibt viel mehr analoge Instrumente (Triebwerksanzeigen, ADI, HSI, etc) die ihre Werte jetzt ständig ändern, und sei es nur um ein paar Nachkommastellen. Die 30-ms-Updates werden zu groß für den Empfangspuffer auf dem Arduino, und er läuft voll. Wie kann man das abstellen? Bisher gab es da nur einen Workaround: lass den PC die Daten langsamer senden, so dass der Puffer nicht ganz so schnell vollläuft. Dazu musst du in connect-serial-port.cmd die BAUDRATE von 500000 auf z.B. 115200 runtersetzen, und das gleiche im Arduino-Sketch mit dem Parameter für Serial.begin() machen. Das kann in manchen Fällen helfen, beseitigt aber das eigentliche Problem nicht. Die vernünftige Lösung des Problems wird in der nächsten Version der Arduino-Library drin sein (die ich hoffentlich in den nächsten Tagen veröffentliche, es fehlen hier und da noch etwas Feinschliff und vor allem Dokumentation). Hier wird weitgehend auf einen Empfangspuffer verzichtet, stattdessen wird die Verarbeitung eingehender Daten priorisiert (die meisten können sowieso schnell verworfen werden, weil sich ein einzelner Arduino nie für die Daten des kompletten Cockpits interessiert). Der Code ist schon im rs485-Branch auf GitHub verfügbar. Eine wichtige Änderung ist, dass die neue Standard-Ubertragungsrate auf dem seriellen Port 250000 bps statt 500000 bps ist, du musst also die BAUDRATE in connect-serial-port.cmd anpassen. Die weiteren Änderungen sind hier knapp beschrieben, es sollte aber reichen, wenn du den neuen IRQSerial-Template-Sketch benutzt und deine DcsBios::LED-Zeilen reinkopierst. Leider unterstützt diese Version noch nicht den Arduino Mega, das werd ich vor Release aber noch einbauen (sollte nicht weiter schwierig sein, ich hatte nur auf einen zweiten Mega zum Testen gewartet, der ist mittlerweile angekommen).

For EU customers, it might be a good idea to offer payment via SEPA wire transfers. As far as I know there is a EU directive that says banks are not allowed to charge more for wire transfers to other EU countries than they charge for domestic wire transfers.

Do you have a part number and source for these? Whenever I try to find inexpensive toggle switches in that price range on eBay or AliExpress, all I seem to find are miniature versions. Sorting the Toggle Switch category over at Digikey by unit price lists the least expensive switch at $1.45 a piece with a minimum order quantity of 500. Have I been looking in the wrong places?

Your power source should be fine. Its quality does not matter too much anyway because there's a 5V linear regulator between it and the electronics. If you have some specific reason to mistrust it, you could grab a very clean 12V feed from a PC power supply or disconnect the 5V regulator (desolder if you have to) and power the board's +5V line directly from the PC power supply or a USB port. I don't expect termination or bias resistors to be needed below a bus length of 10 meters. Your setup is way below that. Can't say much about crosstalk, as I don't have any experience with it, let alone a theoretical background of how it works (I know that it exists and the basic principles of how it works, but I have no idea of how to quantify it). The software should be able to recover from short transient faults (such as interference on the bus caused by hotplugging a new slave device), but that timeout mechanism has not been tested a lot yet. On the other hand, as long as the TX/RX LEDs keep flashing, the software has not hung itself in a deadlock and there's a pretty good chance it's still operating as intended. You can try to set your RS-485 slave address to 0 ("#define DCSBIOS_RS485_SLAVE 0"). Address 0 will never be polled, so the slave device should not try to send anything. To make extra sure, disconnect the TX_ENABLE line from the Arduino and tie it to ground. Then see if you can get an output (such as a Master Caution LED on pin 13) to work over RS-485.

The whole thing was an exercise in getting the greatest improvement in usability for the least amount of money. The setup has since been replaced by a touch screen, but when I built this, touch screens (even the crappy ones) were still $600+. This was built with about $15 worth of materials. I figured since I lacked the time, space or money to build a proper simpit, I'd challenge myself to do it as cheap as possible instead. I printed out an image of the UFC and the MFCD outlines on the heaviest paper my laser printer would accept. I laid the printout on top of a piece of monitor-sized foamboard. Then I punched holes for the buttons (soldered four pins into a piece of protoboard to use as the hole-punch tool), and stuck the buttons through. To help them stay in place during the next step, I placed a tiny dab of glue under each button. I used a wire-wrap tool to connect everything without soldering (I was even too cheap to use a PCB -- and curious if I could get away with this). The wires go between the foamboard and the printout. For the UFC, I taped a second printout on top, to be able to see the labels on the buttons. I wouldn't recommend this technique for the MFCDs, it takes too much time to wire up and the large amount of wires in a small space made them fail after a few months of use. But I'd still use the UFC if the whole thing hadn't been replaced by a $250 touch screen when Windows 8 came out and caused the prices of touch screens to drop significantly.

I'll just leave this here...

Not going to happen, unless you can show me a piece of Lua code that can get the airspeed in any aircraft. The CommonData module is only for those pieces of data that can be reliably retrieved independent of the aircraft type. Also, please read the first post of this thread. It's meant for release announcements only, to give people a low-traffic thread to subscribe to. For questions, open a new thread. For general discussion, use the DCS-BIOS Discussion Thread.

The magic word to search for is "hackerspace", possibly also "makerspace". Maybe you should check out RevSpace, there's a picture of a PCB mill in this hackaday.com article about them. Maybe those FABlabs are more geared towards the artist crowd.

You can't send the same unicast UDP stream to two computers either, so what's your point here? Multicast UDP is nice in theory, but it's a nightmare to support in practice. There were several people who just couldn't get it to work, and the fix was to switch to TCP. You can send to the broadcast address, but I wouldn't be surprised if that approach would yield the same amount of firewall issues (and thus "support calls") as multicast UDP does. And then there will be that one guy who has a network setup where his wireless is on a different broadcast domain to the wired ethernet and he'll wonder why he can't connect to DCS-BIOS from his tablet/smartwatch/fridge/whatever. The context is important here. I agree with you when talking about microcontrollers, which is why I said I will keep the option to configure unicast UDP streams if people are actually using Ethernet shields. But IMO, on a microcontroller you'd want to use either a direct serial connection or RS-485, because both of those have a lot less overhead than parsing raw Ethernet frames, let alone UDP or TCP. If we are talking about a PC, smartphone or tablet on your local network, then yes, TCP does have more overhead than UDP, but it's not significant. TCP probably needs a few kilobytes more RAM -- insignificant when you measure the amount of system memory in hundreds of megabytes. It will also need a few more CPU cycles to maintain its state, but I would be very surprised if you could even measure that. If a TCP packet gets lost, it will need to be retransmitted and it may increase the latency of a few subsequent packets which may have to wait for it. We are on a local network, so the common case is that no retransmissions occur. If you do have retransmissions using TCP, that means that you'd have packet loss if using UDP, which would be even worse. The one big advantage of UDP over TCP is that the order in which you start DCS and the client application does not matter. But it's not that hard to implement some "retry connecting once a second" logic into the client application. Correct me if I am wrong, but that only allows one application (Helios) to connect at a time. Which means the next application does not only establish its own connection to DCS, but comes with its own Export.lua file, so the data is not only sent twice, but also calculated twice. TL;DR: A properly implemented TCP solution is easier to support, more flexible, and creates no difference in user experience. Network-connected microcontrollers are the exception, and if enough people are actually using those instead of RS-485 or USB-serial connections, I'll keep the option to configure unicast UDP streams for those. If DCS-BIOS 2.0 drops UDP support, you can still run "socat tcp-connect:localhost:PORT udp-recv:LISTENPORT!!udp-send:ip:port" to bridge between the two.

UART1_TXENABLE_PIN corresponds to the RX1 and TX1 pins, UART2_TXENABLE_PIN to RX2 and TX2 and UART3_TXENABLE_PIN is for RX3 and TX3. If the TXENABLE pins were mixed up in your setup, you would have a floating TXENABLE pin (because the other two transceivers are disabled by the commented-out TXENABLE #defines), which could cause all sorts of semi-working behavior -- electromagnetic interference can be weird like that. When you operate the same switch repeatedly, do you get the same (garbage) data every time or does it change? I am currently thinking about a few different tests we could set up. For example, you can connect a MAX487 transceiver to one of those USB-to-UART adapters and tie the RX_ENABLE pin to +5V. That gives you a way to see what is happening on the RS-485 bus, assuming the data is valid (e.g. no two transceivers trying to talk at the same time and no framing errors). If you make two of those constructs, you can listen on two different places on the bus at the same time and compare the data you receive. If there is a difference, there must be a hardware problem. You should also order one of these $7.20 logic analyzers. They are cheap knockoffs of the original Saleae Logic 8 / USBee AX designs (not much more than just a breakout board for a particular Cypress chipset -- the reason normal commercial logic analyzers cost hundreds of dollars is the high-quality software they come with). You can use them with the open source sigrok project. From my experience with such a device and sigrok under Windows, it is not rock solid above 4 to 6 MHz sample rate and with multiple channels (the capture just stops randomly after about 30 seconds to two minutes), but it's good enough to capture two or four channels at 4 MHz sample rate, which is all you need for a 0.25 Mbps serial channel. On Linux, I had better results, with stable capture on 8 channels at up to 12 MHz sample rate.