This wiki is archived and useful information is being migrated to the main bzflag.org website
BZFS can be built to support the loading of external libraries as plug-ins. These plug-ins can alter or replace the logic applied by the server, as well as automate many common tasks.
Plug-ins are one of the more popular ways to apply modifications to the game. They do not require modifications of the BZFS application source code so it can be kept up to date with out the need to constantly apply patches. They have also proven to be a very simple method for distributing modifications from developers to players.
Plug-ins are compiled dynamic link libraries, that are built for the same OS/RuntimeEnvironment as the BZFS server that hosts them. On Microsoft Windows they are built as DLL files. On Linux and other Unix-like systems they are built as .so files.
Plug-ins are loaded at startup by the -loadplugin option, or at run time with the /loadplugin command. If the full path to the plug-in is not specified, then BZFS will search a number of known sub directories for the plug-in as it attempts to load it. Using a valid path to the plug-in on load is highly recommended. While playing, all plug-ins loaded onto the server are visible with the /listplugins command.
Some plug-ins take parameters that are passed to the plug-in on load. This is often a numeric value, or a path to a file. To pass a parameter to a plug-in, simply add a ',' after the plug-in name or path, and then add the parameter. Parameters can not have spaces, due to the way BZFS parses command line options and / commands.
On load, plug-ins install a number of callbacks and event handlers with the hosting BZFS that are called when specific events happen. This allows the plug-in to perform additional actions on these events, or if need be, alter the results of the default logic of the server.
BZFS searches for plug-ins in two standard locations: the config directory and the global plug-ins directory. The config directory is where the BZFlag config.cfg file is located, and the global plug-ins directory is $(prefix)/lib/bzflag/.
As of February 2016, Git tree contains the following plug-ins:
Third Party Plug-ins
A number of non-developers have created plug-ins for BZFS, and usually release them on the BZFlag Forums.
Here are the steps to compile a hypothetical third party plug-in named "Example":
For versions older than 2.4.3
- In the plugins directory of the BZFlag source tree run the command ./newplug.sh Example
- Remove all of the files from the newly created plugins/Example directory (they were created by newplug.sh)
- Copy all of the distributed Example files into the plugins/Example directory
- In the top-level BZFlag source directory run autogen.sh, configure, and make as usual
For versions on or after 2.4.3
- Store the distributed plugin files into the plugins/Example directory
- In the top-level BZFlag source directory run:
./autogen.sh ./configure --enable-custom-plugins=Example ./make
Note that you can use a comma-separated list to specify multiple plugins to be built:
When that finishes successfully the plug-in should be ready to use as described above.
On Mac OS X
In Xcode on Mac OS X, follow these instructions:
- Create a new target for your plug-in.
- Xcode 5 (and below): Click on the BZFlag project name in the project navigator. Click Add Target, and create a new C/C++ Library. Name the plugin, and select "Dynamic" for type.
- Xcode 6: Click on the BZFlag project in the project navigator. Go the File > New > Target. When prompted for the template for the target, under the "OS X" section, select the "Framework & Library" section and finally select "Library." In the next dialog, select "None (Plain C/C++ Library)" for the Framework and "Dynamic" for the type.
- In the project navigator, move the new library target from the bottom of the screen into the "Targets" group.
- Click on the BZFlag project name in the project navigator again. In the list of targets, select the BZFlag application target. In the Build Phases tab, in the Target Dependencies pane, add your new library target as a dependency of the application target. Also add it to the Copy Files phase for the PlugIns directory.
- Select your new library target. Select the Build Settings tab, and locate the Other Linker Flags option. Add the option "-undefined dynamic_lookup"
- Find the Architecture build setting for your new library. Make sure it is the same architecture as the main codebase, or click Levels, click the Architecture setting under your library target, click Other, and delete the setting. This will make it assume the overall project build architecture.
- If your plug-in uses "plugin_utils.h", then ensure that under Build Phases the libplugin_utils.a library is listed under "Link Binary With Libraries"; add the library if it is not already listed.
- Find the Executable Prefix build setting for your new library, and delete the "lib" setting.
- Add your source file(s) to the project, and make them members of your library target; ensure you select the "Copy items if needed" checkbox and to choose "Create groups."
- Build as usual.
Preparing a Linux BZFS
In order to run plugins in BZFS, you need to recompile it with the --enable-shared option on the configure script.
Note that as of 2.4.0 the BZFlag configuration has --enable-shared automatically enabled.
$ ./configure --enable-shared --disable-client; make; make install;
|There is still documentation to be done here!! If you feel up to the task, please have a go at it. Specifically what needs to be added is:
Describe the basics of plug-in development.
The plug-in system was added in BZFlag V. 2.0.4 and was initially met with a lukewarm reception by some of the core developers and the maintainer. The community has since embraced the concept and built a multitude of useful modifications, many that have been incorporated into the project as standard plug-ins.
For Version 3.0 major changes to the BZFS API have been made to increase its lifespan.