Open HugoBDesigner opened 6 years ago
Perhaps add different "tiers" for compatibility, like this:
Green: Fully compatible, with no issues.(using correct version, or another version that doesn't change gameplay elements much)
Yellow: Compatible, but may have issues.(using a version that makes certain elements behave differently, or some other minor compatibility issue)
Red: Incompatible, this cannot be played.(using a version with drastic changes, such as level format, or the mappack has features from a future version that can render the mappack unplayable)
I'm more inclined towards using a numeric version. If the version number in the mappack is greater than the mod version downloaded, then the mappack won't play. If the mappack version is lesser than the mod version, the mod will retroactively adapt to the different/missing features. Version control would have two values: major and minor release. Minor releases (x.1, x.2, etc.) would adapt their features retroactively. Major releases (1.x, 2.x, etc.) would require users to download a mod version of that tier (whether the mappack version is greater or smaller).
For instance, if a player has a mappack version 2.4, they should be able to play it on mod version 2.4 through 2.9, but not on 3.x or above, nor on 2.3 or below.
Unless some other, more effective version control method is presented, I'll keep this as the planned implementation.
As new features come, some mappacks might become incompatible. We should have a version control system for mappacks, such that they won't play unless the user has the necessary version - or, at least, give them a warning before proceeding.
Ideally, every new update would be retro-compatible, such that older mappacks work on whatever the latest version is. I could use some suggestions for the best approach for version control (or its implementation).