Thanks XuN and Feeh!
It seems that the plugin you linked converts the Classic Client uops (like map0LegacyMUL.uop) into muls and back, unfortunately CC and EC uop packs different types of files inside, so it isn't useful for the EC.
Looking the directory of the CC (all patches done) there are some things i don't understand:
1) First, i have MapXLegacyMUL.uop AND facet0X.mul, staticsX.mul, staidxX.mul, stadifX.mul (same situation with anim files). Why? What's the usefulness of having both filetypes?
2) Does MapXLegacyMUL.uop contain also statics, like facetX.uop does in the EC?
3) What is the difference between client and client_tc? I have both of them.
4) What is UO-MCE, inside the GDF directory? It launches UO.exe with -mce argument.
5) There are now some new map files that has same file sizes, like map0LegacyMUL.uop and map0XLegacyMUL.uop (but there aren't facet00.mul and facet00X.mul). "Duplicated" maps appear also in EC's directory. What are they for? I calculated MD5 hashes of both map0 and map0x and they are different, so between these two maps there should be some differences (or, if the maps are identical and map0blah.uop files packs also statics, the differences may lie in the statics).
Now, the findings part.
I unpacked KR and SA EC facet0.uop and took the unknown file from both sources. Yes, Mythic Package Editor doesn't know the name of only one file in the KR uop. This file has the SAME size of the SA unknown file (8 bytes).
Another observation: MPE extract files from KR uop with the .bin extension, the same of SA EC uop contents, but Radstar map conversion tool creates .raw files and i also remember to have read that the file extension used was .dat, so lol, which one is the correct format? Maybe Radstar's one, because its tool was claimed to work.
So, i checked with the hex editor both the unknown files, see what i found:
facet0.uop_0_00 is from KR (file in the block 0 of the uop, "number" 00, so it's the first in the list, or the first in the packaging order maybe, just an assumption)
facet0.uop_4_488 is from SA EC (file in block 4, number 488 of 1000 per block)
The file content is IDENTICAL.
I don't know much of hex editing, bits, bytes and so on, but i tried these conversions:
0x1c00 (hex) to decimal: 7168 (X of map0)
0x1000 (hex) to decimal: 4096 (Y of map0)
So, this unknown file contains informations about the current map resolution. And this file format remained unchanged from KR to SA, so this piece of Radstar's code is still good.
To develop a tool to convert pre-KR maps to SA EC ones we have to know map block files format (which we have, see the above link
http://code.google.com/p/kprojects/wiki/Sector) and the name of this unknown file.
Radstar's map converter names that file "facet0-00_00.raw", so we should start from this to guess the SA file name.
Another observation is that KR converted raw files are all put in the same directory, no subdirs, while extracting with MPE SA facet0.uop the bin files are extracted in the build/sectors/facet0/ directory (except the unknown file, which is extracted in the root of the output directory, i think because the filename contains also the file path and we don't have it).
Moreover, i don't get another thing, maybe it's a bug: MPE says that in the block_7 (which is the eighth, because numeration starts from zero) there are 1000 files (like the other blocks), but actually there are 169 files. Unpacking and repacking facet0.uop (without the unknown file, because as i said before we must know its name to pack it), MPE reports the right file number in block_7, which is 168 (169-1, the unknown file).
Is there any C# programmer who can help me in upgrading Radstar's tool or someone who wants to help guessing the unknown file's name?
EDIT: ah, i forgot this. Did anyone succeed in logging in using KR client? I tried UOKRLoader (with all encryption combinations), UOSALoader and Cheese but after selecting the shard the client waits until it returns to the login screen. Sphere console says i got disconnected as i double-clicked the shard to log in (or clicked the forward button).
I tried Sphere 0.56c and my old 0.56b (i tried also updating its old spherecrypt), which i remember worked like 3 or 4 years ago, so dunno.