0000051: desynchronization of player momentum when using teleporter or respawning online

(0000150)
unknownna (updater)
2010-09-24 17:05

The same effect can be observed if you hold jump when using the silent teleporters.

(0000151)
TIHan (reporter)
2010-09-24 17:23

I've noticed this in silent teleporters. When you go through them, you can see, for less than a second, parts of the map before you end up at your destination. Basically, it flashes your screen with garbage when you go through them.

(0000479)
unknownna (updater)
2010-10-28 19:17

With player movement prediction, i.e. "cl_predict_players" set to true, you're actually in the "future" on your client. That's why you shake around when using teleporters or respawning. Client-side location vs server-side one.

However, even with "cl_predict_players" set to false, respawning while holding "+forward" still has some side effects. It seems that "+forward" moves you in the direction you faced when dying. If the spawn spot is facing north, dying while facing east/west/south will move you accordingly at respawn. So if you die facing south, moving forward upon respawning moves you backwards instead.

Emulate a ping of around 700ms with the example WAD and set "cl_predict_players" to false. The direction you move isn't reset upon respawn.

(0001501)
unknownna (updater)
2011-04-30 05:43

I just altered the priority. For competitive players, this is a major issue.

(0001777)
unknownna (updater)
2011-05-31 07:25

And the player animation isn't frozen locally after using a teleporter online.

(0001954)
unknownna (updater)
2011-07-25 09:42

When your player body is spawned (spawn/respawn/map reset/join/teleport), you might fall down to a lower floor height without seeing any drop locally. It's highly inconvenient. You always see the drop locally in ZDaemon under the same circumstances.

Steps to reproduce:

1. Start a standard server with the example WAD loaded.
2. Connect a client to the server with an emulated ping of 300 ms.
3. Join the game.
4. Kill your player.
5. Respawn while holding +forward.

(0001982)
Torr Samaho (administrator)
2011-07-28 12:03

> With some ping, the client tries to force it's own momentum to the server when using a teleporter or when respawning.

Can you make a demo of this effect when respawning with the latest build?

(0001983)
unknownna (updater)
2011-07-28 12:11

> Can you make a demo of this effect when respawning with the latest build?

Yes. Done.

(0001984)
unknownna (updater)
2011-07-28 12:22

You wanted the momentum desync, not the z height desync. I recorded a demo of the momentum desync as well.

(0001989)
Decay (reporter)
2011-07-28 20:57

This happens to me a lot in GV when I play far from my router with a ping of roughly 106.

(0001990)
Torr Samaho (administrator)
2011-07-28 23:49
edited on: 2011-07-28 23:56

This seems to fix the moment desync issue in the demo, didn't test if it also fixes it online, but I hope so. The change will also have an effect on teleporting, I didn't test yet though if it's for the better of the worse...

EDIT: I had an idea for an alternative (and likely cleaner) fix. Please also test this binary.

(0001992)
unknownna (updater)
2011-07-29 01:23

It looks like the builds fixed the momentum issue when there's no input from you after death. But if you move after respawning the momentum/z desync is still there. So in terms of gameplay, it's still buggy.

(0001993)
Torr Samaho (administrator)
2011-07-29 01:34

> But if you move after respawning the momentum/z desync is still there. So in terms of gameplay, it's still buggy.

Can you make a new demo that shows the remaining momentum problems? Or are they not shown in a demo? BTW: I didn't look into the z-desync problem at all yet, so I can't comment on this.

(0001996)
unknownna (updater)
2011-07-29 01:49

> EDIT: I had an idea for an alternative (and likely cleaner) fix. Please also test this binary.

I recorded a new demo with this binary.

> Or are they not shown in a demo?

They are definitely shown in a demo.

> BTW: I didn't look into the z-desync problem at all yet, so I can't comment on this.

They're probably directly related to one another.

(0001997)
Torr Samaho (administrator)
2011-07-29 02:02

> But if you move after respawning the momentum/z desync is still there.

Just to confirm: You have to press some kind of move button after respawning to cause the momentum desync and it doesn't matter whether you moved before you repawned, right?

BTW: Did you test how teleporters react to the code change?

(0001998)
unknownna (updater)
2011-07-29 02:18

> Just to confirm: You have to press some kind of move button after respawning to cause the momentum desync and it doesn't matter whether you moved before you repawned, right?

I tested with "compat_instantrespawn 1; sv_forcerespawn 0" and yes, you have to press a move button. I let the client be dead for a few seconds before respawning and it still happens.

> BTW: Did you test how teleporters react to the code change?

Yes, it seems to show the same effects. There's no misprediction if you don't press a move button after entering a teleporter, but if you do press and/or hold a move button it'll desync. It's even worse if you hold +jump.

(0002001)
Torr Samaho (administrator)
2011-07-29 02:36

Would you say that teleporting is now better / worse or similar to how it was in earlier builds or 98d?

(0002002)
unknownna (updater)
2011-07-29 02:45
edited on: 2011-07-29 02:46

It's better in that sense that there's no misprediction if you don't press a single key after using a teleporter and/or respawning. But who plays the game like that?

So in a practical sense it's no different compared to 98d. Your client still mispredicts your movement and z position when you move after teleporting/respawning. It's quite horrible, bluntly said.

(0002012)
Torr Samaho (administrator)
2011-07-30 12:25

> It's better in that sense that there's no misprediction if you don't press a single key after using a teleporter and/or respawning. But who plays the game like that?

I'm just asking to make sure that the change doesn't cause any harm. The code adjustment seems very natural and before I commit it to our repository, I want to make sure that it doesn't break anything.

(0002020)
unknownna (updater)
2011-07-30 14:14
edited on: 2011-07-30 14:27

It seems to work, but I noticed that Orcas in AOW2 are choppier now. But I'm not completely sure.

Edit:

False alarm.

(0002022)
unknownna (updater)
2011-07-30 14:49

But I'd still like to see an improvement here before releasing 98e, if possible.

(0002023)
Torr Samaho (administrator)
2011-07-30 16:54

I'll see what I can do. So far I don't know yet though what's causing these problems.

(0002024)
unknownna (updater)
2011-07-30 18:48
edited on: 2011-07-30 19:36

> I'll see what I can do.

Excellent.

BTW: The OpenGL renderer is now broken on my end. Whenever I try to join my own server it crashes. It doesn't crash in 98d or 3283.

Edit:

Something in my ideserver.cfg and skulltag-name.ini is causing it to crash. I'll send you the files through a PM on the forums.

(0002027)
Torr Samaho (administrator)
2011-07-31 12:24

> It's better in that sense that there's no misprediction if you don't press a single key after using a teleporter and/or respawning.

Do you manage it to mispredict if you press any keys directly after initially spawning, i.e. is the prediction for the first spawn better than when respawning?

(0002028)
unknownna (updater)
2011-07-31 12:45
edited on: 2011-07-31 12:58

It depends on what you mean by initial spawning. Spawning upon connecting with "cl_startasspectator 0", or upon joining the game with "cl_startasspectator 1", or spawning after map resets, or spawning after "changemap" map changes.

They all seem to show the same symptoms: Lots of misprediction and shaking. The view is instantly shifted to the lower floors. Joining the game with "cl_startasspectator 1" is a bit worse though due to the fact that the client thinks that it's lagging.

Edit:

Actually, with an emulated ping of 300 rather than 600, joining the game with "cl_startasspectator 1" is actually better than the rest.

(0002029)
Torr Samaho (administrator)
2011-07-31 13:38

I have a vague theory of what's causing the problems now. Please test if this improves the prediction somehow. Note that this is not really a proper fix but more of a server side band-aid. It also only effects respawning for now, not teleporting. The build also contains some debug messages that you can ignore.

(0002030)
unknownna (updater)
2011-07-31 14:07
edited on: 2011-07-31 14:18

> Please test if this improves the prediction somehow.

I don't feel that it improved the prediction that much.

> The build also contains some debug messages that you can ignore.

It starts to display the messages when the client mispredicts its position.

Hmm, perhaps it improved the prediction a little when being resurrected after dying in survival or when joining games with "cl_startasspectator 0", but I'm not completely sure.

(0002031)
Torr Samaho (administrator)
2011-07-31 14:42
edited on: 2011-07-31 14:43

For me with an emulated ping of 300 it seems to prevent the z desync after respawning almost always on your spawn_z_desync_test_01 example wad. Without the change I can easily reproduce the issue there. You can still reproduce the z height issue there easily?

(0002032)
unknownna (updater)
2011-07-31 14:53

> You can still reproduce the z height issue there easily?

Yes, with an emulated ping of 302 the z height issue is still there. It's almost always there after respawns and after being resurrected, and after map resets. Simply hold +forward all the time and it should happen. It's even more likely to happen if compat_instantrespawn is set to 1, and even worse if sv_forcerespawn is set to 1 as well. I hate to say it, but it's still not good enough.

(0002033)
Torr Samaho (administrator)
2011-07-31 15:04

> It's almost always there after respawns and after being resurrected, and after map resets. Simply hold +forward all the time and it should happen.

I think before I can proceed working on a fix I need to understand why you can reproduce it easily while I can't reproduce it almost all of the time after adding the band-aid. I only tested when respawning after using "kill" on your example map in coop on a server started with

skulltag.exe -file spawn_z_desync_test_01.wad -host +sv_cheats 1 -nomonsters

and with a ping emulation of 302.

(0002034)
unknownna (updater)
2011-07-31 15:19

> skulltag.exe -file spawn_z_desync_test_01.wad -host +sv_cheats 1 -nomonsters

It still happens when I start the server like that. Try to press your +use button in a fast manner while holding +forward after using the "kill" command.

...
Putting on floor
Putting on floor
Putting on floor
Failed to predict x ticks.
Expected x <value>, obtained x <value>, server x <value>
Expected y <value>, obtained y <value>, server y <value>
...

(0002035)
Torr Samaho (administrator)
2011-07-31 15:23
edited on: 2011-07-31 15:24

> It still happens when I start the server like that. Try to press your +use button in a fast manner while holding +forward after using the "kill" command.

Did you bin "kill" to a key for this? And does it also happen if you don't hold +forward before respawning?

(0002036)
unknownna (updater)
2011-07-31 15:31
edited on: 2011-07-31 15:35

Did you bind "kill" to a key for this?

Yes, but it still happens if I use the command through the console.

> And does it also happen if you don't hold +forward before respawning?

Yes. I use the "kill" command, let the view sink down to the floor, press +use and then press +forward immediately after releasing +use. I do it very fast. But it also happens when I press +forward after respawning locally.

(0002037)
Torr Samaho (administrator)
2011-07-31 15:34

> Press +use and then press +forward immediately after releasing +use. I do it very fast.

Since you don't respawn immediately after hitting +use (it's delayed by your ping) you are pressing +forward before you are respawned on your client then, right? What happens if you only press +forward after you are actually respawned on your client?

(0002038)
unknownna (updater)
2011-07-31 15:42

> Since you don't respawn immediately after hitting +use (it's delayed by your ping) you are pressing +forward before you are respawned on your client then, right?

Yes.

> What happens if you only press +forward after you are actually respawned on your client?

For some reason it still desyncs. I press +forward immediately after seeing my player respawn locally and the same z prediction error still appears, i.e., the view is instantly put to the lower floor. But if I wait a bit longer it will not desync.

(0002039)
Torr Samaho (administrator)
2011-07-31 17:14

> For some reason it still desyncs.

Then there is a slight chance that this somehow has an effect on the issue.

(0002040)
unknownna (updater)
2011-07-31 17:53
edited on: 2011-07-31 19:38

Excellent work, Torr. It definitely improved the respawning behavior. Even with an emulated ping of 600 it plays nicely. I sometimes still get some error debug messages though.

Failed to predict x ticks.
Expected x <value>, obtained x <value>, server x <value>
Expected y <value>, obtained y <value>, server y <value>

What did you do in order to improve the behavior? I'll do some further testing (to check various classic duel maps).

BTW: I found a separate client-side prediction issue. It occurs when you bump into walls in a rhythmic pattern. And the client-side crouch prediction isn't 100% accurate. It's very minor though.

Edit:

The classic duel maps (Judas23_) are working great. But the "putting on floor" z height desync still occurs if you hold +jump after respawning.

Steps to reproduce:

1. Start a standard server with compat_instantrespawn and sv_forcerespawn set to 1.
2. Connect a client to the server with an emulated ping of 603 ms.
3. Join the game.
4. "+jump; kill" in the console.
5. Hold +forward.

(0002041)
Torr Samaho (administrator)
2011-07-31 20:29

> What did you do in order to improve the behavior?

After respawning the player is prevented to move for a fixed amount of tics. Server and client both start to count this time directly after spawning the player, but since the spawning on the client is delayed by the ping, the player was allowed to move on the server while the client was still thinking it may not move yet. To account for this I increased the non-movement time on the server by the client's ping (which seemed to fix the problems for me) and now also made the client not send any movement requests while it locally still thinks it is not allowed to move (which seems improve the situation for you).

This also prevents the client from sending jump requests while the client assumes it can't move. Please check if this improves the jumping behavior.

(0002042)
unknownna (updater)
2011-07-31 21:00
edited on: 2011-07-31 21:23

I see. Well, you certainly fixed it. Thank you.

> This also prevents the client from sending jump requests while the client assumes it can't move. Please check if this improves the jumping behavior.

Initial testing indicates that it fixed the issue. I'll do some further testing.

But I noticed that teleporters are still a bit laggy. The debug messages kick in. It also desyncs when you join games (cl_startasspectator 0). If the client thinks that it's lagging (cl_startasspectator 1), the z height desync will appear. Map resets seem to be fine (the client will sometimes think that it's lagging when being resurrected).

BTW: I forgot to mention that it also desyncs after "changemap" map changes. There's no direct z height misprediction, but you shake around a little after dropping down from your initial height (tested in Judas23_). For some reason it'll only desync in DM.

(0002043)
Torr Samaho (administrator)
2011-07-31 22:04

> But I noticed that teleporters are still a bit laggy.

I didn't apply the server-side part of the fix to teleporting yet (the client side part applies to respawning and teleporting). In this binary I cleaned the code a bit and also applied the server-side adjustment when the player is teleported. I didn't test though if this actually improves teleporting or not.

BTW: Whenever the client thinks it's lagging, there will be sync and prediction problems. That's a separate issue.

(0002044)
unknownna (updater)
2011-07-31 22:33
edited on: 2011-07-31 22:38

> In this binary I cleaned the code a bit and also applied the server-side adjustment when the player is teleported. I didn't test though if this actually improves teleporting or not.

It's near-perfect. There's no misprediction on standard teleporters with an emulated ping of 600. But I wonder why the player frames aren't frozen after teleporting online compared to offline. And I noticed that some teleporters in Zombie Horde are still desyncing a little in terms of the z height. The teleport destinations are placed near the ceilings and you drop down. The teleporters are silent, triggered by sector actor things. Nevertheless, things are looking really good by vanilla standards.

> Whenever the client thinks it's lagging, there will be sync and prediction problems. That's a separate issue.

Yeah, I know. I just noted down my observations.

BTW: I somehow managed to crash the former build. I Alt+Tab'ed to the tracker from the fullscreen window, then I got hit by a rocket in-game and it crashed.

Edit:

> For some reason it'll only desync in DM.

I can now confirm this in my example WAD (spawn_z_desync_test_01.wad).

(0002045)
unknownna (updater)
2011-07-31 22:50

Yeah, silent teleporters aren't predicted properly. You can see that in the first example WAD, i.e., teleport_desync_test.wad.

(0002046)
Torr Samaho (administrator)
2011-07-31 22:53

Unfortunately silent teleporters can't be predicted by the current system by design. Here, the client would actually have to predict the teleportation, i.e. teleport itself before he gets the message from the server that he was teleported.

(0002047)
unknownna (updater)
2011-07-31 23:15

Well, the most important thing is to get rid of the remaining desyncs, e.g., those that occur after "changemap" map changes in DM.

(0002048)
Torr Samaho (administrator)
2011-07-31 23:59

Since "changemap" map occur an order of magnitude less often than respawns / teleports, I'm not sure if it's worth to spend much more time on this issue, but I can have a brief look. Can you detail under which conditions the "changemap" problems occur and make a short demo?

(0002049)
unknownna (updater)
2011-08-01 00:12

Yeah, it's not that important, but for some reason it's specific to DM starts.

1. Start a server with skulltag -file spawn_z_desync_test_01.wad -host +sv_cheats 1 +deathmatch 1
2. Connect a client to the server with an emulated ping of 603.
3. Join the game.
4. "changemap map01" in the server console.
5. Tap +forward in a fast manner until the desync appears.

(0002050)
Torr Samaho (administrator)
2011-08-01 01:54

I had a quick look at this and can reproduce the issue now. So far I have no idea what's causing this, in particular since it only happens in DM. Probably I'll just leave it like it is for now.

(0002051)
unknownna (updater)
2011-08-01 12:07

It doesn't affect the main gameplay that much (definitely not in duel and CTF). We can safely ignore the desyncs that occur when joining games (cl_startasspectator) for now, but those that are a part of the gameplay should IMHO be fixed, if possible.

(0003512)
unknownna (updater)
2012-04-30 17:07
edited on: 2012-04-30 17:10

I noticed that clients start to mispredict their player movement after using teleporters if using them while having a turbo sphere. Does the sphere alter the player reaction time?

(0004573)
Torr Samaho (administrator)
2012-09-02 15:53

Can somebody go through everything reported in here and check what's working and what's not in Zandronum 1.0? I only briefly tested the turbo sphere and it didn't seem to increase misprediction in the example wad.

(0004576)
ZzZombo (reporter)
2012-09-02 17:00

From my experience nothing has improved in v1.0.

(0004579)
Torr Samaho (administrator)
2012-09-02 18:09

I fixed several of the things mentioned in this ticket (confirmed in unknownna's notes), so certainly 1.0 behaves better regarding some of the things discussed here than 98d did. What I need somebody to do is to test the things mentioned in here and report in detail what's working and what's not.

(0004584)
ZzZombo (reporter)
2012-09-04 00:36

If I knew how to simulate high ping or at least how to do that with DelayedUDPProxy1.0a (that seems not to work although I've heard somebody used it) I would do that.

(0004586)
Torr Samaho (administrator)
2012-09-04 05:26
edited on: 2012-09-04 05:27

DelayedUDPProxy1.0a.jar does work, I'm always using it to debug ping related problems and just it on multiple different machines. Just start the server and the proxy with the default settings, chose the desired ping in the proxy and connect the client to localhost:10667 (instead of just localhost).

(0004588)
ZzZombo (reporter)
2012-09-04 09:27

Stupid me, but can you tell me what EXACTLY you do to simulate your ping with this program.

(0004596)
Frits (reporter)
2012-09-05 12:27
edited on: 2012-09-05 12:28

- Normal teleports: work fine and displayed no jittering/screenshaking with a ping up to 1000, after that i just got a connection interrupted.
Not even jumping shooting or killing myself after being teleported added some sort of disorientation.
With a turbosphere however, it got "laggy" at 300 ping. Perhaps because the delay before you can move after a teleport isn't there with a turbosphere? Jumping only made the shaking worse.

- Silent teleporters: Even at 5 ping walking over them flashes the view of the previous room (The room/teleporter you see just before you cross the line).
At higher pings (300 and onwards) you get a short period of acceleration after crossing the line, the higher the ping the faster and longer this acceleration. A turbosphere only makes the acceleration issue more noticable.
The biggest problem (with high ping)is that your client can cross the line, continue to move forward and then gets teleported.

This issue is already marked as resolved. If you feel that is not the case, please reopen it and explain why.
Supporters:	No one explicitly supports this issue yet.
Opponents:	No one explicitly opposes this issue yet.

Issue History
Date Modified	Username	Field	Change
2010-09-22 13:30	unknownna	New Issue
2010-09-22 13:30	unknownna	File Added: teleport_desync_test.wad
2010-09-24 17:05	unknownna	Note Added: 0000150
2010-09-24 17:23	TIHan	Note Added: 0000151
2010-10-28 19:17	unknownna	Note Added: 0000479
2011-04-30 05:39	unknownna	Priority	low => high
2011-04-30 05:43	unknownna	Note Added: 0001501
2011-05-31 07:25	unknownna	Note Added: 0001777
2011-05-31 07:25	unknownna	Relationship added	related to 0000309
2011-07-18 06:35	unknownna	Relationship added	related to 0000130
2011-07-25 09:42	unknownna	Note Added: 0001954
2011-07-25 09:42	unknownna	File Added: spawn_z_desync_test_01.wad
2011-07-28 12:03	Torr Samaho	Note Added: 0001982
2011-07-28 12:03	Torr Samaho	Status	new => feedback
2011-07-28 12:11	unknownna	File Added: 2011.07.28_14.08.12_spawn_z_desync_test_01.cld
2011-07-28 12:11	unknownna	Note Added: 0001983
2011-07-28 12:11	unknownna	Status	feedback => new
2011-07-28 12:22	unknownna	File Added: 2011.07.28_14.20.33_doom2.cld
2011-07-28 12:22	unknownna	Note Added: 0001984
2011-07-28 20:57	Decay	Note Added: 0001989
2011-07-28 23:49	Torr Samaho	Note Added: 0001990
2011-07-28 23:49	Torr Samaho	Note Edited: 0001990	View Revisions
2011-07-28 23:56	Torr Samaho	Note Edited: 0001990	View Revisions
2011-07-29 01:23	unknownna	Note Added: 0001992
2011-07-29 01:34	Torr Samaho	Note Added: 0001993
2011-07-29 01:34	Torr Samaho	Assigned To	=> Torr Samaho
2011-07-29 01:34	Torr Samaho	Status	new => assigned
2011-07-29 01:34	Torr Samaho	Status	assigned => feedback
2011-07-29 01:47	unknownna	File Added: 2011.07.29_03.43.42_doom2.cld
2011-07-29 01:49	unknownna	Note Added: 0001996
2011-07-29 01:49	unknownna	Status	feedback => assigned
2011-07-29 02:02	Torr Samaho	Note Added: 0001997
2011-07-29 02:10	Torr Samaho	Status	assigned => feedback
2011-07-29 02:18	unknownna	Note Added: 0001998
2011-07-29 02:18	unknownna	Status	feedback => assigned
2011-07-29 02:36	Torr Samaho	Note Added: 0002001
2011-07-29 02:45	unknownna	Note Added: 0002002
2011-07-29 02:46	unknownna	Note Edited: 0002002	View Revisions
2011-07-30 12:25	Torr Samaho	Note Added: 0002012
2011-07-30 13:19	Torr Samaho	Assigned To	Torr Samaho =>
2011-07-30 13:19	Torr Samaho	Status	assigned => feedback
2011-07-30 14:01	Torr Samaho	Assigned To	=> Torr Samaho
2011-07-30 14:01	Torr Samaho	Status	feedback => assigned
2011-07-30 14:01	Torr Samaho	Status	assigned => feedback
2011-07-30 14:14	unknownna	Note Added: 0002020
2011-07-30 14:14	unknownna	Status	feedback => assigned
2011-07-30 14:27	unknownna	Note Edited: 0002020	View Revisions
2011-07-30 14:49	unknownna	Note Added: 0002022
2011-07-30 16:54	Torr Samaho	Note Added: 0002023
2011-07-30 18:48	unknownna	Note Added: 0002024
2011-07-30 19:36	unknownna	Note Edited: 0002024	View Revisions
2011-07-31 12:24	Torr Samaho	Note Added: 0002027
2011-07-31 12:25	Torr Samaho	Status	assigned => feedback
2011-07-31 12:45	unknownna	Note Added: 0002028
2011-07-31 12:45	unknownna	Status	feedback => assigned
2011-07-31 12:58	unknownna	Note Edited: 0002028	View Revisions
2011-07-31 13:38	Torr Samaho	Note Added: 0002029
2011-07-31 13:38	Torr Samaho	Status	assigned => feedback
2011-07-31 14:07	unknownna	Note Added: 0002030
2011-07-31 14:07	unknownna	Status	feedback => assigned
2011-07-31 14:12	unknownna	Note Edited: 0002030	View Revisions
2011-07-31 14:18	unknownna	Note Edited: 0002030	View Revisions
2011-07-31 14:42	Torr Samaho	Note Added: 0002031
2011-07-31 14:43	Torr Samaho	Note Edited: 0002031	View Revisions
2011-07-31 14:43	Torr Samaho	Status	assigned => feedback
2011-07-31 14:53	unknownna	Note Added: 0002032
2011-07-31 14:53	unknownna	Status	feedback => assigned
2011-07-31 15:04	Torr Samaho	Note Added: 0002033
2011-07-31 15:04	Torr Samaho	Status	assigned => feedback
2011-07-31 15:19	unknownna	Note Added: 0002034
2011-07-31 15:19	unknownna	Status	feedback => assigned
2011-07-31 15:23	Torr Samaho	Note Added: 0002035
2011-07-31 15:24	Torr Samaho	Note Edited: 0002035	View Revisions
2011-07-31 15:31	unknownna	Note Added: 0002036
2011-07-31 15:33	unknownna	Note Edited: 0002036	View Revisions
2011-07-31 15:34	Torr Samaho	Note Added: 0002037
2011-07-31 15:35	unknownna	Note Edited: 0002036	View Revisions
2011-07-31 15:42	unknownna	Note Added: 0002038
2011-07-31 17:14	Torr Samaho	Note Added: 0002039
2011-07-31 17:53	unknownna	Note Added: 0002040
2011-07-31 17:54	unknownna	Note Edited: 0002040	View Revisions
2011-07-31 18:32	unknownna	Note Edited: 0002040	View Revisions
2011-07-31 19:38	unknownna	Note Edited: 0002040	View Revisions
2011-07-31 20:29	Torr Samaho	Note Added: 0002041
2011-07-31 20:29	Torr Samaho	Status	assigned => feedback
2011-07-31 21:00	unknownna	Note Added: 0002042
2011-07-31 21:00	unknownna	Status	feedback => assigned
2011-07-31 21:03	unknownna	Note Edited: 0002042	View Revisions
2011-07-31 21:12	unknownna	Note Edited: 0002042	View Revisions
2011-07-31 21:19	unknownna	Note Edited: 0002042	View Revisions
2011-07-31 21:23	unknownna	Note Edited: 0002042	View Revisions
2011-07-31 22:04	Torr Samaho	Note Added: 0002043
2011-07-31 22:05	Torr Samaho	Status	assigned => feedback
2011-07-31 22:33	unknownna	Note Added: 0002044
2011-07-31 22:33	unknownna	Status	feedback => assigned
2011-07-31 22:34	unknownna	File Added: CrashReport.zip
2011-07-31 22:38	unknownna	Note Edited: 0002044	View Revisions
2011-07-31 22:50	unknownna	Note Added: 0002045
2011-07-31 22:53	Torr Samaho	Note Added: 0002046
2011-07-31 23:15	unknownna	Note Added: 0002047
2011-07-31 23:59	Torr Samaho	Note Added: 0002048
2011-08-01 00:12	unknownna	Note Added: 0002049
2011-08-01 00:12	unknownna	File Added: 2011.08.01_02.10.49_spawn_z_desync_test_01.cld
2011-08-01 01:54	Torr Samaho	Note Added: 0002050
2011-08-01 01:54	Torr Samaho	Status	assigned => feedback
2011-08-01 12:07	unknownna	Note Added: 0002051
2011-08-01 12:07	unknownna	Status	feedback => assigned
2012-04-30 17:07	unknownna	Note Added: 0003512
2012-04-30 17:10	unknownna	Note Edited: 0003512	View Revisions
2012-06-09 13:22	Torr Samaho	Category	General => Bug
2012-08-30 08:54	ZzZombo	Note Added: 0004517
2012-09-01 17:11	Torr Samaho	Note Deleted: 0004517
2012-09-02 15:53	Torr Samaho	Note Added: 0004573
2012-09-02 17:00	ZzZombo	Note Added: 0004576
2012-09-02 18:09	Torr Samaho	Note Added: 0004579
2012-09-04 00:36	ZzZombo	Note Added: 0004584
2012-09-04 05:26	Torr Samaho	Note Added: 0004586
2012-09-04 05:27	Torr Samaho	Note Edited: 0004586	View Revisions
2012-09-04 05:27	Torr Samaho	Note Revision Dropped: 4586: 0002481
2012-09-04 09:27	ZzZombo	Note Added: 0004588
2012-09-05 12:27	Frits	Note Added: 0004596
2012-09-05 12:28	Frits	Note Edited: 0004596	View Revisions
2024-03-07 13:12	unknownna	Status	assigned => closed
2024-03-07 13:12	unknownna	Resolution	open => fixed