Problems with determining age version

[diafero]

ULM has a big problem determining the age version: Even though some files differ (because they got updated), it shows that I have the latest version. And if there are several version, it happens that ULM thinks I have the older one even though some files are different - because I exactly have the newer one. This is really annoying. You have to check each age manually to see if you *really* have the latest version, and if you want to download it, you have to delete some other files of the age.
As far as I know this was added to resolve problems with the sum file being different and thus the ULM not recognizing the version correctly, but the current situation is much worse, it makes ULM unusable for keeping ages up-to-date. My suggestion would be:
- easy: Ignore the sum files when determining the version (and strictly compare the rest of the files)
- hard: let ULM generate the sum files, which would also avoid problems with the age moderators to upload illegal sum files

It would also be great if ULM could cache the md5sums somewhere else than in "filename.md5" files which are spread around all Uru folders. Especially when you do own Python stuff or work (as in "hack" ) on other Uru files, these md5 files are really annoying.

[D'Lanor]

To be honest, I am afraid it is all our (writers) fault. We should never delete any older versions from the ULM database. From what I understood that is what confuses it.

Anyway, for MORE we won't be needing ULM anymore to do the client updates. Online Uru has its own superior patching system. I can see a future for ULM though as a tool for writers and maintainers to coordinate testing.

Instead of creating just the md5 checksums it would be nice if ULM could gzip the appropriate files and then generate manifest files for the internal patcher. That way the writer could upload a dataserver ready package.

[diafero]

A dataserver is nice-to-have, but since you would not be able to choose which ages to install, I really prefer something like the ULM.

Even if old versions of the ages are deleted, there's no reason for the ULM to say "you have the latest version" while at the same time the detailed dialogue shows that three prp files and the pak file differ. This is clearly a bug - the age is definitely NOT the latest version.

[D'Lanor]

A dataserver is nice-to-have, but since you would not be able to choose which ages to install, I really prefer something like the ULM.

In MOUL you could not choose, but Prologue/UU had a check box: "Update all ages on launch (Note: Leaving this unchecked will update each age as you link there)". Simple and elegant. I would really like to see that back in MORE.

btw, it was still possible to force this option in MOUL by interrupting the patcher. So this could easily be made the default setting even without a checkbox.

I also prefer the internal updater because the amount of "I cannot get ULM to work" posts is starting to worry me. 3rd party apps tend to be way too complicated for most users.

We can discuss this all we want but in the end the choice is up to Cyan. So I am placing all my bets on the internal updater. I just wanted to point out the areas where ULM can still be useful should it get dropped as client updater.

[GregW11]

Here's my suggestion: have a ULM-like interface when the patcher starts for WIP Ages (basically you can choose which of the Ages you want to download and have appear wherever they do. That would save on disc space, and load times. When you link to any Age, the game would perform a quick check to ensure that you have an Age installed. If not, the game would either automatically download the Age or (if the first does not work) simply link you back to your Relto.

[diafero]

However, disabling "Update all ages on launch" would not work with TPOTS as the TPOTS UruExplorer.exe does not support dataservers, and even with MORE running people will still want to play ages offline (at least, I would ). I'm not talking about the age distribution mechanism we should have when MORE is able to host fan-created ags (which sure will still take a huge while - personally I don't expect that to happen before April or May 2009), but about improving what we have now and what we have to use till MORE is complete, and that is the ULM (or is anyone currently working on a new TPOTS UruSetup.exe with fan-ages integrated?). Why is the possibility of having a better integrated patcher in several months an excuse for ULM not doing right what it should do? I would even try to fix these small problems (at least a small fix should not be too hard IMHO) myself if I had the source and ULM was written with a usable toolkit... but I don't want to learn another toolkit, especially not M$ .NET. In addition, setting up a toolchain for it on Linux doesn't sound like a good idea (perhaps it could be made working with Mono, but I've got experience in that area).

[D'Lanor]

However, disabling "Update all ages on launch" would not work with TPOTS as the TPOTS UruExplorer.exe does not support dataservers, and even with MORE running people will still want to play ages offline (at least, I would ).

Be prepared to do a fair amount of drizzling then. Or would writers be willing to create two versions of their ages? One for MORE and one that is compatible with TPOTS.

btw, Trylon did request help for the ULM redesign project.

[diafero]

Be prepared to do a fair amount of drizzling then. Or would writers be willing to create two versions of their ages? One for MORE and one that is compatible with TPOTS.

I actually thought PyPRP would get two export options, one for TPOTS, one for MORE.

Thanks a lot for the link, I didn't know the "main" discussion about ULM is over at the GoMa. Well, I hope Trylon reads this somewhen since I really don't want to have another Uru forum account.

[D'Lanor]

I actually thought PyPRP would get two export options, one for TPOTS, one for MORE.

In an ideal world perhaps. I expect many hours of tweaking to make our current ages behave in MORE. Cyan had huge problems adapting existing ages to the new physics engine and in the end they only fixed the most urgent issues. So I don't think we will be spared that ordeal.