nathan2055 wrote:diafero wrote: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.
Well, there goes my last idea
.
To be honest, we need someone who not only uses the UU patching system, but someone who can activate it in MOUL.
Oh, I'm going to change the name of this topic from "Building a MOSS Shard" to "CWE Patching System".
Okay, I've asked some people, done a bunch of investigating, and figured out exactly how this worked...
The .pat files were essentially PRP files that stored a BSDiffBuffer of each object that had changed between versions. They included the full plPageInfo header and keyring/index, with special flags indicating that it was a patch and which objects needed updating. Objects that did not change had a DataPosition/DataLength of -1. plPagePatcher would read the .pat file, and for each key in the keyring that needed updating, it would read the plBSDiffBuffer and apply it in memory to the object data. The updated objects (along with a new keyring and new plPageInfo header) would be written out to disk.
Good news: We understand how most of that worked.
Bad news: Cyan removed all the code to read the .pat files, read the patch keys, apply the diffs, and rewrite the page to disk. Also, with the new (version 6) PRP format, plPageInfo no longer has a flags field, so there's no way to indicate that a file is a patch instead of a page. Unless we reimplement all the code that Cyan removed (and break compatibility with MOUL's file format), this is impossible for MOUL.
Cyan changed the PRP format when they moved to version 70 (also when they switched to episodes), where they also removed all the plRegistry, plRegistrySource (plRegistryPackedSource), plRegistryDataSource (plRegistryPackedDataSource), plPagePatcher, and plKeyImpPublic classes/files. I find the old way of doing things much more well designed than the current way in a lot of regards, but that seems true for a lot of things added during the MOUL era