0001752: Strange problem with using world items while moving.

(0000471)
Mirravin (reporter)
15-05-10 23:45

With build #1156 I didn't have this problem.

(0000484)
Mirravin (reporter)
31-05-10 05:41
edited on: 01-06-10 05:09

Build #1288, #1291 problem is NOT solved.
OS: Linux.
Ini settings: different(Packet Priority 0/1, Async Network 0/2).

P.s. It is better to test this bug on transport(for example horse).

(0000486)
Mirravin (reporter)
01-06-10 05:24

I found one interesting thing with this bug: after it the char is displayed in incorrect location, usually it "losses 1 step", char is dislayed 1 step before it's real location.
May be the reasons are also connected with the http://tracker.sphere.torfo.org/bugs/view.php?id=1744 [^] reasons.

(0000487)
Mirravin (reporter)
09-06-10 03:47
edited on: 09-06-10 04:04

Tested today with 100% default ini and scripts - the same.
OS - Linux.

Reprodusing isn't difficult:
1) Bind 'lastobject' in client.
2) Drop a container on the ground.
3) Sit on a horse.
4) While running near the container, use lastobject button, you have ~ 5-50%(sometimes it occurs very often, sometimes - not so often) chanse to get desinhronization between the server and client character position(character in client "losses 1 step"), (update fix it).

! This is also 1 from abilities to have this bug. This can be also caused, for example, by casting spells on other characters while running.

Please fix it, when you will have time. This bug causes big problems to players in PVP.

(0000560)
Mirravin (reporter)
15-08-10 13:32

Are somebody planning have a look of this problem?

(0000571)
ShiryuX (developer)
18-08-10 20:23

Could you fill your EF_ and OF_ flags in the report and try using DEBUGF_WALKCODES or DEBUGF_WALK at the DebugFlags settings in the ini? The walkcode is a little complex and I'm still not used to it.

(0000572)
Mirravin (reporter)
18-08-10 21:53

EF_, OF_ flags and other in sphere.ini: default.
I will activate debugs tonight.

(0000574)
Mirravin (reporter)
19-08-10 06:06

Experimental=01|02|08|010000|0800000
OptionFlags=08|0200|080|02000
With DEBUGF_WALK I get huge amount of flood:
07:00:WARNING:CheckValidMove failed
This flood occurs even with 0 clients in game.
With DEBUGF_WALKCODES I can do ~ 3 steps with character. After this character is stopped by server with other flood in console:
06:53:ERROR:4: Invalid walk echo (00). Invalid after valid.

(0000575)
ShiryuX (developer)
19-08-10 10:19

Okay... Maybe I found the problem.
I'll send a little commit right now, tell me if there's any change at build #1308.
Try with packet priority set to 1.

Oh, by the way, if you're using Linux Build, you shouldn't be using EF_UNICODE :P

(0000576)
Mirravin (reporter)
19-08-10 14:58

You are sure about EF_UNICODE? Because warning may be connected with old, resolved problem...

21-03-2009, MrSugarCube
- Fixed: Crashes with EF_Unicode enabled on Linux builds.

(0000578)
Mirravin (reporter)
20-08-10 06:35
edited on: 20-08-10 06:52

Problem is not solved in Injection, but in with naked clients I couldn't reproduse it. I will test this again later.
(internal build #1308, Linux, UsePacketPriority=1)

(0000600)
MrSugarCube (administrator)
25-08-10 17:02

Did this problem ever exist without injection being used, what symptoms are there other than the "step number failure" message?

Both packet logs look perfectly fine to me, except for the part where injection gets upset (presumably because of the two movement requests with sequence "0", but there isn't really anything wrong with that).

(0000601)
Mirravin (reporter)
25-08-10 19:13

In version #1296, that I'm using now, problem exists in all clients: 2.0.3, 6.0.14.3 with and without Razor. Reprodusing it with injection is very simple, but without it I don't know a simple way to reproduse it "with warranty", but it often occurs in PVP. Reason-bug is desinhronization in character coordinates(when the bug occurs, characted losses 1 step and after it is drown in client with 1 tile displacement. "step number failure" in injection is only a marker of it. Also one problem what is caused by position desinhronization is what the characted can't run to the specific direction. To fix this all, client needs a resend.
Also 1 interesting thing, what this problem is connected with one of changes from version #1156 to version #1276 because on version #1156 problem hasn't been, in injection too. If you can provide me with old Linux builds, I can check the bug existance in its to find, that change caused it.
Also I don't know exactly is this problem exist on Windows builds. When we checked it with injection(the simplest way of reprodusing), we didn't find it. But one admin, who using Windows build said me, that his players complained of common problems, caused by this bug(incorrect char location in client, impossibility to move to the specifix direction).

(0000618)
Mirravin (reporter)
10-09-10 11:07

Build #1328, problem is not solved. :(
May be you need some extra information about it?
I can compare game dinamics between version #1156(what haven't this problem) and new version. Also I can play with SpyUO and try to find some interesting in the packet logs when the errors occurs...
What information do you really need?
Also 1 question, is it better for you to test this with client 2.0.3 or 6.0.14.3?

(0000619)
MrSugarCube (administrator)
13-09-10 11:25

A packet log from build #1156 might show if anything has changed in how the movement packets are being sent. It shouldn't matter which client you use as long as the same is used for each log (I assume this problem isn't restricted to specific clients?). It would also be best to get logs without injection running though, as I'm not sure if it could be manipulating the packets we're seeing in the log.

I'm also wondering if this issue could be the same as 0001744, and the "step number failure" message could be a separate problem that needs to be fixed in injection (their forum seems to indicate that the message is or was a not-to-uncommon issue on certain injection builds).

(0000630)
MrSugarCube (administrator)
15-09-10 01:56

It may be worthwhile testing this again on the latest automated build now that 0001744 has been resolved.

(0000631)
Mirravin (reporter)
15-09-10 03:15
edited on: 15-09-10 03:15

With new build #1333 I no longer see any stupid error in injection and strange resends in movement. Yes, I think it is fixed, thank you. (Going to celebrate this historical moment...:))

Issue History
Date Modified	Username	Field	Change
15-05-10 23:38	Mirravin	New Issue
15-05-10 23:38	Mirravin	File Added: report.zip
15-05-10 23:38	Mirravin	Nightly Version	=> Not Available
15-05-10 23:38	Mirravin	Experimental Flags	=> None
15-05-10 23:38	Mirravin	Option Flags	=> None
15-05-10 23:45	Mirravin	Note Added: 0000471
15-05-10 23:52	Incanus	Issue Monitored: Incanus
31-05-10 05:41	Mirravin	Note Added: 0000484
31-05-10 05:41	Mirravin	Note Edited: 0000484
01-06-10 05:09	Mirravin	Note Edited: 0000484
01-06-10 05:24	Mirravin	Note Added: 0000486
09-06-10 03:47	Mirravin	Note Added: 0000487
09-06-10 03:47	Mirravin	Note Edited: 0000487
09-06-10 03:48	Mirravin	Note Edited: 0000487
09-06-10 03:50	Mirravin	Note Edited: 0000487
09-06-10 03:51	Mirravin	Note Edited: 0000487
09-06-10 03:58	Mirravin	Note Edited: 0000487
09-06-10 04:02	Mirravin	Note Edited: 0000487
09-06-10 04:03	Mirravin	Note Edited: 0000487
09-06-10 04:04	Mirravin	Note Edited: 0000487
15-08-10 13:32	Mirravin	Note Added: 0000560
18-08-10 20:23	ShiryuX	Note Added: 0000571
18-08-10 21:53	Mirravin	Note Added: 0000572
19-08-10 06:06	Mirravin	Note Added: 0000574
19-08-10 10:19	ShiryuX	Note Added: 0000575
19-08-10 14:58	Mirravin	Note Added: 0000576
20-08-10 06:35	Mirravin	Note Added: 0000578
20-08-10 06:52	Mirravin	Note Edited: 0000578
23-08-10 17:27	MrSugarCube	Priority	normal => high
25-08-10 17:02	MrSugarCube	Note Added: 0000600
25-08-10 19:13	Mirravin	Note Added: 0000601
10-09-10 11:07	Mirravin	Note Added: 0000618
13-09-10 11:25	MrSugarCube	Note Added: 0000619
13-09-10 11:26	MrSugarCube	Relationship added	related to 0001744
15-09-10 01:56	MrSugarCube	Note Added: 0000630
15-09-10 03:15	Mirravin	Note Added: 0000631
15-09-10 03:15	Mirravin	Note Edited: 0000631	View Revisions
15-09-10 11:58	MrSugarCube	Status	new => resolved
15-09-10 11:58	MrSugarCube	Fixed in Version	=> 0.56c Nightly
15-09-10 11:58	MrSugarCube	Resolution	open => fixed
15-09-10 11:58	MrSugarCube	Assigned To	=> MrSugarCube
14-11-10 19:54	MrSugarCube	Category	executable - linux => executable - linux build

Notes
(0000471) Mirravin (reporter) 15-05-10 23:45	With build #1156 I didn't have this problem.

(0000484) Mirravin (reporter) 31-05-10 05:41 edited on: 01-06-10 05:09	Build #1288, #1291 problem is NOT solved. OS: Linux. Ini settings: different(Packet Priority 0/1, Async Network 0/2). P.s. It is better to test this bug on transport(for example horse).

(0000486) Mirravin (reporter) 01-06-10 05:24	I found one interesting thing with this bug: after it the char is displayed in incorrect location, usually it "losses 1 step", char is dislayed 1 step before it's real location. May be the reasons are also connected with the http://tracker.sphere.torfo.org/bugs/view.php?id=1744 [^] reasons.

(0000487) Mirravin (reporter) 09-06-10 03:47 edited on: 09-06-10 04:04	Tested today with 100% default ini and scripts - the same. OS - Linux. Reprodusing isn't difficult: 1) Bind 'lastobject' in client. 2) Drop a container on the ground. 3) Sit on a horse. 4) While running near the container, use lastobject button, you have ~ 5-50%(sometimes it occurs very often, sometimes - not so often) chanse to get desinhronization between the server and client character position(character in client "losses 1 step"), (update fix it). ! This is also 1 from abilities to have this bug. This can be also caused, for example, by casting spells on other characters while running. Please fix it, when you will have time. This bug causes big problems to players in PVP.

(0000560) Mirravin (reporter) 15-08-10 13:32	Are somebody planning have a look of this problem?

(0000571) ShiryuX (developer) 18-08-10 20:23	Could you fill your EF_ and OF_ flags in the report and try using DEBUGF_WALKCODES or DEBUGF_WALK at the DebugFlags settings in the ini? The walkcode is a little complex and I'm still not used to it.

(0000572) Mirravin (reporter) 18-08-10 21:53	EF_, OF_ flags and other in sphere.ini: default. I will activate debugs tonight.

(0000574) Mirravin (reporter) 19-08-10 06:06	Experimental=01\|02\|08\|010000\|0800000 OptionFlags=08\|0200\|080\|02000 With DEBUGF_WALK I get huge amount of flood: 07:00:WARNING:CheckValidMove failed This flood occurs even with 0 clients in game. With DEBUGF_WALKCODES I can do ~ 3 steps with character. After this character is stopped by server with other flood in console: 06:53:ERROR:4: Invalid walk echo (00). Invalid after valid.

(0000575) ShiryuX (developer) 19-08-10 10:19	Okay... Maybe I found the problem. I'll send a little commit right now, tell me if there's any change at build #1308. Try with packet priority set to 1. Oh, by the way, if you're using Linux Build, you shouldn't be using EF_UNICODE :P

(0000576) Mirravin (reporter) 19-08-10 14:58	You are sure about EF_UNICODE? Because warning may be connected with old, resolved problem... 21-03-2009, MrSugarCube - Fixed: Crashes with EF_Unicode enabled on Linux builds.

(0000578) Mirravin (reporter) 20-08-10 06:35 edited on: 20-08-10 06:52	Problem is not solved in Injection, but in with naked clients I couldn't reproduse it. I will test this again later. (internal build #1308, Linux, UsePacketPriority=1)

(0000600) MrSugarCube (administrator) 25-08-10 17:02	Did this problem ever exist without injection being used, what symptoms are there other than the "step number failure" message? Both packet logs look perfectly fine to me, except for the part where injection gets upset (presumably because of the two movement requests with sequence "0", but there isn't really anything wrong with that).

(0000601) Mirravin (reporter) 25-08-10 19:13	In version #1296, that I'm using now, problem exists in all clients: 2.0.3, 6.0.14.3 with and without Razor. Reprodusing it with injection is very simple, but without it I don't know a simple way to reproduse it "with warranty", but it often occurs in PVP. Reason-bug is desinhronization in character coordinates(when the bug occurs, characted losses 1 step and after it is drown in client with 1 tile displacement. "step number failure" in injection is only a marker of it. Also one problem what is caused by position desinhronization is what the characted can't run to the specific direction. To fix this all, client needs a resend. Also 1 interesting thing, what this problem is connected with one of changes from version #1156 to version #1276 because on version #1156 problem hasn't been, in injection too. If you can provide me with old Linux builds, I can check the bug existance in its to find, that change caused it. Also I don't know exactly is this problem exist on Windows builds. When we checked it with injection(the simplest way of reprodusing), we didn't find it. But one admin, who using Windows build said me, that his players complained of common problems, caused by this bug(incorrect char location in client, impossibility to move to the specifix direction).

(0000618) Mirravin (reporter) 10-09-10 11:07	Build #1328, problem is not solved. :( May be you need some extra information about it? I can compare game dinamics between version #1156(what haven't this problem) and new version. Also I can play with SpyUO and try to find some interesting in the packet logs when the errors occurs... What information do you really need? Also 1 question, is it better for you to test this with client 2.0.3 or 6.0.14.3?

(0000619) MrSugarCube (administrator) 13-09-10 11:25	A packet log from build #1156 might show if anything has changed in how the movement packets are being sent. It shouldn't matter which client you use as long as the same is used for each log (I assume this problem isn't restricted to specific clients?). It would also be best to get logs without injection running though, as I'm not sure if it could be manipulating the packets we're seeing in the log. I'm also wondering if this issue could be the same as 0001744, and the "step number failure" message could be a separate problem that needs to be fixed in injection (their forum seems to indicate that the message is or was a not-to-uncommon issue on certain injection builds).

(0000630) MrSugarCube (administrator) 15-09-10 01:56	It may be worthwhile testing this again on the latest automated build now that 0001744 has been resolved.

(0000631) Mirravin (reporter) 15-09-10 03:15 edited on: 15-09-10 03:15	With new build #1333 I no longer see any stupid error in injection and strange resends in movement. Yes, I think it is fixed, thank you. (Going to celebrate this historical moment...:))