WeiDU 200 will not be downgrade happy, ...suggest your fix! Options

[The Bigg]

I've modified the backup system in WeiDU 200, to allow backups of multiple files with the same base name (previously, if you held a backup of E.G. override/baldur.gam and Save/path/baldur.gam, only the former would be restored, resulting in potential problems). Unfortunately, I haven't seen a way to have the system be 100% compatible in case somebody wants to downgrade his WeiDU version (more on the technicalities later). Since I know that some modders on this board insist on using WeiDU 185 and suggesting people to downgrade their versions, I hope to collect ideas on how to fix the situation without stirring excessive trouble.

The only way to cause problems is if user installs a mod using WeiDU >=200 and then uninstalls it using WeiDU < 200. Mixing the versions is always safe during install, and uninstalling a <200 mod using a >=200 mod is safe.

These are the ways to solve the situation I can see:

• I do some further homework and recode this to allow safe mixage. Pro: modders won't have to do a thing, the best of both worlds. Con: I need to think a way to implement this.
  Obviously, this'd be the best idea if I can do this.
• I drop the idea altogether. Pro: modders won't have to do a thing. Con: my personal pride
• I develop a special version of WeiDU 185 that doesn't cause problems. Pro: easy for users, and modders will still be safe from bad ideas. Con: if you have a personal grudge against me, this is not a solution.
• I write a program to make backups 185-compatible. Pro: might be easier to accept for people who dislike me. Con: hard for users.
• Modders not requiring WeiDU 185 for their installs. Pro: users won't have to worry about complicate downgrade routines. Con: if you have a grudge against me, this is obviously not a solution.

Now, the algorithms (PM if you want to read the code), in case you want to brainstorm a better backup algorithm:

WeiDU <200:

{BACKUP}/UNINSTALL.X contains the list of modified files.
When copying override/sw1h01.itm: add "override/sw1h01.itm" to UNINSTALL.X, copy old override/sw1h01.itm (if existing) to {BACKUP}/sw1h01.itm.
When copying temp/sw1h01.itm: add "temp/sw1h01.itm" to UNINSTALL.X, don't keep a backup because {BACKUP}/sw1h01.itm already exists.

When restoring:
read override/sw1h01.itm in UNINSTALL.X, delete override/sw1h01.itm, move {BACKUP}/sw1h01.itm to override.
read temp/sw1h01.itm in UNINSTALL.X, delete temp/sw1h01.itm and do not restore the copy (which wasn't saved).

WeiDU >=200:

{BACKUP}/UNINSTALL_NEW.X contains the list of modified files.
When copying override/sw1h01.itm: add "override/sw1h01.itm" to UNINSTALL_NEW.X, copy old override/sw1h01.itm (if existing) to {BACKUP}/override.sw1h01.itm.
When copying temp/sw1h01.itm: add "temp/sw1h01.itm" to UNINSTALL_NEW.X, copy old temp/sw1h01.itm (if existing) to {BACKUP}/temp.sw1h01.itm.

When restoring:
read override/sw1h01.itm in UNINSTALL_NEW.X, delete override/sw1h01.itm, move {BACKUP}/override.sw1h01.itm to override.
read temp/sw1h01.itm in UNINSTALL_NEW.X, delete temp/sw1h01.itm and move {BACKUP}/temp.sw1h01.itm to temp.

If you can see a way to edit the WeiDU >=200 algorithm so that the WeiDU <200 restoring algorithm still works, this'd be really helpful.

[Baronius]

I suppose that the problematic scenario can only happen e.g. when someone installs a Weidu-200 mod, downgrades to v185 (e.g. due to IA), and then tries to uninstall the Weidu-200 mod.

I think Option 1 would be the best.

If you can't implement it, a specially combined Option 1 + 4 might do as well. I don't know WeiDU's backup system, but here are some very quick ideas (if I correctly interpret the problem you've described):

The question is, how to distribute the required responsibilities (WeiDU 185, or the program). Two options are possible: program does everything, or WeiDU 185 participates as well.

The first step of the latter option is probably very easy, i.e. implementing a structure that both 200 and 185-compatible versions understand (I guess this is already done). WeiDU 185 would identify them as different files (different filenames), while 200 would know their common filename and different restore paths (if I've understood correctly the novelty of 200 in this). This ensures that 185 restores the files to their correct locations, but with invalid filenames. The second step is to rename these files, this is what 185 can't do (or the whole procedure wouldn't be needed). At this point, an (otherwise open-source, e.g. C/C++) program could find the files to be renamed (especially if W. 200 -- because installation of that mod was W. 200 -- left some index file there that 185 doesn't uninstall).

The other option is delegating all responsibility to the open-source program (it would have to be used instead of W. 185 to uninstall -- this is required because we assume that players don't have 200 in their folder after a complete "downgrade", otherwise it's quite uncomfortable). However, this would make its size much bigger, and development time much longer (it would need to know all about uninstalling W. 200 mods). So this latter "solution" isn't really good, as the additional program's main advantage would be its small size and easy comprehension of its functionality.


Another major possibility can be a special W. 200 (so you don't have to make a brand-new program with WeiDU functionalities), which would act as an uninstaller for mods. (Just uninstaller, not installer!) It would have to be used to uninstall any WeiDU mods. I would always welcome a central program (no need to have a GUI, console is perfect -- it can be a W. 200 itself) which lists the installed WeiDU mods, and maybe through additional menus, I can select which to uninstall. (In this way, players with "downgraded" executables would only have one W. 200 in the folder which would be responsible for uninstallation. And the incompatible Backup structures could be made in a way to cause a fatal error for W. 185 so corrupt uninstall can be avoided.) This would be very good because those who may insist on v185 do it because of installation, not uninstallation. You could say, of course, that then players could just "upgrade" again to v200 when uninstalling, but this isn't comfortable at all.

I'm sure you can come up with a better and more elegant solution, as you know WeiDU very well.