Jump to content

Tannin

Members
  • Posts

    5
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Tannin's Achievements

Clanfriend

Clanfriend (1/10)

1

Reputation

  1. A version control system is practically a necessity because it allows multiple people to work on the masterlist at the same time, no matter how long they work in isolation. That means you can fork the masterlist, add rules, make your own tests and when you're done, commit the changes to the official repo. Even if your testing takes a week. With a spreadsheet you'd essentially have to "lock" the file throughout your tests so everyone else would have to wait - or you would have a terrible time merging your changes into a sheet that has been changed by others while you were working on your copy. git isn't really complex, it's just intimidating. Once you realize how much of your workflow it makes easier or safer you won't want to miss it. Btw., just for clarification: The person you answered to is "WrinklyNinja", the main developer of LOOT. "Initiate" is just his rank in this forum.
  2. I can obviously not speak for the developer of LOOT, I can just give you my opinion: a) imho YAML is a good choice. Compared to json it's very readable to non-techies and it requires less escaping for special characters. One can argue over whether YAML or JSON is harder to break - yaml depends on indentation, json will break if you miss a comma anywhere or have one too many - either way you will want a validator to ensure the file is valid before it gets committed. The INI format is not simple, it's very deceptive. There is no standard for ini and different parsers may treat files differently in regards to stuff like character encoding, multi-line entries, comments and so on. The perception that ini is simple is very problematic. BethINI for example, a tool for configuring fallout and TES games technically corrupts the ini files for some games it configures because its ini file library treats multi line entries different than the game. 99.9% of the times users will not notice because the entries it corrupts are irrelevant but that's luck more than anything. b) github gives you free file hosting, version control repositories supporting thinks like branching and everything, all of which makes the service more powerful (e.g. when LOOT changes its masterlist format it can host them for the old format in one branch, new format in another without breaking anything). There aren't that many services that do that. Compared to other version control services github is super easy, so the alternatives are either a way more complicated service or a way less powerful one. Besides: It's not like users have to use git to propose changes to the masterlist, if you're scared of git, you can just post a message in the issue tracker and someone more comfortable with it can add it. c) What will happen when: mod C needs to be placed after mod B, mod B must be placed after mod A, mod A must be placed after mod C This can never happen. It's possible to set up (user) rules for such a cycle but LOOT will refuse to sort in its presence but you will never have a situation where it has to be set up like that. The end result always has to be a sorted, one dimensional list, no matter how you do your load ordering. A cycle would mean that the same plugin needs to be in multiple places at once. d) Let's assume that the same mod can be installed into 5 games It's very rare that one mod (with plugins no less) can be installed in multiple games, I'm not aware of any case where a plugin works with more than two games. And then you will always want separate load orders per game. It's true: There is a good chance that if you have two mods that need to be loaded in a certain order they need to be loaded in that same order across all supported games but the effort to account for that is not worth it.
  3. Going by that logic: How often has Wrye Bash been abandoned now? MO is open-source, as is MO2. To my knowledge active development is currently only happening on MO2 but since that should work with all games (if the bugs are fixed) there is little incentive to develop MO separately.
  4. Sorry to raise an old topic but I just came across this and wanted to drop to clear this up: What's breaking MO isn't actually the VRAM fix MS did, they also changed some other stuff in filesystem-related APIs and that's breaking MO. It's not too hard to fix so I wouldn't bet on MO being dead. The fix isn't coming from me though. MO2 isn't affected because it's hooking into lower level APIs that weren't changed. Vortex isn't affected because it's not hooking anything but uses OS functionality.
×
×
  • Create New...