0001781: Problem about walk protection system (walkbuffer)

(0000536)
trinax (reporter)
03-08-10 19:58
edited on: 04-08-10 14:43

This also happens while trying to pass inside an invisible impassable item.

(0000546)
ShiryuX (developer)
10-08-10 08:26

Seems I found the problem about this one. Just sent the fix to the SVN (you might have to wait until tomorrow for the automated build). If the error wasn't fixed with that, reopen this ticket with feedback status.

Thank you.

(0000551)
trinax (reporter)
11-08-10 12:57

Thanks for the fix, the problem is gone when using statf_freeze etc. which was the main problem that affected the players most.

But it still exists when you try to pass inside an invisible, impassable item.

It also happens when you turn GM off and try to pass inside an item which you were able to pass when gm is on, like guildstones.

(0000579)
ShiryuX (developer)
20-08-10 08:16

Client 6.0.7.0: The client denies the walk request directly.
Client 5.0.9.1: The client let me ask (0x02), the server denies (0x21).

Is true, you get some rubberbanding, but that's expected since there's a normal connection delay, will look like you're moving but after the client receives the reject packet the client will return to his correct position. Anyway, I cannot reproduce, neither with invisible object or turning on/off GM (using c_body_gm). Can you attach SpyUO to your client and make a log when the error happens?

(0000580)
khaos (developer)
20-08-10 08:24

It is a simple fix I believe Trinax. Simply test with .update after each issue. It should resend everything and you should not be rubberbanding or walking through things you shouldn't, etc.

Ex1. Paralyze self, update, you shouldn't be able to move.
Ex2. Unparalyze, update, you shouldn't be frozen.
Ex3. After you turn .gm off, update as well.

As ShiryuX said, if there is still issues SpyUO will record it and ShiryuX or someone can get a better idea on how to resolve the issue.

(0000581)
trinax (reporter)
20-08-10 08:55

The paralyze stuff is already fixed, the problem now is the items that client think they are passable but actually they are not.(update will probably fix that after turning the .gm off of course but still if players try to run through a invisible item it becomes a problem)

I am not able to reach any uo client now but ill post feedback as soon as possible.

The problem is sphere still increases the walk limit stuff altough it sends "reject moving" packet to the client. You can see it by putting this to an event ->

on=@UserExWalkLimit
src.sysmessage Over Limit!

I am using 2.0.3 while testing by the way. I will post spyuo thing when I am able to.

(0000653)
ShiryuX (developer)
20-09-10 18:36

Were you able to record the packets?
Maybe you can test if it is fixed in the last nightly?

(0000899)
trinax (reporter)
09-02-11 15:22
edited on: 09-02-11 15:34

r1411 Linux & Windows

Still the same as I said above. The paralyze stuff is already fixed, the only problem now is the items that client think they are passable but actually they are not.(I.E. Trying to pass an invisible item that is impassable (still passable when .GM is on))

"Limiti astiniz!" means "Over Limit!".
SpyUO screenshot with everything on except packet 72:

http://img511.imageshack.us/img511/7713/heypng.png [^]

(0000953)
trinax (reporter)
10-03-11 00:50

Problem still exists as of r1420.

(0000955)
trinax (reporter)
10-03-11 12:49

It also happens when your stam is 0.

(0000984)
trinax (reporter)
27-03-11 17:25
edited on: 27-03-11 17:33

Can some1 else do this? It's very annoying for players and it appears Shiryux does not care about development of sphere.

P.S. I would like to join the sphere dev team. I have a few projects in c++. I believe developing sphereserver will both make it better and help me learn about multiplayer engines/networking. Where should I contact?

(0000985)
ShiryuX (developer)
27-03-11 19:01

I asked for packet log. Where's the log?
Saying "ShiryuX does not care about Sphere development" is pretty stupid after all I've done for Sphere, though.

By the way, let me guess, it only happens with older clients :)

(0000986)
trinax (reporter)
28-03-11 00:04
edited on: 28-03-11 01:40

Maybe if you read comments there is the log just up there. It took a long time to post it.
I am saying you do not care about dev. because I haven't see your name in SVN changelog for a long time, if you are doing hiddenly then sorry.
Yes you guessed right it happens on 2.0.3 so, I assume that is why you don't really pay attention to this, lets just not fix it and leave it assigned huh?

(0000987)
ShiryuX (developer)
28-03-11 02:10

I can't see images from ImageShack, is easier to work with text logs by the way.
No need for explanation but I was on vacations and been working on AI.

So, this is the problem: The newer clients forbid you to request the step when they know there's a blocking object, the older clients don't work like that, they just let you walk, then the server says "no, you can't walk to there" and puts you back in the last tile, so the bounce is expected.

(0000988)
trinax (reporter)
28-03-11 02:14
edited on: 28-03-11 02:49

I was also unavailable thats why it took months to took the ss.

Anyway I uploaded the screenshot.

I hope you can prevent the walk check stuff take action if packet 21 is sent. Because it is not always about objects, every movement rejection is affected by this. (i.e. when stamina=0, or something like @enter return 1 under region, I am not sure if newer clients will also expect that and prevent movement)

Besides, 2.0.3 also forbids you from movement when a blocking object is on the way. I described the problem many times above: (I.E. Trying to pass an invisible item that is impassable, or some passable items that are made impassable for just for a condition with the script(via @step or something))

This is the problem: when the character's movement is prevented in -any- way, walk checking codes should not be in action.

Any movement allowing/denying should be checked -before- the walk-regen codes, doing otherwise is a bug/mistake/miscoding because it mostly kills the point/precision of the walk-regen codes by making players freeze longer. Therefore, I have to use higher values for walk-regen etc. and players start to use speed at a low rate and then walk-regen becomes an non-efficient code that does not do its job well.

P.S. I don't know how can I point out the importance of this bug more.

(0001077)
Cloud_007 (reporter)
17-05-11 18:06

I might be off but as far as I know older clients (such as 2.0.3) send a packet asking if you can move or not. Therefore it's not Sphere's bug since it can not prevent the client from sending this walk checking packet. If sphere doesn't respond to the packet then I believe it would create an unwanted behavior.

(0001078)
trinax (reporter)
17-05-11 18:34
edited on: 17-05-11 18:34

I am not saying sphere shouldn't respond to the packet. It should not consider it as a "valid walk" and change the value of the buffer (or whatever it is doing to control extra movement that is done via speeding). So that players won't stuck for a while after trying to move into an invalid location (client sends "movement request" packets too fast and therefore sphere thinks client is moving too fast, but actually it is not moving)

(0001079)
Cloud_007 (reporter)
17-05-11 19:11

Ohhh, I thought you were talking about the walk-check packets.

I'm sorry, I guess I should have read more carefully.

(0002145)
Ben (manager)
03-05-14 17:52

Rejected moves should now not count for walkbuffer

Issue History
Date Modified	Username	Field	Change
17-07-10 11:49	trinax	New Issue
17-07-10 11:49	trinax	Nightly Version	=> 20-09-2009
17-07-10 11:49	trinax	Experimental Flags	=> DiagonalWalkCheck, New_Triggers, WalkCheck, AllowTelnetPacketFilter
17-07-10 11:49	trinax	Option Flags	=> Command_Sysmsgs, FileCommands, NoHouseMuteSpeech
03-08-10 19:58	trinax	Note Added: 0000536
04-08-10 14:43	trinax	Note Edited: 0000536
10-08-10 08:26	ShiryuX	Status	new => resolved
10-08-10 08:26	ShiryuX	Resolution	open => fixed
10-08-10 08:26	ShiryuX	Assigned To	=> ShiryuX
10-08-10 08:26	ShiryuX	Note Added: 0000546
11-08-10 12:57	trinax	Status	resolved => feedback
11-08-10 12:57	trinax	Resolution	fixed => reopened
11-08-10 12:57	trinax	Note Added: 0000551
20-08-10 08:16	ShiryuX	Note Added: 0000579
20-08-10 08:24	khaos	Note Added: 0000580
20-08-10 08:55	trinax	Note Added: 0000581
20-09-10 18:36	ShiryuX	Note Added: 0000653
09-02-11 15:22	trinax	Note Added: 0000899
09-02-11 15:22	trinax	Status	feedback => assigned
09-02-11 15:23	trinax	Note Edited: 0000899	View Revisions
09-02-11 15:23	trinax	Note Edited: 0000899	View Revisions
09-02-11 15:34	trinax	Note Edited: 0000899	View Revisions
10-02-11 14:25	trinax	Issue Monitored: trinax
10-03-11 00:50	trinax	Note Added: 0000953
10-03-11 12:49	trinax	Note Added: 0000955
27-03-11 17:25	trinax	Note Added: 0000984
27-03-11 17:25	trinax	Note Edited: 0000984	View Revisions
27-03-11 17:33	trinax	Note Edited: 0000984	View Revisions
27-03-11 19:01	ShiryuX	Note Added: 0000985
28-03-11 00:04	trinax	Note Added: 0000986
28-03-11 01:36	trinax	Note Edited: 0000986	View Revisions
28-03-11 01:38	trinax	Note Edited: 0000986	View Revisions
28-03-11 01:38	trinax	Note Edited: 0000986	View Revisions
28-03-11 01:38	trinax	Note Edited: 0000986	View Revisions
28-03-11 01:40	trinax	Note Edited: 0000986	View Revisions
28-03-11 02:10	ShiryuX	Note Added: 0000987
28-03-11 02:14	trinax	Note Added: 0000988
28-03-11 02:14	trinax	File Added: heypng.png
28-03-11 02:22	trinax	Note Edited: 0000988	View Revisions
28-03-11 02:23	trinax	Note Edited: 0000988	View Revisions
28-03-11 02:23	trinax	Note Edited: 0000988	View Revisions
28-03-11 02:27	trinax	Note Edited: 0000988	View Revisions
28-03-11 02:34	trinax	Note Edited: 0000988	View Revisions
28-03-11 02:37	trinax	Note Edited: 0000988	View Revisions
28-03-11 02:39	trinax	Note Edited: 0000988	View Revisions
28-03-11 02:40	trinax	Note Edited: 0000988	View Revisions
28-03-11 02:40	trinax	Note Edited: 0000988	View Revisions
28-03-11 02:42	trinax	Note Edited: 0000988	View Revisions
28-03-11 02:45	trinax	Note Edited: 0000988	View Revisions
28-03-11 02:45	trinax	Note Edited: 0000988	View Revisions
28-03-11 02:47	trinax	Note Edited: 0000988	View Revisions
28-03-11 02:47	trinax	Note Edited: 0000988	View Revisions
28-03-11 02:49	trinax	Note Edited: 0000988	View Revisions
17-05-11 18:06	Cloud_007	Note Added: 0001077
17-05-11 18:34	trinax	Note Added: 0001078
17-05-11 18:34	trinax	Note Edited: 0001078	View Revisions
17-05-11 18:34	trinax	Note Edited: 0001078	View Revisions
17-05-11 19:11	Cloud_007	Note Added: 0001079
03-05-14 17:52	Ben	Note Added: 0002145
03-05-14 17:52	Ben	Status	assigned => resolved
03-05-14 17:52	Ben	Fixed in Version	=> 0.56c Nightly
03-05-14 17:52	Ben	Resolution	reopened => fixed

Notes
(0000536) trinax (reporter) 03-08-10 19:58 edited on: 04-08-10 14:43	This also happens while trying to pass inside an invisible impassable item.

(0000546) ShiryuX (developer) 10-08-10 08:26	Seems I found the problem about this one. Just sent the fix to the SVN (you might have to wait until tomorrow for the automated build). If the error wasn't fixed with that, reopen this ticket with feedback status. Thank you.

(0000551) trinax (reporter) 11-08-10 12:57	Thanks for the fix, the problem is gone when using statf_freeze etc. which was the main problem that affected the players most. But it still exists when you try to pass inside an invisible, impassable item. It also happens when you turn GM off and try to pass inside an item which you were able to pass when gm is on, like guildstones.

(0000579) ShiryuX (developer) 20-08-10 08:16	Client 6.0.7.0: The client denies the walk request directly. Client 5.0.9.1: The client let me ask (0x02), the server denies (0x21). Is true, you get some rubberbanding, but that's expected since there's a normal connection delay, will look like you're moving but after the client receives the reject packet the client will return to his correct position. Anyway, I cannot reproduce, neither with invisible object or turning on/off GM (using c_body_gm). Can you attach SpyUO to your client and make a log when the error happens?

(0000580) khaos (developer) 20-08-10 08:24	It is a simple fix I believe Trinax. Simply test with .update after each issue. It should resend everything and you should not be rubberbanding or walking through things you shouldn't, etc. Ex1. Paralyze self, update, you shouldn't be able to move. Ex2. Unparalyze, update, you shouldn't be frozen. Ex3. After you turn .gm off, update as well. As ShiryuX said, if there is still issues SpyUO will record it and ShiryuX or someone can get a better idea on how to resolve the issue.

(0000581) trinax (reporter) 20-08-10 08:55	The paralyze stuff is already fixed, the problem now is the items that client think they are passable but actually they are not.(update will probably fix that after turning the .gm off of course but still if players try to run through a invisible item it becomes a problem) I am not able to reach any uo client now but ill post feedback as soon as possible. The problem is sphere still increases the walk limit stuff altough it sends "reject moving" packet to the client. You can see it by putting this to an event -> on=@UserExWalkLimit src.sysmessage Over Limit! I am using 2.0.3 while testing by the way. I will post spyuo thing when I am able to.

(0000653) ShiryuX (developer) 20-09-10 18:36	Were you able to record the packets? Maybe you can test if it is fixed in the last nightly?

(0000899) trinax (reporter) 09-02-11 15:22 edited on: 09-02-11 15:34	r1411 Linux & Windows Still the same as I said above. The paralyze stuff is already fixed, the only problem now is the items that client think they are passable but actually they are not.(I.E. Trying to pass an invisible item that is impassable (still passable when .GM is on)) "Limiti astiniz!" means "Over Limit!". SpyUO screenshot with everything on except packet 72: http://img511.imageshack.us/img511/7713/heypng.png [^]

(0000953) trinax (reporter) 10-03-11 00:50	Problem still exists as of r1420.

(0000955) trinax (reporter) 10-03-11 12:49	It also happens when your stam is 0.

(0000984) trinax (reporter) 27-03-11 17:25 edited on: 27-03-11 17:33	Can some1 else do this? It's very annoying for players and it appears Shiryux does not care about development of sphere. P.S. I would like to join the sphere dev team. I have a few projects in c++. I believe developing sphereserver will both make it better and help me learn about multiplayer engines/networking. Where should I contact?

(0000985) ShiryuX (developer) 27-03-11 19:01	I asked for packet log. Where's the log? Saying "ShiryuX does not care about Sphere development" is pretty stupid after all I've done for Sphere, though. By the way, let me guess, it only happens with older clients :)

(0000986) trinax (reporter) 28-03-11 00:04 edited on: 28-03-11 01:40	Maybe if you read comments there is the log just up there. It took a long time to post it. I am saying you do not care about dev. because I haven't see your name in SVN changelog for a long time, if you are doing hiddenly then sorry. Yes you guessed right it happens on 2.0.3 so, I assume that is why you don't really pay attention to this, lets just not fix it and leave it assigned huh?

(0000987) ShiryuX (developer) 28-03-11 02:10	I can't see images from ImageShack, is easier to work with text logs by the way. No need for explanation but I was on vacations and been working on AI. So, this is the problem: The newer clients forbid you to request the step when they know there's a blocking object, the older clients don't work like that, they just let you walk, then the server says "no, you can't walk to there" and puts you back in the last tile, so the bounce is expected.

(0000988) trinax (reporter) 28-03-11 02:14 edited on: 28-03-11 02:49	I was also unavailable thats why it took months to took the ss. Anyway I uploaded the screenshot. I hope you can prevent the walk check stuff take action if packet 21 is sent. Because it is not always about objects, every movement rejection is affected by this. (i.e. when stamina=0, or something like @enter return 1 under region, I am not sure if newer clients will also expect that and prevent movement) Besides, 2.0.3 also forbids you from movement when a blocking object is on the way. I described the problem many times above: (I.E. Trying to pass an invisible item that is impassable, or some passable items that are made impassable for just for a condition with the script(via @step or something)) This is the problem: when the character's movement is prevented in -any- way, walk checking codes should not be in action. Any movement allowing/denying should be checked -before- the walk-regen codes, doing otherwise is a bug/mistake/miscoding because it mostly kills the point/precision of the walk-regen codes by making players freeze longer. Therefore, I have to use higher values for walk-regen etc. and players start to use speed at a low rate and then walk-regen becomes an non-efficient code that does not do its job well. P.S. I don't know how can I point out the importance of this bug more.

(0001077) Cloud_007 (reporter) 17-05-11 18:06	I might be off but as far as I know older clients (such as 2.0.3) send a packet asking if you can move or not. Therefore it's not Sphere's bug since it can not prevent the client from sending this walk checking packet. If sphere doesn't respond to the packet then I believe it would create an unwanted behavior.

(0001078) trinax (reporter) 17-05-11 18:34 edited on: 17-05-11 18:34	I am not saying sphere shouldn't respond to the packet. It should not consider it as a "valid walk" and change the value of the buffer (or whatever it is doing to control extra movement that is done via speeding). So that players won't stuck for a while after trying to move into an invalid location (client sends "movement request" packets too fast and therefore sphere thinks client is moving too fast, but actually it is not moving)

(0001079) Cloud_007 (reporter) 17-05-11 19:11	Ohhh, I thought you were talking about the walk-check packets. I'm sorry, I guess I should have read more carefully.

(0002145) Ben (manager) 03-05-14 17:52	Rejected moves should now not count for walkbuffer

Relationships