PlaneShift
Support => Technical Help: Problems BEFORE entering the game => Topic started by: LigH on May 13, 2011, 12:35:05 am
-
Unfortunately, after releasing version 0.5.6, we lost our updater servers.
Fortunately, we got a new updater server. And pslaunch should be able to retrieve its URL when it was unsuccessful trying the previous update servers.
Unfortunately, pslaunch seems to crash often before it is able to do so. Therefore several users are unable to update the update server list.
updater.log
Using mirror http://216.6.227.163/updater/ for updaterinfo.xml
Using mirror http://planeshift.clevertech.net/Updates/ for updaterinfo.xml
Using mirror http://planeshift.clevertech.net/Updates/ for updaterinfo.xml
There are no active mirrors! Please check the forums for more info and help!^ Here it should have retrieved a new updateserver.xml - but it crashed.
Fortunately, I found a way to enforce this update: Try a repair in console mode. The repair may fail, but at least it retrieves the server list.
NOTE: This guide is based on a clean Win32 installation. No guarantees - especially not for applying it on a previously updated game, or for any other OS version.
There is just a little trap: The current release installer provides client version 0.5.6 / data version 0.5.6.2; but after the repair attempt, you will get the updaterinfo.xml file of data version 0.5.6.5 - which is not the current, but the wanted state. Therefore:
Backup the file updaterinfo.xml in your PlaneShift installation directory!
Then execute:
Windows: cmd.exe
...\PlaneShift>pslaunch.exe --console --repair
PlaneShift Updater Version 2.90 for win32.
Checking the integrity of the install:
Beginning integrity check!
Couldn't open xml file '/this/updateservers.xml'!
Unable to get root node!
Attempting to restore updateservers.xml!
Using mirror http://ss9.us/update/ for updaterinfo.xml
Downloading integrity data:
Failed to download integrity.zip!
Updater finished!
Press a key to close this window...
Afterwards:
Restore the file updaterinfo.xml in your PlaneShift installation directory!
Now start pslaunch as usual and it will update pslaunch, then continue with the client and data update.
-
/me has no updater.xml :o
Will try with a fresh install next week. :)
-
May be you can just post the correct content of updateserver.xml here? This method doesn't achieve anything on Linux really.
I currently have in it:
<mirrors>
<mirror id="1" name="botanic" url="http://216.6.227.163/updater/" repair="true"/>
<mirror id="2" name="clevertech" url="http://planeshift.clevertech.net/Updates/" />
<mirror id="3" name="clevertech2" url="http://planeshift.clevertech.net/Updates/" />
</mirrors>
I changed it to:
<mirrors><mirror id="1" name="ss9" url="http://ss9.us/update/"/></mirrors>And now I get the following:
./pslaunch --repair
PlaneShift Updater Version 2.92 for linux64.
Checking the integrity of the install:
Beginning integrity check!
Using mirror http://ss9.us/update/ for updaterinfo.xml
Downloading integrity data:
Failed to download integrity.zip!
Updater finished, press enter to exit.
And I think that's correct. because there is no integrity.zip on http://ss9.us/update/ So where is integrity.zip supposed to come from?
-
The file "integrity.zip" is only present on update servers which are prepared for "Repair" mode access.
As you see, the attribute 'repair="true"' is missing in the <mirror /> XML tag of server "ss9" for this reason: It is not set up as repair server.
So after retrieving or editing the file updateserver.xml, you should not try anymore to repair.
__
The whole procedure may not work correctly if you did not clean your installation directory, because your updaterinfo.xml may already contain entries of versions 0.5.6.3 or newer.
I believe it should be safe to delete the last 3..5 version entries and try to update after retrieving or editing the current updateserver.xml; already applied updates should just fail (wrong checksums for already patched files), the first matching update should continue the patching. But I still recommend a current installer and clean installation (the Win32 package is at data version 0.5.6.2 / client version 0.5.6; client 0.5.6.1 comes with update 0.5.6.3).
-
well, I had 0.5.6.1 client, but I did a fresh install after cleaning the mess in my ps folder, with a win32 installer from Frubar.
I followed your workaround, pslauncher updated to 0.5.6.1 but that's all.
psclient now is 0.5.6 :oops:
-
I'll be in IRC today, with a TeamViewer 6 ready at hand.
-
I believe it should be safe to delete the last 3..5 version entries and try to update after retrieving or editing the current updateserver.xml; already applied updates should just fail (wrong checksums for already patched files), the first matching update should continue the patching. But I still recommend a current installer and clean installation (the Win32 package is at data version 0.5.6.2 / client version 0.5.6; client 0.5.6.1 comes with update 0.5.6.3).
That worked. I deleted 5 last entries in updaterinfo.xml (so the last entry remaining became 0.5.6 which matched my client version). And after that ps started offering an update to 0.5.6.x Though there were a lot of failures to retrieve certain files in between, like art/skins/base/client_base.zip (but all those are for 5.6.1, 5.6.2, 5.6.3, 5.6.4) and etc. 5.6.5 changes downloaded with success. Is that expected?
How do I check the version of the client afterwards? After the update and running the client it shows 5.6.1 in the login screen. And it all got messy - showing just black screen and UI after logging in. I'll probably just reinstall it from the binary release, and will try the update again.
-
Confirmed. Deletion of entries after 0.5.6 from the file updaterinfo.xml triggered the update from the Launcher.
-
Now, the update from the binary release worked, but it was really my fault with the previous method - I forgot that I just updated my Debian, which brought in newer Nvidia drivers. I just had to reboot the machine. It works fine now, thanks.
-
The installer brings data version 0.5.6.2; deleting update information for data version 0.5.6.1 makes the updater try to patch the existing version 0.5.6.2 data files with a 0.5.6.1 change, that fails of course.