Developing DCS Interfaces
All DCS interfaces are collections of network functions. These are instances of descendants of the DCSFunction class that implement a particular set of { device ID, function ID/argument } pairs and some set of { device ID, command ID, command argument }. There are many existing generic classes that implement normal use cases like "a button implemented by sending and receiving 0 and 1" and so on. You can find many of these classes here:
There are currently 3 types of DCS interfaces in Helios:
In this interface implementation style, all functionality is written in C#, just like the original Helios interface (A-10C) and many other interfaces created before JSON capabilities were added.
All network functions are written in code and instantiated in a C# class that inherits from DCSInterface. Because a specific C# class exists for such an interface, it can optionally have a customized UI by specifying something other than the generic DCSInterfaceEditor as its editor in the HeliosInterfaceAttribute decoration.
In this style, the large function in the interface class that instantiates all the functions is replaced with a load from a JSON file. For an example, see the F/A-18C interface. At the time of this writing, the F/A-18C interface still also contains the C# code, but it isn't used if the JSON file is found. This is a transitional state, as the team had to decided to switch all interfaces over to JSON at the time.
Functions are still written in C# code. The JSON file just instantiates these functions with parameters, just like the code in Style 1 did. In order to support both the legacy code style of C# constructor calls with a bunch of parameters (instead of property initializers) and also make the classes serializable, the code in these functions is written in a very specific and ugly style. Take extreme care to follow the pattern to preserve the dual use as long as there are still Style 1 interfaces in Helios.
A dedicated C# class still exists, so it is still possible to create a custom UI by overriding the interface editor.
However, since all the functions are instantiated from JSON, fixes to the interface can be made in the field by power users and without recompilation. It is also possible to instantiate some functions from code and some from JSON, if not all functions can be represented by JSON. The intention of this functionality was that a Helios profile in a .helios16 archive could contain its own interface definition JSON. This would ensure that the profile is always run with the same exact interface definition against which it was developed and tested.
In order to convert an interface in Style 1 to Style 2, run ProfileEditor.exe with the -g switch and it will write JSON equivalent to the current C# code. Then you can delete the C# code and replace it with a call to LoadFunctionsFromJson. Then you check the JSON into the interfaces repo.
Interface files for Style 2 are hif.json files of type Existing as seen here.
Interfaces can also be created using only JSON. These consist only of a hif.json file of type DCS. On startup, Helios enumerates all such files and creates interfaces from them. Custom export Lua is also loaded from associated hif.lua files, if any.
Functions are still written in C# code. The JSON file just instantiates these functions with parameters, just like the code in Style 1 and Style 2 did.
Because there is no custom C# class, it is not currently possible to provide a customized UI for interfaces of this type. They all use the same class SoftInterface and its associated interface editor.
If, during a transition period, interfaces for the same aircraft exist in JSON form and in native form, they should be named differently. They will be shown in the same list in the "Add Interface..." dialog. Longer term, only the more accurate interface should be retained.
Before the JSON interface functionality existed, there was no way to create an interface for new DCS aircraft without writing C# code and waiting for a Helios release to make it available. Specifically, CaptZeen was always ahead of Helios development, creating profiles for aircraft without any support from Helios coders. To solve this problem, the GenericInterface was added to Helios. This interface has a large bank of network functions of various types, with generic names.
To implement an interface for a new aircraft, an export Lua file is written by hand, sending and receiving all the various codes of the aircraft as these generic arguments. The developer needs to keep a database or spreadsheet to record the mappings of which generic argument represents what aircraft function.
On the profile side, the interface just has generic names. The profile developer then needs the mapping information spreadsheet to tie the interface functions to the correct controls in the profile. This worked fine in the past, since the interface developer was always the profile developer (CaptZeen.)
Sometimes the GenericInterface does not have enough values or the correct types available. In these cases, scripting was used on BOTH sides: in the export script to package things up and on the profile side to unpack things.
The JSON Style 3 interface solves all these shortcomings. In fact, it was created specifically to CaptZeen's requirements and also to the requirements of derammo's DCS-BIOS interface importing work.
Unfortunately, there is a large body of documentation on the web that directs people to develop interfaces in this style. If a contributor would create documentation on how to develop a JSON interface from scratch instead, this would represent a great step forward.
One practical problem with developing JSON interfaces directly, is the inability to add comments to the JSON. Comments are pretty much essential when developing an interface, so unless a fully automated mechanism to parse the DCS Lua files directly into JSON can be created, some additional tooling will be extremely useful for the manual creation of Style 3 interfaces.
One example approach to creating a DCS Interface is here but it definitely does not create the "great step forward" requested above, however it might prove useful to someone.