It has been a long time since my last post, I took some time out to concentrate on other staff but I kept the plugin in shape.
Lately I was working on a mission for Mission-X, and I waited for X-Plane 12 to come out so I could have a better weather representation (rain, rain drops on windshield, puddles and even snow).
After playing around with the weather settings and doing some VR flying, it is really great to see how Laminar Research are pushing X-Plane as a simulator, and I think in the right direction. I know there are people who are disappointment in some areas but the overall feel is quite good, in my opinion.
From performance perspective, I have decided to upgrade my machine, and it now boasts a NV3080TI which is quite a good card, although not the fastest one out there (the 3090ti was the fastest at the time I purchased it and 4090 was out of the question from pricing point of view).
So how all this relates to Mission-X plugin.
In a nutshell, I had few adjustment to do in the plugin, but overall from compatibility side the plugin worked quite well and since I do not use the new XPSDK functions, it is also backward compatible with X-Plane 11.
So why am I writing this rant ?
As I mentioned earlier, I was working on this mission that should have flown during winter days, so I wanted to have some rain effect and better cloud representation during the flight, one of the settings I found interesting and useful, so I thought, was the "Evolution Over Time" setting, you could set the weather to improve or degrade over time, the real problem is that I had no idea how fast it will degrade or improve.
Naively, I set the weather to slowly degrade at the start of the mission and stopped the degradation (set to static) after 20min. The initial weather was "VFR Scattered" and I aimed to maybe have a "VFR Broken" weather state.
I was wrong.
After less than 15min, the weather setup showed that the current state is "Convective" which surprised me, I mean how the weather could degrade in such a short time and reach this state, it was almost unflyable and problematic to implement that way in the mission.
So here is where I started doing some boring research. I have set X-Plane 12 weather to "clear" and start timing the rate of change while picking at the "weather depiction" in the "weather setup screen".
Here are my results:
-- Clear 17:44
-- VFR Few Clouds 17:52
-- VFR Scattered 18:06
-- Convective 18:16
With that information I raised a feature request to have a better control on the weather rate of change (in LR slack page). After some "Ben" explanation it dawn on me that:
- The weather feature is implemented for LR and with LR needs in mind.
- The weather evolution is meant for "instructor/Pupil" in mind (this is how I see it).
- Programmers will have to manually deal with the "degradation" part and no API will be provided to have some control on the degradation speed.
- The way the weather is implemented can change, depends on Austin's math and decisions, so we should not depend on X-Plane internal evolution math and only rely on ourselves.
The last point made me go back to the drawing board and try to figure out how the hell should I implement the weather interpolation.
Before I'll continue this rant, I would like to share few images of datarefs that are being modified by X-Plane when changing the "Evolution over time" setting from "Static" to something else:
Currently weather transition is every ~60 seconds, so every minute there is a small change in the values you see in these images.
Please take into account that these small values can have bigger effect on the weather, so don't think in terms of: "I'll add 1" to the weather datarefs because "1" is a small number, you have to think in decimal values between 0 and 1.
Even more, almost all weather datarefs are "arrays" so you might need to modify part or all of the array dataref values, and lastly, you don't really have to change all the weather datarefs to get the visual effect you won't, focus only on those that matter.
So now I hope I better clarified the complexity of implementing our own weather "Evolution over time" functionality into the plugin.
The first tool, is the dataref class, we always use it and it works quite well for scalar and array values.
The second tool was the implementation of the "<set_datarefs>" element introduced In v3.304.12, it receives a string of "datarefs" and their values while the plugin parses correctly, so I hope, the "key=value" text into a scalar or array datarefs. In the coming v3.304.13 the "fn_set_datarefs()" function is introduced, so you could modify a set of datarefs with one command.
These tools were the base for the "linear dataref interpolation" implementation.
Fast forward, after two days, I had a working prototype of this feature, and now I could "easily" set a group of dataset in one command, the only drawback is the length of the text of the datarefs, it seems that there is a limit to a character argument that is being passed between the "script" and the plugin, and so I had to modify the "MY-BASIC" source to raise the limit from previous "512" characters" to "4096" characters, should be more than enough (thank goodness it is open source).
How do we use this interpolation implementation
The idea of this implementation is that the "mission designer" will set the "target" values they expect to have for a certain dataref, how much time to wait before making the transition and in how many cycles to do that.
The plugin will then pick the information, parse the "text" and convert it to a "dataref" object (one or more, depends on the implementation), and then will calculate the amount of transition based on the "dataref delta value" divided by the "cycle number", then every "Nth seconds (defined by designer)" the plugin will apply the "delta" value into the dataref.
Here is an example from a scriptlet:
- Do not use this feature for the sake of "this is cool", because even if the simmer will change the "heading" while we are interpolating the numbers, it will be the plugin that will eventually override the user "heading" value until the last cycle will end, only then will the simmer have the option to change the "heading" value to his needs.
- In many cases, integer arrays do not have any use for interpolation, I implemented it for the sake of "what if we will need it", but it was hard to find a logical test for integer arrays.
- Weather settings are more complex to change and even harder to seamlessly implement during flight, please remember that X-Plane 12 picks weather changes every 60 seconds, so there is no point in changing the weather values every 30 seconds, for example, it should be at least every 60 seconds or even more.
Weather values should never have large delta because the visual change in the sim will be apparent to the simmer, and it might break the immersion, but it is up to you.
Make sure that you test the visual transition of your code first before handing it over to others, you don't want to find a major glitch in the settings that will cause visual or system breakdown.
Limitations:
There are few limitations I can think of for this implementation:
- The calculation is only being done during "flight loop back call" and not during "draw calls".
- All changes are linear.
- The timing is in integer values and not fractional values, so timing like "0.5" or "1.5" seconds won't work, they will behave like "1" or "2" seconds.
- Intervals are not precise, meaning, the plugin does not promise to execute the change at the exact requested time. The requested time is a hint for the plugin, but the plugin is dependent on the X-Plane performance as a whole and therefore the interpolation will probably occur nearly at the requested time.
- The plugin always calculates the values with "decimal" precision even for integer datarefs, and because the rate of change is linear, there might be cases that a cycle won't have an apparent change in the dataref value, since it rounds the value to the closest integer number.
Eventually, after the Nth cycle, the integer value should reach the "target" value.
Example:
If the ignition was at state "1" and we want to reach state "3" after "three" cycles, then the delta value won't divided to even numbers but the plugin will still handle this. - Sometime using LR own "deteriorating" logic, might make some sense, if you time it correctly, instead of using the interpolation functionality.
So use the "change_mode" dataref at your own discretion but make sure to reset it to "static" in a timely manner.
Hope that you got some sense of the coming features that were implemented in the coming build, and I really hope you could benefit from it.
Until the next time
Blue Skies
Sa'ar