|
Notes |
|
|
|
That's just virtual. A timing problem: You're entering the gate, and Sphere sends you to the new coordinates. Sphere will not send any "walk allowed" packets after that, and will not move you into a new position. But the client, what hasn't realized that the char is somewhere else now, still "assumes" that it's on the old position and therefore executes the walk (without waiting for Sphere to allow it - the walkbuffer related "rubberband" effect".
If you stop at the right moment, the client believes, you're at destination position plus one or two steps. In other words: Your positions in the client and in the server are unaligned. Therefore it may look as if you passed thru the wall, but in reality (defined by the server) you're not. Just try it and type ".fix" or ".update" and you'll see
Of course the server will not allow you to for example handle a container inside of the house, because there's no LOS - even if the client displays one |
|
|
|
(0000131)
|
|
Coruja
|
|
03-11-08 01:34
|
|
"Therefore it may look as if you passed thru the wall, but in reality (defined by the server) you're not. Just try it and type ".fix" or ".update" and you'll see"
But there's a problem.. The player passed over a world static (uo map) wall without problems, he doesn't get stucked on wall without a client update, because using 'update' or 'fix' will not make the player goes back to the other side of the wall. |
|
|
|
(0000132)
|
|
Balrog
|
|
03-11-08 17:12
|
|
If the problem doesn't fix when you use .fix or .update, then the problem is that the server doesn't have the same multis.mul file as the client. So, for the server, there is no wall there, and if you log in without that multis.mul file, you could walk in the region without problems.
I am not having your problem with the last nightly version. |
|
|
|
(0000133)
|
|
Coruja
|
|
14-11-08 19:19
|
|
|
This problem doesn't occour only on multis. Sometimes ppl walk over house walls (multi.mul), sometimes over world-static walls (mapX.mul). Using same client and server files. |
|
|
|
(0002557)
|
|
XuN
|
|
02-11-14 16:16
|
|
|
Is this still happening Coruja? |
|
|
|
(0002784)
|
|
Coruja
|
|
01-05-15 20:59
|
|
that's a old bug from many years ago (2008), since then I'm using TAG.NOMOVETILL=<eval <SERV.TIME>+2> after GO functions as workaround
but a month ago I removed this workaround from the script and it seems to be working fine, so maybe we can consider it fixed |
|