Note: This is a re-send of #1010. Please see my comment there.
Adds an API for other mods to register and implement their own data layers.
The API has a single Register method which takes an IDataLayer. That, in turn, provides the legend data, colors, translations, update logic, etc.
Externally-registered layers act just like internal ones; they show up in the GMCM and the UI widget as if they were normal layers.
There might be a few caveats or rough edges here; in particular:
The ColorScheme is entirely internal to Data Layers. Users of a mod that is based IDataLayersApi probably won't have anything set up in their color scheme for that mod. I'm not sure how useful it really is to bother with color schemes in this context, but if a user adds those keys to the colors.json then it should work normally.
Internally, LegendEntry has a convenient constructor that allows omitting the name if I18n key is used as ID. This doesn't work when going across the API boundary, because DataLayers only sees its own translations, whereas the registering mod would be providing a key for itself. This means mods have to provide layer names as well.
By default, newly-added configurations are set to update 60 times per second. This default is in DataLayers itself, and makes sense when DataLayers is providing its own explicit defaults per "mod integration". However, if external registrations default to 60x and users don't change it (most won't) then it will suck up a lot of performance. Should we consider changing the default in DataLayers, or using a different default for layers added through the API?
There's an example consumer in 078a47d94be49437710639e2d477625cd11d0a4a.
Note: This is a re-send of #1010. Please see my comment there.
Adds an API for other mods to register and implement their own data layers.
The API has a single
Registermethod which takes anIDataLayer. That, in turn, provides the legend data, colors, translations, update logic, etc.Externally-registered layers act just like internal ones; they show up in the GMCM and the UI widget as if they were normal layers.
There might be a few caveats or rough edges here; in particular:
ColorSchemeis entirely internal to Data Layers. Users of a mod that is basedIDataLayersApiprobably won't have anything set up in their color scheme for that mod. I'm not sure how useful it really is to bother with color schemes in this context, but if a user adds those keys to thecolors.jsonthen it should work normally.LegendEntryhas a convenient constructor that allows omitting the name if I18n key is used as ID. This doesn't work when going across the API boundary, because DataLayers only sees its own translations, whereas the registering mod would be providing a key for itself. This means mods have to provide layer names as well.There's an example consumer in 078a47d94be49437710639e2d477625cd11d0a4a.