Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

3 Neutral

About Folko

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi, could you please elaborate what doesn't work? Are you trying it on a supported airport? Which one? And what exactly doesn't work?
  2. Hi Anne, glad to see more C++ developers here on Threshold! The directory structure of X-Plane plugins is a little confusing because there are several different approaches that evolved with different X-Plane versions. Since you are using Visual Studio, the starting point of the plugin deployment should be the DLL file generated by the Visual Studio compiler, let's assume it's called plugin.dll. Now there are different approaches of what you can do to get the plugin into X-Plane, here are three common ones: rename plugin.dll to anything you'd like but replace the file extension with "xpl" and put it into the X-Plane/Resources/plugins directory (and not into a subdirectory!). For example, rename it to annes_plugin.xpl and put it right into the plugin directory. This approach will only work if you develop for one platform (e.g. Windows) only and if your plugin doesn't require any external files like images. This is the oldest but easiest approach. The official name of this approach is "thin plugin". if you need external files for your plugin or want to support more than one platform than Windows, you will need a so-called fat plugin. These are plugins that have their own subdirectory inside the X-Plane/Resources/plugins directory along with a directory called "64" inside your plugin directory. To create a fat plugin, create a subdirectory with your plugin name inside the "plugins" directory and rename plugin.dll to win.xpl. Example: X-Plane/resouces/plugins/AnnesPlugin/64/win.xpl. External files go into the main directory of the plugin. If you ever want to support Linux or OS X, there will be additional files called lin.xpl and mac.xpl in the "64" directory. the previous approach has the disadvantage that every plugin is called "win.xpl" in crash dumps and other diagnostic tools. So the state-of-the-art approach is to create a directory called "win_x64" inside your plugin directory and call the XPL file exactly the same name as the main plugin folder. Example: X-Plane/Resources/plugins/AnnesPlugin/win_x64/AnnesPlugin.xpl I use the third approach for the plugins I develop (AviTab, MoveVR and SAM). That approach is sometimes confusing for users because they can no longer rename a plugin directory for testing purposes because they would have to rename the XPL file as well and are not aware of that. All approaches are explained in more detail here: https://developer.x-plane.com/article/building-and-installing-plugins/ Please don't hesitate to ask further questions, I really want to see more C++ developers on board and will try my best to help them!
  3. Or maybe it doesn't touch the dataref at all so that it will keep the value from the previously selected aircraft? Then it would depend on which aircraft you used in the previous flight of the same session.
  4. You can actually place jetways and marshaller on default airports, it's just not possible to do this automatically or use the default jetways. But you could create a custom overlay for the stock airports and place anything you want there.
  5. Thanks, the empty scenery issues is already known and will be fixed in the next version. Apart from that, did it work on the next start (i.e. after X-Plane generated the ini)?
  6. According to the log, X-Plane loaded the plugin successfully, but it had an error during the initialization phase. Did it create a sam.log file in the plugin directory? Since it even put the version correctly into the log, the version of your OS seems to be supported, otherwise it would have failed sooner.
  7. That part would be easy. But allowing that would make jetways intersect with each other. For example, imagine two jetways on one gate that are configured like that. SAM would have to make sure that the jetways don't intersect when one connects to LF1 and the other one to LF2. By enforcing one door per jetway, the scenery author has control over this.
  • Create New...

Important Information

Please read the Terms of Use