FSFIan

The short version: I have come to realize that I am not able to work on DCS-BIOS while working a full time job that requires a similar skillset. That means I will not work on expanding or supporting DCS-BIOS until circumstances change, and that will probably not happen. The long version: I started getting into DCS and later building DCS-BIOS because I am fascinated by complex systems. This worked out well while I was still studying computer science; it provided me an outlet to do some programming close to the hardware while the curriculum developed more and more towards the theoretical side of things. About three years ago I decided to stop pursuing a masters degree and get a job with the bachelors degree that I had. Starting to work full time stopped almost all progress on DCS-BIOS, but I always kept telling myself that the day job would get less stressful and tiring over time. That did not happen. I have since changed jobs four times, hoping to find one that would not drive me crazy. Well, I found one. For the last three months, none of the stress in my life has been job related. I am now working for a company that makes PC-based automation technology, working on the team that customizes the BIOS for the PC mainboards they design and build in-house (the guys who do the PCB layout sit just one office away). Unfortunately, I am still unable to continue work on DCS-BIOS, and this time, there is nothing I can expect to change about the situation. I have to accept (and admit to myself and to you guys) that after I get home from work, I have had my fill of debugging software and lack any desire or energy to do more of the same. I still don't know exactly what this means for the future of the project. I could do some work on it during a vacation, but that won't be enough to get significantly closer to the goals I had in mind, so I probably won't start working on new features. I will try to fix any regressions (i.e. if a new DCS: World version breaks something that was working before), although the API that DCS-BIOS is using has been pretty stable (I think I had to change something once when ED added the different export options on MP servers).

Try adding a small delay between commands. As far as I can tell, commands for a particular control will be ignored while DCS is still animating that control. If you send multiple commands in the same UDP packet or within a very short time interval, they might even be processed in the same simulation frame. I am also not sure if you could issue the same command twice in one frame even when no animations were involved. The unreliability of UDP tends not to be an issue on a LAN or localhost unless you have a huge amount of data to transfer and manage to fill up all of the buffers.

The callback function receives the value as a function parameter (named newValue in the code snippets). Try the following: AirSpeedConvert = newValue;

Can you post a screenshot of what you do see?

Da gehen mir langsam die Ideen aus. Der Rest vom Webinterface funktioniert ja, d.h. es gibt auch keine Firewall, die sich in die Websocket-Verbindung einmischt. Du kannst mal im Browser F12 drücken, dann geht die Developer-Console auf. Da gibt es einen "Console"-Tab, wo manchmal Fehlermeldungen landen. Ich könnte dir anbieten, dass wir uns das am Wochenende mal im Discord gemeinsam ansehen.

Here is the script that I have been running over the last week or so to test the new "Hub Scripts" feature. It implements the following: Makes my Harrier UFC, ODU and MPCD panels work in the Hornet (Harrier TMR = Hornet A/P, Harrier ALT = Hornet D/L) In the Harrier, whenever the UFC would be blank otherwise, it displays the status of the AFC and ALT HOLD switches and allows to toggle them via the option select buttons. You can also enter or leave this display mode by pressing the (non-functional in DCS) "I/P" button on a physical Harrier panel. How to use: Save anywhere on your hard drive with a .lua extension (e.g. My Documents/remap.lua) Shift+Right Click the file in Windows Explorer and choose "Copy as path" Use the new "Hook Scripts" section on the Dashboard in the web interface to add the path to the script Click the "Reload Scripts" button If you want to play around with your own hub scripts: unfortunately, at the moment there is no way to view the output of Lua's print() function yet. The best way to debug your scripts is to use the Lua Console and select the "hub" environment (see the documentation on how to use enterEnv() to execute Lua code in the environment of your script). Here is the code: acftName = "NONE" local setPanelString = hub.setPanelString local getSimString = hub.getSimString function remapOutput(a, b) setPanelString(b, getSimString(a)) end function remapExportData() acftName = getSimString("MetadataStart/_ACFT_NAME") if acftName == "AV8BNA" then end if acftName == "FA-18C_hornet" then remapOutput("FA-18C_hornet/UFC_COMM1_DISPLAY", "AV8BNA/UFC_COMM1_DISPLAY") remapOutput("FA-18C_hornet/UFC_COMM2_DISPLAY", "AV8BNA/UFC_COMM2_DISPLAY") local scratchpad = getSimString("FA-18C_hornet/UFC_SCRATCHPAD_STRING_1_DISPLAY") scratchpad = scratchpad .. getSimString("FA-18C_hornet/UFC_SCRATCHPAD_STRING_2_DISPLAY") scratchpad = scratchpad .. getSimString("FA-18C_hornet/UFC_SCRATCHPAD_NUMBER_DISPLAY") setPanelString("AV8BNA/UFC_SCRATCHPAD", scratchpad) remapOutput("FA-18C_hornet/UFC_OPTION_CUEING_1", "AV8BNA/AV8BNA_ODU_1_SELECT") remapOutput("FA-18C_hornet/UFC_OPTION_DISPLAY_1", "AV8BNA/AV8BNA_ODU_1_Text") remapOutput("FA-18C_hornet/UFC_OPTION_CUEING_2", "AV8BNA/AV8BNA_ODU_2_SELECT") remapOutput("FA-18C_hornet/UFC_OPTION_DISPLAY_2", "AV8BNA/AV8BNA_ODU_2_Text") remapOutput("FA-18C_hornet/UFC_OPTION_CUEING_3", "AV8BNA/AV8BNA_ODU_3_SELECT") remapOutput("FA-18C_hornet/UFC_OPTION_DISPLAY_3", "AV8BNA/AV8BNA_ODU_3_Text") remapOutput("FA-18C_hornet/UFC_OPTION_CUEING_4", "AV8BNA/AV8BNA_ODU_4_SELECT") remapOutput("FA-18C_hornet/UFC_OPTION_DISPLAY_4", "AV8BNA/AV8BNA_ODU_4_Text") remapOutput("FA-18C_hornet/UFC_OPTION_CUEING_5", "AV8BNA/AV8BNA_ODU_5_SELECT") remapOutput("FA-18C_hornet/UFC_OPTION_DISPLAY_5", "AV8BNA/AV8BNA_ODU_5_Text") end end hub.registerOutputCallback(remapExportData) inputMap = { ["FA-18C_hornet"] = { ["UFC_B1"] = "UFC_1", ["UFC_B2"] = "UFC_2", ["UFC_B3"] = "UFC_3", ["UFC_B4"] = "UFC_4", ["UFC_B5"] = "UFC_5", ["UFC_B6"] = "UFC_6", ["UFC_B7"] = "UFC_7", ["UFC_B8"] = "UFC_8", ["UFC_B9"] = "UFC_9", ["UFC_B0"] = "UFC_0", ["UFC_COM1_SEL"] = "UFC_COMM1_CHANNEL_SELECT", ["UFC_COM2_SEL"] = "UFC_COMM2_CHANNEL_SELECT", ["UFC_CLEAR"] = "UFC_CLR", ["UFC_ENTER"] = "UFC_ENT", ["UFC_TIMER"] = "UFC_AP", ["UFC_IFF"] = "UFC_IFF", ["UFC_TACAN"] = "UFC_TCN", ["UFC_WEATHER"] = "UFC_ILS", ["UFC_ALT"] = "UFC_DL", ["UFC_BEACON"] = "UFC_BCN", ["UFC_ONOFF"] = "UFC_ONOFF", ["UFC_COM1_VOL"] = "UFC_COMM1_VOL", ["UFC_COM2_VOL"] = "UFC_COMM2_VOL", ["UFC_COM1_PULL"] = "UFC_COMM1_PULL", ["UFC_COM2_PULL"] = "UFC_COMM2_PULL", ["UFC_BRIGHT"] = "UFC_BRT", ["UFC_EMCOM"] = "UFC_EMCON", ["ODU_OPT1"] = "UFC_OS1", ["ODU_OPT2"] = "UFC_OS2", ["ODU_OPT3"] = "UFC_OS3", ["ODU_OPT4"] = "UFC_OS4", ["ODU_OPT5"] = "UFC_OS5", } } local resetCrsSwitchCountdown = -1 hub.registerOutputCallback(function() if resetCrsSwitchCountdown > 0 then resetCrsSwitchCountdown = resetCrsSwitchCountdown - 1 if resetCrsSwitchCountdown == 0 then hub.sendSimCommand("LEFT_DDI_CRS_SW", "1") resetCrsSwitchCountdown = -1 end end end) function remapCommand(cmd, arg) mapping = inputMap[acftName] if mapping == nil then return cmd, arg end replacementCmd = mapping[cmd] if replacementCmd ~= nil then cmd = replacementCmd end if acftName == "FA-18C_hornet" then cmd = cmd:gsub("^MPCD_L_(%d)$", "LEFT_DDI_PB_0%1") cmd = cmd:gsub("^MPCD_L_(%d%d)$", "LEFT_DDI_PB_%1") cmd = cmd:gsub("^MPCD_R_(%d)$", "RIGHT_DDI_PB_0%1") cmd = cmd:gsub("^MPCD_R_(%d%d)$", "RIGHT_DDI_PB_%1") end if acftName == "FA-18C_hornet" then if cmd == "NAV_CRS" then if arg == "INC" then hub.sendSimCommand("LEFT_DDI_CRS_SW", "2") resetCrsSwitchCountdown = 3 end if arg == "DEC" then hub.sendSimCommand("LEFT_DDI_CRS_SW", "0") resetCrsSwitchCountdown = 3 end end end return cmd, arg end hub.registerInputCallback(function(cmd, arg) newCmd, newArg = remapCommand(cmd, arg) if newCmd == cmd and newArg == arg then return end hub.sendSimCommand(newCmd, newArg) return true end) local ufcMenuMode = false local idleMode = false hub.registerInputCallback(function(cmd, arg) if hub.getSimString("MetadataStart/_ACFT_NAME") ~= "AV8BNA" then return end if cmd == "UFC_IP" then if arg == "1" then ufcMenuMode = not ufcMenuMode end return true end if not (ufcMenuMode or idleMode) then return end if cmd == "ODU_OPT1" then if arg == "1" then if hub.getSimInteger("AV8BNA/AFC_SW") == 2 then hub.sendSimCommand("AFC_SW", "1") else hub.sendSimCommand("AFC_SW", "2") end end return true end if cmd == "ODU_OPT2" then if arg == "1" then if hub.getSimInteger("AV8BNA/ALT_HOLD_SW") == 1 then hub.sendSimCommand("ALT_HOLD_SW", "0") else hub.sendSimCommand("ALT_HOLD_SW", "1") end end return true end if cmd == "ODU_OPT3" then return true end if cmd == "ODU_OPT4" then return true end if cmd == "ODU_OPT5" then return true end end) hub.registerOutputCallback(function() if hub.getSimString("MetadataStart/_ACFT_NAME") ~= "AV8BNA" then return end idleMode = true if hub.getSimString("AV8BNA/UFC_SCRATCHPAD"):gsub(" ", "") ~= "" then idleMode = false end if hub.getSimString("AV8BNA/AV8BNA_ODU_1_Text"):gsub(" ", "") ~= "" then idleMode = false end if hub.getSimString("AV8BNA/AV8BNA_ODU_2_Text"):gsub(" ", "") ~= "" then idleMode = false end if hub.getSimString("AV8BNA/AV8BNA_ODU_3_Text"):gsub(" ", "") ~= "" then idleMode = false end if hub.getSimString("AV8BNA/AV8BNA_ODU_4_Text"):gsub(" ", "") ~= "" then idleMode = false end if hub.getSimString("AV8BNA/AV8BNA_ODU_5_Text"):gsub(" ", "") ~= "" then idleMode = false end if not (ufcMenuMode or idleMode) then return end local afcEnabled = (hub.getSimInteger("AV8BNA/AFC_SW") == 2) local altHoldEnabled = (hub.getSimInteger("AV8BNA/ALT_HOLD_SW") == 1) local afcMode = " " if afcEnabled and (not altHoldEnabled) then afcMode = "Path" end if afcEnabled and altHoldEnabled then afcMode = "Alt " end hub.setPanelString("AV8BNA/AV8BNA_ODU_1_Text", "AFC") hub.setPanelString("AV8BNA/AV8BNA_ODU_1_SELECT", afcEnabled and ":" or " ") hub.setPanelString("AV8BNA/AV8BNA_ODU_2_Text", "ALTH") hub.setPanelString("AV8BNA/AV8BNA_ODU_2_SELECT", altHoldEnabled and ":" or " ") hub.setPanelString("AV8BNA/AV8BNA_ODU_3_Text", afcEnabled and afcMode or "OFF!") hub.setPanelString("AV8BNA/AV8BNA_ODU_3_SELECT", " ") hub.setPanelString("AV8BNA/AV8BNA_ODU_4_Text", ufcMenuMode and "MENU" or " ") hub.setPanelString("AV8BNA/AV8BNA_ODU_4_SELECT", " ") hub.setPanelString("AV8BNA/AV8BNA_ODU_5_Text", afcEnabled and " " or " AFC") hub.setPanelString("AV8BNA/AV8BNA_ODU_5_SELECT", " ") end)

New Release: v0.10.0 fix IntegerBuffer code snippet (add missing mask and shift_by values) IntegerBuffer snippet is now prioritized over the ServoOutput snippet document Potentiometer code snippet and expose the parameters for the EWMA filter remove "Installed Modules" list (now that module definitions are being installed as plugins, this list will most likely be identical to the list of all available module definitions anyway. Create a bookmark in your browser to quickly find your favorite module.) add "Hub Scripts" feature (the DCS-BIOS Hub can now run Lua scripts that can remap commands and outputs depending on the active aircraft) I will post a quick demo of the new "Hub Scripts" feature in a separate thread today and hope to add a few more examples on the weekend. Note that this update removes the experimental, undocumented "inputmap.txt" remapping feature. Please post comments in the DCS-BIOS Discussion Thread. Please open separate threads for questions.

Die F-18C ist im DCSFlightpanels-Fork entstanden, und da gab es einige Updates, bei denen sich Adresssen geändert haben. Ich hatte damals nicht dokumentiert, wie man Updates macht, ohne dass sich die Adressen ändern, und die DCSFlightpanels-Nutzer haben es nicht bemerkt, weil DCSFlightpanels jedes mal die Adresse anhand des Namens naschschlägt. Das erklärt aber nicht, warum die Live-Daten nicht funktionieren. Ich habe gerade mal DCS-BIOS 0.9.3 neu installiert und mit der F-18C getestet (anhand des UFC-Displays). Mit Edge und Chrome hat es wunderbar funktioniert, Firefox ist mir immer eingefroren. Da hab ich mich wohl im Javascript-Teil irgendwo dumm angestellt, muss ich mal optimieren. Edit/PS: Solange die Live-Daten nicht funktionieren, brauchst du in deinem Arduino-Code keine Fehler suchen.

SkyJunky: Für welches Flugzeug hast du dein Cockpit gebaut? Wenn du in der neuen Control Reference auf "MetadataEnd" > "Metadata" klickst, wird dort der "Update Counter"? immer erhöht oder funktioniert selbst das nicht? (Der ist ja in allen Modulen immer an der gleichen Adresse.) Ist im Menüpunkt "DCS Connection" der Haken bei "Virtual Cockpit" gesetzt? (wenn nicht, dann benutzt du den alten Export.lua-Code mit der neuen DCS-BIOS-Version; wenn sich da die Adressen geändert haben würde das erklären, warum keine Daten angezeigt werden) Welchen Browser benutzt du? (Es sollte zwar in Chrome, Firefox und Edge funktionieren, aber ich teste nicht immer alle Versionen in allen drei -- das muss noch automatisiert werden) Blockt deine Firewall den DCS-BIOS Hub? (Vermutlich nicht, sonst könntest du das Webinterface gar nicht aufrufen) Weißt du noch, ob die vorherige DCS-BIOS-Version eines der jahre alten "offiziellen" Releases oder eins aus dem DCSFlightpanels-Fork war?

The problem that a DCS-BIOS-based simpit can only be used with one aircraft module will be solved in the very near future by adding Lua scripting to the DCS-BIOS Hub. It's already running on my machine and I think I have found an API design that I am happy with now, so I'll probably release it some time next week. If you use DCS-BIOS, you have two options: connect everything via USB or use an RS-485 bus. Connecting everything over USB is not as annoying as it used to be, as the DCS-BIOS Hub has a graphical user interface where you select the COM ports you want to connect to and it remembers a list of ports it should automatically connect to. As long as each panel stays plugged into the same port on the same hub, Windows should not mess with the COM port numbers too much, and when it does change port numbers on you, you can fix it in 20 seconds. You can also connect each panel to an RS-485 transceiver chip like the MAX487. You will have to buy an Arduino Mega 2560 board which will be the bus master and connect all devices on up to three RS-485 buses via a single USB port. In theory, you can connect up to 126 devices to one RS-485 bus (some transceiver chips only support 32 devices per bus). In practice, the RS-485 feature of the DCS-BIOS Arduino library is not well documented yet and people have had various degrees of success in implementing it. It works without issues for some, while others have had a bunch of hard to diagnose problems. In the future, I plan to add features that make it easier to debug a misbehaving RS-485 bus. For nine Arduino boards, you should have no issues with using USB for everything.

If you can, spend about $100 on a decent temperature-controlled soldering station (Hakko FX-888 or similar). For peace of mind, make sure it has an auto-power-off feature. If you have to use a cheap "starter kit" iron without temperature control (definitely possible, I used one for a few years), make sure to avoid lead-free solder. The cheap irons will not match the higher melting point for the lead-free stuff, and while you can still make working lead-free solder joints with one, it is an exercise in frustration. You can write your Arduino sketch in such a way that different string values go to the same display. How exactly you do this depends on the exact display and Arduino library used. One method is the one shown in the tutorial video on LCDs. In the on...Changed() function, the first command sets the cursor of the display to the start position and the second one writes the newValue to the display. This works well for displays that support a partial update. A slightly different method should be used if your display can only update everything at once. In that case, remove the on...Changed functions from the code snippets and replace them with NULL in the parameter list to the StringBuffer so you'd end up with something like this: DcsBios::StringBuffer<1> ufcOptionCueing1Buffer(0x7428); DcsBios::StringBuffer<4> ufcOptionDisplay1Buffer(0x7432, NULL); In this mode, the StringBuffer will not call a function when the data changes. You can check it instead from your main loop() like this: if (ufcOptionCueing1Buffer.hasUpdatedData() || ufcOption1DisplayBuffer.hasUpdatedData()) { // one of the two values has changed // write both values to the display and update; pseudo-code, adapt to whatever display library you are using myDisplay.setCursor(12, 20); // some position myDisplay.print(ufcOptionCueing1Buffer.getData()); myDisplay.print(ufcOptionDisplay1Buffer.getData()); myDisplay.update(); } In general, a lot of people seem to ask "can you do X with DCS-BIOS?", to which the answer is almost always "yes, as long as you write some Arduino code". I wonder what kind of documentation I need to add to make people ask "How do I" instead of "Can I do". I cannot add snippets to cover every possible use case (even if I had the time, the sheer amount of snippets would overwhelm a newbie). I have one more feature I want to add to the DCS-BIOS Hub; after that, I want to take some time to focus on bug fixes, some user interface design, and most importantly improve the documentation. Any advice on how I can make this complex topic easier to approach for complete beginners is appreciated.

New Release: v0.9.3 If you are not using DCSFlightpanels, you can skip this version. Keep a copy of all control reference JSON files from plugins at %APPDATA%\DCS-BIOS\control-reference-json If you are using DCSFlightpanels, point it to C:\Users\<Username>\AppData\Roaming\DCS-BIOS\control-reference-json so it can find the information in one central place again. Please post comments in the DCS-BIOS Discussion Thread. Please open separate threads for questions.

A "recommended plugin" is one that matches one of your DCS: World modules. For example, if the folder "mods/aircraft/A-10C" exists in one of your DCS: World installation folders, the DCS-BIOS Hub will recommend the "module-a-10c" plugin. If a plugin is not recommended but should be, it means I have not updated the catalog file with the correct installation path yet. The "recommended" status says nothing about the quality or completeness of a plugin. I am not the author of the F-16 module definition and I also don't own or fly the F-16 module, so I don't know how complete it is.

Fixed in v0.9.2

New Release: v0.9.2 This fixes the missing info in the control reference. Let's hope this is the last thing I broke in v0.9.0. Please post comments in the DCS-BIOS Discussion Thread. Please open separate threads for questions.

I sure did manage to break a lot of stuff today. It does the same on my machine, I'll take a look.

How did you install DCS? The DCS-BIOS Hub picks up the DCS install location either from the Windows registry or from the Steam folder structure. Are you having problems on the "DCS Connection" page, on the "Plugins" page, or both? Which plugins do you expect to see but don't? If they are displayed when you uncheck "show only recommended plugins", I need the paths in the DCS installation dir so I can add them to the online catalog to make autodetection work.

New Release: v0.9.1 This release fixes a bug that breaks the Lua export as soon as the DCS-BIOS Hub was restarted. Please post comments in the DCS-BIOS Discussion Thread. Please open separate threads for questions.

For those who might have already tried v0.9.0 and could not get it to work: I just noticed I screwed up some file names in the plugin repositories. It's fixed now. To get the updates, go to the "Plugins" page in the web interface, click "Check for updates", "Select all", "Apply available updates". It will get updates for all plugins, even those that didn't have the problem. That was just easier for me to do because I just had to fix a script and run it again.

I am using a Warthog throttle and grip with a Virpil Mongoos-T50CM2 base. I had been using the TMWH for a few years and upgraded the base a few months ago. If you want to get the TMWH grip anyway, I think starting with the TMWH base+grip is a good idea. While it is not on the level of Virpil and VKB, the Warthog base is still very precise when it is new (the spring is quite stiff however, so if you want to fly helicopters, get an extension right away). Once the sticktion sets in after a year or three, you will have saved up enough for the Virpil base.

New Release: v0.9.0 Release v0.9.0 changes how the project is organized. The aircraft-specific parts of DCS-BIOS are now tracked as separate projects and installed using the new plugin manager. This will make future updates to the module definitions easier to publish and faster to apply (go to "Plugins", click "Check for updates", click "Select all" and "Apply available updates"). If you are upgrading from 0.8.x, you will have to follow the new setup instructions. * Install the plugins for the aircraft modules you want to use. The "recommended plugins" feature will only work for the A-10C and Harrier at the time of release. Uncheck "only show recommended plugins" and manually select the plugins you need from the list. Then let me know the exact folder name of your aircraft module in the DCS installation folder (e.g. "mods\aircraft\A-10C" so I can add that information to the plugin catalog. * The checkbox for "Virtual Cockpit Connection" will be unchecked and the Export.lua integration will be broken. To fix it, just check "Virtual Cockpit Connection" in the DCS Connection page again. Please post comments and the folder names for your aircraft modules in the DCS-BIOS Discussion Thread.

The video you are referencing was made with the very first DCS-BIOS version in mind, so the code it shows is based on an outdated example sketch. As you already found out, you need to remove the "Serial.begin(500000);" line. You also need to add "DcsBios::setup()" to your setup() function and "DcsBios::loop()" to your loop() function. Refer to the IRQSerial sketch from the current Arduino library to see how it should look.

Anything outside the "cockpit argument" values (which control the animations) and the return values of the list_indication() and list_cockpit_params() functions in DCS is currently outside of the scope of DCS-BIOS and will probably stay out of scope for a long time. You will need to write a separate program that monitors your USB throttle. When it wants to trigger a command via DCS-BIOS, that program can open a TCP connection to localhost:7778 and send "MESSAGE ARGUMENT\n", e.g. "GND_SAFE_OVERRIDE 1\n".

The DCS-BIOS Hub is running on the computer that DCS is running on, and as such can only connect to that computer's serial ports. You could grab a Windows build of socat from a 0.7.x release and try this from the command line: mode COM1 BAUD=250000 PARITY=N DATA=8 STOP=1 TO=off DTR=off socat tcp4-connect:dcsComputerIp:7778 /dev/ttyS0 /dev/ttyS0 would be COM1, for COMn use /dev/ttyS(n-1)

The #define for the communication mode (DCSBIOS_DEFAULT_SERIAL etc.) needs to be placed before the "#include <DcsBios.h>" line. If you are on an Arduino board with an ATMega328 or ATMega2560 (Uno, Nano, Pro Mini, many others), use DCSBIOS_IRQ_SERIAL instead, it is much more reliable. DEFAULT_SERIAL mode is for compatibility with "Arduino-compatible" boards and needs a faster CPU to be reliable when your loop() is doing a lot of work. It might make sense if you need to drive a large graphical display and want to use a board with an ARM processor or something. For the vast majority of use cases, it's best to stick with boards that can use DCSBIOS_IRQ_SERIAL mode.