once suitable baseline to start with would be an aircraft's set of bindings/multiplayer properties and flight recorder/fgtape config (instant replay).
This is again something where looking at Emesary (wiki) may pay off quickly, very quickly.
Johan G wrote in Sun Mar 29, 2020 8:18 pm: But mainly FGInterface is aimed at Airbus airliners.
daweed wrote in Sun Mar 29, 2020 8:28 pm:Nope nope , that probably wrong explained by me [...] FGInterface can be use for any aicraft [...] the only limit is people's imagination.
Only thing to be know is which properties need to be affected ... and as each aircraft developer use their own ... [...]
D-AINR wrote in Mon Nov 30, 2020 2:40 pm:Hi Daweed,
Have you published any other parts?
The 128 I / O board and the 7-segment board and the Airbus panels maybe?
Robert
Static image streaming does not seem to me to adapt to the situation (need to have a real-time update)
The system via a web browser would cause me a "style" problem (I don't know if I will be able to "hide" the window borders)
I will first start by reimplementing the screens by trying to synchronize the properties, in any case there is no question of reimplementing the logical whatever happens to a device it would undermine compatibility with other aircraft, if there are only Qt screens to develop there is nothing insurmountable from the moment I I manage to synchronize the properties in real time as I did for the other organs (FCU, EFIS, Transponder .. etc)
Hooray wrote:Erik previously talked about his DDS work and how that's limited to fixed structures, subsequently he mentioned Google Proto buffers and the new "property server" implementation using DDS.
Since a Canvas is nothing more than a property tree hierarchy (path with child nodes), maybe we could think of using this to "sync" (replicate) a local property tree node like /canvas/by-index/texture[0] to another fgfs instance using DDS ?
I had this previously working using just the telnet/props protocol, i.e. by manually hooking up two locally-running fgfs instances and replicate a canvas from the master to the slave instance. But with DDS, that sounds like a better option ?
I guess, one proof-of-concept could replicate a single property path (node) to another fgfs process by using just the ID of the canvas texture, something like --native-canvas=dds, ID, out,30
globals.controls._startEngine = globals.controls.startEngine;
globals.controls.startEngine = func(v = 1, which...) {
debug.dump(v);
globals.controls._startEngine(v, which);
};
Users browsing this forum: No registered users and 1 guest