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:

WeiDU >=200:


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.

Option 2 (or Option 1 if you really want to spend the time). At this point, there just isn't any good cause for breaking backwards compatibility. For better or worse, WeiDU is what it is, and without any foundational improvement, there just doesn't seem to be any benefit here.

The easiest solution is to wrap the new backup hierarchy inside an old-world backup hierarchy (you maintain a backup structure WeiDU v185 expects and also have the WeiDU v200 backup in the same "numbered" directory as the old-world backup). I don't know anything about how WeiDU is handling backups to know if this would work, and you'd have to take care to synchronize the two (you don't want the user uninstalling with v185 and then uninstalling again with v200), but this is a fairly typical stone to throw at the backwards compatibility albatross.

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.

I'm not a programmer, but maybe you can follow my idea and see if it is implementable.
Somehow read the file and save it's relative location to the weidu exe file. So that when the mod in question is uninstalled it will repair modified files in their original relative location.

Example modifying a save file:
COPY ~save/000000-Game_Save/baldur.gam~ ~save/000000-Game_Save~
DOWHATEVERPATCHES
BUT_ONLY_IF_IT_CHANGES

Weidu will save {BACKUP}/{PATH}baldur.gam
When mod is uninstalled weidu would replace {BACKUP}/{PATH}baldur.gam where in this example save/000000-Game_Save/ = {PATH}

I know that the path information is already gathered by weidu as SOURCE_DIRECTORY so why can't that information be applied to weidu's backup and restoration methods

By default the path variable would be empty. During uninstall Weidu 200 would look for the saved path info and if it's not found would uninstall with the 199 and less method because {backup}/{path}file.ext with an empty path variable is the same as {backup}/file.ext.

I think I'm clear as mud, but once again I'm not really a programmer (at least not by trade or education).

Because <200 doesn't do this, and I can't alter the <200 algorithm.

I can try to mix the two systems and use `basename x` for the first file x, and `echo x | sed -e's,/\\\\,,g'` for further files named x. This could cause breakage in really obscure situations, though. But then, I believe this was going to cause breakage even when doing a clear <200 install/<200 uninstall, so this'd be a moot point.

I can't say offhand, so I'll have to hack a bit and test various cases to see if this causes anything to act differently - but then, I'm sure that the given situation isn't going to happen, unless for mods using destructive biffing techniques, and it is probably possible that even then I can tiptoe around troubles and avoid differences. Will tell more later today or tomorrow.

EDIT: the dir1/file.ext and dir2/file.ext situation was causing breakage in WeiDU <200 (basically, installing and uninstalling a mod in the given situation would move a file and remove the others) and is difficult to reproduce without ad-hoc code, so I'm going to ignore eventual troubles in the downgrade path in this situation (which, I stress, is not going to happen, save for ad hoc code). Downgrade-happiness for "sane" mods is going to be granted, of course.

Actually, IA is not a good example here as it doesn't really require players to downgrade their version of WieDu installer. The version of WeiDu in IA's download package is v185, but it can also be installed just fine with newer versions of WeiDu. The only difference is that using (some of) the newer versions, some false reports of nonexistent typos may be displayed during installation, but they are not important (because the typos don't actually exist) and the installation will be accomplished just fine. See this topic as well. Downgrading is not necessary.

I saw you suggesting users to downgrade in the linking thread, so I misunderstood that as a "strong suggestion" or "requirement" rather than a "nudge". I've edited the post to reference NeJ2.
EDIT: oops, I thought that was directed at me.

BTW: the warnings are suppressed in WeiDU 199

Sikret: Thank you for the clarification. I had thought that downgrading was recommended (but that also means I made a mistake when I implied it was necessary) because otherwise mods with newer WeiDU versions will replace IA's installer with the new executable -- but as you've said, this isn't a problem eventually.