Creation of Add-on libraries: Difference between revisions

From RPTools Wiki
Jump to navigation Jump to search
(Beginning of edits)
 
(Updated guidance of moving the properties files so they are accessible by MTscript functions.)
 
(12 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{stub}}
MapTool 1.11 introduced [[Add-On Library|add-on libraries]] which are intended to be an easier to work with replacement for [[Library Token]]s while also offering a lot more functionality.


[[Library Token]]s will still function the way that they currently do in MapTool 1.11 and future versions, but will not be getting a lot of the new features that add-on libraries will get, so it is recommended that framework developers transition to add-on libraries if supporting MapTool 1.11 and above.
 


An example add-on library for examination and testing is available at https://github.com/cwisniew/test-maptool-add-on-lib
An example add-on library for examination and testing is available at https://github.com/cwisniew/test-maptool-add-on-lib


== Managing the Add-On Libraries for Your Campaign ==
<p style="clear: both"/>
 
<p style="clear: both" />There are two main ways to create an Add-on Library:
 
# Create the library files and directory structure from scratch; or
# Export a Library Token as an Add-on Library.
 
Each of these approaches is described below.<p style="clear: both" />
== 1. Create the library files and directory structure from scratch ==
Firstly you will need a text editor.  There are many of them mentioned below -- if in doubt, use [https://code.visualstudio.com/ VS Code].
*[https://www.gnu.org/software/emacs/ Emacs]
*[https://neovim.io/ Neovim]
*[https://www.vim.org/ Vim]
*[https://code.visualstudio.com/ VS Code]
After choosing a text editor, create a new directory to hold your Add-on.
 
Top-level files in the Add-on are metadata files; they hold information about your Add-on. The only file your Add-on needs to be accepted by MapTool is {{code|library.json}}.
 
You may have other non-metadata files in a subdirectory named {{code|library}}.
 
For macro code, you may have a {{code|mtscript}} directory inside {{code|library}}.  Both of those subdirectories may have a publicly accessible directory which must be named {{code|public}}.
 
This structure is described in more detail in [[Technical definition of Add-on Libraries]].
=== Creating library.json ===
The only required fields are
*a name string,
*an authors array,
*a short description string, and
*a namespace string.
The other fields are described on the [[Technical definition of Add-on Libraries]] page. Most of these are self-explanatory. Just remember '''bad things''' will happen if you use the same namespace as someone else, so try to use at least 3 words or a reversed domain name.  In the example below, the namespace is {{code|io.github.Azhrei}}, which is a reverse of a hypothetical documentation page, {{code|Azhrei.github.io}}.
 
An example of a minimal {{code|library.json}} could be
  {
    "name": "test",
    "authors": ["you"],
    "namespace": "io.github.Azhrei",
    "shortDescription": "test"
  }
and that is it. You have made an Add-on! Those 6 lines are enough; just zip this file and then rename it so that it ends with {{code|.mtlib}} and have fun.
 
== 2. Export a [[Library Token]] as an Add-on Library ==
 
[[File:export-library-token-as-addon.png|400px|thumb|Library token context menu]]
 
The token pop-up menu includes a way to export your existing library tokens to an Add-on Library structure. This is useful for starting the conversion of an existing token library to an Add-on.
 
In all but the simplest [[Library Token]]s you will want edit the extracted data. At a minimum, you will want to examine whether you prefer to rename the macros.
 
=== Things you will want to change ===
 
# You should edit the {{code|library.json}} file, and change the namespace value from the default ("") to something that is unlikely to conflict with other users. It's a good practice to use a reversed hostname + Add-on name for this.  For example, if you created an account at GitHub and are using the '''GitHub.io''' page mentioned above, an example namespace would be {{code|io.github.''add-on-name''}}.
# All macros (except event-based ones) are created in {{code|mtscript/public/}} with the pattern {{code|macro_''number''.mts}}.  This naming pattern is because macro names have many things that might make them invalid -- or worse, dangerous -- as filenames. There is a {{code|macro_script_map.txt}} file saved in the top-level which contains the names of your macros and the filename that they were saved in.
# Not all macro buttons on [[Library Token]]s contain MTscript macros.  They are sometimes used as containers for CSS or other text content. You will probably want to rename and move them to the {{code|library/public/}} directory.  Don't forget that renaming them means any references in your macros may need updating as well.
# The {{code|onCampaignLoad}} macro will be saved as {{code|onInit}}.
# All Library Token properties are saved to a directory called {{code|property/}}. You should move the contents of this directory to something accessible by [[MTscript functions related to Add-on libraries]] such as {{code|library/public/properties/}}. The Library Token properties are saved with file names {{code|prop_''number''.txt}},  and a mapping file {{code|prop_file_map.txt}} is created to map these the Library Token property names to the newly-created filenames.


The dialog to manage the add-on libraries for your campaign can be reached using the {{ui location|File > Add On Libraries...}} menu item.
These files and structures are described in more detail in [[Technical definition of Add-on Libraries]].
{{Note|After doing the above you should ''REALLY'' take the opportunity to source control your Add-on...}}

Latest revision as of 01:43, 17 November 2023


An example add-on library for examination and testing is available at https://github.com/cwisniew/test-maptool-add-on-lib

There are two main ways to create an Add-on Library:

  1. Create the library files and directory structure from scratch; or
  2. Export a Library Token as an Add-on Library.

Each of these approaches is described below.

1. Create the library files and directory structure from scratch

Firstly you will need a text editor. There are many of them mentioned below -- if in doubt, use VS Code.

After choosing a text editor, create a new directory to hold your Add-on.

Top-level files in the Add-on are metadata files; they hold information about your Add-on. The only file your Add-on needs to be accepted by MapTool is library.json.

You may have other non-metadata files in a subdirectory named library.

For macro code, you may have a mtscript directory inside library. Both of those subdirectories may have a publicly accessible directory which must be named public.

This structure is described in more detail in Technical definition of Add-on Libraries.

Creating library.json

The only required fields are

  • a name string,
  • an authors array,
  • a short description string, and
  • a namespace string.

The other fields are described on the Technical definition of Add-on Libraries page. Most of these are self-explanatory. Just remember bad things will happen if you use the same namespace as someone else, so try to use at least 3 words or a reversed domain name. In the example below, the namespace is io.github.Azhrei, which is a reverse of a hypothetical documentation page, Azhrei.github.io.

An example of a minimal library.json could be

 {
   "name": "test",
   "authors": ["you"],
   "namespace": "io.github.Azhrei",
   "shortDescription": "test"
 }

and that is it. You have made an Add-on! Those 6 lines are enough; just zip this file and then rename it so that it ends with .mtlib and have fun.

2. Export a Library Token as an Add-on Library

Library token context menu

The token pop-up menu includes a way to export your existing library tokens to an Add-on Library structure. This is useful for starting the conversion of an existing token library to an Add-on.

In all but the simplest Library Tokens you will want edit the extracted data. At a minimum, you will want to examine whether you prefer to rename the macros.

Things you will want to change

  1. You should edit the library.json file, and change the namespace value from the default ("") to something that is unlikely to conflict with other users. It's a good practice to use a reversed hostname + Add-on name for this. For example, if you created an account at GitHub and are using the GitHub.io page mentioned above, an example namespace would be io.github.add-on-name.
  2. All macros (except event-based ones) are created in mtscript/public/ with the pattern macro_number.mts. This naming pattern is because macro names have many things that might make them invalid -- or worse, dangerous -- as filenames. There is a macro_script_map.txt file saved in the top-level which contains the names of your macros and the filename that they were saved in.
  3. Not all macro buttons on Library Tokens contain MTscript macros. They are sometimes used as containers for CSS or other text content. You will probably want to rename and move them to the library/public/ directory. Don't forget that renaming them means any references in your macros may need updating as well.
  4. The onCampaignLoad macro will be saved as onInit.
  5. All Library Token properties are saved to a directory called property/. You should move the contents of this directory to something accessible by MTscript functions related to Add-on libraries such as library/public/properties/. The Library Token properties are saved with file names prop_number.txt, and a mapping file prop_file_map.txt is created to map these the Library Token property names to the newly-created filenames.

These files and structures are described in more detail in Technical definition of Add-on Libraries.

After doing the above you should REALLY take the opportunity to source control your Add-on...