Interview: DCS A-4E EFM Developer Insight with JNelson

As a follow-up to our review of this spectacular community creation, we got in contact with JNelson to ask him a series of questions about some of the experiences he had while developing the External Flight Model (EFM) for the Skyhawk alongside Farlander.
We hope this interview brings some insight into what goes into making an EFM for DCS, the discoveries that were made along the way that enabled some of the best additions for v2.0 of the Scooter. We'd like to thank JNelson and the entire A-4E dev team for allowing us to have this interview and for their work on this mod. Q: Hello! We really appreciate that you are taking your time to have this interview with us. Could you please start by introducing yourself? A: Hello I’m JNelson, one of the A-4E Community Developers. I wrote the EFM for the A-4E with Farlander. I also have programmed many requested features, a few being the CP-741/A bombing computer, radio, new Tacan and ICLS. Q: How did you get into DCS? Have you done/been a part of any other projects prior to the Skyhawk? A: I’ve been playing DCS since late 2012. I picked up the A-10C on steam for £7 back then and since then I’ve been hooked and now have several thousands of hours flying in DCS. The A-4E was my first DCS related project. Q: What brought you and Farlander to the A-4E project? Did you have any previous experience with coding an EFM or was this your first time? A: Farlander had worked with the team before to produce some 3d assets in the past, so I knew about the project. We both love the A-4E however we both absolutely hate simple flight models and thought the A-4E being SFM was a tremendous waste of potential. So rather than complaining about it we both looked into it. This was the first time for both of us creating an EFM, however I have a degree in Physics and Farlander is studying to be an Engineer, that combined with our experience in DCS and general interest in aerodynamics certainly gave us a foundation to learn the principles we needed for a detailed and realistic EFM. Q: Which was the first step you took to create the EFM? Data gathering or did you start by researching how things work inside of the DCS framework? A: The DCS framework is really quite straightforward. It’s essentially an interface into the DCS physics engine. The first issue was we did not have a good collection of equations to implement a basic flight model. We tried to make a basic example back in October 2019 this worked but was pretty garbage. In May 2020 Farlander found a book called Principles of Flight Simulation by David Allerton. This had everything we needed to get going. The first step after gaining this information was to get a minimal working example which we could expand on. The night Farlander found this book I told him by tomorrow I’ll have a working EFM. All night later I had a very garbage but functioning EFM. There were all kinds of problems with this initial model but it was a base from which to improve. From here we gathered as much NASA data as possible. To replace the placeholder values I had used for the first version. Q: Which parts of the EFM were the hardest to code? (stall characteristics, engine simulation, system simulation, etc). A: Not necessarily the hardest thing to code but the thing we ran into the most problems with were conversions between the wind axis and the body axis. This was compounded when we went to an element based model as alpha and beta had to be calculated for each element. A good set of tests would have prevented a lot of this pain but we were doing this in our spare time and who wants to write tests. Other than that I don’t think anything was particularly difficult to implement, the primary difficulty for most things is getting the first working example to be improved. Q: How hard was it to code the EFM while not having access to the SDK? Are there still things that cannot be added due to not having access to it? A: This is generally a common misconception out in the community. There are very few things (if any) that stop a fully realistic implementation of an EFM. There of course limitations for systems and interactions with the DCS world however something like the A-4E can almost all be accurately simulated with the current interface we have available to us. One thing I would love ED to add would be the ability to write our own hook physics similar to the Tomcat and F/A-18. Q: When it comes to systems the way they interact with the SFM, which ones had to be rewritten in order to make them work with the EFM? Probably the most time consuming thing from my perspective for the early part of the project was integrating the EFM to the existing lua. A lot of the sensors and data no longer existed and had to be replaced with values from the EFM. There are other things which were completely broken and needed complete replacement, a couple of examples would be the AFCS and radio. When these were re-written we took the opportunity to make sure these systems were as close to real life as possible. There were other systems which had to be ripped out for the system to be functional. An example of this was all the carrier work-around script. The work-around had interesting things like an invisible afterburner to get the A-4E to launch off the deck, but this had unforeseen things like the throttle being routed through the carrier script so the player couldn’t engage this afterburner. This all had to be removed and replaced with the official DCS interface for the carrier. Q: One of the most impressive additions to the A-4E that came with the EFM was the addition of functional radios and TACAN/ILS/ICLS navigation. What was the process of developing these like? Any hurdles that you had to get through along the way? A: These changes fall into two categories. The radio and the radio navigation. Radio The process itself is really just a case of browsing the memory for known values and trying to tie that back to things to which you have access. I spent weeks without getting anywhere. Once you have memory addresses of important objects you can then easily call their functions (without getting too technical is not always straightforward since some are virtual). It is easy to see what functions and objects are possible to interact with by looking at the relevant DLL’s. This information is available to anyone who simply dumps these functions. The issue is that the exact makeup of the structures used is not known. This would normally be given in a file (header file) with the SDK which of course we do not have. So this has to be worked out by monitoring the memory. I eventually found a method for reliably getting the position in memory for any lua device using the lua. The final step was figuring out functions which needed to be called to enable the radio. TheRealHarold had already figured this out and shared this information with us. Combining this with my method for getting the positions in memory allowed us to get the radio working reliably. There was only one remaining thing to be sorted which was to get the radio menu to come up during flight and this was just simply calling one of the functions relating to the intercom with the memory address for the intercom. Radio Navigation The primary issue to solve is the position and heading of the beacon you are trying to track. There is no interface for getting this information in DCS. There are avTACAN devices you can try and create however these fail to be initialised so you cannot use the same method as the radio. The avILS device can be reverse engineered in a similar way to the radio, I did get this working however this is of no use because it only works for land based ILS without some unknown and likely time consuming (to reverse engineer) changes. The static land based ILS and TACAN were already covered since we can retrieve the map beacon data. This is how the initial TACAN and ILS were implemented. There was no implementation for the ILS yet so I implemented this. These aren’t too complicated since it’s just basic geometry Video of AA TACAN working. Video source: JNelson. The position and heading of the beacons for moving objects, ships, aircraft and portable tacan units was the big problem to solve. After a long time investigating all kinds of avenues. I found a way (which I won’t go into for security reasons) to essentially get the memory address of an object based on it’s ID in the mission file. This is useful because the vehicles in the mission file have their TACAN and ICLS channels, so I can essentially correlate a mission ID to a real object in game. Once you have that object you just need to find the location of the positional and rotational data which is just some offset from the address of the object. This is easy enough to do by just comparing the values in the memory to the position in game. Since this is essentially a hack we haven’t released the source code for this. Although ED are welcome to get in touch if they want to find out how exactly I did it. Q: The A-4E, as of now, is one of the only if not the only community made mod capable of doing air to air refueling. Which discoveries made this possible? Was it a complex feature to add? A: The DCS API supported this already for any EFM’s the issue was getting in contact with the tanker which required the radios to be reverse engineered. Once that was reverse engineered it worked like a charm. Q: Getting an EFM to behave accordingly is quite the challenge but with the Skyhawk, flight characteristics seem to be on-point according to NATOPS. Did you have any help from a Subject Matter Expert (SME) at any point during the development? Very early carrier tests (Not everything is smooth sailing, but at least you get cool videos)
Video source: JNelson A: We mostly used NASA wind-tunnel data for the EFM. However the transient data was not as accurate so a lot of this was augmented by help from our SME (A-4M pilot). We also had a few excellent testers which found discrepancies for us to fix. This sped up the development and was incredibly helpful. Q: How complex is the code behind the flight dynamics in terms of simulation? Any highlights you would have that you think are cool and worth mentioning? A: As stated before we used NASA wind-tunnel data for the EFM. Farlander spent a long time splitting the wings and surfaces into elements, this provides a more dynamic simulation of the wing. It’s not completely accurate since these elements are completely independent but it provides a good approximation. The other cool thing are the physically realistic slats, modeled physically and deployed based on their aerodynamics. Q: How many hours do you think you have spent coding the EFM as a whole? A: At least more than a thousand hours between Farlander and myself. Q: The A-4E had public tester events that members of the mod’s Discord could request access to. What was some of the most beneficial data learned through these events? A: The primary reason for these events were to pick up difficult to detect bugs. There were some very interesting bugs that were found and fixed as a result of these. Q: Version 2.0 is going to be a big release for the project. Are there any additions that are going to be made after 2.0? How will the mod be supported after the launch? A: The radar has been re-written for v2.1 to greatly improve performance and resolution. Making the radar much more useful for IFR and regular navigation. The JATO is also being modeled and simulated for v2.1 which will make shortfields much more possible and exciting. Early look at v2.1 radar improvements. Notice the radar shadows being cast from the terrain. Video source: JNelson Thank you so much for taking the time to answer these questions. We really appreciate it and we wish that these answers help to clarify any of doubts some of the users might have had about the complexity of the development of an EFM for DCS World. Our review of this community module can be found HERE , check it out! About the Interviewer Santiago "Cubeboy" Cuberos Longtime aviation fanatic with particular preference towards military aviation and its history. Said interests date back to the early 2000's leading into his livelong dive into civil and combat flight simulators. He has been involved in a few communities but only started being active around the mid 2010's. Joined as a Spanish to English translator in 2017, he has been active as a writer and content manager ever since. Twitter | Discord : Cubeboy#9034