Hello,
I need to block dozens of updates, but it's hard to find them: not only AutoPatcher doesn't have a search feature (which makes it hard to find the updates I want to block), they keep re-appearing again and again once I download updates.
Can I do what I want with a script? And if so, how?
Regards,
Amarildo
Script to block certain updates?
Re: Script to block certain updates?
Hello Amarildo 
I'll assume you mean AutoPatcher when talking about updates & blocking, finding, searching, and reappearing..? and I'm not exactly sure of what you mean by "they keep re-appearing again and again once I download updates." What are you doing to make them disappear? If a file is removed from a release, as long as the file remains in the official script it will redownload if missing.
So, the short answer is no, if an official script is edited in any way (files added or removed) it will become unofficial and AP will give you the warning in RED text -- though this is meaningless to some degree if you were the one who edited an official release. Many users remove the rti files to speed up load time, this will bypass verification but also makes a release unofficial, and IIRC Sweeper freaks out too.
You can find & search the scripts using the releases list -- http://www.autopatcher.net/releases.list -- the list (and scripts) is a simple text file, open the list in your browser, copy & paste the link of the release you want to search in a new tab -- http://www.autopatcher.net/releases/msr ... 201.script.
You have a few options but they are tedious
... Edit a script, commenting-out the updates you want to bypass, both the apm file (2 lines) and the update exe (7 lines), then run the custom script locally. Older versions of AP worked perfectly, I used this feature regularly. I'm uncertain how well AP 6x versions run a script locally anymore -- sad if not-so-good because this feature was very easy to use when testing and customizing scripts. Now, what is better but much more tedious is to create a custom releases.list file that points to your custom scripts (releases). Use the links (hopefully direct) provided by a cloud service, copy & paste the link in AP's URL Options, then select your custom script from the list.
The options above were fun to use, I experimented quite a bit with both. A former team member explained it to me and once I understood it was great fun, yes, even creating my own releases.list containing a few custom scripts. Running locally can be used by just about any AP user, it requires a bit more of a tech-no-geek
to want to maintain their own list and scripts -- assuming it's even possible anymore. IIRC I used Dropbox (free) as my cloud host, they provided direct links at the time -- I'm not sure how they work now..?
... A simpler (yet still tedious) option is to maintain 2 collections of updates -- the main collection is always up-to-date & official, the other is your custom (edited) collection with those files you want to bypass removed from AP's \modules folder. You'll update your main releases by running AP regulary, making sure the releases stay official. Thru the use of copy-to, paste, and delete, you can create a specially designed AP release to suit your needs. I would use 2 unique folder names that make it clear what collection is what -- \APMain & \APCustom for example.
I'll only offer one way of getting started, you can go with what works for you -- assuming you still care to do anything at this point
Decide on folder names and location, maybe a root folder --> \APRoot, and 2 subfolders --> \APMain & \APCustom. Populate \APMain with the releases you need, now copy-to all the contents inside \APMain to \APCustom, pasteing everything from \APMain to \APCustom, excluding the main folder. You now have 2 identical releases with different names. Create shortcuts to the various files (AP, Sweeper, logs) and drop them in \APRoot. Don't forget about switches in your shortcuts.
What you alter (bypass, aka delete) in \APCustom is your call, but you'll want to remove both the apm & exe for said update -- both should use the same KB number, see script for reference. You might as well remove all rti files in root, this will speed-up load time. I might employ the use of a .sha1 or .md5 (after latest edits, additions and deletions) that will verify your custom release hasn't changed should you copy-to a flash drive or some other location.
*** Important note about rti files and Sweeper. The rti file determines what files should be in the release, it contains size & hash info. Sweeper uses the rti to determine what files are expected and what files are supposedly extra. If Sweeper is run normally it will want to delete any files not listed in the rti -- you should be given a warning. The point, its best to remove all rti files otherwise Sweeper will assume there are many extra files in the custom release. The way I like to do it, I keep the rti files even for customized release and ALWAYS run Sweeper in /test mode. Sweeper should print to the log file all the missing or extra files -- I use this to keep track of my customizations -- any files I add or remove from an official script should be flagged as 'missing' or 'extra'. But, Sweeper must be run in /test mode otherwise files can get deleted.
Updating \APCustom should be as easy as determining what new updates from \APMain you want to add (copy-to) to \APCustom -- you don't want to move them from \APMain, this will make the release unofficial and they will only redownload when updating the script. Don't forget you will also need to pay close attention to those updates that need to be removed from \APCustom every month. The official script will list all the updates + (added), - (removed), or ~ (updated, 1.1 to 1.2 etc).
It is as easy as running the latest scripts to maintain official releases for \APMain, consulting the latest scripts, and after updating your official packages, taking a look at the log should make clear the updates that need to be removed -- this is crucial -- obsolete, outdated, and superceeded updates need to be removed or problems are guaranteed
How you decide to deal with the various test versions of AP (AutoPatcher) in \APCustom is also your call, you can use the Update dialog in AP to update AP only -- just avoid selecting the other scripts otherwise your hard work will be over-written.
Like I said, sounds tedious, in reality it takes much longer to write all this out versus actually creating & maintaining a custom release. I bet it takes maybe 1/2 hour to setup a custom release, including deciding on folder names. Updating maybe 20 minutes including what additions & subtractions are needed -- this is done roughly 2 times a month.
I usually wonder after writting a tome like this if the OP will ever come by to read it, ultimately if the user decides not to thats OK -- here's why -- I'm also thinking about the many users who only read the forums. Regardless, my goal in taking the time is that atleast one approach is outlined, in this case mine, by all means my way is not the only way.
I always hope other experienced users will chime in and offer alternatives.
I'll assume you mean AutoPatcher when talking about updates & blocking, finding, searching, and reappearing..? and I'm not exactly sure of what you mean by "they keep re-appearing again and again once I download updates." What are you doing to make them disappear? If a file is removed from a release, as long as the file remains in the official script it will redownload if missing.
So, the short answer is no, if an official script is edited in any way (files added or removed) it will become unofficial and AP will give you the warning in RED text -- though this is meaningless to some degree if you were the one who edited an official release. Many users remove the rti files to speed up load time, this will bypass verification but also makes a release unofficial, and IIRC Sweeper freaks out too.
You can find & search the scripts using the releases list -- http://www.autopatcher.net/releases.list -- the list (and scripts) is a simple text file, open the list in your browser, copy & paste the link of the release you want to search in a new tab -- http://www.autopatcher.net/releases/msr ... 201.script.
You have a few options but they are tedious
... Edit a script, commenting-out the updates you want to bypass, both the apm file (2 lines) and the update exe (7 lines), then run the custom script locally. Older versions of AP worked perfectly, I used this feature regularly. I'm uncertain how well AP 6x versions run a script locally anymore -- sad if not-so-good because this feature was very easy to use when testing and customizing scripts. Now, what is better but much more tedious is to create a custom releases.list file that points to your custom scripts (releases). Use the links (hopefully direct) provided by a cloud service, copy & paste the link in AP's URL Options, then select your custom script from the list.
The options above were fun to use, I experimented quite a bit with both. A former team member explained it to me and once I understood it was great fun, yes, even creating my own releases.list containing a few custom scripts. Running locally can be used by just about any AP user, it requires a bit more of a tech-no-geek
to want to maintain their own list and scripts -- assuming it's even possible anymore. IIRC I used Dropbox (free) as my cloud host, they provided direct links at the time -- I'm not sure how they work now..? ... A simpler (yet still tedious) option is to maintain 2 collections of updates -- the main collection is always up-to-date & official, the other is your custom (edited) collection with those files you want to bypass removed from AP's \modules folder. You'll update your main releases by running AP regulary, making sure the releases stay official. Thru the use of copy-to, paste, and delete, you can create a specially designed AP release to suit your needs. I would use 2 unique folder names that make it clear what collection is what -- \APMain & \APCustom for example.
I'll only offer one way of getting started, you can go with what works for you -- assuming you still care to do anything at this point
Decide on folder names and location, maybe a root folder --> \APRoot, and 2 subfolders --> \APMain & \APCustom. Populate \APMain with the releases you need, now copy-to all the contents inside \APMain to \APCustom, pasteing everything from \APMain to \APCustom, excluding the main folder. You now have 2 identical releases with different names. Create shortcuts to the various files (AP, Sweeper, logs) and drop them in \APRoot. Don't forget about switches in your shortcuts.
What you alter (bypass, aka delete) in \APCustom is your call, but you'll want to remove both the apm & exe for said update -- both should use the same KB number, see script for reference. You might as well remove all rti files in root, this will speed-up load time. I might employ the use of a .sha1 or .md5 (after latest edits, additions and deletions) that will verify your custom release hasn't changed should you copy-to a flash drive or some other location.
*** Important note about rti files and Sweeper. The rti file determines what files should be in the release, it contains size & hash info. Sweeper uses the rti to determine what files are expected and what files are supposedly extra. If Sweeper is run normally it will want to delete any files not listed in the rti -- you should be given a warning. The point, its best to remove all rti files otherwise Sweeper will assume there are many extra files in the custom release. The way I like to do it, I keep the rti files even for customized release and ALWAYS run Sweeper in /test mode. Sweeper should print to the log file all the missing or extra files -- I use this to keep track of my customizations -- any files I add or remove from an official script should be flagged as 'missing' or 'extra'. But, Sweeper must be run in /test mode otherwise files can get deleted.
Updating \APCustom should be as easy as determining what new updates from \APMain you want to add (copy-to) to \APCustom -- you don't want to move them from \APMain, this will make the release unofficial and they will only redownload when updating the script. Don't forget you will also need to pay close attention to those updates that need to be removed from \APCustom every month. The official script will list all the updates + (added), - (removed), or ~ (updated, 1.1 to 1.2 etc).
It is as easy as running the latest scripts to maintain official releases for \APMain, consulting the latest scripts, and after updating your official packages, taking a look at the log should make clear the updates that need to be removed -- this is crucial -- obsolete, outdated, and superceeded updates need to be removed or problems are guaranteed
How you decide to deal with the various test versions of AP (AutoPatcher) in \APCustom is also your call, you can use the Update dialog in AP to update AP only -- just avoid selecting the other scripts otherwise your hard work will be over-written.
Like I said, sounds tedious, in reality it takes much longer to write all this out versus actually creating & maintaining a custom release. I bet it takes maybe 1/2 hour to setup a custom release, including deciding on folder names. Updating maybe 20 minutes including what additions & subtractions are needed -- this is done roughly 2 times a month.
I usually wonder after writting a tome like this if the OP will ever come by to read it, ultimately if the user decides not to thats OK -- here's why -- I'm also thinking about the many users who only read the forums. Regardless, my goal in taking the time is that atleast one approach is outlined, in this case mine, by all means my way is not the only way.
I always hope other experienced users will chime in and offer alternatives.
Re: Script to block certain updates?
your words are always welcome to me ChrisJeven if the op doesn't read them. I can see how you use it and it enlightens my mind with new possibilities.