Hello @omarsmak,
I give a little bit of context / background information, such that also other readers understand the basics, how a “flight recorder” works. Just enough that even if you are not a developer you get the gist out of it, and not too much in order not to bore you to death (in case you are a developer) 
Sky Dolly and other replay apps / 3rd party tools communicate with FS2020 via SimConnect, a standardised “application programming interface” (API) introduced with FSX. That API let’s you read and in most cases also “write” (set) so-called “simulation variables” (there exist also “events”, but for simplicity’s sake I’ll ignore them for now - they have been declared “legacy” anyway).
So what are “simulation variables” again? Basically the state of the aircraft: the position and velocity of the aircraft itself, its instrument / lever / knobs settings (flaps position, yoke, throttle, RPM settings, …) which control the aircraft, but also simulated values such as engine temperature and oil pressure etc.
In order to access (“get the values”) those simulation variables the 3rd party application first needs to “register” the exact set of variables that it is interested in, including the desired unit (e.g. “feet / sec”) and update frequency. The same goes for “setting” those variables (= “replay”): the application first needs to specify the set of variables it is going to “write” later (typically for “replay” purposes the set of read / write variables is identical).
Or simply said: “Know what you want, tell exactly what you want”.
Here is already the first small problem (with the current state of the SimConnect API): most of those simulation variables are indeed also writeable (settable) by the 3rd party application, but quite a few variables are only readable.
Take for instance the variable APU GENERATOR SWITCH: as we can see in the API documentation (in the column “Settable”) that variable is only readable. So while this is sufficient e.g. for some hardware indicator it is of no use to a “replay app”: while we can record it, we cannot replay (set / write) it!
(Again, I am conciously ignoring events for now, both for simplicity’s sake and because they are now considered “legacy” - also refer to my question that I raised for the next developer update, if interested).
Why are some variables writeable, and others not? I guess for “historic reasons” - I don’t see any technical reason for this.
Second problem: not all 3rd party aircrafts actually use those “simulation variables” (at least not all of them: “basic variables” are supported, but not all of them). So while there exists the CANOPY OPEN variable (which indicates by how much percent the canopy is opened) some aicrafts simply ignore it: neither do they report the value properly, nor do they react to it.
And this is exactly where your qeustion comes in now 
So those aircrafts use their own set of internal variables, so-called “local variables” (or L:vars in short). While there exist at least one solution (well, I’d call it “workaround”) to access those local variables there are several reasons why I won’t go down that road for now:
- That solution requires the installation of a so-called WASM module into the community folder, which reads those “local variables” and sends it back - as custom “client data” - via the SimConnect API
- (I am not 100% sure, but that WASM module could even be aircraft-specific)
- This solution requires custom “client data” (as mentioned): the required IDs could “collide” with other WASM modules (which might try to do the same) → hence the “workaround” nature of any such approach
- Even if such a solution would run “collision-free” (and the users were willing to install such WASM modules, simply to get replay working with their 3rd party aircraft) a replay tool would have to write “custom code” (namely the specification of which “local variables” exactly it wants to read / write).
So in the worst case you would end up with N solutions (for N 3rd party aircrafts) in order to e.g. control the state of the canopy (or landing hook, throttle, …), because each of those N aircrafts might be using another “local variable” (assuming that they are identified “by name”) for the same thing.
And what for: we already have a “standardisation” of all those variables, and it’s called - SimConnect!
Now why are some aircrafts using their own “local variables” instead of the “simulation variables”, such as e.g. the mentioned CANOPY OPEN then? A fair question! And I’ve had some conversation with one of the 3rd party aircraft developers, and there are at least two reasons (for aircraft developers):
- They simply won’t work (as expected) in the current FS2020 implementation - yet. So for “time to market” reasons aircraft developers invent their own variables (that they can “fully control”)
- They simply don’t exist (yet) for a given feature of the aircraft
Again the CANOPY OPEN example: landing procedures for “WW II warbirds” foresee that the canopy be opened (in the best case “sliding backwards” ;)) for landing - at speeds around 100 knots or so. The problem: apparently the “stress simulation” in FS2020 causes then a “stress failure” at such “high speeds” (assuming that any canopy should be closed before take-off, and remain closed until after landing).
So what do 3rd party developers of such “warbirds” do? Exaclty: they invent their own “local variable” to control the canopy state - unfortunatelly.
Now personally I have zero experience with the aircraft development aspects of the MS software development kit (SDK), I only know about the SimConnect aspects. So I just let those statements stand here on their own.
But IMHO the proper solution would be that Asobo would introduce a “canopy stress factor / threshold” of some sort, such that aircraft developers could still use the standard CANOPY OPEN variable. But of course that is just one out of many examples…
So to fully answer your question: while I am certainly looking into more SimConnect “simulation variables” (specifically also with regards to engine start/shut-down currently - also considered to still use “events” for the time being…), supporting “custom/local variables per aircraft” is not something that I can consider.
Especially not as a “one-man show” developing Sky Dolly in my free time Because even if such “custom variables” would technically work (possibly with the help of a custom WASM module) it would mean to maintain different solutions, in the worst case “one solution per 3rd party aircraft” - and which would imply that I own those aircrafts in the first place (I do own a couple by now, but only those that personally interest me ;)).
So, the answer got a bit longer than planned, but - “such is life as a developer”