The new UOP file format

[_Epila_]

I'm trying to decompress the new UOP file found in UO recent patches but im cant generate the index files for some of them (gumpart.mul and gumpidx.mul)
I can generate the gumpart.mul without problems but i have no idea on how to generate the gumpidx.mul (the index file for gumpart.mul since it is a run of pixels

Its strange because the new UOP files include only gumpartLegacyMUL.uop, there are no new index file

For file formats:
gumpart.mul and gumpidx.mul (old mul)

gumpartLegacyMUL.uop (new uop)

If anyone have an idea of how to generate the indexfile i'd be pleased

thanks

 

[Warstone]

There is no new uop format. Index data was there since 1st times.

 

[_Epila_]

Both gumpart.mul and gumpidx.mul were replaced by gumpartLegacyMUL.uop when EA released >7.0.24 patches
Although its possible to "extract" or generate the old gumpart.mul, i found no way to "extract" or generate the gumpidx.mul

 

[HellRazor]

Don't know if this helps, but I found this .UOP file format on another forum. Perhaps they have 2 files in the .UOP, one being the index and one being the MUL?

Mythic Package File Format (.UOP)
---------------------------------

[1] Format Header
BYTE -> 'M'
BYTE -> 'Y'
BYTE -> 'P'
BYTE -> 0
DWORD -> Version
DWORD -> Signature?
QWORD -> Address of the first [2] Block
DWORD -> Max number of files per block
DWORD -> Number of files in this package
BYTE[]-> 0

[2] Block Header
DWORD -> Number of files in this block
QWORD -> Address of the next block

[3] File Header
QWORD -> Address of [4] Data Header
DWORD -> Length of file header
DWORD -> Size of compressed file
DWORD -> Size of decompressed file
QWORD -> File hash
DWORD -> Adler32 of [4a] Data Header in little endian, unknown in Version 5
WORD -> Compression type (0 - no compression, 1 - zlib)

[4] Data Header (Version 4)
WORD -> Data type
WORD -> Offset to data
QWORD -> File time (number of 100-nanosecond intervals since January 1, 1601 UTC)
BYTE (size of compressed file) -> File 

[4] Data Header (Version 5)
BYTE[]-> Metadata used by UO patcher

Pseudocode:
[1] Format Header

while ( Address of the next block > 0 )
[2] File Header

while ( Max number of files per block )
[3] File Header
end

while ( Number of files in this block )
[4] Data Header
end 
end

 

[_Epila_]

This is the pseudo code im using to extract the gumpart.mul

foreach(block in package)
foreach(file in block[n])
write block[n].file[m].contents to file(gumpart.mul)
end
end

since it loop through every blocks/files inside the uop to extract only gumpart.mul, there are no remaining data to generate the gumpidx.mul
gumpart.mul is being generated with no problems, i've checked it side-by-side with the original file from old uo versions
i just cant figure a way to generate the gumpidx.mul

 

[Vorspire]

Jeff hasn't done it yet, there is no support for Gumps in OpenUO right now unfortunately, but I am in the process of updating the old Paperdoll.php code which requires similar algorithms to be written. When I've completed that task I will write the algorithms in C# and then forward the code to Jeff for perusal. If he gives the nod, I'll add it to to the project source. There is currently no ETA for this feature.

 

[Vorspire]

All IDX format files, to the best of my knowledge, are made up of blocks of 12 bytes of data, detailing the <lookup-index> (4 bytes), <data-length> (4 bytes) and <reserved> (4 bytes)

In order to generate this file, you would have to write the IDX file during the execution of your current code.
You will need to write the <lookup-index> (Int32), then after the run, write the <data-length> (Int32) and then write 4 null-bytes for <reserved>.

The <lookup-index> is the position of the file at which pixel data starts for a Gump.
The <data-length> is the size of the pixel data from <lookup-index> to the end of the run, this is just the pixel data length and does not include extra group indexers or flags.

 

[MalGanis]

Yeah classic client is one big mess right now. Half of the files are in .uop, half in muls...

Anywho there are no index files in the uops anymore, because there's no need for them. At startup client loads all file headers ([3] in HellRazors attachment) in .uop files and stores it in one big hashtable (by filename hash). When client stumbles upon a resource, lets say it needs to load gump with id 100, it will construct a filename like so: "build/gumpartlegacymul/00000100.bin", hash it to obtain filename hash and find appropriate file header in that hashtable, then read compressed pixel data from .uop.