projectFLY Bridge Plugin Rewrite.
This post is for users of the projectFLY X-Plane bridge plugin.
Recently we've been seeing a lot of bug reports involving the projectFLY bridge plugin.
Users with this plugin installed have been reporting simulator crashes or Log.txt files with mentions of Gizmo throwing a lot of errors. Clearly we have a clash between Gizmo64 and projectFLY's bridge plugin.
After downloading the projectFLY client app I installed their plugin and can replicate an X-Plane crash or glitch with 100% certainty when using our X-Aviation Saab 340A product.
Further investigation showed that if you start the projectFLY client App after you start X-Plane the simulator usually loads without error.
This gave me reasonable confidence that the problem was somewhere on the projectFLY side of things so I started to investigate what their plugin was doing.
Using a HexEditor to open the win.xpl shows that they're using a Windows Named Pipe to pass data to their client App.
Their client App also contains a handy debug window showing us what is probably the expected data format over the wire.
Using an App called IO Ninja I was able to watch the data being passed between the bridge plugin and their client App.
From the size and send-rate of the data packets things look good. The hex data is mostly repeating and is of a nice small size to reverse engineer.
The log also tells us that the data channel is one way. The client App never sends anything back to the plugin. (Blue packets are the plugin writing data. Green packets are the client App reading data.)
IO Ninja also shows us that the plugin tries to open the \projectfly pipe and that the client App creates it.
I saw some strange IPC log data events while repeatedly crashing the simulator.
It seems like their bug is a bounds-overflow glitch where they're sending way too much data under some circumstance. I don't have the source code so it's hard to narrow down exactly what's going on.
I got in contact with their plugin developer(@dev_mitchellw) via Twitter...
And he kindly sent me the following cheat sheet for their packet format:
So I got to work writing a test App to replicate their IPC protocol.
Eventually I arrived at the following data struct:
A new X-Plane plugin was then created with this knowledge in hand.
Along the way a few of their dataref choices were updated.
The original "Landing Speed" logic is uknown to me so I wrote a quick function to handle bumpy landing rejection and landing speed capture.
The new plugin functions correctly with Gizmo64 installed where the official projectFLY plugin will crash reliably.
I call that a win.
The new plugin is available now free of charge from github.
https://github.com/benrussell/Open.FlyBridge/releases
Enjoy.
Recently we've been seeing a lot of bug reports involving the projectFLY bridge plugin.
Users with this plugin installed have been reporting simulator crashes or Log.txt files with mentions of Gizmo throwing a lot of errors. Clearly we have a clash between Gizmo64 and projectFLY's bridge plugin.
After downloading the projectFLY client app I installed their plugin and can replicate an X-Plane crash or glitch with 100% certainty when using our X-Aviation Saab 340A product.
Further investigation showed that if you start the projectFLY client App after you start X-Plane the simulator usually loads without error.
This gave me reasonable confidence that the problem was somewhere on the projectFLY side of things so I started to investigate what their plugin was doing.
Using a HexEditor to open the win.xpl shows that they're using a Windows Named Pipe to pass data to their client App.
The hex editor also revealed a list of datarefs that were being sent to the client App.
Their client App also contains a handy debug window showing us what is probably the expected data format over the wire.
Using an App called IO Ninja I was able to watch the data being passed between the bridge plugin and their client App.
From the size and send-rate of the data packets things look good. The hex data is mostly repeating and is of a nice small size to reverse engineer.
The log also tells us that the data channel is one way. The client App never sends anything back to the plugin. (Blue packets are the plugin writing data. Green packets are the client App reading data.)
IO Ninja also shows us that the plugin tries to open the \projectfly pipe and that the client App creates it.
I saw some strange IPC log data events while repeatedly crashing the simulator.
It seems like their bug is a bounds-overflow glitch where they're sending way too much data under some circumstance. I don't have the source code so it's hard to narrow down exactly what's going on.
I got in contact with their plugin developer(@dev_mitchellw) via Twitter...
And he kindly sent me the following cheat sheet for their packet format:
So I got to work writing a test App to replicate their IPC protocol.
Eventually I arrived at the following data struct:
A new X-Plane plugin was then created with this knowledge in hand.
Along the way a few of their dataref choices were updated.
The original "Landing Speed" logic is uknown to me so I wrote a quick function to handle bumpy landing rejection and landing speed capture.
The new plugin functions correctly with Gizmo64 installed where the official projectFLY plugin will crash reliably.
I call that a win.
The new plugin is available now free of charge from github.
https://github.com/benrussell/Open.FlyBridge/releases
Enjoy.
Comments
Post a Comment