CodeToad

SkateZilla: SOLVED thank you Turns out VR mode was turned on but I wasnt using the Oculus Rift (which itself still needs some debugging) I must have had VR mode turned on in DCS previously. My bad ! Thank you and hopefully that solves Aegers issue too !

Hey all - thanks for your ideas ! Unfortunately the log file (also attached to this post) was not much use, seems pretty ok - except one line: UIBASERENDERER: Cannot load font [C:\Program Files\Eagle Dynamics\DCS World\dxgui\skins\fonts\]! That directory exists, and fonts are in there and they are readable as far as I can tell. Not sure that alone would keep the screen black... I did notice that Aeger in his post describing the same problem has the same font error - can someone check whether their successful boot log has this error also ? If not, perhaps thats the place to dig deeper next... Second, I ran the repair and no weirdness reported. Current versions: installed version 2.5.5.41371.1 DCS updater 2.9.16.18 I have no mods running (also told repair it could remove any if it found any). Tacview 1.8.2 is installed though. Log file says it successfully loaded the Tacview files. GPU is a NVidia GTX 1080Ti driver 445.87 (4/15/2020) Like Aeger said in his post, Task Manager reports low CPU/GPU/Memory once DCS is loaded and displaying black, suggesting maybe it is just in the main menu, not unsuccessfully trying to do any heavy lifting. snap attached dcs.log.txt

Asking for advice: after updating my DCS (after a longish break) to 2 9 16 18 updater 2.5.5 dcs on windows 10, latest NVidia drivers everything *else* seems to work fine, ie windows, other apps etc. but on starting DCS, I get the logo screen to pop up and after that it is just a black screen, not the typical main app screen w the modules list below etc. No network or disk or CPU activity out of the ordinary, DCS is just "sitting there" in the dark. I have restarted, renamed my "Saved Games" folder to see whether some incompatible preferences / configs caused this, but nothing seems to help. Can anybody suggest how I debug this further (short of a complete reinstall which given how many modules I have may take a week of downloading....) Thanks in advance !

Just donated as well. Good project - thank you Andre !

See this thread on the Gametrix KW-908 Jetseat from Russia. It has 8 vibro motors (4 for each side left/right located 4 on your seat and 4 on your back) controlled by USB controller (ie allowing digital control rather than just analog audio) A russian guy named Andre makes software for it that drives it digitally from DCS telemetry (using Export.lua) called ibaEffects. There is also software called SimShaker from the same website. Not sure what the difference is. I asked Andre about using his digital output (and custom vibration patterns) drive a ButtKicker instead of a Gametrix seat. You can see his answer here (Spoiler it is "Yes, but") Here is what SimShaker can do with DCS: Andre points out that the $175 Gametrix seat can provide neighbor friendly QUIET haptic feedback to your body (vs the ground shaking Buttkicker) And in multiple places on your body no less :)

Hello Andre - question: looks like you have already done the hard work of exporting the necessary event data from DCS to trigger the right sound/vibration effects at the right time. And you have the vibration data files. Any chance you could emit those to a single channel of a sound card so we could connect that to a Buttkicker ? Kind of like what SimVibe does for many car racing sims and Xplane ? Outside Russia, these Buttkickers are likely easier to get than the Gametrix Jetseat (I never even got a response to my email enquiry to the company, so I bought a buttkicker instead.) Based on for racing games, having the transducer driven by specific events - from game metadata like Export.lua - is much better than just using game sound to drive it.

rocketeer: Indeed "Mega" usually means "Mega 2560 R3" at least for now (Sparkfun - link below - also has some other Mega variants) The Mega has 54 digital I/O pins (15 of which can be used for PWM) and 16 analog pins. You may find this chart useful for more comparisons between different Arduino boards #digital, analog ,PWM pins: http://arduino.cc/en/Products.Compare https://learn.sparkfun.com/tutorials/arduino-comparison-guide The next best (#pins wise) is the Arduino Leonardo (or Yun, or Micro) with 20 pins Most of the other ones (Uno, Pro Mini) have 14 or fewer

I am just working on a radio panel (pretty ghetto compared to other panelists) and I'm happy to share my arduino code, although it is work in progress (but perhaps you find it useful for your experiments already) I have it working with adafruit rotary encoders so far (24 step per rotation + push button) but I am also getting sparkfun encoders which have an RGB LED lit shaft/button. The basic hookup and rotation detection is fairly trivial. For the adafruit encoder: Connect the center pin on the rotary side and one of the pins on the pushbutton side to ground. The rotary side left and right pins are called A and B in the code below. The other pushbutton pin is called push. You can connect these directly to 3 digital pins on the Arduino. No need for pull up resistors since we use internal pullups (see lines with INPUT_PULLUP) This does mean the logic is inverted ie push button pressed == LOW Anyway heres the Arduino code (for brevity this is generic rotary encoder sample not DCSBIOS specific yet but that will be easy extension given DCSBIOS clean design) int value = 120; // init to whatever const int pin_A = 2; const int pin_B = 3; const int push = 4; unsigned char encoder_A; unsigned char encoder_B; unsigned char encoder_A_prev = 0; // http://www.hobbytronics.co.uk/arduino-tutorial6-rotary-encoder void setup() { pinMode(pin_A, INPUT_PULLUP); pinMode(pin_B, INPUT_PULLUP); pinMode(push, INPUT_PULLUP); Serial.begin( 115000 ); } void loop() { encoder_A = digitalRead(pin_A); // Read encoder pins encoder_B = digitalRead(pin_B); if ((!encoder_A) && (encoder_A_prev)) // A has gone from high to low { value += encoder_B ? 1 : -1; // see diagram on linked page: B hi=red=clockwise, B lo=blue=ccw Serial.println( value ); } encoder_A_prev = encoder_A; // Store value of A for next time // push button on encoder resets (optional obviously) if ( digitalRead(push) == LOW ) value = 0; } I have not personally needed debouncing capacitors between pin_A and ground and pin_B and ground respectively, but if you see a lot of "noise" while turning the knob, put a .1 uF (104 package) capacitor each there. For my actual panel, I will get a little more advanced and use the RGB LEDs for feedback. I will try to get 3 rotaries (UHF, VHF FM, VHF AM) and one 16x2 or 20x4 LCD display . Just so all the analog tuning stuff in DCS can be done with physical twiddles instead of the somewhat tedious rotation mode onscreen. I am also implementing a "push for menu" capability where menu selection might be something like - Frequency - Volume - Preset - Mode with each having an integer, float or set of strings to choose from. While selecting the menu, the LED will light up in some color for feedback. You select a menu item by rotating the knob. With a push of the knob you pick the currently selected menu item and can change the value. Functionally similar to but much simpler code. I am also implementing "turn acceleration" for large range, high precision variables like frequencies. Whereas in a real A-10 cockpit for example you might have multiple dials, for the various digits of a frequency, I want a single rotary encoder for each radio. Slow turns will be high precision. Fast turns will move in much larger increments, allowing zipping from 80.0 Mhz to 103.5 Mhz for example while maintaining precision of 0.1 Mhz with slow turns. (Otherwise each turn would only yield 24 * 0.1 = 2.4 Mhz and that would get old fast) That code I am still cleaning up and documenting (and wrapping into a object oriented library so you dont have to see the guts and can use multiple rotaries from a single arduino sketch) I will post it here, probably next week as I am traveling this week/end. References just in case you want different approaches (I ended up not needing Arduino interrupts or bounce delays etc. and I like to keep code as short as possible, but your mileage may vary): http://www.hobbytronics.co.uk/arduino-tutorial6-rotary-encoder http://dev.tetrastyle.net/2012/08/blog-post.html https://github.com/medecau/QuadEncoder PS: the sparkfun encoder has 5 pins on the RGB LED side (R,G,B, pushbutton, ground) and these are NOT the standard 0.1" separation but around 0.08", so they will not plug into a breadboard or protoboard nor will female jumpers connect (too tight). Grrr. Sparkfun sells a breakout board, but it is so big, that it makes breadboarding hard (see comments section on their product page) Still the LED is nice for signalling and price is good.

If you do not know Spintires: it is a physics simulation/tech demo/game (available on Steam) of heavy vehicle tires interacting with the mud/water/soil underneath (soil deforms, leaves tracks, mud flies around etc.). It is really well done and kind of unique. So particularly interesting for off road/cross country terrain one would encounter with CA vehicles, Shilkas, tanks etc. For some spintires demo videos, check out ChristineItr's youtube channel. Warthunder will include some of these effects as well (see (In Development) Enhanced vehicle to surface interaction) for ground combat. Not sure whether this is at all SpinTire related or whether the physics engine is now licensable ? Wouldn't this be awesome for Combined Arms, 2018 edition ? You kind of have to see it in action, but all the tracks, grass, mud deformations below are created dynamically while driving: there are lots more examples via Google

I would suggest you look at Touchscreens Gadroc's Helios (if you want to make touchscreen UI's) now open source ! of his very popular A10 Helios Profile Lately, Capt Zeen has been making some very nice Helios profiles for F15, Su25, Ka50. Helios Lives ! Panels for cockpits and if you want to hook up physical hardware (buttons, rotary switches etc with Arduinos), may I recommend the excellent DCS BIOS from [FSF]Ian. It is well written, well documented and well supported. Generic UI variable export Both of these work by shoveling data out of DCS World (into files, other processes, your local network etc.) while it is running through an Export.lua script. The basic process is described here but you can find plenty more documentation by googling around and reading forum posts.

Don't see why not - as long as you have the code to drive the display from the Arduino. Here are a couple of potentially useful Arduino libraries to drive character displays: LiquidCrystal I have used this one, for the displays that commonly use the HD44780 chipset LCDi2c for serial i2c displays If you are new to character displays, you may find this general tutorial from Adafruit NYC about hooking them up to Arduinos useful. Beyond that, connecting up to DCS BIOS is trivially easy thanks to Ian and you will find instructions for that both in his documentation and in this thread.

Felm - any chance you are running into the same issue I did (USB overwhelmed, reduce speed, captain !) see http://forums.eagle.ru/showpost.php?p=2294113&postcount=101 how to set back baudrate to 115K or 250K (which still worked for me, but 500K which is the default in DCSBIOS did not)

Naîve question: could the slew switch operation be improved with "just" a better (longer offset) 3D printed switch cover/hat or does the actual switch itself really have to be replaced ? (Analogously to: the TM Joystick operation can be improved for some by adding in an extender)

@Ian: Thank you, problem solved, indeed it was baud rate related. Everything working to spec now. For the benefit of anyone not reading the whole thread: IF you use the DCS-BIOS library unmodified AND you are seeing weird characters, irregular update rates etc. in Arduino app AND shows the correct live data THEN reduce your baudrate from 500000 to 115000 in: 1. the Arduino setup() code: Serial.begin(115000); and in the 2. connect-serial-port.cmd script: ...mode COM%COMPORT% BAUD=115000 PARITY=N DATA=8 STOP=1 TO=off DTR=on... I love it. Thank you Ian ! Your library really makes building cockpit panels very straightforward (once I got the bug squashed :) Next, I will research how to get the stream of data into a mobile browser (Android, iOS, likely Chrome) so I can show a plane icon and some telematics on an iPad/Nexus kneepad app. Maybe websockets... Oh sigh, no UDP support :( And WebRTC with a raw data channel & UDP might work, but support still pretty sketchy on mobile. Maybe I need to write something like Ian's node server (which would update/keep current state data on the PC and allow http access to it, polled from a web page's js) Also looking forward to the extra information which might be exposed by DCS-BIOS in the future.

@Ian: Tried using your suggestion to only update LCD when MetadataEnd (0xfffe) gets encountered. Did not fix the problem. Still seeing junk bytes, strings too short (like empty HH/MM/SS), very rare updates (possibly due to corrupted stream => missing MetadataEnd packets) and likewise TACAN test light on wrong (which is independent of LCD mechanics, pointing to a software rather than hw updating issue) Code pasted below. Tricky to debug because I can't use Serial.print because the serial port is obviously being used by the socat cmd. Is there a way to "debug dump" what is being sent over the serial port by socat ? Additional info: I verified again that your chrome extension with live data display shows the data coming from your DCS BIOS export correctly, so the issue is likely downstream of that. Curiously I noticed that when I put the A10 into autopilot flying straight, things start looking better on the LCD soon after: updates happen more frequently and the text looks more correct ! Could it be that if I fly manually that causes more cockpit display data changes and thus more required updates and that may flood socat or my serial interface ? This is reversible: if I go out of autopilot, I once again get more garbage chars, fewer updates. ---------- Second, following up on your suggestion that the LCD might be overwhelmed w too many updates, I also looked into that a little bit, and to save others this particular trip down debugging lane: My LCD display, a 20x4 liner (http://www.adafruit.com/products/198) is based on the HD44780 chip which is also used by many other character displays. They all have similar pinouts: VSS, VDD, V0, RS, RW, E, D0, D1, D2, D3, D4, D5, D6, D7, LED+, LED- General info and hookup instructions can be found here. The tutorials all show a wire & pin conserving 4-data wire hookup of the display, rather than all 8. Quoting from that page: There is also a way to talk to the LCD using only 4 data pins instead of 8. This saves us 4 pins! Why would you ever want to use 8 when you could use 4? We're not 100% sure but we think that in some cases its faster to use 8 - it takes twice as long to use 4 - and that speed is important. For us, the speed isn't so important so we'll save some pins! I did try hooking up all 8 data lines (since we are testing whether LCD speed might be a culprit) and used the full 8 dataline constructor for the LCDLibrary LiquidCrystal(rs, enable, d0, d1, d2, d3, d4, d5, d6, d7) That however did not work at all (nothing shows up on the LCD) So I assume there is a bug in the library and left that experiment alone. Just FYI. ------------- As per Ian's suggestion, modified Arduino code that collects telemetry as usual but only updates the LCD when a MetadataEnd packet (0xfffe) is encountered (which by design should be about every 30ms). See onDcsBiosWrite() and updateLCDDIsplay() below. #include <DcsBios.h> #include <Servo.h> #include <LiquidCrystal.h> #define TACAN_TEST_BUTTON 2 #define TACAN_TEST_LED 3 LiquidCrystal lcd(7, 8, 9, 10,11,12); unsigned int altMslFtValue; unsigned int hdgDegValue; // ------------------------------------------------------------------------------ DcsBios::LED tacanTest(0x10da, 0x0400, TACAN_TEST_LED); DcsBios::Switch2Pos tacanTestBtn("TACAN_TEST_BTN", TACAN_TEST_BUTTON); void onCmscTxtMwsChange(char* newValue) {} DcsBios::StringBuffer<8> cmscTxtMwsBuffer(0x12b0, onCmscTxtMwsChange); void onAcftNameChange(char* newValue) {} DcsBios::StringBuffer<16> AcftNameBuffer( 0x0000, onAcftNameChange); void onClockHhChange(char* newValue) {} DcsBios::StringBuffer<2> clockHhBuffer(0x10fe, onClockHhChange); void onClockMmChange(char* newValue) {} DcsBios::StringBuffer<2> clockMmBuffer(0x1100, onClockMmChange); void onClockSsChange(char* newValue) {} DcsBios::StringBuffer<2> clockSsBuffer(0x1102, onClockSsChange); void onClockEtcChange(char* newValue) {} DcsBios::StringBuffer<3> clockEtcBuffer(0x1104, onClockEtcChange); // ------------------------------------------------------------------------------ DcsBios:: ProtocolParser parser; void setup() { Serial.begin(500000); lcd.begin(20,4); lcd.clear(); } void loop() { while (Serial.available()) { parser.processChar(Serial.read()); } DcsBios:: PollingInput::pollInputs(); } void sendDcsBiosMessage(const char* msg, const char* arg) { Serial.write(msg); Serial.write(' '); Serial.write(arg); Serial.write('\n'); } void onDcsBiosWrite(unsigned int address, unsigned int value) { // show heading and altitude on line 3 of LCD if (address == 0x040a ) { hdgDegValue = (value & 0x01ff) >> 0; } if (address == 0x0408 ) { altMslFtValue = (value & 0xffff) >> 0; } if (address == 0xfffe ) { // end of DCS BIOS update marker (~every 30ms) updateLCDDisplay(); } } void updateLCDDisplay() { lcd.setCursor(0,0); lcd.print( cmscTxtMwsBuffer.buffer ); lcd.setCursor(0,1); lcd.print( String(AcftNameBuffer.buffer) + " " ); // assemble clock string here so we dont hammer LCD more than necessary String c = String(clockHhBuffer.buffer) + ":" + String(clockMmBuffer.buffer) + ":" + String(clockSsBuffer.buffer) + " " + String( clockEtcBuffer.buffer ); lcd.setCursor(0,2); lcd.print©; String s(hdgDegValue); lcd.setCursor(0,3); lcd.print( "Hdg:" + s + " " ); String s2(altMslFtValue); lcd.setCursor(10,3); lcd.print( "Alt:" + s2 + " " ); }

@Felm: http://dcs-bios.a10c.de/docs/v0.2.2/control-reference.html select CommonData, Advanced View Altitude MSL (ft) => 0x0408 Heading (degrees) => 0x040a

Quick update: I pulled the latest master ( 2e316564b8 ) from github (with your _ACFT_NAME fix.) Aircraft name now works, but I am almost never getting updates for other parameters like clock HH, MM, SS, ETC. (in the order of minutes, at first I got none and thought they would never update) Strange because the code is the same for aircraft name, and the other stuff (as per templates) My LCD is a 20x4. (I use underscores in this post for empty spaces so vBulletin doesnt mangle) Intended: [CSMC Text___________] eg ACTIVE/NONE [A/C NAME___________] eg A-10C/NONE [HH_MM_SS_ETC______] eg 11 25 34 ETC [Hdg:295___Alt:9326___] instead, when I start the connect-serial-port.cmd (DCS is already running) I get [____________________] missing ? [A-10C_______________] works ! [____________________] missing ? [Hdg:295___Alt:9326___] works ! Heading and Alt are updated correctly and frequently (they are done in the onDcsBiosWrite() call back not using the StringBuffer snippets) Aircraft name is correct also. But what is weird - where is my CMSC text and my clock ? It stays like that for quite a while (>1 min I estimate) and after a while longer I have stuff like this (Not always the same, U's seem to come up often, but other chars appear also, so this is just an example): [AC_________________] note missing "TIVE" [A-10C&UUUU________] what are those chars behind the name ? [16_00_UU___U_______] randomly other chars instead of numerals [Hdg:295___Alt:9326__] these keep working fine The Stringbuffer based methods seem to be called back far too infrequently and sometimes contain garbage characters (U's, umlaut, and graphic symbols on my LCD) I also still saw the OFTIVE issue (ACTIVE overwritten by first two chars of OFF). Likewise vice versa ACF (ACtive + ofF) There is something about "2 character updates" vs the whole buffer it seems in the StringBuffers When I throw my countermeasures panel switch (to force a ACTIVE/OFF toggle, it takes at least 5 seconds (sometimes way longer) to get the callback to trigger updating the LCD. (Is it missing packets in between ? Is the stream corrupted ?) Occasionally I also see my TACAN test LED go on when I am not touching anything in the cockpit, further making me suspicious that garbage data is coming across or the parser got confused. I tested my LCD's display hardware with constant strings in a separate sketch and found it to be functional, so I dont think wiring or pixel problems are an issue, it is something in the updates/callbacks or parsing? Just in case it helps illuminate things, I attach a section of the socat dump - at the end the plane crashes and the name of the aircraft should change to "NONE". On my LCD I have NONECU ( = NONE + leftover C from A-10C + stray U) If I can provide any additional information / do other tests, I am happy to. #include <DcsBios.h> #include <Servo.h> #include <LiquidCrystal.h> #define TACAN_TEST_BUTTON 2 #define TACAN_TEST_LED 3 LiquidCrystal lcd(7, 8, 9, 10,11,12); // ------------------------------------------------------------------------------ DcsBios::LED tacanTest(0x10da, 0x0400, TACAN_TEST_LED); DcsBios::Switch2Pos tacanTestBtn("TACAN_TEST_BTN", TACAN_TEST_BUTTON); // CMSC Status on line 0 (ACTIVE/OFF) void onCmscTxtMwsChange(char* newValue) { lcd.setCursor(0,0); lcd.print( newValue ); } DcsBios::StringBuffer<8> cmscTxtMwsBuffer(0x12b0, onCmscTxtMwsChange); // aircraft name on line 1 (A10C/NONE) void onAcftNameChange(char* newValue) { lcd.setCursor(0,1); lcd.print( newValue ); } DcsBios::StringBuffer<16> AcftNameBuffer( 0x0000, onAcftNameChange); // clock on line 2 (HH MM SS ETC) void onClockHhChange(char* newValue) { lcd.setCursor(0,2); lcd.print( newValue ); } DcsBios::StringBuffer<2> clockHhBuffer(0x10fe, onClockHhChange); void onClockMmChange(char* newValue) { lcd.setCursor(3,2); lcd.print( newValue ); } DcsBios::StringBuffer<2> clockMmBuffer(0x1100, onClockMmChange); void onClockSsChange(char* newValue) { lcd.setCursor(6,2); lcd.print( newValue ); } DcsBios::StringBuffer<2> clockSsBuffer(0x1102, onClockSsChange); void onClockEtcChange(char* newValue) { lcd.setCursor(9,2); lcd.print( newValue ); } DcsBios::StringBuffer<3> clockEtcBuffer(0x1104, onClockEtcChange); // ------------------------------------------------------------------------------ DcsBios:: ProtocolParser parser; void setup() { Serial.begin(500000); lcd.begin(20,4); lcd.clear(); } void loop() { while (Serial.available()) { parser.processChar(Serial.read()); } DcsBios:: PollingInput::pollInputs(); } void sendDcsBiosMessage(const char* msg, const char* arg) { Serial.write(msg); Serial.write(' '); Serial.write(arg); Serial.write('\n'); } void onDcsBiosWrite(unsigned int address, unsigned int value) { // show heading and altitude on line 3 of LCD if (address == 0x040a) { unsigned int hdgDegValue = (value & 0x01ff) >> 0; String s(hdgDegValue); lcd.setCursor(0,3); lcd.print( "Hdg:" + s + " " ); } if (address == 0x0408 ) { unsigned int altMslFtValue = (value & 0xffff) >> 0; String s2(altMslFtValue); lcd.setCursor(10,3); lcd.print( "Alt:" + s2 + " " ); } } dump.zip

Wow, I hooked up an Arduino and followed your DCS-BIOS video example, and had stuff flowing onto my lcd display first time (same with a TACAN test button and LED) Also tried your very handy live preview extension for Chrome and again, success. Gotta love German engineering - very good code, documentation and videos ! A few issues: 1. MetaDataStart/Aircraft name documentation is missing a hex constant: void onAcftNameChange(char* newValue) { /* your code here */ } DcsBios::StringBuffer<16> AcftNameBuffer( RIGHT HERE, onAcftNameChange); 2. Commondata heading, lat, long etc. do not follow the common pattern of declaring a event handler function and a buffer. Instead these have an if statement. How to incorporate that into the Arduino code ? In the main loop ? EDIT: reminded myself to RTFM and i think the answer is: void onDcsBiosWrite(unsigned int address, unsigned int value) { if (address == 0x040a) { unsigned int hdgDegValue = (value & 0x01ff) >> 0; String s = hdgDegValue + " "; lcd.setCursor(0,3); lcd.print( s ); } } 3. Servos are my next experiment and I will try Commondata::Altitude MSL I see you have conveniently shown how to do that in the docs: DcsBios::ServoOutput altMslFt(0x0408, PIN, 544, 2400); If I wanted instead to catch the altitude integer for display on my LCD is this what I should do: void onDcsBiosWrite(unsigned int address, unsigned int value) { if (address == 0x0408 ) { unsigned int altMslFtValue = (value & 0xffff) >> 0; /* your code here */ } } 4. your chrome extension shows string values (like CSMC text, digital clock digits) coming through just fine. On my LCD I see hiccups like frequent umlauts or other strange characters instead of digital clock numerals. Sometimes strings seem to be null terminated early (for example, if CSMC switches from ACTIVE to OFF I may see "OFTIVE" in the lcd meaning only the first two chars changed. Could my serial port hardware be screwing up for the arduino (I haven't changed the Serial.begin(500000); in the arduino code or the serial port settings in your connect-serial-port.cmd) ? I should probably test on another USB socket perhaps there is too much other traffic on that particular USB controller and bits get dropped/corrupted ?...gotta find an empty one on my rig...not easy :) My computer is not sweating: DCS is at 100 fps. Perhaps the updates are coming TOO FAST ? I attach the Arduino code for reference although it is vanilla, following your examples. arduinoCockpit.zip

Ian - thanks for the detailed reply. I am just starting to scratch the surface, so I did not know about DCS-BIOS yet. Wow, you are a prolific coder ! It looks very useful indeed. As you mentioned the CommonData section of DCS-BIOS (Alt/Heading/Position) will likely answer my first point. Let me read up a bit more and experiment with DCS-BIOS then I can be a more informed Gesprächspartner on TeamSpeak :) !

Ian: great stuff, thank you. Installation worked flawlessly based on your instructions. I know nothing of Lua as yet nor of the mysterious world of objects and functions that DCS exports (but Witchcraft has definitely whetted my appetite!) In your tutorial video, you show an object dumping method from the Lua Wiki. I wonder whether building that right into the Witchcraft Lua console could be quite useful: For example, you could have a (witchcraft) function wdir() which not only dumps back out text to the console, but could include inline buttons for subobjects/array elements/functions, which when pressed would dump sub-objects (perhaps in a new snippet or "in place"). I don't know whether Lua provides you back enough introspection meta information to tell whether a given symbol is a function, an object, an array etc. since obviously the output would be formatted differently for each. That would allow exported object exploration even for people with zero Lua experience. One could just start with return wdir(_G) and drill down as desired ----- My personal interest is to see whether I could export some things at runtime to a kneeboard app running in a browser on an iPad while the mission is proceeding. (Via your witchcraft nodejs server naturally, but with a custom polling javascript client) For example: - player aircraft location (lat/lon/alt/hdg/speed) - mission briefing text/images (ha!) - any scripted mission prompts as they come up - any kills, or other DCS notifications ("Player X landed at Anapa" etc.) I have no idea whether the mission runtime allows this type of info to be sucked out at runtime. Do you ? But if it does, this should be technically feasible and I'd give it a go. In any case, intriguing work, thank you !

Just noticed this in the Dora (while stopping over to rearm / refuel, need to power down, and open canopy) used the RWin-End stop procedure cheat / shortcut which does: flaps to landing throttle to stop ignition/magnetos off fuel valve close cage artificial horizon canopy open I noticed it keeps various circuit breakers in the main and auxiliary panel on (I would have expected them all off to return the aircraft to "cold" state but perhaps thats open to interpretation). Oxygen valve also stays on FYI. The exceptions to the breakers staying on are the generator and battery breakers in the main panel which are off after the stop procedure finishes (although this is not called out in the text prompts) Now, neither a manual nor a "start procedure" startup will work: the generator breaker can be pressed, but when you try to press the battery ("Sammler") breaker, you get: a brief cockpit lights flash the generator breaker trips off a "pfffhhh" sound rather than the typical breaker on sound and the battery breaker stays off. Without that, your plane cannot be started again, so basically you now have inherited a doorstop. Whats up with that ;) I have tried manually shutting down systems, and that seems to work: i.e. I am able to start up again after that. So it appears this is some problem specific to the "Stop procedure" Random fact: the red button fwd right of the ignition/magneto switch, labeled "Netz Notschalter" (emergency electrical cutoff), when pressed, will trip the generator and battery breakers to off just like the result of the above procedure (it is reversible however)

Thank you both, helpful replies !

After having gotten VERY frustrated w the Dora take off (half a Luftwaffe arsenal destroyed on Batumi myself) I am trying to get a training mission together with some planes "ready for takeoff" so I do not have to taxi every time - it gets very frustrating. I use Multiplayer but on my own so I can burn one plane up and have the next one ready to go without having to go through the rather funny but pointless SP reload every time. I am setting several Doras up with "Takeoff from runway" but they all start from from the ramp hot. What could I be doing wrong ?

Thought this might be interesting information to DCS fans. Questions of F35 purpose, cost and readyness aside, there is a boatload of interesting cockpit tech in there. Among that is the , 6 HD, fast infrared cameras mounted around and under the plane whose imagery gets panorama stitched in real time to create a full 360 degree IR view. This can be projected into the pilots helmet mounted display (immersively, ie. virtual reality rather than augmented reality) and cued with pilot head movements. The pilot can thus literally "look through the floor and behind the wings etc. of the plane. Useful for threat localization and seeing the ground while landing the VTOL versions of the plane. Other things happening in the helmet are spatially registered target & friendly cues (like augmented reality) acquired from optical, infrared and radar sensors as well as incoming "SPI"s. Of course these systems all track multiple targets nowadays. The pilot can also target weapons by "looking at the target" rather than just joystick designating. This includes cueing of high off-boresight sensors and weapons (eg look back over shoulder, below you etc.) Of course the F35 still has a "real" cockpit in addition to all the HUD user interface in the helmet. Not clear to me whether the helmet functions in only fully opaque (virtual reality), semi-opaque (augmented reality / traditional helmet-HUD) and/or fully transparent modes. In addition, there are several issues around display latency, resolution, head and eye tracking, motion sickness due to miscueing etc. that we are probably all somewhat familiar with from the intense development efforts and publications around the Oculus Rift and related tech (slides on Rift DK2 latency mitigation, Oculus Blog entry on VR sickness). Certainly the military has large budgets (even larger than Facebook ;) for this, but these are hard technical problems. Anybody have thoughts / insights as to how "solved" these issues are for a live & death platform like a military jet ? Beyond the obligatory rara advertising videos by the vendors (which look a but simplistic, but perhaps we are spoiled from DCS videos !) there is a lot of fascinating technical information in the links below. Overall Systems & Sensors The F-35′s X-Ray Vision Is The Future Of Naval (And All Other) Warfare F-35's Pilots Get Iron Man Targeting Upgrade Lockheed Martin F-35 Lightning II stealth fighter cockpit demonstrator hands-on Helmet Mounted Display F-35 Helmet Display System To Scare the Bejeezus Out of Enemies F-35 VSI non-HUD HMD Videos F-35 glass cockpit - How to fly and drop bombs (F35 cockpit demonstrator video) More F35 Helmet Images More F35 cockpit images

These might also be useful in your context (from Adafruit NYC): SMALL 1.2" 8X8 BI-COLOR (RED/GREEN) SQUARE LED MATRIX $7.95 ADAFRUIT MINI 8X8 LED MATRIX W/I2C BACKPACK - RED $9.95 ADAFRUIT BICOLOR LED SQUARE PIXEL MATRIX WITH I2C BACKPACK $15.95 MINIATURE ULTRA-BRIGHT 8X8 WHITE LED MATRIX $7.50 MEDIUM 32X32 RGB LED MATRIX PANEL $39.95 Lots of color options, and tutorials on how to use on the site also.