New Updater
 

Since the old updater will cease working anytime soon due to Java's security restrictions and there are no free code signing certificates available, I have developed a new version as 'stand alone' Java Application.

http://updater.pala.de/new/

I am currently testing any possible fault condition I can think of, but it is always better to have other people play around with it and try to break it.

Java 7 is required, but the launcher will automatically download a local version to its folder if it cannot find any installed on the system.

The download is currently tunneled through a CDN (updater.pala.de.nyud.net, which is coralcdn.org), because Chrome freaks out about the executable file until Google has crawled the website again.

Please feel free to test it and report back.

Here's a shortcut icon for it that looks a bit better than the old Web updater one, and is a bit more obvious than the default one for the executable. I did 3 sizes that should fit most uses. They're zipped up, just unzip the zipfile to extract the icons.

The executable icon is deliberately generic, as the updater is used by other UIs as well. Could use better icons though :P

As per windows design guidelines, you need sizes 16x16, 32x32, 48x48, and 256x256 (optionally 24x24, 40x40, 64x64)
http://msdn.microsoft.com/en-us/libr.../aa511280.aspx

I'll give it a test.

Will you be able to support an updated version for me as well? Appreciate your time spent on this!

Will do once it runs stable

I'll have to add those. I did it as separate files for the most common desktop/shortcut icon sizes since I figured having them in the binary wouldn't work.

ProfitUI icon file
 

A new icon file, with multiple icon sizes: 16x16, 24x24, 32x32, 40x40, 48x48, 64x64, 256x256. That should cover all the sizes of icon Windows will need. The .ico file's zipped up, just unzip to extract it.

Variants reset
 

Noticed that when the new updater ran today and updated itself, it reset all my selected variants to the defaults (the ignored files list and the settings like the path to the game folder were unaffected). This hasn't happened before, just today.

Changed a lot of things around. You are actually lucky it did not destroy itself. I think it might have done that for some people :P

Should not happen again.

I have to test MSI installers. "destroy itself" I'm intimately familiar with. :) At least yours is a standalone program, worst I have to do is delete 2 folders and grab a new copy (as long as I remember my ignore list and the variants, anyway).

Settings wipe incoming .. probably ..

it wont keep the variants after "exit" nor will it apply the variants the the game once launched. The merc window is also back to b4 the fix, no buttons

Tested every configuration I can think of and it is working fine for me. Maybe download the *.zip file again and overwrite your current installation. The latest update will delete all settings though, that is the expected behaviour.

I can actually see where things go wrong with already installed variants. To fix it just do Install/Uninstall/Install of that particular variant.

Or delete the UI files (or to be specific: the *.zip file of that variant).

Had to change things around to support other UIs. Should not happen again :P

The behavior I'm seeing is that when I applied the update it reverted all variants to the default and downloaded/installed the default version of files, but then when I selected the variants I wanted it didn't download the variant zipfiles and didn't install the variant versions of files. I had to exit the updater, restart and unselect my variants, then reselect them to get it to download the zipfiles (they were already present, shouldn't they have been used without re-downloading?) and install the variant files. It's like when I select variants it's not rescanning to check whether the current files match the new variants.

I'm going to try wiping out the program and settings, downloading a new copy of the updater and reinstalling it, see if it's some sort of artifact from leftover cruft.

Put in some code which will delete unused files, should fix that behaviour.

Thinking about it it looks like a nasty glitch. It's easy enough to fix if you know the trick, but it happens every time variant selections get reset. It may be that you want to not minimize disk access so much, when a variant's selected it's zipfile should always be unzipped if it's present and current (I'm assuming that'll happen automatically if it's queued and downloaded either because it's absent or because it's presetn but out-of-date compared to the copy on the updater).

crc error
 

I have tried to unzip the file, but I am getting crc errors. Is it possible I have tried installing it incorrectly?

where are we with this? i just noticed the old updater no longer works. is this still in testing? is it official? is there someplace i can find my old settings to duplicate in this new version?

thanks.

New Updater Stopped Updating...
 

A few days ago the new updater stopped working. It closes the update window as soon as it opens with no update. The log file shows:

de.pala.updater.Updater - Cannot activate core
org.java.plugin.PluginLifecycleException: can't find plug-in class de.pala.updater.services.settings.SettingsPlugin
at org.java.plugin.standard.StandardPluginLifecycleHandler.createPluginInstance(Sta ndardPluginLifecycleHandler.java:117) ~[jpf.jar:1.5.1]
at org.java.plugin.standard.StandardPluginManager.activatePlugin(StandardPluginMana ger.java:403) ~[jpf.jar:1.5.1]
at org.java.plugin.standard.StandardPluginManager.checkPrerequisites(StandardPlugin Manager.java:469) ~[jpf.jar:1.5.1]
at org.java.plugin.standard.StandardPluginManager.activatePlugin(StandardPluginMana ger.java:397) ~[jpf.jar:1.5.1]
at org.java.plugin.standard.StandardPluginManager.activatePlugin(StandardPluginMana ger.java:245) ~[jpf.jar:1.5.1]
at de.pala.updater.Updater.start(Updater.java:102) [Updater.jar:na]
at de.pala.updater.Updater.main(Updater.java:76) [Updater.jar:na]
Caused by: java.lang.ClassNotFoundException: de.pala.updater.services.settings.SettingsPlugin
at org.java.plugin.standard.StandardPluginClassLoader.loadClass(StandardPluginClass Loader.java:378) ~[jpf.jar:1.5.1]
at java.lang.ClassLoader.loadClass(Unknown Source) ~[na:1.7.0_51]
at org.java.plugin.standard.StandardPluginLifecycleHandler.createPluginInstance(Sta ndardPluginLifecycleHandler.java:113) ~[jpf.jar:1.5.1]
... 6 common frames omitted
de.pala.updater.Updater - Cannot activate updater
org.java.plugin.PluginLifecycleException: plug-in de.pala.updater.services.updater requires plug-in de.pala.updater.services.settings which failed activation
at org.java.plugin.standard.StandardPluginManager.checkPrerequisites(StandardPlugin Manager.java:445) ~[jpf.jar:1.5.1]
at org.java.plugin.standard.StandardPluginManager.activatePlugin(StandardPluginMana ger.java:397) ~[jpf.jar:1.5.1]
at org.java.plugin.standard.StandardPluginManager.activatePlugin(StandardPluginMana ger.java:245) ~[jpf.jar:1.5.1]
at de.pala.updater.Updater.main(Updater.java:77) [Updater.jar:na]

Not sure if its somthing with Java or the de.pala.updater address. Java 7 is installed and verified.

Just checked the new updater. I didn't get the problem mentioned above, but did have other issues. When the updater opened, a popup appeared stating that there were updates available for the updater and asked permission to proceed. I clicked OK. The update completed and the updater restarted, but had lost the EQ2 file path. I had to select the path again, quit the updater and run it again for the updater to work correctly.

Besides the clumsiness of the operation, it reminded me of another issue that I find annoying. When you click CHOOSE to update the EQ2 file path, the selection dialog opens pointing to the current user's My Documents folder. In the current case, the updater had lost the file path so I can understand it not having to path to start from. However, most of the time I am switching from the live instance to the Test instance or vice versa. In such cases, the updater really ought to start at the last selected path, which would save a lot of clicking.

Another option would be to let the user directly edit the displayed path, but I can see how that might be more work to code and could create another failure point.

-= Therendil =-

Should be a one time thing when I changed around where settings are saved.

This is already implemented, but not yet released as I am still collecting bugs.

Okay. Probably the same reason that the welcome screen started showing up - the Ignore setting for that file got lost. No big deal. I'll set things back as they should be and let you know if there are further issues.


I'm glad to hear that you're adding that. Even more glad that you have your priorities right. I don't mind waiting for a new feature if the delay is due to squashing bugs first.

-= Therendil =-

The older Updater usually popped up the Changelog if you patched any files. The new one doesn't seem to do this (I only saw it when I first set my directory).

Not sure if intentional or not.

Any chance of adding support for side-by-side installations of the same installer, ie. i run multibox on 1 machine with multiple installations of EQ2. inorder for the updater to work i would prefer to install it once per EQ2 installation etc.

The 'simple' solution would be to use config files based on the name of the executable (like how ACT does it) would make it simple for those who want to use multiple installs etc.