POL HEAD release from GIT - bug in uoconvert

[OWHorus]

Hello,

I tried this on Windows and on Linux, with new compiled POL releases, GIT from today:

We use UO-ML, client 5.06a. I also have a version 6.x here, the difference is, that in V5 map1.mul does not exist (but is created with dif-files), in version 6 map1.mul exists.
I have both versions on my disk, we use version 5.

Normally the path in pol.cfg points to the version 5 UO installation. We use no custom maps, but have edited the statics a bit. This is in the staticX.mul.

uoconvert multis/tiles/landtiles - seems to work normally.

But the options in the command line for uoconvert are ignored. The correct line for mapid=0 is for us:
uoconvert map realm=britannia mapid=0 usedif=1 width=7168 height=4096

The output from uoconvert (newest core, runs on Windows 7):

Code: Select all

Reading pol.cfg.
Reading uoconvert.cfg.
Creating map base and solids files.
  Realm: britannia
  Map ID: 0
  Use Dif files: No
  Size: 6144x4096
Initializing files: Done.
  Reading mapfiles time: 667 ms.
Conversion complete.
Conversion details:
  Total blocks: 98304
  Blocks with solids: 39503 (40%)
  Blocks without solids: 58801 (59%)
  Locations with solids: 4956000
  Total number of solids: 5234216
  Elapsed time: 18873 ms.

As you can see - it ignores the different width and uses 6144.

The command for Ilshenar (mapid=2):
uoconvert map realm=ilshenar mapid=2 usedif=1 width=2304 height=1600

shows the output:

Code: Select all

Reading pol.cfg.
Reading uoconvert.cfg.
Creating map base and solids files.
  Realm: ilshenar
  Map ID: 0
  Use Dif files: No
  Size: 6144x4096
Initializing files: Done.
  Reading mapfiles time: 673 ms.
Conversion complete.
Conversion details:
  Total blocks: 98304
  Blocks with solids: 39503 (40%)
  Blocks without solids: 58801 (59%)
  Locations with solids: 4956000
  Total number of solids: 5234216
  Elapsed time: 18712 ms.

As you can see - the input values for mapid, widht and height are ignored. It also writes the wrong values to realm.cfg.

Next I copied all the .mul files to Linux (binary copy, files have the same size) and tried uoconvert in its Linux version.
The result is the same - input parameters are ignored, except the realm name. The realm name is correct.

Interesting is also, that on Linux the same map (map0.mul, britannia, mapid=0) gives different values for the blocks:

Code: Select all

Reading pol.cfg.
Reading uoconvert.cfg.
Creating map base and solids files.
  Realm: britannia
  Map ID: 0
  Use Dif files: No
  Size: 6144x4096
Initializing files: Done.
  Reading mapfiles time: 232 ms.
Conversion complete.
Conversion details:
  Total blocks: 98304
  Blocks with solids: 38228 (38%)
  Blocks without solids: 60076 (61%)
  Locations with solids: 3361575
  Total number of solids: 3509456
  Elapsed time: 17084 ms.

If you compare this values to the values for mapid=0 above, the errors (ignored mapid, width, height) are the same, the total block count too, but the number of blocks with solids, blocks without solids, and so on differs.
So the tool behaves different in Windows and Linux with the same maps. POL will not work with this realm files. I use my old generated map files from the last core, this seems to work...

When I change the UO folder in pol.cfg to the version 6 UO, the result is the same.

UO-Fiddler shows the map also only up to 6144, but I just tried it and with the new core I can go over 6144, and there are a few things. So the map is okay, and the old realm files from an older POL work. So the width is indeed 7168 as it should be in UO-ML.

OWHorus

[Nando]

Thanks for the report, I'm looking into it.

[Nando]

This should be fixed now (thanks Turley!). Could you confirm?

[OWHorus]

Tested it under Windows and under Linux (after recompiling both):

Seems to work now!

Comment: UseHSAFiles is important - the results differ, when I change this (default according to documentation = 0, but uoconvert.cfg has it set to 1, when delivered). I set it to 0, because we use UO-ML.

I copied all the mul/idx files to Linux, checked them with MD5, and converted them - results are equal, options are read correctly. I checked the resulting files on Windows and Linux, using a MD5-Tool, they are identical.

Thank you!

OWHorus