AutoPatcher Forum

weird. i've just checked. the dxcpl files wasn't in the downloaded files and wasn't reported as broken download in the log. the file containing those files is still online (lost at http://www.autopatch...eleases/modules , but is in there). maybe it was some issue at the download, i can't be sure because there's any issue reported in the log, except from the flashplayers that was updated. well, fixed (i hope). but i will check more at home. now i'm really tired due an bike travel

[]s

This is weird indeed. The dxcpl files downloaded and now are part of the .rti verification but, the muweb.dll is missing from the .rti verification,
makes the release Unofficial when present, Official when removed - here's the AutoPatcher log making mention of it...

UNOFFICIAL: File 'L:\AP\Addons.Misc\modules\AddOns\MicrosoftUpdate_x86.apm_files\muweb.dll' was found, but not mentioned by any RTI!

About the Flash players:

I didn't see a problem with them, Flash 10 with ActiveX is for IE and was in the correct folder, as well, Flash not_IE was also correct, and the
.apm files are / were correct - did you switch the folders - unless I have my wires crossed, I thought Flash with ActiveX was IE / standard Flash
was Mozilla? Bottomline, at my end when I updated the new Flash files they downloaded to the proper folders ActiveX to IE - standard to not_IE
and the .apm files were pointing to the correct files and folders.

I am really getting confused

I can confirm what Guitar_Mike said. From my AP log:


FYI The flash files are in the correct folders.
Edited by click-click, 15 February 2010 - 02:06 AM.

@click-click

Have you rerun APUP, the remaining file seems to be the muweb.dll that is causing problems, the dxcpl files were picked up this time - STRANGE.

BTW, am I confused about the Flash players issue? Thanks for the info click-click
Edited by gUiTaR_mIkE, 15 February 2010 - 02:12 AM.

In my case all the dxcpl_files and muweb were downloaded. Those files are missing in the
md5_checksum_for_Extras_Addon_Pack.md5 which may be causing this.
Edited by click-click, 15 February 2010 - 02:33 AM.

click-click said:

Exactly, this is why this is strange to me???

All the files that were missing from the .rti have been in the script for download, which means they should have been in the \modules folder
when the RTI tool was run? Cristiano fixed the 3 dxcpl files (which were in the script before, but absent from the .rti) and here is muweb.dll
in the script...

and as you already mentioned, the muweb.dll is absent from the latest .md5 and .rti files created against the Extras package, which is why
AutoPatcher gives off the Unofficial warning when it finds muweb.dll in the \modules folder.

The question, why are these files absent when the .md5 and .rti tools are run, the files are in the script for download - STRANGE!

I wonder if the RTI tool is becoming a little buggy

this is driving me crazy already. it's nearly impossible sign an script without an file that was present in the md5 check. mike knows why, but to the other ones, we have to take the entire modules folder and move his entire content to another folder where the rti tool is present. after sign, then we move the entire modules folder and the .rti file to another one, where are the remaining files, to take the md5 from those files. so, if an file present at the moment where we create the rti file, then the file should be present at the moment when we take the md5

> muweb.dll
this may be part of the other issue. as i said, i was at my girlfriend home at that time. as i didn't had the files from the script in there, i've downloaded the whole script. the only issue pointed in the log was the flashplayers, nothing else. then, i've updated those files, signed, and it was supposed to be ok, because nothing else was in the download log. but no, was missing the dxcpl and muweb.dll. why, i don't know. those files wasn't mentioned in the log.

but no problem, i was supposed to stay with my girlfriend by today (since we are in an half-a-week holiday), but i also have to wait at home for someone that shall fix an issue in my apartment. so i've fixed this issue from my pc, that has all those files. it's raining and i had to come anyway to wait for the guy, but i guess that the guy will not come, because it's raining...

by the way, the rti is buggy. when an script becomes unofficial, sometimes the report about "unofficial" becomes an mess, because autopatcher goes out of sync with the rti tool

[]s

How did you manage to read the .rti files? I can't browse them because they seem encrypted.

I reran APup on the Extras Addon Pack and the md5 now includes all files and AP now
shows the release as Official. APup shows a date of 2-15-2010 for the pack so I guess it's been updated.

Ciao..

Edit ... You slipped in-between Cristano - i missed your append
Edited by click-click, 15 February 2010 - 01:00 PM.

> How did you manage to read the .rti files?
the rti tool generates one copy of the .rti file that is unencripted

but still, i beliee that i will be forced to buy another memory card, big enough to have all the scripts inside. this shall helps with issues like this one

[]s

Is access to the unencrypted script restricted? I don't see it getting downloaded.

yes and no. that file isn't hosted at our site. but the content is something like this:

as you may see, it may be an problem to an automated tool check for that and antonis never did an tool to check for broken things in the rti. so, the md5 file do fine

[]s

the extras script was updated to reflect the changes done by the removal of the wga related modules and open the flashplayers modules to allow them load into any seven version. the script remains unsigned, because it's untested yet. it will be done tonight

[]s

Before you sign the modules, it looks like there might be a new version published by adobe: v10.1.51.95
Edited by Erik Ramey, 12 March 2010 - 12:09 AM.

again? they did an reloaded version 1-2 days ago. but no problem, i'm testing the script right now and this will be fixed

thanks

[]s

the extras script was updated. the issue with the flashplayers was fixed and i will keep on eye on them for some time. the script that was online already had the hash for the reloaded version and in deed, it wasn't matching again. but the version still looks to be the same. also, the flashplayers modules was open to all seven versions

[]s

Hmm, I hope I'm wrong - you've been on double time - it looks like a bit more editing is needed to finish it up, see below...



Sorry I don't know why I like Spoiler so much.

### shouldn't the executable go to, with this addition to the script...
no. the folder and the update are still the same. if i set an removal, then it will broke the download in the main script. but that rogue download shall be removed

thanks

[]s

fixed. in a closer look, booth of wga files still was in that script. booth was removed. if the removal become an problem, i can change the name of the folder and set an removal for it, but it will force the users to re-download that, if they have the main script in the same folder than the extras script (and this probably be the most common scenario)

[]s

> no. the folder and the update are still the same.

This makes sense now but I wasn't sure initially what you meant, XP SP3 would download WGA and Extras would delete WGA.

You did good here just removing all traces of WGA from Extras but the problem for me until I figured out what you were
getting at is my Extras is not in a folder with XP SP3 - it is shared with DirectX, DotNet, and Java so there was no
removal happening - I had to manually delete...

.....\wga
.....windows_wga.apm

It's all good now - Extras Is Official

good to know. i've saw a few days ago an old documentation about autopatcher and certain macros. i don't know if still applies, but i will see if possible do something about this kind of issue

[]s