The clientversions 6.0.x.x ( when OSI separated the map0 and map1 ) and higher doesnt use mapdif and staticdif files anymore, and the dif files make the trammel ( britannia_alt ) map unusable.

The realms are working nicely using difs with clientversion up to 5.x.x.x but the problem comes with the 6.x.x version.

Im trying atm. to convert the realms with using no difs and will post my results later, but there maybe have to be made some change in core for cleintversion checks and if version 6.x.x.x it doesnt read the dif files anymore.

I dont know exactly how the UOConvert has been coded, but I assume there is some problems with reading the map1.mul without dif files because Trammel is the only map that seems to be having serious problems.

To point this out, I tried 1 custom map I have, and when using it as realm britannia ( map 0 ) there was no problems, but when I used it as britannia_alt ( map 1 ) there came alot of problems, because I think UOConvert doesnt read the map 1 correctly with map1.mul and it still somehow read the diff files.

okay and the test results for running this with Converted maps when setting use dif to 0.

It didnt work, so there still seems to be something wrong about this map1.mul, could you devs take a look at this problem ?

if you want to reproduce this problem, just patch your client up to version 6, go to britannia_alt and to Haven island and move around, thats the easiest way to see this because thats the part of map that has been changed most.

I even tried to run this with no dif or difl files in UO directory, but still the same problem, so for now with Pol and Clients 6+ its impossible to use map 1 ( britannia_alt ) correctly. Neither a custom map instead of map1.mul

I did one more test trying to stop the server from sending 0xBf packet subpacket 0x18 to use mapdiffs, but that didnt work either, so the problem actually seems to be with how UOConvert handles map1.mul, statics1.mul and staidx1.mul

I dont recall that there were any changes when OSI changed from using Trammel inside diff files to use it as an own map file. So that why there should be a check in UOConvert if map1.mul exist it will no longer read diff.

And there should also be some changes to how the core read map files, if clientversion 6.x the core should not anymore use diff files at all.

Discussion about this topic on RunUO forum and some information:

http://www.runuo.com/forums/general-dis ... patch.html

Any comment from devs, if this will be fixed or ?? because for now at least the map1 is impossible to use due to diff problems with clients with version 6+

tomi, sorry for the delay. I've been reading this post for some time, but thought it was a harder fix so I decided not to answer until I could discuss with someone else. Talking to Turley, he figured out what the problem is: UOConvert is considering uomapid 1 to be map0.mul. I'll see if I can get this fixed today.

As a quick fix, save map0.mul, rename map1.mul to map0.mul and convert without the usedif option. Then you can rename back to map1.mul. Tell me if that works. (I'm almost sure it will work, but...)

[edit]
Oh, Turley just remembered here: staidx and statics also get changed from 1 to 0. So you'll have to rename those, too.
[/edit]

Yes I'm trying atm renamed map1.mul, statics1.mul and staidx1.mul to ...0.mul and convert it as britannia_alt, then just move them back to ..1.mul

I don't know how Pol is using the 0xBF subcommand 0x18 packet to read diffs either, should there be a cfg setting use Diff files or something like that ?

in UoConvert only if map1.mul is available it should read it, but else it should read the diff files for britannia_alt map. Because if you just make it read map1.mul and not the diffs at all anymore it will break the clients < version 6 and same thing why there should be that cfg setting, but that depends on how the core read the diff files.

I will soon post my test results for converting the map1 as map0

in realm.cfg in your realm's dir there's an option: "uodif", that's saved when you run uoconvert. You can make it false by removing the "usedif=1" from command line, or
placing it "usedif=0".

What I changed is the bold part:

if mapid == 1 && map1.mul doesn't exist then filename = map0.mul;

So it should fall back as normal. The difs, as I said above, are used according to your options when running uoconvert. If you run it via StartHere.bat, you can change it in line 100 of RealmGen.bat.

Okay result of my tests are negative, it still doesnt seem to work correctly.

There seems to be something else about handling the map1 ( realm britannia_alt ), because when I logged the packets I saw several 0xBF subpacket 0x18 ( use diff ) be sent from server to client even if I choose UseDiff 0 in UOConvert.

okay I converted the map1.mul renamed as map0.mul and same with static files to realm britannia and then used the same map0.mul ( originally map1.mul and static files as is with the client too ) That time Trammel ( britannia_alt ) worked with no problems, so the problems are only with map1 as it seems to be.

Did one more test with stopping the core from sending the 0xBF 0x18 subpacket by returning it 1 with a packethook but didn't work either.
ON top of that did one more test to remove the diff files totally from client directory while running the client and still the same problem, so it seems to be in the converted files for Pol not on client side, and because it didn't work with using the map1 as map0 and then converting ( I dont know how much they actually are different in file sizes etc. ) but..... I hope this get fixed

Good news Nando, I got it working, forgot to change mapid 0 to mapid 1 after converting as map0. So that means after the fix for UOConvert this problem will be fixed as well.

But anyway the server should stop to send the 0xBF subpacket 0x18 when having UseDif 0 option in UOConvert

POL sends the 0xBF 0x18 packet according to the num_static_patches and num_map_patches, and they're set when uoconvert runs. Don't know what's the problem of sending it with both fields 0.

By the way, you could've just used "mapid 1" renaming map1.mul to map0.mul.

nice thx

Tomi wrote:But anyway the server should stop to send the 0xBF subpacket 0x18 when having UseDif 0 option in UOConvert

Anyone bothered testing this, to see if the CLIENT runs just fine with Tomi's suggestion? Should be doable with a quick and dirty packethook to test, and just some strong determination to make sure client is seeing stuff as it should (without the dif patches) and running fine. Sorry, I can't (more like won't sorry), do this right now only reason explaining how to do it, but not doing it, hehehe

MuadDib I tested this when converting the map1 as map0 and then later on changing the client files back to 1 from 0 and edit the realm.cfg to change mapID 0 to MapID 1.

After that I made the quick and dirty packethook for that subpacket and return 1; so it never sends it.

And with all that the britannia_alt realm worked nicely, I did only try with Haven island because if that's working the other places are aswell becuase Haven has been through the most of changes.

Now I can see the walls that were invisible and blocking me before in the Haven ruins, and I dont fall in any whole either.

I tried also with putting a custom map instead of map1 and now with these changes it worked aswell.

What are you saying? It only worked after you used a packethook to block the 0xBF packet?

Tomi wrote: But anyway the server should stop to send the 0xBF subpacket 0x18 when having UseDif 0 option in UOConvert

Perhaps i didn't understand the problem, but i looked in some of my old UOLog Files and
in my case (3 custom maps all converted with UseDif 0) i get the following packet which
i think simply tells the client that there is no need to load any of these dif files:
At least i never see any OSI statics or map parts on our custom maps (only in UOAM ).

I removed my packethook for 0xBF subpacket 0x18 and it worked as is now too, no need to block it.

And I saw the same thing as Pierce did, it sends the packet full of "0" when convert with UseDif 0

So the fix on uoconvert with map1.mul will fix this problem completely.

Good Any other quirks with the maps that I should know?