Test Server Patching Failure

[Technogen]

This may sound weird but try moving the Prefs directory out of your AO folder and patching.

[Tikra]

This may sound weird but try moving the Prefs directory out of your AO folder and patching.

Didnt work, still the trouble with client.exe

[meatybtz]

Yup, prefs, nothing seems to affect this bug.

It should be noted the following has been tried by me:
Copy Various Live files are replacement
Re-Duplicate Testlive
Change Version IDs to various older versions
Re-Duplicate Testlive
Download and install AO fresh in a seperate folder, dupe that one.
Patch up using live.

Still get the same error I have been getting.

[Noky69]

stuck in the same boat i guess. running 32 bit vista if that matters.
ive tryed everything you all have posted and a few odd things on my own. nothing seems to get by the client.exe error.
/sigh

[Essessceeaych]

I guess I should add...When I did it and changed the version id, I just added a .0 to the end at first, let it "patch" up that way, but when it started patching, of course it said the client.exe was wrong. So that's when I went and changed the version up to what test was currently at, and it let me log in np.

Dunno if that will help, but it's worth a shot if you guys haven't tried it yet.

[Technogen]

What is the current version of test? I dont have a test client on this system to tell them.

[meatybtz]

I guess I should add...When I did it and changed the version id, I just added a .0 to the end at first, let it "patch" up that way, but when it started patching, of course it said the client.exe was wrong. So that's when I went and changed the version up to what test was currently at, and it let me log in np.

Dunno if that will help, but it's worth a shot if you guys haven't tried it yet.

That does not work for me. It gives me the wrong client.exe version error. As in the ver 57 vs 56. (happens after log in).

This is for those of us who get the textcolor.xml error. You cannot update to current version and you cannot just mod the version.id

[Eponyx]

The only thing that I know have worked in the past when these kind off issues have showed up have be to do a new redupe in a new directory. So you don't redupe over your old "broken" dupe.
Then do the version.id fix (change from 18.3.1_EP1 to 18.3.1.4_EP1) and try to go from there.

[meatybtz]

The only thing that I know have worked in the past when these kind off issues have showed up have be to do a new redupe in a new directory. So you don't redupe over your old "broken" dupe.
Then do the version.id fix (change from 18.3.1_EP1 to 18.3.1.4_EP1) and try to go from there.

I have reduped from completely fresh installs into fresh directories and yet the problem persists.

Permissions are full control, directories are clean. Hell I even pulled from another computer to get a much further out of date test to try patching on and still generated the same results.

At this point I am considering hacking the client.exe to allow for a proper version sync with the server to spoof it into thinking it is patched just so I can connect.

And for the recrord I have reduped 6 times from clean installs, old installs, current installs (yes I have other computers that I use only rarely). I never copy over but only to a clean directory. This is beyond absurdity at this point. That a patcher fails over TEXT COLORS!!!!!! what kind of CRC is that?

I would like someone who can get in to post a textcolor.xml that is currently working on test to see if I can work about this problem.

OK had a friend send me a textcolors.xml It worked. I had to use a textcolors.xml from an already patched computer for the patch to apply. Why I will NEVER know.

[Technogen]

I would like to point out that after all this weird crazy fix stuff that macro has to code in it every day, and that the code is horrible. Poor Macro.

[meatybtz]

I did some digging and some comparitive work.

The patch specifcly wanted to change the textcolor.xml on one line. This was the hangup. If the textcolor.xml was not identical to the default (aka modified for any reason.. or just glitched) the patching failed.

Be forewarned.

You need a recent clean default gui to fix this issue. I have posted it as a bug and made some commentary as to the effect that the patcher should simply overwrite the file rather than doing a comparison test as to eliminate the need for the end user downloading and manualy repairing the game before they can apply the patch. This is addressed as a concern towards when the patching rolls to live.

It is unreasonable to expect your userbase to guess what the problem is. I was informed it was a KNOWN ISSUE, and yet no one saw fit to make it KNOWN to me. Either way, a better way to allow/inform/direct end users shouldbe used in the future or the patcher itself should handle this without user intervention (the better choice).

[Honorbound]

I did some digging and some comparitive work.

The patch specifcly wanted to change the textcolor.xml on one line. This was the hangup. If the textcolor.xml was not identical to the default (aka modified for any reason.. or just glitched) the patching failed.

Be forewarned.

You need a recent clean default gui to fix this issue. I have posted it as a bug and made some commentary as to the effect that the patcher should simply overwrite the file rather than doing a comparison test as to eliminate the need for the end user downloading and manualy repairing the game before they can apply the patch. This is addressed as a concern towards when the patching rolls to live.

Of course you do.

Since the default GUI (or any other file of the client, for that matter) should never, under any circumstances, be modified by the users, the patcher has every reason to expect it to be found in the exact state it should be, and abort if it isn't.
More so because of what patching is about and how it is performed.

The common way to create patch packages is to include only the differences, not on file level, but on byte level within the affected files, to reduce the size of the package to as small as possible. If you tried to apply those byte-level modifications to a file which is not the exact same one as the patch was created for, the file would get irreparably garbled. That's why the patcher cannot accept such files, and has to abort.
Making a patch completely fail-safe in terms of being able to fully recreate any and all files it finds incorrect would mean that the package would have to contain a full copy of every single file it will have to modify, in case the one on client side doesn't pass the pre-patch verification. Which petty much mean that about 99% of the patches would have to contain a pre-patch version of the whole RDB file, for one.
2GB patch files, anyone...?

[Onack]

It fails at client.exe from 18.3.1.0 to 18.3.1.1
(from fresh dupe)
if i change version.id to 18.3.1.4
eh... it suddently works... ah well, thanks :P

[Tikra]

Yup, changing version.id to 18.3.1.4 does the trick. Thx for the hint epo

[meatybtz]

Of course you do.

Since the default GUI (or any other file of the client, for that matter) should never, under any circumstances, be modified by the users, the patcher has every reason to expect it to be found in the exact state it should be, and abort if it isn't.
More so because of what patching is about and how it is performed.

The common way to create patch packages is to include only the differences, not on file level, but on byte level within the affected files, to reduce the size of the package to as small as possible. If you tried to apply those byte-level modifications to a file which is not the exact same one as the patch was created for, the file would get irreparably garbled. That's why the patcher cannot accept such files, and has to abort.
Making a patch completely fail-safe in terms of being able to fully recreate any and all files it finds incorrect would mean that the package would have to contain a full copy of every single file it will have to modify, in case the one on client side doesn't pass the pre-patch verification. Which petty much mean that about 99% of the patches would have to contain a pre-patch version of the whole RDB file, for one.
2GB patch files, anyone...?

Except.. in this case I also had an unmodified file that it ALSO DIDNT WORK WITH.

No, to make a failsafe patch you simply have it able to self-correct errors. What that means is you do not just fail out with cryptic messages but instead when an error is found you auto-correct it. MOST PATCHERS worth their spit will do just this. And no yo do not package all the replacements that you wont need. YOU design it so it is self correcting. If there is an error it grabs the needed file, runs the repair, restarts patching. AO just uses a primitive patching mechanism that cannot handle any errors at all and leaves it up to the player to figgure it out.

Just to be sure, I tested this with other modern game and their patchers..,. sure enough when I purposfully corrupted a file the patcher just overwrote it with the "good one". Yet another one entered an auto-correct and again replaced the bad file then continued patching as normal.

It does not take up alot of space to have the entire default GUI in the download package but wait.. you don't have too. Why?!? Because you as the developer know what you have changed and you can include a 5.5KB file without ballooning your patch. A selective downloader can get the files it needs as well. What we have is a primitive patcher, crude and dumb. It is obviously able to do comparitive error checking and should be extenseble to FTP pull the needed files via a system of flaged :bad: retrieve new: retry patch. However that being said, FC I think tried this once with their patcher and it resulted in a perm-retry loop. I cannot recall what patch that was but it was pretty funny. Then again you would implement an error level system that minor errors are autocorrectable while major errors would prompt for reinstall and the installer would include a "repair" option for the user.

Normally I think you think things through man but in this case you go all tinfoil hatty .. 2 GB haha. Wonderful comparison. Then again I am not surprised no one these days wants to make failsafe software. No, it would be too much work that irregardless if people modify files to assume the possibillity of corruption. But instead we will prompt the user for a complete several hours long reinstall of a program because of a one line change in an XML file that overall is fairly irrelevant.

Of course if FC had color choices and GUI that didnt suck so hard, people wouldnt need to bother as much. Again color picking should have been an included feature. Game: Crude GUI SYSTEM: Crude Patching System: Stone Age. Yup.. that is AO for certain.

[Tralauri]

I would like to point out that the address on the launcher page:

" http://arf.ark.funcom.com/bugsy " is a dead link as well.

Where do I get an unmodified textcolors.xml file without redownloading the entire game again? My original .bak backup of the file does not seem to be what the game wants.

[Technogen]

Bugsy has moved, but for the life of me I cant find the new address, I was looking for it for you but dark or epo will have to fill you in.

[Technogen]

meatybtz: Actually the GUI system has changed, thanks to Macro, players do not need to overwrite the old GUI code now for a new GUI code. Yes I agree the GUI needs upgrades but yeah there's no reason to touch the old code any more just a new directory for the code then point your client at it.

[BugsCoT]

http://ark.ext.funcom.com/bugsy/ is the new address.