Feature: External (mod-provided) data layers #1020
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Components: - Registration API and internal lookup API - Configuration schema additions (per-mod-layer dictionary) - Adding external layers to GMCM - Adapter layer to actually render things - Minor implementation tweaks like event priorities.
- Empty type IDs should simply be ignored, not considered errors. - Original implementation was logging errors every time, even for valid IDs; only log when ID isn't registered.
With mods potentially able to add their own layers that Data Layers knows nothing about, it doesn't make much sense to require all the colors and schemes to be registered in Data Layers' own asset. This allows registration of color schemes along with the layers themselves, using the same asset data format used by Data Layers.
Forcing a global ID means the color has to be specified _in the calling mod's own asset_ with an awkward prefix, like "author.ModName:LayerName_value". It also makes it effectively impossible for using the API to add color schemes for Data Layers itself, or for other mods, which seems like a useful thing to be able to do.
The original idea was to have the mod be able to reference some shared color in Data Layers itself. However, that's not how it works today; colors are already saved/queried using the layer ID as a prefix; shared color schemes do not exist. As such, the color ID field was only adding needless boilerplate and another possible source of human error. It's even less useful with the addition of mod color scheme registrations. There should never be any practical reason to require a color ID that's different from the tile type ID.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 078a47d.