SphereServer BugTracker - SphereServer
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0001781SphereServerexecutable - genericpublic17-07-10 11:4903-05-14 17:52
Reportertrinax 
Assigned ToShiryuX 
PrioritynormalSeveritymajorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version20-09-2009, 0.56b Prerelease 
Target VersionFixed in Version0.56c Nightly 
Nightly Version20-09-2009
Experimental FlagsDiagonalWalkCheck, New_Triggers, WalkCheck, AllowTelnetPacketFilter
Option FlagsCommand_Sysmsgs, FileCommands, NoHouseMuteSpeech
Internal Build Number
Summary0001781: Problem about walk protection system (walkbuffer)
DescriptionWhen you are frozen with paraylze spell or with the flag manually added, if you try to run, altough you don't move it assumes like you are moving and makes you freeze even when you are actually able to move.

It is in nightly, I don't know about SVN.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filespng heypng.png (93,979) 28-03-11 02:14
http://tracker.sphere.torfo.org/bugs/file_download.php?file_id=60&type=bug
png
Issue History
Date ModifiedUsernameFieldChange
17-07-10 11:49trinaxNew Issue
17-07-10 11:49trinaxNightly Version => 20-09-2009
17-07-10 11:49trinaxExperimental Flags => DiagonalWalkCheck, New_Triggers, WalkCheck, AllowTelnetPacketFilter
17-07-10 11:49trinaxOption Flags => Command_Sysmsgs, FileCommands, NoHouseMuteSpeech
03-08-10 19:58trinaxNote Added: 0000536
04-08-10 14:43trinaxNote Edited: 0000536
10-08-10 08:26ShiryuXStatusnew => resolved
10-08-10 08:26ShiryuXResolutionopen => fixed
10-08-10 08:26ShiryuXAssigned To => ShiryuX
10-08-10 08:26ShiryuXNote Added: 0000546
11-08-10 12:57trinaxStatusresolved => feedback
11-08-10 12:57trinaxResolutionfixed => reopened
11-08-10 12:57trinaxNote Added: 0000551
20-08-10 08:16ShiryuXNote Added: 0000579
20-08-10 08:24khaosNote Added: 0000580
20-08-10 08:55trinaxNote Added: 0000581
20-09-10 18:36ShiryuXNote Added: 0000653
09-02-11 15:22trinaxNote Added: 0000899
09-02-11 15:22trinaxStatusfeedback => assigned
09-02-11 15:23trinaxNote Edited: 0000899bug_revision_view_page.php?bugnote_id=0000899#r107
09-02-11 15:23trinaxNote Edited: 0000899bug_revision_view_page.php?bugnote_id=0000899#r108
09-02-11 15:34trinaxNote Edited: 0000899bug_revision_view_page.php?bugnote_id=0000899#r109
10-02-11 14:25trinaxIssue Monitored: trinax
10-03-11 00:50trinaxNote Added: 0000953
10-03-11 12:49trinaxNote Added: 0000955
27-03-11 17:25trinaxNote Added: 0000984
27-03-11 17:25trinaxNote Edited: 0000984bug_revision_view_page.php?bugnote_id=0000984#r202
27-03-11 17:33trinaxNote Edited: 0000984bug_revision_view_page.php?bugnote_id=0000984#r203
27-03-11 19:01ShiryuXNote Added: 0000985
28-03-11 00:04trinaxNote Added: 0000986
28-03-11 01:36trinaxNote Edited: 0000986bug_revision_view_page.php?bugnote_id=0000986#r205
28-03-11 01:38trinaxNote Edited: 0000986bug_revision_view_page.php?bugnote_id=0000986#r206
28-03-11 01:38trinaxNote Edited: 0000986bug_revision_view_page.php?bugnote_id=0000986#r207
28-03-11 01:38trinaxNote Edited: 0000986bug_revision_view_page.php?bugnote_id=0000986#r208
28-03-11 01:40trinaxNote Edited: 0000986bug_revision_view_page.php?bugnote_id=0000986#r209
28-03-11 02:10ShiryuXNote Added: 0000987
28-03-11 02:14trinaxNote Added: 0000988
28-03-11 02:14trinaxFile Added: heypng.png
28-03-11 02:22trinaxNote Edited: 0000988bug_revision_view_page.php?bugnote_id=0000988#r211
28-03-11 02:23trinaxNote Edited: 0000988bug_revision_view_page.php?bugnote_id=0000988#r212
28-03-11 02:23trinaxNote Edited: 0000988bug_revision_view_page.php?bugnote_id=0000988#r213
28-03-11 02:27trinaxNote Edited: 0000988bug_revision_view_page.php?bugnote_id=0000988#r214
28-03-11 02:34trinaxNote Edited: 0000988bug_revision_view_page.php?bugnote_id=0000988#r215
28-03-11 02:37trinaxNote Edited: 0000988bug_revision_view_page.php?bugnote_id=0000988#r216
28-03-11 02:39trinaxNote Edited: 0000988bug_revision_view_page.php?bugnote_id=0000988#r217
28-03-11 02:40trinaxNote Edited: 0000988bug_revision_view_page.php?bugnote_id=0000988#r218
28-03-11 02:40trinaxNote Edited: 0000988bug_revision_view_page.php?bugnote_id=0000988#r219
28-03-11 02:42trinaxNote Edited: 0000988bug_revision_view_page.php?bugnote_id=0000988#r220
28-03-11 02:45trinaxNote Edited: 0000988bug_revision_view_page.php?bugnote_id=0000988#r221
28-03-11 02:45trinaxNote Edited: 0000988bug_revision_view_page.php?bugnote_id=0000988#r222
28-03-11 02:47trinaxNote Edited: 0000988bug_revision_view_page.php?bugnote_id=0000988#r223
28-03-11 02:47trinaxNote Edited: 0000988bug_revision_view_page.php?bugnote_id=0000988#r224
28-03-11 02:49trinaxNote Edited: 0000988bug_revision_view_page.php?bugnote_id=0000988#r225
17-05-11 18:06Cloud_007Note Added: 0001077
17-05-11 18:34trinaxNote Added: 0001078
17-05-11 18:34trinaxNote Edited: 0001078bug_revision_view_page.php?bugnote_id=0001078#r309
17-05-11 18:34trinaxNote Edited: 0001078bug_revision_view_page.php?bugnote_id=0001078#r310
17-05-11 19:11Cloud_007Note Added: 0001079
03-05-14 17:52BenNote Added: 0002145
03-05-14 17:52BenStatusassigned => resolved
03-05-14 17:52BenFixed in Version => 0.56c Nightly
03-05-14 17:52BenResolutionreopened => fixed

Notes
(0000536)
trinax   
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   
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   
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   
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   
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   
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   
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   
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   
10-03-11 00:50   
Problem still exists as of r1420.
(0000955)
trinax   
10-03-11 12:49   
It also happens when your stam is 0.
(0000984)
trinax   
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   
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   
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   
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   
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   
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   
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   
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   
03-05-14 17:52   
Rejected moves should now not count for walkbuffer