Razor-Item problem (16383 limit)

[once]

On our shard, we have a custom map, which has quite unconventional size (that is 28672 x 4096). We use UOML, and the latest razor version (1.0.6), to play on it.

All works just perfect, exept the fact, that when we cross coordinate 16383 basing on zero (0-base), which is 16384 (2^14), the Razor wont let us pick up any items from the map (floor, tables etc.) to characters bacpack/bank/other containers.

What is worse, the client 'thinks', that we have managed to put the item into container, in spite that the item is still on a map, and a client stops showing us the item at all - it dissapears.

Probably, setting a bigger variable to taking care of this sort of things, should do the trick.

Using UOgateway doesn't cause us any problems, and that error accures only when we are playing using Razor.

At the end, I wish to say, that we are very satisfied using razor for so long time, and we hope, that the next razor version will solve our problem.

[Killamus]

Originally Posted by once

What is worse, the client 'thinks', that we have managed to put the item into container, in spite that the item is still on a map, and a client stops showing us the item at all - it dissapears.

That's a client problem; it happens to me all the time when I attempt to move stuff too far (Instead of doing a bounce. This is quite possibly due to the fact that I have an outdated client.... 4.9.9z or something, just before 5.0.0a.) As for the 16383 thing, is it just on that X or Y cord that it happens, or anything above that cord? If it is, I doubt its that big of a problem, but then again, maybe not. I would have thought, however, that it runs off of a 16 bit base, not a 14. 14 is rare, except in video games where there is a limited space for saving. Oh wait, that describes OSI

I really can't offer help here, because I think this is a client issue; not a razor issue. Maybe it'll be fixed in KR. We can only hope.

[once]

huh, i tested this without Razor, running uoml with uogateway :
multitest, same test-place, same test-item : works
next
this same client version, this same @ll - with razor : don`t work.

mayby there is a probem in code like:

    i &= 32767;
    if (byt1 != 0)
    {
        i |= 32768;
    }
    base.Write(((ushort)i));
    i1 &= 16383;
    if (usht2 != 0)
    {
        i1 |= 32768;
    }
    if (byt != 0)
    {
        i1 |= 16384;
    }

[Zippy]

This is a limitation of the UO client->server protocol. I'm really sure how this is even possible without Razor running. This isn't a Razor limitation, the client expects coordinates for items to be shorts (14 bits, to be exact).

It uses the other 2 bits for flags.

Also, please don't decompile Razor. It's not nice.

[once]

ok, sorry for decompile.

[once]

btw, i make all test with another program 'connectuo' and all works good. Only when i`m using Razor i have problem with items bayond 16383x.

so, i think it`s not a client-problem.

[Kenko]

Originally Posted by once

ok, sorry for decompile.

roflExtrachars

[once]

Forum Expert
Rep Power: 38
rotfl

Yep, you are very usefull.
can you answer on my question? no? ups

[Kenko]

ConnectUO has nothing to do with your client.. it just handles to which server you connect or at least I have been told so by the sages

[once]

I know, You right...

my point is:
If client works fine with uogateway and connectuo
and don`t work with Razor...
then, where is problem ?

And Yes, i need Razor, it`s great tool.

Regards.

[Kenko]

well everything points to be that Razor is the problem, but Zippy said it's not a Razor's limitation so it is not a Razor's limitation.

Zippy 4tw <3

[Zippy]

I think I have discovered what the issue is, so I'll look into releasing a fix for it soon.

[once]

thx

Regards