FSFIan

Since DCS-BIOS does not offer any code snippets specific to a certain type of display, there is no display that fits DCS-BIOS better than another one. To use a display with DCS-BIOS, you first have to learn to use the display without DCS-BIOS, i.e. find an Arduino library that can drive the display and understand its example sketch. You will then add the necessary code to initialize your display to your DCS-BIOS sketch and grab a generic "StringBuffer" code snippet from the DCS-BIOS reference documentation. You need to "fill in the blanks" in that code snippet by adding a few lines that take the value provided by DCS-BIOS in the "newValue" function parameter and put it onto your display. The vast majority of display libraries will work with DCS-BIOS, the exception is when the library is so badly written that it blocks interrupts for an extended period of time (we had issues with a library for 7-segment displays once that had very naively written timer code for PWM dimming).

No and no. This is normal. When DCS is not rendering a display, it also stops updating the values that DCS-BIOS exports. A workaround might be to export the cockpit display to a monitor as a 1x1 pixel window somewhere so it is technically always visible. I don't know if that still works, the last time I tried that was with DCS 1.5. No. (v0.8.5 was just released and I don't have a pull request for these changes yet. It will take some time for someone who is interested in the F-16 to add these.) I am working on adding functionality that lets you remap controls between different aircraft. Maybe once that is implemented, we can offer a few "default" remappings. Standardizing the command names works in some cases (e.g. an "ILS" push button on the UFC) but does not solve the problem completely: the left and right MFDs have 20 buttons in all western aircraft I know of, but the numbering differs; OSB 1 is the first one in the top row on the A-10C and the bottom-most one on the left side in the Harrier. Which naming scheme should win? we already have different naming conventions in different module definitions. When standardizing, it would break backward compatibility for at least some of them. A lot of aircraft have a "Battery Switch", but sometimes it has two positions (OFF, ON) and sometimes three (OFF, ON and TEST or RESET or something). To make a long story short, standardizing the command names is not as easy as it sounds and does not completely solve the problem anyway. It will be easier to set up a system where we can add information like "these two switches on these two aircraft have exactly the same meaning" and "here's how you translate from this switch in aircraft A to this switch in aircraft B". PS: It would really really help if you would start separate threads for separate questions. This feels like having four conversations at once and it's really annoying. This thread is fine for short feedback and comments, but anything that requires further discussion should be on its own thread. This thread only exists because if you don't provide one like this, people will just post in the announcement thread, which is meant to be a low-traffic thread to subscribe to if you want to be notified of new releases. I guess I should just stop answering questions in here altogether. Every time I answer one in here I encourage the growth of a 100+ page thread where I can't re-use answers to the same questions because I can't find them again. /rant

New Release: v0.8.5 Re-add the controls that were removed in release v0.8.4 in a way that retains compatibility with v0.7.1-based hardware cockpits and v0.7.30-based DCSFlightpanels configurations F-14B: weapon store gauges are now exported as indicator lights F-16: add UHF and CMDS display outputs F-16: add OBOGS and GPS switches Please post comments in the DCS-BIOS Discussion Thread.

The Virpil bases use independent mechanisms to create the forces for the X and Y axes. I would assume that other competitors in this price range (VKB) do the same. I started with a TM Warthog stick and throttle a few years ago and recently upgraded the base to a Virpil MongoosT-50CM2. I never paid attention to the issue you described, so I just grabbed my TM Warthog base out of storage and did a quick test. On my Virpil base, the force required to move the X axis stays exactly the same no matter where the Y axis is at (as far as I can tell by feel; the increased total force required to hold the stick while deflecting two axes makes it feel like moving the X axis requires slightly more force when Y is deflected). On the TM Warthog, there is a very clear difference in the force required to move the X axis between a neutral and a fully deflected Y axis: moving the X axis requires a lot less force when Y is deflected away from the neutral position. That (in addition to the continuously adjustable spring tension) explains why flying helicopters is that much easier with the Virpil base even though the Warthog base also has very precise sensors.

Hi Heling, versuch es mal mit Version 0.8.4, das sollte funktionieren. Ich hab auch ziemlich lange gesucht, bis ich den Fehler gefunden hatte.

New Release: v0.8.4 fix bingo fuel selector in AV8BNA revert some changes to A-10C and UH-1H profiles to make the output addresses compatible with v0.7.1 again A-10C: remove Canopy Position, TISL ENTER Light, TISL OVER TEMP Light, TISL BITE Light, TISL TRACK Light UH-1H: change radar altimeter display, chaff and flare counts back to a string exports There were some changes to the A-10C and Huey profiles in the DCS Flightpanels fork of DCS-BIOS that changed a bunch of export addresses, which would break existing home cockpit builds. I have reverted these changes for now so simpits that worked with v0.7.1 will also work with v0.8.4+. Please post comments in the DCS-BIOS Discussion Thread.

@Heling: deine Hardware und der Sketch sind vermutlich beide richtig. Der Fehler kommt daher, dass in diesem Commit hier etwas am Anfang der A-10C.lua hinzugefügt wurde, dadurch haben sich alle Adressen danach verschoben: https://github.com/dcs-bios/dcs-bios/commit/e73ad2b9d684d7a2ba609e8cd60eeae91665123b Ich werde die Änderung im nächsten Release wieder rausnehmen, dann sollte das alles wieder stimmen.

Wenn die falschen LEDs angehen und einige schon an sind, wenn das CLP im virtuellen Cockpit noch dunkel ist, dann passen deine Hardware und dein Arduino-Sketch nicht zusammen. Du musst also entweder deine Verdrahtung dem Sketch anpassen oder den Sketch deiner Verdrahtung anpassen. Der MAX7219 hat eine 8x8-Matrix (8 Ziffern mit je 7+1 Segmenten, also 7 Segmente für die Zahl und einen für den Dezimalpunkt), kann also 64 LEDs ansteuern. Das Caution Lights Panel benutzt davon 8x6. Die Leitungen SEG_A und SEG_F werden nicht benutzt. Diese Zeile hier: memset(max7219_rows, 0xff, sizeof(max7219_rows)); schaltet erstmal im setup() alle LEDs ein. Wenn davon welche anbleiben, sobald die Daten fließen (und alle Lampen im Cockpit aus sind), dann hast du LEDs mit SEG_A oder SEG_F verbunden, was in dem Schaltplan nicht vorgesehen ist. Guck dir mal die Variablen cl_row_map und cl_mask_map an, die sind schon so formatiert, dass man da visuell ganz gut sieht, welche LED womit verbunden sein muss. Z.B. sollte die obere linke LED mit "DIG 0" (digit 0) und SEG_DP (decimal point segment) verbunden sein. Wenn dann die Positionen nicht stimmen, kannst du vielleicht ein Muster erkennen (z.B. zwei bestimmte Zeilen vertauscht) und dann den Sketch so anpassen, dass das wieder richtig gedreht wird.

New Release: v0.8.3 FA-18C: fix COMM1 and COMM2 channel preset displays when the first digit is "1" or "2" FA-18C: right-justify UFC scratchpad display Fix control reference communication in Edge browser The automatic setup now detects DCS: World if it was installed via Steam Please post comments in the DCS-BIOS Discussion Thread.

Can you elaborate on what you mean by this? Your description confuses me, and I wrote the damn thing (granted, that was four years ago, so I may have forgotten how some of it works...) Can you post your sketch?

I can't see anything wrong with your code. If you have an excessive delay() in your main loop(), that could cause issues with rotary encoders, but then the message would not be sent in the first place. Try installing the latest version of DCS-BIOS (v0.8.2), that comes with a working interactive control reference documentation out of the box. Go to the ILS_VOL knob on the A-10C, increase the slider value a bit (the volume knob needs larger increments than 3200 to work), and see if the knob turns in your virtual cockpit. I just tried that on my machine and had no issues.

There are two functions in the DCS-BIOS Arduino Library: void sendDcsBiosMessage(msg, arg) bool trySendDcsBiosMessage(msg, arg) The first one will block until the message can be sent (for example, when you are on a RS-485 slave that already has a message in its transmit buffer), the second version will just ignore the message and return false in that case. For example, to put the A-10C into reverse gear, you could use: sendDcsBiosMessage("GND_SAFE_OVERRIDE", "1"); For examples on how to use the second variant, see: https://github.com/dcs-bios/dcs-bios-arduino-library/blob/master/src/internal/Switches.h

The DCS-BIOS Arduino Library does not implement debouncing yet. The typical tactile push buttons usually do not bounce at all. Toggle switches tend to bounce around for a few milliseconds. Usually, if a switch bounces, it does not cause any issues, as it will settle on a position and that position will be sent last to DCS. If the switch bouncing does cause problems, a simple workaround is to add a small delay, e.g. a call to "delay(10);" to your loop() function. This might cause issues if you are using rotary encoders, though. I will eventually get around to add debouncing logic to the Arduino library. When I first wrote it, I tried to save every single byte of memory I could, so I did not want to allocate two bytes per toggle switch to store a debounce timer. I now realize that memory is not that constrained. Can you describe the issues you have in more detail? Are we talking about a bouncing switch (you get multiple state changes within a few milliseconds when you flip it) or something else?

@Fang: I have answered you in the other thread.

Hi Fang, thanks for reporting this. I understand that error messages like these are especially frustrating if the manual suggests that everything should Just Work. Well, the manual is right -- it should work. Unfortunately, while cleaning up the code, I managed to break the error handling logic for the case where two directories inside the DCS profile directory do not exist yet. Please try v0.8.2, that should fix the issue. Thanks to your feedback I also added an explicit mention of the installer's file name to the documentation. The line about manual editing of the Export.lua file is meant for advanced users who may have installed DCS by other means than the official installer (e.g. using the DCS Updater on the command line) so the DCS-BIOS Hub cannot find the installation directory and cannot provide the automatic setup. These users would know what to do with this information. You have picked both a good and a bad time to get started with DCS-BIOS and DCS Flightpanels. Good because I have just been able to restart DCS-BIOS development after I had to take a break for two years (v0.8.0 is a major rewrite and was released a week ago). Bad, because that means that some things may break, but I will try to fix those as fast as I can. The next problem you will run into is that DCS Flightpanels is looking for a bunch of files in C:\Users\Fang3\Saved Games\DCS.openbeta\Scripts\DCS-BIOS\doc\json (that's were DCS-BIOS v7.x placed them) but these files are now located in C:\Program Files\DCS-BIOS\control-reference-json You can change that path in the DCS Flightpanels settings. If that does not work (IIRC someone had problems with Flightpanels not remembering that setting a few days ago), try copying the .json files from C:\Program Files\DCS-BIOS\control-reference-json to C:\Users\Fang3\Saved Games\DCS.openbeta\Scripts\DCS-BIOS\doc\json. Unfortunately, I don't own any of the Saitek hardware so I am not an expert on DCS Flightpanels. The new DCS-BIOS release includes a change that will enable DCS Flightpanels to discover the location of these files automatically once it is updated to do so. Best regards, Ian

New Release: v0.8.2 the PDF download of the documentation on readthedocs.org now shows the correct version number the web interface of the DCS-BIOS Hub should now work on Internet Explorer and Edge browsers the FA-18C Hornet is correctly recognized as an installed module the automatic setup of Lua scripts no longer fails if the "Scripts" and/or "Hooks" directories do not exist in the user profile improved error message when the user profile does not exist at all the installer now saves the install location in the Windows registry at HKLM\Software\DCS-BIOS\DCS-BIOS Hub\Path. Third-party software could use this registry key to locate the control reference JSON files. the installation documentation now explicitly mentions the name of the installer file Please post comments in the DCS-BIOS Discussion Thread.

You only need diodes when using a matrix layout. If each switch is connected to its own pin number, no diodes are required.

The control reference looks at the JSON files in C:\Program Files\DCS-BIOS\control-reference-json\ to know how to interpret the data from DCS. To generate a new AJS37.json, create a folder "DCS-BIOS JSON" in your DCS user profile (%USERPROFILE%\Saved Games\DCS\DCS-BIOS JSON" or "%USERPROFILE%\Saved Games\DCS.openbeta\DCS-BIOS JSON"). If that directory exists, new json files will be placed there when you start a mission. (In v0.7.x, everything lived under %USERPROFILE% so the Lua script in DCS could update the "production" .json files every time, this is no longer possible as the DCS-BIOS Hub is installed under Program Files, where normal users are not allowed to write.)

You can use the "X: SET COMMAND" trigger to trigger command 816. That will enable Active Pause. I don't know much about ME trigger conditions, so I don't know how you would find out when the player enters the cockpit (probably trigger on the unit being activated or something?), but one of the ME experts here can probably help you with that.

That is not possible (it just tells Windows to open an URL, and Windows decides what to do with that). The next release of DCS-BIOS will have a control reference that works in IE11, I just needed to add a polyfill for Array.flatMap.

Yes, point your browser at http://localhost:5010

For cockpit argument numbers, you can use the model viewer to manipulate specific cockpit arguments and see which switch moves. Most argument numbers can be found in clickabledata.lua, you can then use the model viewer to check your results. If all else fails, you can play around with the custom animation feature in the Model Viewer to find any argument value relatively quickly. Maybe I'll do a video on that. For indications and cockpit parameters, try the "return list_cockpit_params()" and "return list_indication(n)" in the Lua Console of the new DCS-BIOS release: https://dcs-bios.readthedocs.io/en/v0.8.1/lua-console.html#using-the-lua-console-to-help-with-mission-building

v0.8.1 is out: https://github.com/dcs-bios/dcs-bios/releases/tag/v0.8.1%2B29 It includes the last missing changes from the DCSFlightpanels fork of DCS-BIOS. It also includes the new documentation, which is mostly complete (it could still use more pictures / schematics and a few tutorials, and a new developer guide). To access it, click the "Documentation" link in the web interface of the DCS-BIOS Hub. The documentation is also available online on ReadTheDocs. If you click the version number in the bottom right corner, you can download it in ePub, PDF or HTML formats. Their search function is also a bit more reliable than the one in the offline documentation. I will also use ReadTheDocs as a place to link to from the GitHub Readme and website (which I both still have to update) so new users can read about how to install DCS-BIOS without having to install DCS-BIOS first. Please post comments in the DCS-BIOS Discussion Thread.

Switch to VSTOL master mode (I think NAV also works, A/G does not). Go to MENU > VREST and box STO (short take off) at the top. That will show you the runway length you need with (WET) and without (DRY) using water injection. The LHA has distance markings, the furthest of them shows 750 feet of runway. If you back up a little more you can squeeze out a bit more distance, but within 750 feet you can take off with quite heavy loadouts if you switch your water injection system on (and double-check that your flaps are set to V/STOL, not that I have ever forgotten to do that).

I don't think it's documented anywhere yet, but the Switch2Pos class takes an optional "reverse" argument. Try this: DcsBios::Switch2Pos hydContSw("HYD_CONT_SW", 3, true);