As more features get added to the plugin API, more statistics may be added to take advantage of the increased data. However, this also poses the risk of people still using older versions which cannot track these statistics. As it stands, there is no check to ensure players are using a compatible version of the plugin API.

There exists a minApiVersion when registering a plugin, but for the purposes of this project, this is not a good fit. Say, a player wishes to track time spent in parks. However, they are using the previous version of the plugin API after we updated to track a brand new statistic. Well, the player doesn't need to track that new statistic, but we are locking them out despite time tracking still having support.

The proposed solution is to make a new class: UnsupportedStatistic. It will extend Statistic so it may be returned in its place when being added to the StatController. It should have a very basic definition, where the only thing needed is the API version that needs to be supported. It should override the get widget() method to display to the player what version of OpenRCT2 is needed to track the statistic. Priority should be taken to main releases (i.e. v0.4.1 or v0.3.0), and only if there hasn't been an main release should a develop version be suggested (and for simplicity, suggesting the most recent develop version should be fine).

This plugin is intransient, and as such, works only with OpenRCT2 v0.4.0 or newer. Nothing in the documentation states this. This should be in the README at a minimum (maybe in CONTRIBUTING.md, but this is likely not needed).

In OpenRCT2 v0.4.3 and onward, the reload icon displays as intended. In older versions, the plugin API doesn't have the ability to take a string and convert it to the image id. What complicates the matter is that the reload icon was only introduced in v0.4.2, so setting the value to a constant number will not solve the problem for older versions.

A proposed solution is to check for if the API version is less than that for v0.4.3 and use a different icon instead. Ideally one that would be the same across v0.4.0 to 0.4.2 (so most likely something in G1). Perhaps the sprite for demolish (5165)?

Users may be interested in seeing more stats than can fit into the small widget space. For instance, they might want to see a table view of how much they've played each day for the last month, and that wouldn't fit in the current main widget layout.

I'm interested in implementing a tab system, where each Statistic could have a detailedExtendedDisplay property (I'm not attached to this specific name) which would return a TabCreator. Then each Statistic with a detailedExtendedDisplay would get a new tab added to the window, and no tabs added for a Statistic that doesn't have an extended display.

I actually tried implementing this using just two tabs - the main content tab, and a single other tab with a dropdown that would let you select which extended display you'd like to view. Unfortunately, there isn't a concept of visibility hierarchy,(e.g. there's no way to set a parent horizontal visibility to "none" and have all its children also be turned to visibility none), so creating separate tabs is the only way I see to do this.

Another way to display more details could be to make the main window larger to fit bigger widgets. I like this less because I like the uniformity of the current createWidget() output, and it might be challenging to figure out how to add future new widgets if the main window is clogged up with these extended details.

Included is a proposed screenshot of what the tabs could look like. The flexUI window auto resizes the window height based on the size of the content in it, which I very much like. If it wasn't desirable, a static height could be used.

Would you be interested in seeing a PR of this, and if so how would you prefer I submit since I see there being 3 parts: a potential new Statistic, the architecture for an extended display, and some potential extended display implementation ideas.