Today 0.8.8 will be available for download. If you are just interested in the bugfixes and added features scroll down to the bottom.
The biggest changes during this update have been happening under the hood. The settings menu was completely hand-coded. Each range field consisted of the same logic with different headers and names. In the code example below I’ve pasted the code that is needed to display this image.
auto headerRowProp = new QHBoxLayout(); auto propHeader = new QLabel(); propHeader->setText("Propeller range"); headerRowProp->addWidget(propHeader); uiOptions->vlEngineRange->addLayout(headerRowProp); auto minMaxLabels = new QHBoxLayout(); auto minLabel = new QLabel(); minLabel->setText("Min"); auto maxLabel = new QLabel(); maxLabel->setText("Max"); minMaxLabels->addWidget(minLabel); minMaxLabels->addWidget(maxLabel); // uiOptions->vlOptions->addLayout(builder.RangeBuilder(), 1); uiOptions->vlEngineRange->addLayout(minMaxLabels); auto propLineEditRows = new QHBoxLayout(); auto leMaxProp = new QLineEdit(); auto leMinProp = new QLineEdit(); leMinProp->setObjectName("leMinProp"); leMinProp->setText("0"); leMaxProp->setObjectName("leMaxProp"); leMaxProp->setText("1023"); propLineEditRows->addWidget(leMinProp); propLineEditRows->addWidget(leMaxProp); uiOptions->vlEngineRange->addLayout(propLineEditRows);
It are 24 lines of code for 2 fields and a header. If you add up the mixture, engines or flaps things start to add up code-wise and most importantly timewise.
To make it more future proof I refactored the entire range block to be dynamically generated. Instead of having to code up 10 text fields, I’m now able to pass it a list of headers, and the code will generate the min and max inputs plus their naming automatically. The moment I started to add the flaps, I realized this change was necessary to ensure I don’t spend half an hour adding a single input with ranges in the future.
THERE IS A CHANCE YOUR RANGE SETTINGS WILL BE SET TO THE DEFAULTS DUE TO SOME NAMING CHANGES
Inputs, outputs, both
I know I promised to add more features to the hooked boards that can receive in and outputs simultaneously but bear with me. The image below shows the current situation that I’ve started to rebuild.
You can clearly see the three modes (inputs, outputs, both). The inputs are programmed to receive the data, but they pass that data to an input handler that checks against a list of know inputs and sends them to the game. This makes it very modular and enables me to add the same logic to both (inputs + outputs) modes without rewriting code. The outputs, however, handle all their logic internally. They receive the data, handle the data and send the data. What happened is that both modes would be a reiteration of the same code (be it with slightly different timings). In an ideal world, the code would look like this.
The groundwork to implement this is almost done, but it needs some extra finetuning. That is why the inputs have been expanded to facilitate all available inputs in both modes while the outputs have remained the same. This modular approach also makes it very easy to add outputs, inputs, and duo mode Arduino’s without running the same logic handling in the backend.
Inputs in duo mode
All the inputs that are available for the dedicated input mode have been added to the duo mode.
The flaps have received a potentiometer focused function in the library and the connector.
//This function only takes the pin number of the potentiometer and handles the rest itself connector.setPotFlaps(byte flapsPin);
This function will have a min and max range which are settable through the settings of the connector. This can be any number you’d like depending on the range of your potentiometer. (use Serial.println(analogRead(potPin)) to discover your own range). How the simulator handles this logic can differ per plane. If the flaps have set indents or stages, the potentiometer will trigger each stage, but you cannot put them in between indents (unless the plane facilitates this).
Throttles, mixture, props
The throttle, mixture and props have received some extra smoothness. The Arduino will only send differences that are bigger than 1 to ensure that the light jitter gets filtered out. It’s a simple solution for a simple problem but somehow it flew under my radar for far too long.
//functions like these should now reduce the load you are sending out significantly connector.simpleInputHandling(throttlePin);
- Trim being saved as a byte. It now stores it as an int returning the negative values as well (-100 till 100)
- Changing settings could crash the connector (forgot to implement a failsafe) this should be fixed (fingers crossed).
- Mixture reverse range is now recognized (the setting groups weren’t opened / closed properly, It tried to search for the mixture in the engine section etc.)
- Propeller reverse range is now recognized
- Removed snedKhzComStandby1Plus and sendKhzNavStandby1Min (these were deprecated and were supposed to be removed a long time ago)
Still needs some investigating
- For some reason the ADF is being a nosy brat. It sometimes messes with timings and data coming in. Haven’t pinpointed the issue yet.