This request is the result of the combination of several things happened at once. Let me start with the idea that 'mod data folder' and 'mod backup folder' are two completely different things. And IMHO, WeiDU should threat them internaly as two separate things.
design-A)
BACKUP ~MyMod\backup~
design-B)
BACKUP ~weidu_external\backup\MyMod~
1. Most mods uses design-A for the value of BACKUP keyword. But some mods are using 'immutable' mod design-B with workaround. First, set the backup outside of 'mod data folder' via 'BACKUP' keyword. But it also sets MOD_FOLDER variable thi the value of it, so they need to overwrite MOD_FOLDER variable back to proper 'mod data folder'. This has no consequences when installing such mod but it has when mod manager try to detect ''mod data folder'.
2. While WeiDU provide way to get proper 'mod data folder' by using --debug-assign (or future supported version of it), when the mod BACKUP keyword has design-A (MOD_FOLDER will be set to 'MyMod'), it doesn't work for the design-B (MOD_FOLDER will be set to 'weidu_external').
My request would be:
- ability to set 'MOD_FOLDER' along with "BACKUP"
BACKUP ~weidu_external\backup\MyMod~
MOD_FOLDER ~MyMod~
BEGIN "MyMod"
and make it so WeiDU will handle backup path from 'BACKUP' keyword and if MOD_FOLDER keyword exist, set MOD_FOLDER variable to the value of this keyword. This should handle compatibility with older mods and allow new mods to use this feature. Lastly, --debug-assign (or future supported version of it) will output both values into two separated variables even if they match.
This would allow to have clear 'immutable' mod design without hacks around the fact that WeiDU currently has one variable for 'mod data folder' and 'mod backup folder'. Plus, I get the proper values for both of them.
Alternative would be:
Introduce another variable, let's call it 'BACKUP' for --debug-assign (or future supported version of it), where WeiDU will put raw value of 'BACKUP' keyword, without touching it. So I could get it when I'm launching WeiDU and then deal with weidu_external-thing.
Q: Why PI simply doesn't load tp2-file and extract the full value of BACKUP keyword?
A: It was at the begging. No matter how fast tp2 scanning is (not possible to use something like yeld return), the reality of having to scan 100+ mods makes this approach impossible for mod manager: people put crazy things into their tp2, some tp2 are huge and there are some tp2 which aren't mods at all. Launching WeiDU and getting the keyword values is the fastest and most error-safe way.