Toma400
commented
7 months ago Interesting issue coming with MLO that "searches" for its position after new mod is added. Imagine we have four mods:
- A (11 December 2022)
- B (13 December 2022)
- C (18 December 2022)
- D (30 December 2022)We then proceed to add E from 22nd December 2023. If A/B/C/D remains intact, it's all good - algorithm could check D, go up, then check C and find itself between C or D. But, what if we change order of mods? Going the same way, it will not be able to determine if proper range is in place where it tries to add itself, based only on position above and below:
- A (11 December 2022)
- D (30 December 2022) <-- meanwhile this is its proper position --\
- C (18 December 2022) |
- B (13 December 2022) <-- checks here, thinks it's older, ergo it should be put last --/Going from above (so scanning from A to D, not from D to A) is a bit better, but then we still have question "what if we have 100 mods and this new one is added >>randomly<< somewhere". Putting new mods at the end seems like good solution conceptually, but in the same time, makes it very much prone to errors. Making it work only after initial set is made is also a bit bad, because you can put one mod there, and basically all newly added mods after initial one would need to be positioned manually, which is also no bueno.
For now I'm leaning towards "go from upper position and find first position where it fits", but I think it could also be somehow shown as "new mod", like have exclamation mark or something to indicate "hey, here is your new mod", so you can see if its MLO position is proper without much browsing.
In general though, indicators of new or disabled mods should be different, and ideally not ASCII-based (but this is probably more related to custom GUIs, so not doable at the moment)
Currently, MLO works in simple way:
This makes packs structure alphabetically, and then ordered alphabetically again with each new added packs. This, however, makes MLO a bit useless for structuring it correctly and all ordering correctness is set on user.
There was idea of making it set on modder by manually putting "dependency number", but this had number of issues to be honest.
What I'd suggest though, is different approach, again inspired by Morrowind: sorting by date of changes. This makes all dependent files naturally come after its dependency, unless older version is used. In most cases though, it'd do a better job than current (brainless) algorithm. So, to sum it in points:
In short, MLO should not overwrite order everytime, because this would make horror out of manual changes done by user - it should try to keep all existing mods intact, and focus on the ones that are not existing, putting it either at the end of queue, or more logically, wherever it fits best. But, if someone updates mods, they could try reshuffling themselves at one point - there is some reasoning behind it. There's however one argument against it, which is "what about hypothetical not-updated dependent mod". On example:
Some workaround if you'd like to keep both options is button that would "reshuffle" specific mod after its initial phase. So it'd keep its position after update, but you can force it to adjust if you really need to. There's a question however what are use cases for such autoshuffling in general.
Myself, I suggest sticking to "not shuffling" unless very important matter appears in favour of shuffling.
* shuffling in this case means reordering, I just find this word more interesting to use and less confusing in terms that reordering sounds like doing ordering of all packs, not one specific