Managed add-ons - For Developers

This page describes managed add-ons from a developer's point of view. You should have read the introduction for users before reading on.

There are some fundamental requirements that you need to fulfill in order to publish your add-on as managed content.

Author.
Only the original author of an add-on may upload it as managed content. It means that you are not allowed to upload existing legacy add-ons as managed content unless you created them.

Rights.
In order to ensure that add-ons are available forever, you must grant everyone irrevocable permission to make verbatim copies of your add-on. Of course you are free to grant additional rights under the terms of your choice.

Server.
All add-ons must be available on servers that allow direct access to the files with no restriction on user agent, referrer, geolocation or otherwise. This means that you cannot use most popular free hosts such as Rapidshare, MediaFire and the like because they do not allow direct downloads unless you pay them.

Playability.
All routes and trains released as managed content must be playable. As a general rule, this means that routes should have at least two stations and trains at least a cab. It also means that add-ons must not produce error messages and must not contain Windows-only train plugins.

Users do not have to worry about what is going on behind the scenes when they open the Get Add-ons menu and install add-ons onto their computers. You, however, need a solid understanding of how the system works if you want to publish your add-on this way.

To start with, managed content is organized into packages. There are four types of packages:

Routes.
These packages contain routes that can be selected in the main menu. They can also contain any other kind of data such as textures, objects or sounds.

Trains.
These packages contain trains that can be selected in the main menu. They can also contain any other kind of data such as textures, objects or sounds.

Libraries.
These packages do not contain anything that users can directly select in the main menu. Rather, they serve to contain any kind of data such as textures, objects or sounds in order to split add-ons into multiple packages.

Shared libraries.
These are the same as libraries, but are specifically intended to be re-used by other add-on developers. They come with the promise backward compatibility.

One of the ideas behind the organization into packages is that you can split your add-on into multiple packages. In fact, you must place routes and trains into different packages. But, you can further split your add-on if you want to. For example, you could create separate packages for your background images, for your rails, for your signals and for your buildings. The advantage is that you can later update any single package and users will not have to download just about everything anew, only the package that was updated.

This organization also allows you to re-use packages across different add-ons. For example, you could share your signals across different routes. The advantage is that users only have to download the signal package once, not again and again for every route, and that if you make an improvement to the signals, every route using the signals will automatically benefit from the change.

Every package has a name and a version number, and every version of a package is identified by size and MD5 to protect against accidental download corruption. This also means that whenever you want to update a package, you have to increment its version number, because once changing the package, the size and MD5 are inevitably going to change as well.

If you split your add-on into multiple packages, it means that your primary route or train package will depend on other library packages. This set of dependencies is another vital property of every package. Without the set of dependencies, openBVE could not automatically download the dependencies along with the primary package, meaning your add-on would not function properly.

Your add-on can also provide a set of suggestions. For example, if you distribute a route, you can suggest a suitable train. It is important to understand that the route would also work without the train, therefore the train is not a dependency.

These tutorials will explain everything you need to know in order to distribute your add-on as managed content.

Basic topics

Advanced topics

Further information