Feature tags

Introduction

feature is represented as a string, which can refer to many of the following:

• Platform name.
• Platform architecture (64-bit or 32-bit, x86 or ARM).
• Platform type (desktop, mobile, Web).
• Supported texture compression algorithms on the platform.
• debug or release (debug includes the editor).
• Whether the project is running from the editor or a “standalone” binary.
• Many more things. Features can be queried at run-time from the singleton API by calling:

  OS.has_feature(name)

  Default features

  case-sensitive: Warning immutable. This means that they will not change depending on run-time conditions. For example, OS.has_feature("mobile") will return false when running a project exported to HTML5 on a mobile device. call JavaScript code that reads the browser’s user agent.

  Custom features

  export preset used to generate it:

  Overriding project settings

  Project Settings. This allows you to better customize any configuration when doing a build. In the following example, a different icon is added for the demo build of the game (which was customized in a special export preset, which, in turn, includes only demo levels). After overriding, a new field is added for this specific configuration: Note project settings “override.cfg” functionality (which is unrelated to feature tags), remember that feature tags still apply. Therefore, make sure to also override the setting with the desired feature tag(s) if you want them to override base project settings on all platforms and configurations.

  Default overrides

  There are already a lot of settings that come with overrides by default; they can be found in many sections of the project settings.

  Customizing the build

  ExportPlugin. They are also used to specify which shared library is loaded and exported in GDNative.