SphereServer BugTracker - SphereServer
View Issue Details
0001450SphereServerexecutable - genericpublic14-07-08 00:5219-04-09 03:12
mert 
 
normalminoralways
closedno change required 
 
 
08-02-2008
None
None
0001450: Ladders & Some Walls.
Ladders: Ladders do not update my Z position. So If i climb up a ladder and i check my

. i am still 'on the group'... wich checks when I .update.

Walls: Some walls (ex: sandstone patio house 2nd floor) don't act as walls... so you can just run through em and fall.. this doesn't apply to all sides (only down and up - same dispid (this is from memory)).

No tags attached.
Issue History
14-07-08 00:52mertNew Issue
14-07-08 00:52mertNightly Version => 08-02-2008
14-07-08 00:52mertExperimental Flags => None
14-07-08 00:52mertOption Flags => None
19-04-09 03:12MrSugarCubeStatusnew => closed
19-04-09 03:12MrSugarCubeNote Added: 0000188
19-04-09 03:12MrSugarCubeResolutionopen => no change required

Notes
(0000188)
MrSugarCube   
19-04-09 03:12   
The wall issue is a problem with the multi/tiledata mul files, it appears that the 'Impassable' flag has been removed from the sandstone walls in some of the 'more recent' UO data files (even the client believes it should be capable of walking off otherwise it wouldn't let you try). The best solution would be to either change the multi definition to use different walls (01ec could be replaced with 01b1, as they appear to be identical except for the 'Impassable' flag), or change your tiledata to restore the Impassable flag (0x40).

For a solution that doesn't involve editing mul files then you could change your ITEMDEF so that the CAN_I_BLOCK flag is specified in the CAN flags. This will cause Sphere to block the movement but not prevent clients from attempting to walk (they will see an apparent 'rubberbanding' effect). For example the ITEMDEF for 01ec may be changed to look like:

[ITEMDEF 01ec]
//wall
DEFNAME=i_wall_sandstone_01ec
TYPE=T_WALL
CAN=CAN_I_BLOCK
RESOURCES=100 i_stone_sand
CATEGORY=Buildings - Walls
SUBSECTION=Sandstone Wall
DESCRIPTION=@



As for ladders, I believe the issue you're describing may have already been resolved in the latest build although it is not too clear [to me] as to what you mean. If this is still a problem in the latest build then more details will be required (Experimental/Option flags, Ladder IDs, reproduction steps, etc).