Posted by: the bigg
« on: February 09, 2011, 04:35:24 AM »Moves (and copies) are uninstalled in the same order as they're performed, rather than in inverted order. This can lead to problems like this one.
MOVE ~try/file~ ~try/file3~
MOVE ~try/file3~ ~try/file2~
and I've noticed that, when you uninstall it, neither of the move actions is reverted, ie, I still have file2 in the try folder.I think that using AT_NOW and AT_UNINSTALL instead of the _EXIT options should not break [R]einstall, as the situation is completely re-established to the initial one before the new install takes place.--make-biff is not compatible with [R]einstall, if that's what you're asking.
I think some INTERACTIVE checks can be used to make SOS behave the old way for interactive installations, and how BWP wants for the BWP onesBTW, what happens in the following situation?
MOVE ~folder/file~ ~override~
the old file should be backed up.MOVE + is possible and going in. I'm just pointing out that, if SoS is moving + deleting files, then you shouldn't replicate that behavior blindly. In particular, the biffing routine used by SoS and the like breaks [R]einstall and wastes space and time in a BiG environment. You should take a look at what Lollorian's Trimpack does, but the better procedure for compatibility with [R]einstall and BiG:I think that using AT_NOW and AT_UNINSTALL instead of the _EXIT options should not break [R]einstall, as the situation is completely re-established to the initial one before the new install takes place.
- WED, BAM, MOS, BMP, TIS, WAV resources are (if necessary) decompressed in their source folder and then MOVEd in one (or more) appropriate directories, on which MAKE_BIFF is called. The files must remain in the temp directory for [R]einstall to work.
- The other resources (ITM, SPL, CRE, BCS, DLG, ARE, ...) are copied (compiled, appended) in the override, and then left there - no biffing, no moving, etc.
Sometimes, when trying to improve the solution of a problem, it is better not to reproduce the solution with an optimization, but rather take a step back, analyze the problem, and implement an entirely different solution.Well, the problem was somewhere else (the AT_UNINSTALL was in an action_if controlled by a variable), and it works now. Anyway, I would prefer to have MOVE + for some parts of that mod, if it's possible. Thanks
Yes, I can make MOVE +, but that's a "don't use this feature without a real reason". That said, the standard syntax for passing a list of strings is U_O ~MOVE~ ~STRSET~ ~COPY~ ~AT~.thanks. Is it possible to write an example such as this one in the WeiDU documentation, to make it clearer?