Monday, September 17, 2018

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.

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.


Wednesday, February 18, 2015

Gizmo64 v14.12.31.0008 beta

A new plugin is now available for download. (10.6 MB)

64 bit Only.
Mac, Windows and Linux.

Linux plugin was compiled on Ubuntu 14.04 LTS.

This is a beta release intended for developers only.
It may not work with your installed payware products.
Some products may require a patch to take full advantage of the updates in this release.

New Features:
Forum user wim1976 has been very helpful recently and noticed some missing events.
These are:

  • OnDraw_BeforeLocalMap3D()
  • OnDraw_LocalMap3D()


  • Clears OpenGL error log data before compiling shaders ensuring correct error reporting.
  • Modified dref.publish so we broadcast our message.
    This allows use of DRE and DRT together.
  • OpenAL: Mutes warning about stereo sound file on 3D Sound Stage.
  • Improves error reporting for unexpected usages of deployment.key file.
  • Lots of Linux fixes to work with Ubuntu 14.04 LTS tool chain.
  • Improved XA Activation wizard.
    Now shows you your existing license data including expiry information.

Tuesday, February 17, 2015

Gizmo64 on Ubuntu 14.04 LTS

Gizmo64.plugin is working for me with Ubuntu 14.04 LTS.

I recently upgraded from Ubuntu 12.04 LTS to 14.04 LTS because people were seeing issues with Gizmo64.plugin compiled on 12.04.

Ubuntu 14.04 LTS is a more sensible support target for re-introduction of the Linux plugin.

Unfortunately the upgrade broke my dev setup. The plugin would no longer link.
A third party library was unhappy and required both source code and Makefile tweaks before I could recompile it with the 14.04 toolchain.

Gizmo64.plugin now compiles and links on Ubuntu 14.04 LTS but I'm seeing a random seg-fault caused by what appears to be a misplaced memset() call.

More work to be done..

A memset() bug was found and fixed.
Linux behaves differently when we query the file system for the size of a file.

Tuesday, May 27, 2014

A reflection on the state of simming...

No, really; Simulated radar reflection:

Here's a GPU shader powered radar back scatter image dynamically generated
 from the normal map provided by the new API detailed in the posts below...

The original normal map used to calculate back scatter.

Another test image, this time with the radar located at 0.5, 0.0
This version is much simpler, displaying a wider backscatter area for easier debug.
It also lacks color and height mapping.

New mapping API:

This is the major news for this release, it brings a whole new level of power to Gizmo64 with regards to mapping the DSF files for use with synthetic vision systems, TAWS, moving maps and more..

Here's some sample images; 

Heat mapped to show height, normal mapped to show definition.

Composite Normal map made by joining two adjacent sample tiles.

Composite Height map made by joining two adjacent sample tiles.

This set of images is a composite of two different tile data sets. 
The images were joined in photoshop by pixel alignment only. There is no detectable seam.

An earlier height map example showing a different tonal range.

I am creating more reference code that will show how to tile and manage the data sets in the simulator at runtime.

The height map is colored using a simple shader and this texture lookup table stored as a PNG file.

The color table is very simple to replace with each horizontal pixel matching a height in the heightmap.
Colors start at the left hand side representing the lowest terrain and finish with the highest terrain color at the right.
Your color map texture should be exactly 256 pixels wide. 
If it is more than 1 pixel high only the bottom row of pixels are used.

Black height map pixels read as 0 representing a low altitude. 
White height map pixels read as 1.0 representing a high altitude.

A heightmap value of 0.25 (a dark grey tone) would cause the shader to select a color from the left hand side of the color map texture.

The shader is fairly crude at the moment and is part of a 
It was nice to find a solution that avoids any branching in the shader code.

Synth Vision:

Significant progress has been made towards providing in-sim synth vision display.

The new map API includes functions for converting terrain data into both a TriMesh (more on these later) and optionally, directly into an OpenGL VBO* handle.

There are some "fitting" errors, this is to be expected when you translate floating point numbers through two different coordinate sets three times... 

The error appears to be about 120 meters in horizontal on both X and Z axis, it may be possible to find an offset value that results in a better fitting of the terrain, experiments yield good results but nothing definitive yet.

World > GL Query > Probe > GL Response > World(Fix gravity normal) > GL Query > RE-Probe > GL Response > World(Altitude instead of probe returned Y value... *phew*)

Here are some example images from the core of the synth vision system:

Wide area long distance terrain fit.

Close-up at the airfield, where lots of ground based effects are possible.
Vertical offset error is about 20 centimeters in this shot.
Long distance fitting of mountainous terrain is also quite good.

Testing two sample tiles with entirely different query parameters.
Both display good results. FPS impact was minimal.

Long distance wide area tiling test.
Three different sets of data tiled together in OpenGL.
Horizontal fitting is excellent for all tiles.
Vertical fitting displays some errors that are returned by the
 Terrain Probe API, these may be reduced in future.

TriMesh Data

We also have a new trimesh API that can be used to create large blobs of vertex data that is suitable for using with OpenGL to use high performance drawing techniques.

This area of the new API code is lacking in documentation or example code.

It was developed to enable the new synth vision systems and bloomed into a new API for scripts to pass vertex data into C++ and OpenGL efficiently.

I am planning to create a new OBJ8 loader script example shortly that will demonstrate how to use TriMesh data.

For now, please refer to the documentation:

For more information on the new mapping API please see the reference manual here:

...and also the working example code here:

The shaders API has also had some new code added to it.
We can now do shader powered multi textured (upto 16 textures!) custom (OBJ8) drawing effects.

* Drawing with VBO data unlocks the speed in modern graphics cards. 
Gizmo64 is now free from the limits if LuaGL in terms of custom OpenGL drawing and we should start to see some really interesting effects in the near future.

Thursday, January 16, 2014



You can download a zip file containing Gizmo64.plugin version here:


Make a backup of your existing plugin: X-Plane/resources/plugins/Gizmo64.plugin
Download and unzip the new plugin.
Move the new Gizmo64.plugin item into the X-Plane/resources/plugins/ folder.

Will this work with my Payware?

Yes. It should work perfectly but please make a backup of your existing plugin to be sure.

General Updates

  • Fixes memory leak bug in the activation scripts.
  • Added a simple Preferences GUI that allows you to toggle the ToolTray.

Core Plugin Updates

  • Tweaks map generator code; minor optimisation, hopefully killed the frame tearing bug.
  • Fixes OnBeforeReboot() event.
  • Adds name-and-shame log output when you try and create a command name that starts with sim/
    (The SDK complains that this is illegal but returns a perfectly sane value that we use to override or supplement the sim/ command.)
  • Very large amount of weed trimming from the Log.txt output. Should be more concise now.
  • Fixes shader.setParam(...) so that it correctly accepts 3 parameters.
  • Internal code changes so we use the same code for all three platform builds, also more careful about memory initialisation.
  • Adds plugin.sendBlob and utils.getBlobFromCPointer functions to allow more powerful use for the X-Plane SDK Inter-Plugin-Comms functions.
  • Windows plugin was rebuilt with a fully patched copy of Visual Studio 12. Runtime DLL's in download package have been refreshed.

Tuesday, January 7, 2014


Gizmo64 is now much quieter in the X-Plane/Log.txt file.

The average startup entry looks like this:

Aircraft change events are much cleaner now:

Many log entries have been tweaked to only appear if there's an error.

Log data has been made more informative where possible.