- #Skyrim fnis mod organizer 2 data structure download#
- #Skyrim fnis mod organizer 2 data structure windows#
I think Ortham is entirely correct with his conclusion here and a new repository for these centralized masterlist localizations would be best.
A separate repository would be better because of that.
#Skyrim fnis mod organizer 2 data structure download#
We could put it in the LOOT repo, but the repo is relatively large and application development would cause LOOT to download those changes when checking for updates. Another approach would be to store the new file in the LOOT repository, to which replied on Discord:
Providing it via the different masterlist repositories would mean that we still would need to edit the same file for every supported game, so we wouldn't reduce the workload like this. One question would be of course from where this new file should be fetched. Everyone would also be able to see all messages and translations in one place, which would help with identifying which message is most applicable for the use case at hand. As it is now, some translations can be forgotten to be distributed to other masterlists, which has happaned in the past. Through this we only would need to add, remove or change translations within a single file, instead of pushing these additions, removals and changes to all the masterlists - which would reduce the workload significantly.Īdditional positive effects of this would be, that every masterlist would have access to every available translation. What I imagine would be that localization.yaml would include all the localized strings of the message anchors and localized strings of the globals sections, and these messages could then be referenced from within the masterlists. Let's call this new file localization.yaml for now (since it potentially could include localization data from the common and globals sections within the masterlists), the name could be changed to something different of course. Since the main problem is, that we need to add, remove or change the same data for multiple masterlists, I'd like to invent a system in which we centralize the localization data in one single file that is seperate of masterlist.yaml. If we were to add more masterlists to our catalogue, the workload on masterlist maintainers would further grow in this regard and it arguably would start getting in the way of managing the other parts that make the masterlists what they are. While doing this is (currently) still somewhat manageable, it already is a lot of work, work that needs to be done so that these messages don't start to differentiate between the masterlists. With other words, we currently need to add the new translation to 7 masterlist.yaml files, push the changes to the GitHub repositories of the different masterlists and finally merge them. If we want to add, remove or change a message anchor as a whole, or some specific translations within an existing message anchor, we need to perform this editing (up to) n times for n masterlists.Ĭurrently we maintain 8 masterlists, so if we were to add a new translation for &alreadyInX, it would need to be distributed to every masterlist except the one for Enderal (this one is currently the only one that doesn't feature &alreadyInX). While the above described system allows us to easily reuse the same messages within each individual masterlist, we still face a problem in the context of multiple masterlists. Here's a complete list of message anchors that can be found within the common section of the different masterlists.ĭynamicall圜reatedPlugin CreationClubPlugins LatestLOOTthread xxSE_Plugins_Requirements xxSE_NVAC xxSE_Required_Scripts The Problem It's precisely this aspect that I'd like to discuss, and I think that in theory we could reduce the workload for masterlist maintainers significantly, at least when it comes to the localized content within the masterlists.
This last point is something that we ideally should further improve, because even though it's a system that makes use of standardised messages that can be referenced through key words - and as such it already reduces repetitive and duplicate data - in the context of multiple masterlists it still means that we often need to distribute the same things multiple times to different places. The past has shown that maintaining a masterlist does not solely mean to add sorting rules and cleaning data, it also means verifying existing data, including the removal of invalid data if we come to such a conclusion, as well as maintaining translations of custom messages that can be found within the masterlists.
#Skyrim fnis mod organizer 2 data structure windows#
With the prospect of supporting potential further Bethesda games, as well as the potential support for the new Windows Store versions of existing Bethesda games, it is inherently clear that the number of supported games and as such, to be maintained masterlists could further grow.īecause of this, it becomes increasingly important to be as sufficient as possible in maintaining the masterlists. We currently maintain 8 different masterlists.
0 kommentar(er)
