Main | My View | View Issues | Change Log | Roadmap
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001530SphereServerexecutable - genericpublic06-10-08 01:1501-05-15 20:59
ReporterCoruja 
Assigned ToCoruja 
PrioritynormalSeveritymajorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0001530: Problem with GO functions
DescriptionSometimes the function GO allow ppl to make 'exploits' on structures and terrains.

Example: I entered on a moongate that use GO to send me to a dest near to a house wall. If I enter on this gate running, and don't stop running after enter on gate, I will get some chance to pass through the destination house wall, like if Sphere allow the walk packet because it's think that I not entered on the gate.

The problem doesn't occour only on houses (multis), this can occour on map/statics items too.
TagsNo tags attached.
Nightly Version09-09-2008
Experimental FlagsNone
Option FlagsNone
Internal Build Number
Attached Files

- Relationships

-  Notes
(0000104)
nazghul (developer)
06-10-08 02:39

 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 (developer)
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 (reporter)
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 (developer)
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 (developer)
02-11-14 16:16

 Is this still happening Coruja?
(0002784)
Coruja (developer)
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

- Issue History
Date Modified Username Field Change
06-10-08 01:15 Coruja New Issue
06-10-08 01:15 Coruja Nightly Version => 09-09-2008
06-10-08 01:15 Coruja Experimental Flags => None
06-10-08 01:15 Coruja Option Flags => None
06-10-08 02:39 nazghul Note Added: 0000104
03-11-08 01:34 Coruja Note Added: 0000131
03-11-08 17:12 Balrog Note Added: 0000132
14-11-08 19:19 Coruja Note Added: 0000133
02-11-14 16:16 XuN Note Added: 0002557
01-05-15 20:59 Coruja Note Added: 0002784
01-05-15 20:59 Coruja Status new => resolved
01-05-15 20:59 Coruja Resolution open => fixed
01-05-15 20:59 Coruja Assigned To => Coruja

Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker