Post reply

Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic.
Name:
Email:
Subject:
Message icon:

Verification:
Type the letters shown in the picture
Listen to the letters / Request another image

Type the letters shown in the picture:
What color is grass?:
What is the seventh word in this sentence?:
What is five minus two (use the full word)?:

shortcuts: hit alt+s to submit/post or alt+p to preview


Topic Summary

Posted by: K4thos
« on: October 20, 2014, 02:12:11 PM »

editing MOVE.0 is no longer in the code. That was a workaround for the issue mentioned in this topic that in the end turned out to be a bug in code, not weidu issue. I've now rewritten all the bits of old SoBH code that did the weird stuff like backuping and deleting whole override folder, doing things with bat files etc., so it now works as it should without any workarounds. The uninstallation procedure proved to work as expected.

Thanks Imp and Wisp for taking the time on this matter.
Posted by: The Imp
« on: October 20, 2014, 02:05:06 PM »

Does that include screwing with the backup data?
If I followed K4thos line of thinking, using the code your supplied, there's no need to break a thing cause he fixed the breaking part of his own code, well technically it wasn't his either, but old SoBH code rearing it's zombie head.
Posted by: Wisp
« on: October 20, 2014, 12:15:54 PM »

in the end everything can be done with the current uninstallation system.
Does that include screwing with the backup data? Because that is not part of the current uninstallation system.

In the event it is not immediately obvious to everyone: Do not do this.. It will, one day, result in your mod not being uninstallable.
Posted by: K4thos
« on: October 19, 2014, 05:15:32 PM »

After failing to reproduce the problem with that sample code you provided Wisp, I reviewed the whole code again and found a leftover from the old SoBH code that I somehow missed, which conflicted with my move/copy operations. I'm sorry for everyone's time that I wasted with this :-[ The request for pre difined actions on uninstall is no longer valid, because in the end everything can be done with the current uninstallation system.
Posted by: Wisp
« on: October 19, 2014, 01:40:51 PM »

this way the mod can be uninstalled, but files moved from the override dir to BH-TIS1, BH-TIS2, BH-REST will end up in override folder after the mod is uninstalled. If I add + to MOVE commands the mod will fail to uninstall.
I can't reproduce the first problem. This:
Code: [Select]
MKDIR ~test/foo~

LAF HANDLE_AUDIO END
LAF HANDLE_TILESETS END

MOVE ~override/audio.wav~ ~test/foo~
MOVE ~override/tileset.tis~ ~test/foo~

MAKE_BIFF fl#test BEGIN ~test/foo~ ~.+~ END
works and only leaves the directory ~test/foo~ upon uninstallation, which is as expected. If the files are moved with no backup that does fail the uninstallation, but that's also as expected (well, the failure is arguable; I'll consider having WeiDU handle missing files with more grace) because you are doing something stupid. Note the "do not use" on optNoBackup. That means it is possible to do stupid things with it ("do not use" is not to be taken literally, but it does mean the action is potentially unsafe; and moving a file without backup which was moved to where is was by another MOVE is unsafe and expected to blow up).
Posted by: Wisp
« on: October 19, 2014, 01:23:22 PM »

edit: btw. is there a reason why we can't delete whole directories with DELETE command? Would be usefull in some cases.
The backup system can't handle directories. I don't know if there is something in its design that prevents it from handling directories, or if it might be possible to add that capability.

2. First of all I'm copying all the files to override in order to make a backup copies of files with conflicting names.
3. Then I'm using HANDLE_TILSETS and HANDLE_AUDIO to extract these resources to override.
Step 2 is redundant. HANDLE_* already does that.

this way the mod can be uninstalled, but files moved from the override dir to BH-TIS1, BH-TIS2, BH-REST will end up in override folder after the mod is uninstalled.
So a trivial change to HANDLE_AUDIO and HANDLE_TILESETS (specify output directory) would make your life easier? Then that's the thing to ask for, not these... other things. The two functions also use a redundant MOVE, which I can optimise away for 238. MOVE sometimes behaves oddly, which is probably the source of some of your problems (and it sounds like there is at least one bug in there).
Posted by: The Imp
« on: October 19, 2014, 06:49:09 AM »

Code: [Select]
MOVE ~override/%BASH_FOR_FILE%~ ~generalized_biffing/prod/0/biffs/%currentFile%/%BASH_FOR_FILE%~still doesn't change anything :P
The case here should be that those files need to be placed back there as it allows the previously installed and next to be uninstalled component then to remove them during it's uninstall process. This is how the chain auto uninstall has always happened and it ensures that the process is clean. So it makes sure that the uninstall only removes the files that are not needed there anymore. '*
'a totally clean install of the game is easier to get by deleting all the mod folders, added .bif files and overwriting a few files backup'ed at the start of the Auto-install as the BWS does it. Not uninstalling mods. It's by far faster too. The actual size of the backup is ~150MB's.

*Also when the MAKE_BIF is used inside the weidu 's .tp2 file, the process doesn't need to wait for the uninstall .bat file to complete and as the restored files are in the override folder before the uninstall of the previously installed component gets started, which allows their removal on it's uninstall. This was always the problem with the old type of uninstalling of bif'ed mods. Or so I assume from what I have read. I could be totally off my rocket, though here.
Posted by: K4thos
« on: October 19, 2014, 06:27:18 AM »

Quote
Erhm, I am waiting for Wisp to give his reply, but did you notice that the "rej" folder is for files that were REJECTED from being biffed in the first place ? The files that have either too long file names, as the game can't handle files that have a more than the 8 characters +.extension .  And files that are not supposed to be .bif'ed cause they can't, example being .txt file some one though was good idea to put into the override folder.
You are right, I should have posted this part of code:
Code: [Select]
MOVE ~override/%BASH_FOR_FILE%~ ~generalized_biffing/prod/0/biffs/%currentFile%/%BASH_FOR_FILE%~still doesn't change anything :P

Quote
Well there's two sides on this;
1) If you install the mod as an add on, you probably don't want to be asked if you wish to bif the files as it's usually yes answer anyways.
2) If you are auto installing, there are arguments that can be made that separately biffing content is time consuming and doing it at the very end is more time considerate as the user can be asleep while all of it is been done, while not needing to watch the files that are critical of importance.
3) The crazy people that can't count up to just two.
Fair enough. I agree with these arguments. Biffing will be optional.
Posted by: The Imp
« on: October 19, 2014, 05:33:18 AM »

MOVE ~override/%BASH_FOR_FILE%~ ~generalized_biffing/prod/0/rej/%BASH_FOR_FILE%~
Erhm, I am waiting for Wisp to give his reply to my biffing question... I some how assume the answer is the evil "yeah". :P "Duh" would be even better. But I don't think he is not that evil. (Wisp is a reeaally good guy.)
But while we are at this: Did you notice that the "rej" folder is for files that were REJECTED from being biffed in the first place ? The files that have either too long file names, as the game can't handle files that have a more than the 8 characters +.extension .  And files that are not supposed to be .bif'ed cause they can't, example being .txt file some one though was good idea to put into the override folder.

As for making the biffing optional, sure I could add it (with just adding BEGIN before the biffing code - it is at the end of the file and all files are in override dir before they are moved outside), but I don't see a reason for this even if you are planning to use general biffing at the end.
Well there's two sides on this;
1) If you install the mod as an add on, you probably don't want to be asked if you wish to bif the files as it's usually yes answer anyways.
2) If you are auto installing, there are strong arguments that can be made that separately biffing content is time consuming and doing it at the very end is more time considerate as the user can be asleep while all of it is been done, while not needing to watch the files that are critical of importance.
3) The crazy people that can't count up to just two.
Posted by: K4thos
« on: October 18, 2014, 08:11:07 PM »

Quote
Erhm, the MAKE_BIF command that the generalized biffing uses, it doesn't move the files back, but just restores the file structure during the biffing.
This is not what I meant, sorry for my bad spelling skills. When I said "files going back to override directory after uninstalling the mod" I meant this code:
Code: [Select]
MOVE ~override/%BASH_FOR_FILE%~ ~generalized_biffing/prod/0/rej/%BASH_FOR_FILE%~is telling weidu to move files from "generalized_biffing/prod/0/rej/" back to override when the mod is uninstalled. And this what it is supposed to do. But in the case I've described above files moved to directory outside of override should not go back to override when uninstalling the mod. And adding "+" to MOVE command breaks the uninstallation process.

As mentioned in the last post I've managed to fix it using REPLACE_TEXTUALLY on "MOVE.0" backup info file, but I'd like to handle it differently if it is possible, because it is not a pretty workaround. Here is the current (working) code from SoBH that will be implemented in v2.75d update unless someone will help me improve it:
Code: [Select]
MKDIR ~Bonehill/temp/BH-TIS1~
~Bonehill/temp/BH-TIS2~
~Bonehill/temp/BH-REST~

ACTION_FOR_EACH file IN "BH0100" "BH0200" "BH0300" "BH0302" "BH0400" "BH0401" "BH0402" "BH0403" "BH0500" "BH0507" "BH0600" "BH0700" "BH1000" "BH1004" "BH1100" "BH1101" "BH1200" BEGIN
MOVE ~override/%file%.tis~ ~Bonehill/temp/BH-TIS1~
COPY + ~Bonehill/backup/0/MOVE.0~ ~Bonehill/backup/0~
REPLACE_TEXTUALLY ~^.*Bonehill.temp.BH-TIS1.%file%.tis$~ ~~
END

ACTION_FOR_EACH file IN "BH1300" "BH2000" "BH2001" "BH2002" "BH2005" "BH2006" "BH2008" "BH2010" "BH2012" "BH2018" "BH2019" "BH2020" "BH2021" "BH2022" "BH2025" "BH2100" "BH2101" "BH2102" "BH2103" "BH2104" "BH2105" "BH2106" "BH2107" "BH2108" "BH2109" "BH2110" "BH2111" "BH2200" "BH2201" "BH2202" "BH2301" BEGIN
MOVE ~override/%file%.tis~ ~Bonehill/temp/BH-TIS2~
COPY + ~Bonehill/backup/0/MOVE.0~ ~Bonehill/backup/0~
REPLACE_TEXTUALLY ~^.*Bonehill.temp.BH-TIS2.%file%.tis$~ ~~
END

ACTION_FOR_EACH file IN "AM9100E1" "AM9100E2" "AM9100E3" "AM9100E4" "AM9100E5" "AM9100E6" "AM9100E7" "AM9103B" "AM9103C" "AM9105B" "AM9400F1" "AM9400F2" "AM9400F3" "AM9400F4" "AM9400F5" "AM9400F6" "AM9400F7" "AM9700A" "AM9700B" "AM9711D" "AM9712B" "AM9712C" "AM_1003" "AM_1007" "AM_1008" "AM_1008A" "AM_1011" "AM_1016" "AM_2000A" "AM_2002" "AM_2103" "AM_4001" "AM_5203A" "AM_9101" "AM_9102" "AM_9103" "AM_9104" "AM_9104A" "AM_9108" "AM_9301" "AM_9400" "AM_WSP01" "AM_WSP02" "AM_WSP03" "AM_WSP04" "AM_WSP05" "AM_WSP11" "AM_WSP13" "AMB_E04A" "AMB_E04B" "AMB_E05B" "AMB_E05D" "AMB_E05E" "AMB_E05F" "AMB_E05G" "AMB_E05H" "AMB_E06A" "AMB_E06B" "AMB_E06C" "AMB_E08A" "AMB_E08B" "AMB_E14A" "AMB_E14B" "AMB_E15A" "AMB_E15B" "AMB_E15C" "AMB_E15D" "AMB_E17A" "AMB_E17B" "AMB_E24" "AMB_E25" "AMB_E29A" "AMB_E40A" "AMB_E40C" "AMB_M01C" "AMB_M03B" "AMB_M16X" "AMB_M26A" "AMB_M26G" "AMB_M26K" "AMB_M28A" "AMB_M35D" "DIRELUTE" "FABIO0" "FABIO1" "FABIO10" "fabio11" "fabio12" "fabio13" "fabio15" "fabio16" "fabio18" "fabio19" "FABIO2" "fabio20" "FABIO3" "FABIO4" "fabio5" "fabio6" "fabio7" "fabio8" "fabio9" "fabio=" "fabio_" "fabioa" "Fabiob" "fabioc" "fabiod" "fabioe" "fabiof" "fabiog" "fabioh" "fabioi" "fabioj" "fabiok" "fabiol" "fabiom" "fabion" "FABIOnBF" "FABIOnG" "FABIOnG1" "FABIOnI" "FABIOnM" "FABIOnM1" "FABIOnSh" "FABIOnV" "FABIOnZ" "fabioo" "fabiop" "fabioq" "fabior" "fabios" "fabiot" "fabiou" "fabiov" "fabiow" "fabiox" "fabioy" "fabioz" "Ign01" "Ign02" "Ign03" "Ign04" "Ign05" "Ign06" "Ign07" "Ign08" "Ign09" "Ign10" "Ign11" "Ign12" "Ign13" "Ign14" "Ign15" "Ign16" "Ign17" "Ign18" "Ign19" "Ign20" "Ign21" "Ign22" "Ign23" "Ign24" "Ign25" "Ign26" "Ign27" "Ign28" "Ign29" "Ign30" "Ign31" "Ign32" "Ign33" "Ign34" "Ign35" "Ign36" "Ign37" "Ign38" "Ign39" "Ign40" "SS_4005A" "SS_4005B" "SS_4005C" "SS_4005D" "SS_4005E" "SS_4005F" "SS_4005G" "SS_4005H" "SS_4005I" "SS_4005J" "SS_4005K" "SS_4005L" BEGIN
MOVE ~override/%file%.wav~ ~Bonehill/temp/BH-REST~
COPY + ~Bonehill/backup/0/MOVE.0~ ~Bonehill/backup/0~
REPLACE_TEXTUALLY ~^.*Bonehill.temp.BH-REST.%file%.wav$~ ~~
END

ACTION_FOR_EACH dir IN "areas" "bam" "bmp" BEGIN
ACTION_BASH_FOR ~Bonehill/base/%dir%~ ~^.+~ BEGIN
MOVE ~override/%BASH_FOR_FILE%~ ~Bonehill/temp/BH-REST~
COPY + ~Bonehill/backup/0/MOVE.0~ ~Bonehill/backup/0~
REPLACE_TEXTUALLY ~^.*Bonehill.temp.BH-REST.%BASH_FOR_FILE%$~ ~~
END
END

MAKE_BIFF ~BH-TIS1~ BEGIN ~Bonehill/temp/BH-TIS1~ ~^.*$~ END
MAKE_BIFF ~BH-TIS2~ BEGIN ~Bonehill/temp/BH-TIS2~ ~^.*$~ END
MAKE_BIFF ~BH-REST~ BEGIN ~Bonehill/temp/BH-REST~ ~^.*$~ END

ACTION_FOR_EACH dir IN "BH-TIS1" "BH-TIS2" "BH-REST" BEGIN
ACTION_BASH_FOR ~Bonehill/temp/%dir%~ ~^.+~ BEGIN
DELETE + ~%BASH_FOR_FILESPEC%~
END
END

Quote
The restoration happens before the other parts of the mod get uninstalled, if there are, so there won't be any trace of the operation left... if you use this code too in the biffing component:
Code: [Select]
ACTION_IF ~%WEIDU_OS%~ STRING_COMPARE_CASE ~WIN32~ THEN BEGIN
AT_UNINSTALL ~rm -rf generalized_biffing/prod/0~
END ELSE BEGIN
AT_UNINSTALL ~del /q /f generalized_biffing\prod\0~ EXACT
END
The problem I've described will still be present if I use it. It is literally external version of this code:
Code: [Select]
ACTION_FOR_EACH dir IN "BH-TIS1" "BH-TIS2" "BH-REST" BEGIN
ACTION_BASH_FOR ~Bonehill/temp/%dir%~ ~^.+~ BEGIN
DELETE + ~%BASH_FOR_FILESPEC%~
END
END
As for making the biffing optional, sure I could add it (with just adding BEGIN before the biffing code - it is at the end of the file and all files are in override dir before they are moved outside), but I don't see a reason for this even if you are planning to use general biffing at the end. These 3 biff archives will contain 300 MB of data that will not be modified by other mods. As you can see ITM, SPL, CRE, ARE, BCS, DLG, EFF files are not biffed.

btw. this update for SoBH will also add OSX support, EE engine compatybility (if Beamdog decides to fix worldmap icons palette issues in BG1:EE), EET compatybility on BG2:EE, fix many bugs, cleaned tp2 code, introduce cmpvars libraries instead of doubling files and some other minor stuff.
Posted by: The Imp
« on: October 18, 2014, 05:35:42 PM »

edit2: well, it looks like that code will not help to solve this matter because it works similarly (with additional stuff to automatically generate biffs based on file sizes etc.). In GeneralizedBiffing the problem I mentioned with files going back to override directory after uninstalling the mod is what is desired. And in my case these files should not be moved back to override.
Erhm, the MAKE_BIF command that the generalized biffing uses, it doesn't move the files back, but just restores the file structure during the biffing. This also means that if you separate the biffing to it's own component as you probably should, as there are people that do not want to do it ! WAVE, hey I am here.
The restoration happens before the other parts of the mod get uninstalled, if there are, so there won't be any trace of the operation left... if you use this code too in the biffing component:
Code: [Select]
ACTION_IF ~%WEIDU_OS%~ STRING_COMPARE_CASE ~WIN32~ THEN BEGIN
AT_UNINSTALL ~rm -rf generalized_biffing/prod/0~
END ELSE BEGIN
AT_UNINSTALL ~del /q /f generalized_biffing\prod\0~ EXACT
END
As that deletes folders above the one the biffing component uses to make stuff to be in folders(which includes the uninstalled and thus restored biffed stuff). You also notice that the biffing size line is there just to restrict adding more than a selected amount of files to a folder which then is biffed with MAKE_BIF, then the process will make a new folder and add stuff there until it's full and so on and of until all files are in those folders and made to bif's.

Note that you have to of course use a different folder than "generalized_biffing/prod/0" to do the biffing in. Duh... and name it in the command...
Posted by: K4thos
« on: October 18, 2014, 02:10:42 PM »

I've just read my previous post again and it's confusing even for me ;D English is not my first language.

I will post a code to show where the problem lay, using modified Bonehill as an example:
1. I'd like to create 3 biff files with Bonehill resources that won't be edited by other mods (so things like ARE, CRE, ITM, etc. won't be biffed).
2. First of all I'm copying all the files to override in order to make a backup copies of files with conflicting names.
3. Then I'm using HANDLE_TILSETS and HANDLE_AUDIO to extract these resources to override.
4. And then I'm trying to biff some resources added by this mod. Things unpacked with external tools are moved with ACTION_FOR_EACH and things copied over with ACTION_BASH_FOR (using original folders to make a list of files to move over):

Code: [Select]
MKDIR ~Bonehill/temp/BH-TIS1~
~Bonehill/temp/BH-TIS2~
~Bonehill/temp/BH-REST~

ACTION_FOR_EACH file IN "BH0100" "BH0200" "BH0300" "BH0302" "BH0400" "BH0401" "BH0402" "BH0403" "BH0500" "BH0507" "BH0600" "BH0700" "BH1000" "BH1004" "BH1100" "BH1101" "BH1200" BEGIN
MOVE ~override/%file%.tis~ ~Bonehill/temp/BH-TIS1~
END

ACTION_FOR_EACH file IN "BH1300" "BH2000" "BH2001" "BH2002" "BH2005" "BH2006" "BH2008" "BH2010" "BH2012" "BH2018" "BH2019" "BH2020" "BH2021" "BH2022" "BH2025" "BH2100" "BH2101" "BH2102" "BH2103" "BH2104" "BH2105" "BH2106" "BH2107" "BH2108" "BH2109" "BH2110" "BH2111" "BH2200" "BH2201" "BH2202" "BH2301" BEGIN
MOVE ~override/%file%.tis~ ~Bonehill/temp/BH-TIS2~
END

ACTION_FOR_EACH file IN "AM9100E1" "AM9100E2" "AM9100E3" "AM9100E4" "AM9100E5" "AM9100E6" "AM9100E7" "AM9103B" "AM9103C" "AM9105B" "AM9400F1" "AM9400F2" "AM9400F3" "AM9400F4" "AM9400F5" "AM9400F6" "AM9400F7" "AM9700A" "AM9700B" "AM9711D" "AM9712B" "AM9712C" "AM_1003" "AM_1007" "AM_1008" "AM_1008A" "AM_1011" "AM_1016" "AM_2000A" "AM_2002" "AM_2103" "AM_4001" "AM_5203A" "AM_9101" "AM_9102" "AM_9103" "AM_9104" "AM_9104A" "AM_9108" "AM_9301" "AM_9400" "AM_WSP01" "AM_WSP02" "AM_WSP03" "AM_WSP04" "AM_WSP05" "AM_WSP11" "AM_WSP13" "AMB_E04A" "AMB_E04B" "AMB_E05B" "AMB_E05D" "AMB_E05E" "AMB_E05F" "AMB_E05G" "AMB_E05H" "AMB_E06A" "AMB_E06B" "AMB_E06C" "AMB_E08A" "AMB_E08B" "AMB_E14A" "AMB_E14B" "AMB_E15A" "AMB_E15B" "AMB_E15C" "AMB_E15D" "AMB_E17A" "AMB_E17B" "AMB_E24" "AMB_E25" "AMB_E29A" "AMB_E40A" "AMB_E40C" "AMB_M01C" "AMB_M03B" "AMB_M16X" "AMB_M26A" "AMB_M26G" "AMB_M26K" "AMB_M28A" "AMB_M35D" "DIRELUTE" "FABIO0" "FABIO1" "FABIO10" "fabio11" "fabio12" "fabio13" "fabio15" "fabio16" "fabio18" "fabio19" "FABIO2" "fabio20" "FABIO3" "FABIO4" "fabio5" "fabio6" "fabio7" "fabio8" "fabio9" "fabio=" "fabio_" "fabioa" "Fabiob" "fabioc" "fabiod" "fabioe" "fabiof" "fabiog" "fabioh" "fabioi" "fabioj" "fabiok" "fabiol" "fabiom" "fabion" "FABIOnBF" "FABIOnG" "FABIOnG1" "FABIOnI" "FABIOnM" "FABIOnM1" "FABIOnSh" "FABIOnV" "FABIOnZ" "fabioo" "fabiop" "fabioq" "fabior" "fabios" "fabiot" "fabiou" "fabiov" "fabiow" "fabiox" "fabioy" "fabioz" "Ign01" "Ign02" "Ign03" "Ign04" "Ign05" "Ign06" "Ign07" "Ign08" "Ign09" "Ign10" "Ign11" "Ign12" "Ign13" "Ign14" "Ign15" "Ign16" "Ign17" "Ign18" "Ign19" "Ign20" "Ign21" "Ign22" "Ign23" "Ign24" "Ign25" "Ign26" "Ign27" "Ign28" "Ign29" "Ign30" "Ign31" "Ign32" "Ign33" "Ign34" "Ign35" "Ign36" "Ign37" "Ign38" "Ign39" "Ign40" "SS_4005A" "SS_4005B" "SS_4005C" "SS_4005D" "SS_4005E" "SS_4005F" "SS_4005G" "SS_4005H" "SS_4005I" "SS_4005J" "SS_4005K" "SS_4005L" BEGIN
MOVE ~override/%file%.wav~ ~Bonehill/temp/BH-REST~
END

ACTION_FOR_EACH dir IN "areas" "bam" "bmp" BEGIN
ACTION_BASH_FOR ~Bonehill/base/%dir%~ ~^.+~ BEGIN
MOVE ~override/%BASH_FOR_FILE%~ ~Bonehill/temp/BH-REST~
END
END

MAKE_BIFF ~BH-TIS1~ BEGIN ~Bonehill/temp/BH-TIS1~ ~^.*$~ END
MAKE_BIFF ~BH-TIS2~ BEGIN ~Bonehill/temp/BH-TIS2~ ~^.*$~ END
MAKE_BIFF ~BH-REST~ BEGIN ~Bonehill/temp/BH-REST~ ~^.*$~ END

this way the mod can be uninstalled, but files moved from the override dir to BH-TIS1, BH-TIS2, BH-REST will end up in override folder after the mod is uninstalled. If I add + to MOVE commands the mod will fail to uninstall.

I can't biff files directly from the mod directory due to potential conflicts with files that are already in override dir. I could use ACTION_BASH_FOR to find these conflicts and use DELETE command in order to store them in backup folder, but it is still not a perfect solution because HANDLE_TILSETS and HANDLE_AUDIO automatically move files to override dir, so the problem is not solveable this way. I could delete these useless files from BH-TIS1, BH-TIS2, BH-REST directories with this code (workaround because weidu can't delete whole directories for some reason):
Code: [Select]
ACTION_FOR_EACH dir IN "BH-TIS1" "BH-TIS2" "BH-REST" BEGIN
ACTION_BASH_FOR ~Bonehill/temp/%dir%~ ~^.+~ BEGIN
DELETE + ~%BASH_FOR_FILESPEC%~
END
END
but weidu will than complain about missing files during uninstallation...

edit: Thanks Imp, I will take a look.

edit2: well, it looks like that code will not help to solve this matter because it works similarly (with additional stuff to automatically generate biffs based on file sizes etc.). In GeneralizedBiffing the problem I mentioned with files going back to override directory after uninstalling the mod is what is desired. And in my case these files should not be moved back to override.

edit3: I could probably just REPLACE_TEXTUALLY strings in "MOVE.0" file, but that would be kinda hackish workaround. I'd like to do it in a sane way, and I'm probably missing something obvious.
Posted by: The Imp
« on: October 18, 2014, 01:08:11 PM »

I'm sorry, but asinine uninstallation procedures, as an example, cannot be attributed to age (unless we are talking first-few-versions-of-WeiDU old, and we are not).
Well, the last time the mods code ... could be argued to be changed was with weidu v199 if it needed that, but far more probable is that it was coded far before that. Time when the MAKE_BIFF didn't exist.... But never mind this bit. As I know you might have your plate full already in other stuff, so I'll follow with an evil questions ...
... evil cause it's intended is to help you.  ;D

What's the best way to make .bif files ? :D To enable uninstall etc. etc.
K, looking at the the_bigg_biff 's tp2 code(Generalized Biffing), I can mainly hold my thoughts on what's going in there, so is it that or is there a better way? I am asking this, not only because I know the mod can uninstall itself without hassle ... but mostly to give K4thos a base code to use/alter.
Posted by: K4thos
« on: October 18, 2014, 12:15:35 PM »

From what I've observed  unbiffed files and directories created with MKDIR will not be automatically uninstalled. COPY/MOVE commands followed by + can result in errors during uninstallation (for example use HANDLE_TILESETS, than try to move converted tis files from override to another directory with "MOVE +" command in order to biff them. When you try to uninstall the mod you will receive bunch of errors - harmless, but confusing for the mod user. And if in the override dir there was already a file with the same name before we used HANDLE_TILESETS than the whole uninstall procedure will be screwed, because weidu will try to delete the file that no longer exists within override and move the backed up one over - this can be fixed by not using "+", but in such case all this usless data will be placed in backup folder :-X).

In other words - what is a good coding method to deal with such problems without using batch files?

How exactly can we register additional files for uninstallation? You mean APPEND_OUTER to one of the files located in backup directory? This could indeed solve most of the problems if one of the ".TEXT /.0" files is responsible solely for deleting files instead of swapping them with backed out copies. If this is the case than which file should I append to?


Quote
he/she
he :)

edit: btw. is there a reason why we can't delete whole directories with DELETE command? Would be usefull in some cases.
Posted by: Wisp
« on: October 18, 2014, 11:36:15 AM »

Well, you have to give them a little credit due to the facts like they are old, and they didn't have all the nifty weidu functions we have today
I'm sorry, but asinine uninstallation procedures, as an example, cannot be attributed to age (unless we are talking first-few-versions-of-WeiDU old, and we are not).