With the removal of the symlink used by the old launcher, the local filter editing process has gotten...much more involved. Requiring either a re-copy of the filter via the launcher with each edit or editing of the main loot.filter and remembering to copy it into the local folder before the next run (lest the edited loot.filter be overwritten).
The idea behind this change is to load the launcher-selected filter directly, falling back to the current behavior of the root loot.filter then default.filter files in the events the launcher config can't be loaded or the expected filter doesn't exist.
A couple notes:
This does depend on the launcher config staying in the same place it's at now, with the same setting names. With it being as young as it is, I get that this may be subject to change.
I also wasn't sure if this made more sense to be left in BH where the current loading is, or put into Config where...well...the config stuff is.
If a launcher-selected filter loads properly on launch and the launcher config is then ruined in some way, reloading will continue to use the same filter file instead of immediately falling back, assuming it's still valid. I'm on the fence as to whether or not this is intuitive behavior.
fergushev
commented
2 weeks ago
With the removal of the symlink used by the old launcher, the local filter editing process has gotten...much more involved. Requiring either a re-copy of the filter via the launcher with each edit or editing of the main
loot.filterand remembering to copy it into the local folder before the next run (lest the editedloot.filterbe overwritten).The idea behind this change is to load the launcher-selected filter directly, falling back to the current behavior of the root
loot.filterthendefault.filterfiles in the events the launcher config can't be loaded or the expected filter doesn't exist.A couple notes:
BHwhere the current loading is, or put intoConfigwhere...well...the config stuff is.