Guild of Writers

nathan2055 wrote:Do you guys think some kind of patcher like UruDistro could be added to the MOUL client itself?

You can do anything since the source has been released. You could add the ability to connect to Quake 3 Servers and play death-match with the URU Avatar if you wanted. Though it would be unlikely to get into the Official Client(People currently have to download a custom client to play on a server other than Cyans).

nathan2055 wrote:

Chacal wrote:You guys are pretty much describing UruDistro!


The workaround suggested here is pretty much what we do with POTS (and the MOUL, Myst5 and other conversions done by Drizzle, and I think what Dustin does with his UAM shard): use the player's already existing prps. This means the player has acquired the game(s), presumably legally, so that there is no distribution of Cyan's content.

Do you guys think some kind of patcher like UruDistro could be added to the MOUL client itself? This would allow us to update shard user's clients without them having to install extra URU utilities.

As I said, most of the code is already there from UU. Look at Sources/Plasma/PubUtilLib/plResMgr/plBSDiffBuffer.

Paradox wrote:

nathan2055 wrote:

Chacal wrote:You guys are pretty much describing UruDistro!


The workaround suggested here is pretty much what we do with POTS (and the MOUL, Myst5 and other conversions done by Drizzle, and I think what Dustin does with his UAM shard): use the player's already existing prps. This means the player has acquired the game(s), presumably legally, so that there is no distribution of Cyan's content.

Do you guys think some kind of patcher like UruDistro could be added to the MOUL client itself? This would allow us to update shard user's clients without them having to install extra URU utilities.

As I said, most of the code is already there from UU. Look at Sources/Plasma/PubUtilLib/plResMgr/plBSDiffBuffer.

Well then, all we have to do is edit those PRP files and build a new client that shard owners can set up and distribute for their shard!

Neither MOSS or DirtSand supports those bsdiff'd PRPs, so it's something that would actually take a bit of implementation effort server-side. Not to mention trying to make that bsdiff code work correctly again client-side, as it's been disabled for years.

I haven't actually looked at the bsdiff code yet, but when it comes to Plasma nothing is ever as easy as you think it will be.

Branan wrote:Neither MOSS or DirtSand supports those bsdiff'd PRPs, so it's something that would actually take a bit of implementation effort server-side. Not to mention trying to make that bsdiff code work correctly again client-side, as it's been disabled for years.

I haven't actually looked at the bsdiff code yet, but when it comes to Plasma nothing is ever as easy as you think it will be.

Yikes. Do you think it's possible to access fan Ages another way?

Branan wrote:Neither MOSS or DirtSand supports those bsdiff'd PRPs, so it's something that would actually take a bit of implementation effort server-side.

I could be easily wrong(Im not 100% on how the update process works) but doesn't the server send the client a list of files to check and if the MD5 is different the client requests the files which are different from the server? If so then the Binary Differences* could be stored in a folder, which are downloaded to the clients folder, if the client detected that a Binary Difference* file was downloaded it would add it to a list. Once the client has finished the normal update bit it would check to see if the Binary Difference* list had anything in it, if so it would then apply the appropriate Binary Differences* to the clients files.

It would still take time to implement in the client, but if im correct on how the update system works then it would mean the server wouldn't have to be touched.

* Binary Differences would have to be grouped into one file based on the PRP they are applied to and the order they need to be applied in. Rather than separate files for each change.

In UU, the update system consisted of downloading binary diffs which were applied client-side. This used the plBSDiff code that I mentioned earlier. There was (IIRC) some sort of detection of file version based on the MD5 (a UU admin would know for certain how it worked).

In MOUL, the client redownloads any files that do not match the MD5 in the manifest. There is no code for patching implemented in the client.

Paradox wrote:...a UU admin would know for certain how it worked...

There has got to be a UU admin somewhere. For some reason, diafero jumps to mind as someone who might know that kind of code.

UU shards used Cyan's central dataserver so admins did not need to bother about updates and patches. And I bet that those who do run their own dataserver and push regular updates use the full prp download method rather than patches.

I do have a test UU Shard in a virtual machine, not sure if that qualifies me as UU admin
Admittedly, the dataserver of an Alcugs/TPOTS Shard works exactly the same as a UU one. However, as D'Lanor pointed out, I do not use the patching functionality. On the DI server, there is a huge directory containing all the prp, age, sdl, ... files for all available ages in their appropriate folder (to make organizing easier, they are not all in one folder, but rather separated in one Uru folder structure for each age). A python script is reading all those files, and doing some magic (involving Java and native C++ apps... yeah, it's quite messy^^), to create a consistent dataserver out of it (so the files end up on the server twice: uncompressed in the dataserver source folder, and compressed available for download). If the client sees that a file is outdated, it just re-downloads it entirely.
I wrote together most of what I know about dataservers at http://alcugs.almlys.org/AlcugsDataserver, but I could never find any documentation or tools for the patching functionality.