Zandronum Chat @ irc.zandronum.com
#zandronum
Get the latest version: 3.0
Source Code

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000193Zandronum[All Projects] Bugpublic2010-11-09 20:312018-09-30 22:54
ReporterXenaero 
Assigned ToTorr Samaho 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformMicrosoftOSWindowsOS VersionXP/Vista/7
Product Version98d 
Target VersionFixed in Version2.0 
Summary0000193: Able to fire weapon before it's passed A_Raise
DescriptionI have noticed that in games where you spawn on a weapon, to the best of my knowledge while the pistol is being brought up on the screen, and you switch to the weapon you spawn on due to picking it up, you will be able to fire before that weapon's A_Raise state is fully completed, allowing you to fire before you should be able to.
Steps To ReproduceIt's hard to reproduce on command. I find I'm able to do it in maps like Judas23 where you spawn on a weapon and try to fire before it's fully raised, allowing a desync in firing and the animations, allowing you to fire 'faster' off the point. It's very noticeable with BFG as neither the sound nor animation will play for you, but it will for your opponent.
Additional InformationNone
Attached Files? file icon 2011.02.10_02.48.25_player_sprite_desync_test.cld [^] (85,201 bytes) 2011-02-10 01:56
? file icon player_sprite_desync_test.wad [^] (660 bytes) 2011-02-10 01:56
? file icon 2011.02.10_03.27.52_player_sprite_desync_test_02.cld [^] (102,271 bytes) 2011-02-10 02:33
? file icon player_sprite_desync_test_02.wad [^] (660 bytes) 2011-02-10 02:33
? file icon 2011.02.11_21.20.28_player_sprite_desync_test_03.cld [^] (28,171 bytes) 2011-02-11 20:22
? file icon player_sprite_desync_test_03.wad [^] (660 bytes) 2011-02-11 20:22
? file icon 2011.02.12_20.04.17_player_sprite_desync_test.cld [^] (40,762 bytes) 2011-02-12 19:08
png file icon coop_spy_bot.png [^] (153,275 bytes) 2011-02-15 18:40


png file icon coop_spy_player.png [^] (166,160 bytes) 2011-02-15 18:41


? file icon 2011.03.30_17.42.49_player_sprite_desync_test_02.cld [^] (40,935 bytes) 2011-03-30 15:47
? file icon 2011.04.17_21.44.00_doom2.cld [^] (33,111 bytes) 2011-04-17 19:56
? file icon 2011.04.24_22.07.17_player_sprite_desync_test_02.cld [^] (53,503 bytes) 2011-04-24 20:14
? file icon 2011.04.25_02.49.05_player_sprite_desync_test_02.cld [^] (50,777 bytes) 2011-04-25 00:51
zip file icon compat_oldweaponswitch_1_no_ping.zip [^] (4,195 bytes) 2011-07-25 02:12
? file icon 2011.07.28_14.55.39_player_sprite_desync_test.cld [^] (52,074 bytes) 2011-07-28 13:12
zip file icon player_sprite_desync_3287.zip [^] (14,061 bytes) 2011-07-30 05:31
? file icon 2011.07.30_14.19.17_player_sprite_desync_test_02.cld [^] (11,701 bytes) 2011-07-30 12:21

- Relationships
parent of 0000444closedTorr Samaho Weapon order desync after a "changemap" map change if "switchonpickup" is set to 0 or 2 
parent of 0000512closedTorr Samaho Coop spy/info desync if cl_startasspectator is set to 0 
parent of 0001116feedback Client fires weapon too early after respawning 
related to 0000465closedTorr Samaho "compat_oldweaponswitch" doesn't work properly in "nointermission" maps 
related to 0000534confirmed Ammo desync if you have a high ping. Client thinks that it didn't use any ammo. 
related to 0000540resolvedLeonard Weapon selection is desynced between clients 
related to 0000544closedTorr Samaho Client can't fire selected weapon after "changemap" map changes in COOP when being telefragged 
related to 0001094confirmed Clients raise morph weapons online 
related to 0002067closed Strife Player "Burn" state crashes server 
Not all the children of this issue are yet resolved or closed.

-  Notes
User avatar (0000596)
Xenaero (reporter)
2010-11-09 20:40

Spleen has just informed me this is related to latency and is a bug regarding weapon desyncs. I have no further information.
User avatar (0000597)
Torr Samaho (administrator)
2010-11-09 21:33

Is it the same in 98c?
User avatar (0000598)
Xenaero (reporter)
2010-11-09 22:23

Aye, the problem was present in 98c as well. I was waiting until 98d to report it though, as the betas were already being pushed out and for simplicity's sake a fresh stable version would have been best to report this for.
User avatar (0000935)
Torr Samaho (administrator)
2011-02-03 01:31

I haven't looked into this yet, but noticed thathttp://www.skulltag.com/forum/viewtopic.php?f=33&t=25512 [^] discusses the same problem and has a lot of useful information (and note it here so that it isn't forgotten).
User avatar (0000938)
unknownna (updater)
2011-02-03 10:46

Yes, I commend you for finally acknowledging this issue. It is actually a very severe bug that has been causing distress to many people for a long time. It would be nice to have this fixed as soon as possible, if possible. I managed to reproduce the bug in a demo. You can find it in the linked thread.
User avatar (0000952)
Torr Samaho (administrator)
2011-02-04 01:11

More information: I just checked Chocolate Doom and found out that it also calls A_Raise twice in the first tic. I'd assume that Vanilla Doom does the same and hence any possible fix should not try to make A_Raise only be called once.
User avatar (0000953)
unknownna (updater)
2011-02-04 01:26

I see. In that case, I hope you manage to find something in the demo.
User avatar (0000954)
Torr Samaho (administrator)
2011-02-04 03:14

I started to work on a fix and need some feedback / testing. This should improve the weapon sync when the player initially joins the game. I'm not sure if the sync is perfect for this case yet, so please test this thoroughly. I only did some very limited testing with a 600 ping coop server so far, where it usually is very easy to cause a desync.

Note: Currently the sync is not improved when respawning after dying or spawning after a map change. I still need to make further changes for this. Furthermore, it will also not work in instagib, lms or buckshot right now.
User avatar (0000956)
unknownna (updater)
2011-02-04 11:36
edited on: 2011-02-04 14:02

I can't seem to reproduce the projectile bug anymore when picking up weapons, even after respawning from death. Tested with the same setup as in the demo. What did you do in order to "fix" this? To avoid sounding ambiguous, it looks like it fixed that particular issue.

User avatar (0000966)
Torr Samaho (administrator)
2011-02-05 20:45
edited on: 2011-02-05 20:47

Let me quote what Spleen found out and planned to do when he worked on this issue a few months ago:

Spleen: "When a player spawns, both the client and server start bringing up the pistol. Usually a server should be behind a client in terms of bringing up a weapon, but in this case it gets ahead because it starts right away and doesn't wait for the client. The server then has to lower the weapon more than the client if the client picks up a weapon, so it goes out of sync.

I am thinking of forcing the player's current weapon to be null server-side, until the server gets a message from the client saying the player is actually switching to his first weapon."

The latter paragraph is pretty much what I did. The fix also tries to let A_Raise being called twice in the first tic for the player's spawn weapon.

BTW: I think there is no need to put fix in quotation marks :P. The only thing that is somewhat hacky is the way the code tries to ensure that A_Raise is called twice for the weapon the player spawned with.

I continued to work on the fix. This possibly works in all game modes and also when respawning.

Furthermore, the fix also hopefully takes care of the sync problems that happen if you have a high ping and fire your spawn weapon too early.

User avatar (0000988)
AlexMax (developer)
2011-02-06 18:57

I'll host it if it has a linux build. :)
User avatar (0000997)
Torr Samaho (administrator)
2011-02-07 01:55

Ok, I made a new official beta build with the fix:http://www.skulltag.com/forum/viewtopic.php?f=77&t=28140 [^]

Happy testing :).
User avatar (0001001)
Xenaero (reporter)
2011-02-07 04:40

Alex hosted a deathmatch server and I conducted some tests. Where normally symptoms would be obvious at my 100ms delay, I was unable to reproduce the problem originally described using the beta. Seems like your fix is working. :)
User avatar (0001032)
Xenaero (reporter)
2011-02-09 22:30

One issue I noticed in playing the beta with some other people was this weird player sprite bug where the player appears locked in the bright firing sprite but he's not actually firing anything. I didn't notice any specific circumstances where this would occur. It seemed to happen a lot off spawning though.
User avatar (0001033)
Torr Samaho (administrator)
2011-02-10 01:20

Please try to make a client side demo of this problem.
User avatar (0001034)
unknownna (updater)
2011-02-10 02:07
edited on: 2011-02-10 02:34

> One issue I noticed in playing the beta with some other people was this weird player sprite bug where the player appears locked in the bright firing sprite but he's not actually firing anything. I didn't notice any specific circumstances where this would occur.

I don't know if I managed to reproduce this, but I might have found something.

> It seemed to happen a lot off spawning though.

Yes, you can see that in the demo.

EDIT:

Recorded a new demo.

User avatar (0001035)
Torr Samaho (administrator)
2011-02-10 02:49

So far I only looked at the first demo and it's clearly showing that something is wrong. Can you explain what exactly you are doing in the demo?
User avatar (0001036)
unknownna (updater)
2011-02-10 03:01
edited on: 2011-02-10 13:44

After death, I hold +forward and tap the +attack button until I see the player change frames on the other client (the demo recorder).

In the second demo, I start to hold +attack whenever I run over the rocket launcher (in the pistol "Deselect" / RL "Select" state).

User avatar (0001037)
Torr Samaho (administrator)
2011-02-11 12:57

This hopefully improves the handling of this situation, so far I only tested the first demo though.
User avatar (0001039)
unknownna (updater)
2011-02-11 13:55
edited on: 2011-02-11 20:23

Looks like it fixed both issues. The "clearing weapon" string is displayed twice whenever the other client picks up a weapon upon respawn.

But as usual I noticed some other things.

* The view angle isn't cleared upon respawn. The player respawns facing the same angle as the death camera did.
* And this isn't related to the above, but no respawn protection is given when you join the game for the first time (if cl_startasspectator is 1).
* And if cl_startasspectator is 0, the view height will flicker from floor- to standard-level based on your ping.

EDIT:

* If a player is standing still before you reconnect, but is moving once connected, the player will not display the running animation. Actually, it happens all the time. If a player is running once connected, the running animation will not be displayed.

And also, there's still a desync when a player joins the game and picks up a weapon. I noticed it with the BFG. If you tap the +attack button, the attack sound might play, but without actually firing the weapon or displaying the fire / flash animation.

You can also desync the BFG attack sound by tapping the +attack button. The other client will hear the sound play when it's not supposed to.

Recorded a new demo. It should illustrate the BFG desync.

User avatar (0001044)
Torr Samaho (administrator)
2011-02-12 02:42

> * The view angle isn't cleared upon respawn. The player respawns facing the same angle as the death camera did.
> * And this isn't related to the above, but no respawn protection is given when you join the game for the first time (if cl_startasspectator is 1).
> * And if cl_startasspectator is 0, the view height will flicker from floor- to standard-level based on your ping.
> * If a player is standing still before you reconnect, but is moving once connected, the player will not display the running animation. Actually, it happens all the time. If a player is running once connected, the running animation will not be displayed.

Did those things already happen in 98d?
User avatar (0001045)
unknownna (updater)
2011-02-12 10:11

Yes.
User avatar (0001048)
Torr Samaho (administrator)
2011-02-12 14:55

Please test if this improves the BFG behavior.
User avatar (0001049)
unknownna (updater)
2011-02-12 15:15
edited on: 2011-02-12 15:27

Looks like it fixed the issues. But I wonder why I am able to fire a pistol shot before picking up a weapon when I join the game, but not when I respawn.

User avatar (0001051)
Torr Samaho (administrator)
2011-02-12 16:01

> But I wonder why I am able to fire a pistol shot before picking up a weapon when I join the game, but not when I respawn.

Can you elaborate this?
User avatar (0001052)
unknownna (updater)
2011-02-12 16:20
edited on: 2011-02-12 16:25

I hold +forward and tap the +attack button. I am able to fire a pistol shot before picking up a weapon when I join the game, but not when I respawn after death. It seems to be related to the ping. I'm doing this with an emulated ping of 251ms.

User avatar (0001053)
Torr Samaho (administrator)
2011-02-12 16:42

In both cases you are spawning right on top of a weapon and switch to it on pickup? In that case it sounds like you shouldn't be able to fire the pistol in either case. Is the pistol brought completely up even though you immediately pick up another weapon?
User avatar (0001054)
unknownna (updater)
2011-02-12 16:46
edited on: 2011-02-12 16:50

> In both cases you are spawning right on top of a weapon and switch to it on pickup? In that case it sounds like you shouldn't be able to fire the pistol in either case.

The same setup as in the example wads. You spawn right on top of a weapon and switch to it once you start to move.

> Is the pistol brought completely up even though you immediately pick up another weapon?

You pick up the weapon too late when joining the game compared to when respawning. That's what it looks like.

User avatar (0001055)
unknownna (updater)
2011-02-12 19:11

Recorded a demo of it with this build.
User avatar (0001092)
unknownna (updater)
2011-02-15 18:37
edited on: 2011-02-15 18:55

It looks like coop spy / info is broken. Bots do not bring up the pistol at map start if a changemap / nextmap map change has occurred. You have to be in-game (not a spectator) for this to happen.

For bots:

1) Start a standard coop server.
2) Connect a client to the server.
3) Join the game.
4) Add a bot.
5) "changemap X / nextmap" in the server console.

For players:

1) Start a standard coop server.
2) Connect two clients to the server.
3) Join the game with both clients.
4) Use coop spy.

And only the first attack sound is played from the SSG when coop spying. You can see that in the latest demo.

FYI, it is not like this in 98d.

User avatar (0001235)
unknownna (updater)
2011-03-30 14:54
edited on: 2011-03-30 15:48

I just encountered the missing missile bug again in r3120M. It was at map start. Picked up a chaingun, then a rocket launcher before the chaingun was ready. compat_oldweaponswitch was set to 1. I had no ping emulation enabled.

Edit:

Recorded a demo of it with the latest beta build.

User avatar (0001328)
Torr Samaho (administrator)
2011-04-10 16:15

> And only the first attack sound is played from the SSG when coop spying. You can see that in the latest demo.

This should fix the sound issue.
User avatar (0001329)
unknownna (updater)
2011-04-10 16:45

> This should fix the sound issue.

It did, but if I alternate between the coop spy view and the regular view, the sounds will *desync*. I noticed that clients coop spying might not always see the flash animation of the grenade/rocket launcher (BFGs as well).

I also noticed another unrelated issue: Clients coop spying don't see any icons above the player sprite. But this behavior is also present in 98d.
User avatar (0001330)
Torr Samaho (administrator)
2011-04-10 17:44

This hopefully fixes the coop spy / info no weapon bug for both bots and players. Note that these were two different issues and needed distinct fixes.

> It did, but if I alternate between the coop spy view and the regular view, the sounds will *desync*.

I think that is a separate issue that is also present in 98d, but there it is only affecting the first sound of the ssg (and should also affect various other weapons).
User avatar (0001331)
unknownna (updater)
2011-04-10 18:17

> This hopefully fixes the coop spy / info no weapon bug for both bots and players. Note that these were two different issues and needed distinct fixes.

It fixed the issues.
User avatar (0001332)
unknownna (updater)
2011-04-10 18:26

I just found another coop spy desync. It happens in LMS with a bot. The bot will be seen as using the grenade launcher instead of the plasma rifle.
User avatar (0001333)
Torr Samaho (administrator)
2011-04-10 18:31

> I noticed that clients coop spying might not always see the flash animation of the grenade/rocket launcher (BFGs as well).

Do you have more information on when this happens? Does the client probably think that this player is out of ammo? And did this already happen in 98d?
User avatar (0001334)
unknownna (updater)
2011-04-10 18:42

> Do you have more information on when this happens?

It's most likely due to the WEAPON.NOAUTOFIRE flag.

> Does the client probably think that this player is out of ammo?

When the desync occurs, the coop spying client thinks that no ammo is used by the other client.

> And did this already happen in 98d?

Yes, it did.
User avatar (0001335)
Torr Samaho (administrator)
2011-04-10 19:50

> I just found another coop spy desync. It happens in LMS with a bot. The bot will be seen as using the grenade launcher instead of the plasma rifle.

This should fix the bot coop spy issue in LMS.
User avatar (0001337)
unknownna (updater)
2011-04-10 22:10

> This should fix the bot coop spy issue in LMS.

It did, but if lmsallowedweapons is 0, your client will think that the bot is using a BFG10K, whereas you have nothing.
User avatar (0001390)
unknownna (updater)
2011-04-17 19:58
edited on: 2011-04-17 20:41

> Do you have more information on when this happens? Does the client probably think that this player is out of ammo? And did this already happen in 98d?

I managed to reproduce this. It seems that a desync between the Select/Deselect states is causing this to occur.

I fire the RL, wait for the fire animation to finish, release +attack, select the GL, then back to the RL while holding +attack again. If you then release +attack and select the GL while holding +attack again, the GL fire animation will desync. The coop spying client thinks that the other client is firing.

I recorded a demo of it with build 3151.

Edit:

Other clients don't have the default movebob value in demos.

User avatar (0001415)
unknownna (updater)
2011-04-23 21:15

> I just encountered the missing missile bug again in r3120M. It was at map start. Picked up a chaingun, then a rocket launcher before the chaingun was ready. compat_oldweaponswitch was set to 1. I had no ping emulation enabled.

This also happens when you join the server with cl_startasspectator set to 0.
User avatar (0001436)
Torr Samaho (administrator)
2011-04-24 14:32

After sinking a few more hours into debugging this nightmare, I think I found out what was causing the problems when connecting with "cl_startasspectator 0" or directly after a map change. Please test if it works better with this binary.
User avatar (0001440)
unknownna (updater)
2011-04-24 20:10

Unfortunately the nightmare is not over yet. I'm still able to make it desync after map changes if compat_oldweaponswitch is set to 1. I recorded a demo of it with build 3188.
User avatar (0001449)
Torr Samaho (administrator)
2011-04-24 21:43
edited on: 2011-04-24 21:49

I didn't test anything with "compat_oldweaponswitch 1" yet, but can you confirm that the sync is better now when connecting with "cl_startasspectator 0" or directly after a map change (with compat_oldweaponswitch 0 EDIT: and without directly spawning on a weapon)?

User avatar (0001453)
unknownna (updater)
2011-04-24 22:26

It's difficult to confirm that, as I'm only able to visually desync it when spawning on top of a weapon, in this case a rocket launcher (if compat_oldweaponswitch is set to 1). The fire animation plays and ammo is used, but no missile comes out. But one thing I noticed in your newest fix is that the "Connection Interrupted!" message isn't displayed as often as it used to when connecting with "cl_startasspectator 0".

Actually, I'm able to make Skulltag freeze. If I connect to the server with "cl_startasspectator 0", "disconnect" in the console and then "reconnect" in the console, once connected, Skulltag will freeze. This is a major issue. I'm doing this with an emulated ping of 251 ms.
User avatar (0001455)
Torr Samaho (administrator)
2011-04-24 22:59

> It's difficult to confirm that, as I'm only able to visually desync it when spawning on top of a weapon, in this case a rocket launcher (if compat_oldweaponswitch is set to 1).

The thing that I fixed is that you could fire the pistol you got on default after a map change before it was fully pulled out on the client.

> But one thing I noticed in your newest fix is that the "Connection Interrupted!" message isn't displayed as often as it used to when connecting with "cl_startasspectator 0".

That's part of the fix: Skulltag wrongly assumed that it was lagging always after a map change or upon connecting with "cl_startasspectator 0". With a low ping you shouldn't get the "Connection Interrupted!" message anymore under these conditions.
User avatar (0001456)
Torr Samaho (administrator)
2011-04-24 23:22

Are you sure that the "compat_oldweaponswitch 1" problems only occur directly after a map change? I tracked down these problems so far that I can say that the sync problems are caused by the "original weapon switch cancellation behavior" of this flag. And if they really only happen directly after a map change, I probably have a bandaid to fix them.
User avatar (0001457)
Torr Samaho (administrator)
2011-04-24 23:47

Ok, this hopefully improves the behavior with "compat_oldweaponswitch 1" after map changes.
User avatar (0001458)
unknownna (updater)
2011-04-24 23:48
edited on: 2011-04-24 23:55

> The thing that I fixed is that you could fire the pistol you got on default after a map change before it was fully pulled out on the client.

I see. I can sometimes see 2 pellets hit the wall when 1 pistol shot was fired locally (or 3 pellets when 2 pistol shots were fired locally). I tap the +attack button in a fast manner during the intermission screen. And the decal locations aren't always accurate. They seem to be spawned locally as well. I'm doing this with an emulated ping of 600 ms. It's very difficult to reproduce this.

> Are you sure that the "compat_oldweaponswitch 1" problems only occur directly after a map change?

For the "missing missile" issue, yes.

User avatar (0001459)
Torr Samaho (administrator)
2011-04-24 23:53

> For the "missing missile" issue, yes.

Good, then the binary I posted in #c1457 hopefully takes care of this.

> Actually, I'm able to make Skulltag freeze. If I connect to the server with "cl_startasspectator 0", "disconnect" in the console and then "reconnect" in the console, once connected, Skulltag will freeze. This is a major issue. I'm doing this with an emulated ping of 251 ms.

So far I couldn't reproduce this. Can you reproduce this always? Is there a special timing necessary?
User avatar (0001460)
unknownna (updater)
2011-04-25 00:12

> So far I couldn't reproduce this. Can you reproduce this always? Is there a special timing necessary?

I can always reproduce this with these steps:

1. Start a standard server.
2. Connect a client to the server with an emulated ping of 251 ms. Make sure that cl_startasspectator is 0.
3. Once in-game, "disconnect" in the console.
4. "reconnect" in the console.
5. Once in-game again, the pistol will be brought up. It will now freeze. If not, repeat step 3 and 4.

> Ok, this hopefully improves the behavior with "compat_oldweaponswitch 1" after map changes.

Only partially. The missiles are spawned, but the fire animation will not play and no ammo is used.
User avatar (0001461)
Torr Samaho (administrator)
2011-04-25 00:34

> Only partially. The missiles are spawned, but the fire animation will not play and no ammo is used.

With which ping did you test this? I only tested it with low ping and there it seemed to work fine.
User avatar (0001462)
unknownna (updater)
2011-04-25 00:43
edited on: 2011-04-25 00:54

> With which ping did you test this? I only tested it with low ping and there it seemed to work fine.

I can reproduce this without any ping emulation. It's tedious to reproduce it though. Should I try to record a demo of it?

Edit:

I recorded a demo if it with build 3193M.

User avatar (0001463)
Torr Samaho (administrator)
2011-04-25 00:57

> It's tedious to reproduce it though. Should I try to record a demo of it?

No, that's not necessary at the moment. If it's tedious to reproduce, it's apparently not very likely to happen. I think we are reaching a state now where the weapon sync is good under most circumstances and where it's getting extremely difficult to improve the sync further.

BTW: I think I fixed the freeze problem and will release a new beta build soon.
User avatar (0001464)
unknownna (updater)
2011-04-25 01:02

> No, that's not necessary at the moment.

I overestimated the difficulty. It happens if you fire a pistol shot before picking up a rocket launcher. So it's very likely to happen often.
User avatar (0001465)
Torr Samaho (administrator)
2011-04-25 02:15
edited on: 2011-04-25 02:25

> It happens if you fire a pistol shot before picking up a rocket launcher. So it's very likely to happen often.

Does it mean it happens regardless of the compat_oldweaponswitch setting and also not only after map changes?

User avatar (0001466)
unknownna (updater)
2011-04-25 03:59

"compat_oldweaponswitch 1" without ping emulation:

1. Start a deathmatch server with player_sprite_desync_test_02.wad loaded.
2. Connect a client to the server.
3. Join the game.
4. "changemap map01" in the server console.
5. Mark yourself as ready and enter the next map.
6. Upon spawn, tap your +attack button in a fast manner until one pistol shot has been fired.
7. Move a direction to grab the rocket launcher while tapping +attack in a fast manner.
8. When you see a missile appear before the fire animation has started, hold +attack.

The missiles start to appear when the RL begins its "Select" state. You can see this behavior in the demo.

"compat_oldweaponswitch 1" with ping emulation (251 ms):

1. Start a deathmatch server with player_sprite_desync_test_02.wad loaded.
2. Connect a client to the server.
3. Join the game.
4. "changemap map01" in the server console.
5. Mark yourself as ready and enter the next map.
6. Upon spawn, move a direction to grab the rocket launcher.
7. When you hear the pickup sound, hold +attack.

The fire animation plays and ammo is used, but no missiles are spawned.

I can barely reproduce the desyncs with "compat_oldweaponswitch 0". It is possible though.
User avatar (0001469)
unknownna (updater)
2011-04-25 22:11

> I see. I can sometimes see 2 pellets hit the wall when 1 pistol shot was fired locally (or 3 pellets when 2 pistol shots were fired locally). I tap the +attack button in a fast manner during the intermission screen. And the decal locations aren't always accurate. They seem to be spawned locally as well. I'm doing this with an emulated ping of 600 ms. It's very difficult to reproduce this.

With an emulated ping of 700 ms, I'm able to fire 2-3 pellets upon joining the game when only one pistol shot was fired by me locally. It doesn't matter whether compat_oldweaponswitch or cl_startasspectator is set to 1 or not. I simply tap the +attack button in a very fast manner.

If compat_oldweaponswitch is set to 1 and a map change takes place, the first pistol shot fired by me locally will not be registered by the server (decal spawns, but no puff appears and monsters aren't alerted). This does not happen if compat_oldweaponswitch is set to 0. This one is probably related to the "missing missile" issue.

So there are two separate issues: Desyncs after map changes, and desyncs upon joining games.

BTW: If cl_startasspectator is set to 1, the client starts to lag whenever you join the game. The "Connection Interrupted!" message appears on-screen. This does not happen if cl_startasspectator is set to 0.
User avatar (0001474)
Torr Samaho (administrator)
2011-04-26 01:56

> BTW: If cl_startasspectator is set to 1, the client starts to lag whenever you join the game. The "Connection Interrupted!" message appears on-screen. This does not happen if cl_startasspectator is set to 0.

This only happens to me with a very high ping and I'm not sure if it should be considered to be a bug.

> So there are two separate issues: Desyncs after map changes, and desyncs upon joining games.

But this also means that the sync issues that happen during the game (i.e. not in the first seconds after a map change or after joining) are fixed, right?

BTW: Sync issues that only happen with insanely high ping are almost irrelevant for practical purposes. With a ping of 700 the game is unplayable anyway.
User avatar (0001475)
unknownna (updater)
2011-04-26 02:28

> But this also means that the sync issues that happen during the game (i.e. not in the first seconds after a map change or after joining) are fixed, right?

I think so.

> BTW: Sync issues that only happen with insanely high ping are almost irrelevant for practical purposes. With a ping of 700 the game is unplayable anyway.

I don't disagree with this statement, but it is still possible to desync the weapons though. I advise you to at least get rid of the compat_oldweaponswitch issues before an official 98e release. It's not difficult to reproduce the desyncs.
User avatar (0001522)
unknownna (updater)
2011-05-01 06:11
edited on: 2011-05-01 06:52

I found another desync:

If you hold +attack when a new warm-up round begins after a player has scored in (Team)Possession, your weapons will desync. The visual effect of the desync is that it looks like your bullet puffs are predicted by the client. This also happens in (T)LMS.

User avatar (0001529)
Xenaero (reporter)
2011-05-01 15:29

My goodness, this bug is a doozy.
User avatar (0001842)
Xenaero (reporter)
2011-07-09 20:48

Any updates on this?
User avatar (0001859)
Torr Samaho (administrator)
2011-07-10 20:38

> Any updates on this?

I think by now the weapon synchronicity of 98e is much better than in 98d in pretty much every regard. It's still not absolutely perfect but we probably arrived at a point where we should keep it as it is (at least for now). Or does the current state of 98e still have any noteworthy problems that 98d does not?
User avatar (0001876)
unknownna (updater)
2011-07-11 00:18

> It's still not absolutely perfect but we probably arrived at a point where we should keep it as it is (at least for now).

I'd still like to get rid of the evident compat_oldweaponswitch issues that occur after map changes. I can reliably reproduce the desyncs without any trouble. Other than that, it's working quite well now.
User avatar (0001877)
Torr Samaho (administrator)
2011-07-11 01:21

> I'd still like to get rid of the evident compat_oldweaponswitch issues that occur after map changes

This doesn't work any better in 98d, does it?
User avatar (0001878)
unknownna (updater)
2011-07-11 01:39

> This doesn't work any better in 98d, does it?

You can also desync it in 98d, but it works better there. It's a lot easier to desync it in 98e. I can easily reproduce the 98e desyncs compared to the 98d ones.
User avatar (0001934)
Xenaero (reporter)
2011-07-23 21:50

> It's a lot easier to desync it in 98e.

So the problem is worse / more pronounced in 98e?
User avatar (0001935)
Torr Samaho (administrator)
2011-07-24 00:01

> It's a lot easier to desync it in 98e. I can easily reproduce the 98e desyncs compared to the 98d ones.

Is "compat_oldweaponswitch 1" behaving differently from "switchonpickup 2" on the client plus ""compat_oldweaponswitch 0" on the server? If so, the desync is caused by the reintroduced Vanilla Doom cancellation behavior.
User avatar (0001936)
unknownna (updater)
2011-07-24 00:13
edited on: 2011-07-24 00:18

> So the problem is worse / more pronounced in 98e?

Yes.


> Is "compat_oldweaponswitch 1" behaving differently from "switchonpickup 2" on the client plus ""compat_oldweaponswitch 0" on the server?

It is.


> If so, the desync is caused by the reintroduced Vanilla Doom cancellation behavior.

I hope you're not going to remove the new behavior though.

Edit:

> Is "compat_oldweaponswitch 1" behaving differently from "switchonpickup 2" on the client plus ""compat_oldweaponswitch 0" on the server?

It is, but I'm sometimes able to desync it when compat_oldweaponswitch is set to 0, without any ping emulation.

User avatar (0001938)
Torr Samaho (administrator)
2011-07-24 00:53

> I hope you're not going to remove the new behavior though.

Currently I don't see any way to fix this problem. After a map change client and server are not perfectly in sync and this most likely causes the sync problems you are observing here. They are just more apparent with the new cancellation behavior.
User avatar (0001940)
Xenaero (reporter)
2011-07-24 01:14

Wouldn't there be a way to enforce that the client goes through the full raise/switch sequence before initiating firing?
User avatar (0001943)
Torr Samaho (administrator)
2011-07-24 12:18

> Wouldn't there be a way to enforce that the client goes through the full raise/switch sequence before initiating firing?

This wouldn't help but just introduce more sync problems. Clients and server have to switch weapons based on the exactly same premises. The problem here is that the raise of the weapon is slightly ahead on the server.
User avatar (0001944)
Edward-san (developer)
2011-07-24 13:51

Uh, sorry for the disturbance, but can someone explain with "client-server" diagrams what's the problem?

Also, this tracker got so big that it's hard to check the latest post. Wouldn't be possible to create a new tracker with the actual problems?
User avatar (0001945)
Torr Samaho (administrator)
2011-07-24 19:40

> but can someone explain with "client-server" diagrams what's the problem?

I'll try to explain it with an example: Under some circumstances, the server is ahead a few tics in raising or lowering of the player's current weapon. When then something happens whose outcome depends on the state of the weapon, noticeable desyncs occur. For instance, a player pushes the fire button while the weapon is already completely raised on the server but is not completely raised on the client yet. Then the server will fire the weapon, which let's everybody see the puffs or missile, but the client ignores the fire command since the weapon is not fully raised on the client end and firing is forbidden under this circumstances. This way you will see puffs even though you don't see a firing animation.
User avatar (0001947)
Edward-san (developer)
2011-07-24 21:34
edited on: 2011-07-24 22:39

Then what about if the server communicates the client to skip the raise of the weapon when the server is ready? Obviously it won't solve perfectly the problem, but the margin of error will slightly decrease IMHO.

User avatar (0001950)
Torr Samaho (administrator)
2011-07-25 00:55

> Then what about if the server communicates the client to ski p the raise of the weapon when the server is ready?

If anything, this likely makes things even worse. The client is predicting the weapon state, hence, by the time the server command reaches the client, the state correction is already outdated by the client's ping. So after such a server "correction", the client would definitely be out of sync in the state. The only proper way to fix this is to prevent the server from being ahead of the client in the first place.

I revisited the problem once again and hopefully found a way to improve the behavior after changemap map changes. This contains the new code (along with a lot of debugging messages that you should ignore for now), please test if it improves the situation somehow.

The amount of time I put into this issue is getting completely outrageous though...
User avatar (0001951)
unknownna (updater)
2011-07-25 01:37
edited on: 2011-07-25 01:45

> I revisited the problem once again and hopefully found a way to improve the behavior after changemap map changes. This contains the new code (along with a lot of debugging messages that you should ignore for now), please test if it improves the situation somehow.

I can still easily desync the rocket launcher in the example WAD if "compat_oldweaponswitch" is set to 1, and I managed to desync it with "switchonpickup 2" and "compat_oldweaponswitch 0", without any ping emulation.

"compat_oldweaponswitch 1" without ping emulation:

[03:19:53] A_Raise 22622 Pistol
[03:19:53] Spawned Pistol NULL
[03:19:53] server_AuthenticateLevel - PLAYER_ClearWeapon
[03:19:53] Bringing up first weapon Pistol
[03:19:53] A_Raise 22627 Pistol
[03:19:53] A_Raise 22627 Pistol
[03:19:53] A_Raise 22627 Pistol
[03:19:53] A_Raise 22628 Pistol
[03:19:53] A_Raise 22629 Pistol
[03:19:53] A_Raise 22630 Pistol
[03:19:53] A_Raise 22631 Pistol
[03:19:53] A_Raise 22632 Pistol
[03:19:53] A_Raise 22633 Pistol
[03:19:53] A_Raise 22634 Pistol
[03:19:53] A_Raise 22635 Pistol
[03:19:53] A_Raise 22636 Pistol
[03:19:53] A_Raise 22637 Pistol
[03:19:53] A_Raise 22638 Pistol
[03:19:53] A_Raise 22639 Pistol
[03:19:53] A_Raise 22640 Pistol
[03:19:54] A_Raise 22655 RocketLauncher
[03:19:54] A_Raise 22656 RocketLauncher
[03:19:54] A_Raise 22657 RocketLauncher
[03:19:54] A_Raise 22658 RocketLauncher
[03:19:54] A_Raise 22659 RocketLauncher
[03:19:54] A_Raise 22660 RocketLauncher
[03:19:54] A_Raise 22661 RocketLauncher
[03:19:54] A_Raise 22662 RocketLauncher
[03:19:54] A_Raise 22663 RocketLauncher
[03:19:54] A_Raise 22664 RocketLauncher
[03:19:54] A_Raise 22665 RocketLauncher
[03:19:54] A_Raise 22666 RocketLauncher
[03:19:54] A_Raise 22667 RocketLauncher
[03:19:54] A_Raise 22668 RocketLauncher
[03:19:54] A_Raise 22669 RocketLauncher
[03:19:54] A_Raise 22670 RocketLauncher // Last rocket is fired.
[03:20:00] A_Raise 22888 Pistol // Pistol isn't brought up locally.
[03:20:00] A_Raise 22889 Pistol
[03:20:00] A_Raise 22890 Pistol
[03:20:00] A_Raise 22891 Pistol
[03:20:00] A_Raise 22892 Pistol
[03:20:00] A_Raise 22893 Pistol
[03:20:00] A_Raise 22894 Pistol
[03:20:00] A_Raise 22895 Pistol
[03:20:00] A_Raise 22896 Pistol
[03:20:00] A_Raise 22897 Pistol
[03:20:00] A_Raise 22898 Pistol
[03:20:00] A_Raise 22899 Pistol
[03:20:00] A_Raise 22900 Pistol
[03:20:01] A_Raise 22901 Pistol
[03:20:01] A_Raise 22902 Pistol
[03:20:01] A_Raise 22903 Pistol
[03:20:01] A_Raise 22918 RocketLauncher
[03:20:01] A_Raise 22919 RocketLauncher
[03:20:01] A_Raise 22920 RocketLauncher
[03:20:01] A_Raise 22921 RocketLauncher
[03:20:01] A_Raise 22922 RocketLauncher
[03:20:01] A_Raise 22923 RocketLauncher
[03:20:01] A_Raise 22924 RocketLauncher
[03:20:01] A_Raise 22925 RocketLauncher
[03:20:01] A_Raise 22926 RocketLauncher
[03:20:01] A_Raise 22927 RocketLauncher
[03:20:01] A_Raise 22928 RocketLauncher
[03:20:01] A_Raise 22929 RocketLauncher
[03:20:01] A_Raise 22930 RocketLauncher
[03:20:01] A_Raise 22931 RocketLauncher
[03:20:01] A_Raise 22932 RocketLauncher
[03:20:01] A_Raise 22933 RocketLauncher

"compat_oldweaponswitch 1" with ping emulation (251 ms):

[03:22:58] A_Raise 29252 Pistol
[03:22:58] Spawned Pistol NULL
[03:22:58] server_AuthenticateLevel - PLAYER_ClearWeapon
[03:22:59] Bringing up first weapon Pistol
[03:22:59] A_Raise 29275 Pistol
[03:22:59] A_Raise 29275 Pistol
[03:22:59] A_Raise 29275 Pistol
[03:22:59] A_Raise 29276 Pistol
[03:22:59] A_Raise 29277 Pistol
[03:22:59] A_Raise 29278 Pistol
[03:22:59] A_Raise 29279 Pistol
[03:22:59] A_Raise 29280 Pistol
[03:22:59] A_Raise 29281 Pistol
[03:22:59] A_Raise 29282 Pistol
[03:22:59] A_Raise 29283 Pistol
[03:22:59] A_Raise 29284 Pistol
[03:22:59] A_Raise 29285 Pistol
[03:22:59] A_Raise 29286 Pistol
[03:22:59] A_Raise 29287 Pistol
[03:22:59] A_Raise 29288 Pistol
[03:23:00] A_Raise 29303 RocketLauncher
[03:23:00] A_Raise 29304 RocketLauncher
[03:23:00] A_Raise 29305 RocketLauncher
[03:23:00] A_Raise 29306 RocketLauncher
[03:23:00] A_Raise 29307 RocketLauncher
[03:23:00] A_Raise 29308 RocketLauncher
[03:23:00] A_Raise 29309 RocketLauncher
[03:23:00] A_Raise 29310 RocketLauncher
[03:23:00] A_Raise 29311 RocketLauncher
[03:23:00] A_Raise 29312 RocketLauncher
[03:23:00] A_Raise 29313 RocketLauncher
[03:23:00] A_Raise 29314 RocketLauncher
[03:23:00] A_Raise 29315 RocketLauncher
[03:23:00] A_Raise 29316 RocketLauncher
[03:23:00] A_Raise 29317 RocketLauncher
[03:23:00] A_Raise 29318 RocketLauncher // Last NULL rocket is fired. No more ammo.
[03:23:06] A_Raise 29538 Pistol // Pistol is brought up locally.
[03:23:06] A_Raise 29539 Pistol
[03:23:06] A_Raise 29540 Pistol
[03:23:06] A_Raise 29541 Pistol
[03:23:06] A_Raise 29542 Pistol
[03:23:06] A_Raise 29543 Pistol
[03:23:06] A_Raise 29544 Pistol
[03:23:06] A_Raise 29545 Pistol
[03:23:06] A_Raise 29546 Pistol
[03:23:06] A_Raise 29547 Pistol
[03:23:06] A_Raise 29548 Pistol
[03:23:06] A_Raise 29549 Pistol
[03:23:06] A_Raise 29550 Pistol
[03:23:07] A_Raise 29551 Pistol
[03:23:07] A_Raise 29552 Pistol
[03:23:07] A_Raise 29553 Pistol

"switchonpickup 2" & "compat_oldweaponswitch 0" without ping emulation:

[03:25:52] A_Raise 35454 Pistol
[03:25:52] Spawned Pistol NULL
[03:25:52] server_AuthenticateLevel - PLAYER_ClearWeapon
[03:25:52] Bringing up first weapon Pistol
[03:25:52] A_Raise 35458 Pistol
[03:25:52] A_Raise 35458 Pistol
[03:25:52] A_Raise 35458 Pistol
[03:25:52] A_Raise 35458 Pistol
[03:25:52] A_Raise 35460 Pistol
[03:25:52] A_Raise 35461 Pistol
[03:25:52] A_Raise 35462 Pistol
[03:25:52] A_Raise 35463 Pistol
[03:25:52] A_Raise 35464 Pistol
[03:25:52] A_Raise 35465 Pistol
[03:25:52] A_Raise 35466 Pistol
[03:25:52] A_Raise 35467 Pistol
[03:25:52] A_Raise 35475 RocketLauncher
[03:25:52] A_Raise 35476 RocketLauncher
[03:25:52] A_Raise 35477 RocketLauncher
[03:25:52] A_Raise 35478 RocketLauncher
[03:25:52] A_Raise 35479 RocketLauncher
[03:25:52] A_Raise 35480 RocketLauncher
[03:25:52] A_Raise 35481 RocketLauncher
[03:25:52] A_Raise 35482 RocketLauncher
[03:25:52] A_Raise 35483 RocketLauncher
[03:25:52] A_Raise 35484 RocketLauncher
[03:25:53] A_Raise 35485 RocketLauncher
[03:25:53] A_Raise 35486 RocketLauncher
[03:25:53] A_Raise 35487 RocketLauncher
[03:25:53] A_Raise 35488 RocketLauncher
[03:25:53] A_Raise 35489 RocketLauncher
[03:25:53] A_Raise 35490 RocketLauncher // Last rocket is fired.
[03:25:59] A_Raise 35706 Pistol // Pistol isn't brought up locally.
[03:25:59] A_Raise 35707 Pistol
[03:25:59] A_Raise 35707 RocketLauncher
[03:25:59] A_Raise 35708 RocketLauncher
[03:25:59] A_Raise 35709 RocketLauncher
[03:25:59] A_Raise 35710 RocketLauncher
[03:25:59] A_Raise 35711 RocketLauncher
[03:25:59] A_Raise 35712 RocketLauncher
[03:25:59] A_Raise 35713 RocketLauncher
[03:25:59] A_Raise 35714 RocketLauncher
[03:25:59] A_Raise 35715 RocketLauncher
[03:25:59] A_Raise 35716 RocketLauncher
[03:25:59] A_Raise 35717 RocketLauncher
[03:25:59] A_Raise 35718 RocketLauncher
[03:25:59] A_Raise 35719 RocketLauncher
[03:25:59] A_Raise 35720 RocketLauncher
[03:25:59] A_Raise 35721 RocketLauncher
[03:25:59] A_Raise 35722 RocketLauncher

It's always the same patterns.

User avatar (0001952)
Torr Samaho (administrator)
2011-07-25 01:51
edited on: 2011-07-25 01:52

Can you make a new demo and post the logfiles of client and server? The raise pattern should be different on client and server when there is a desync.

User avatar (0001953)
unknownna (updater)
2011-07-25 02:11
edited on: 2011-07-25 02:16

What happens in the demo isn't what I see locally on the server. I see no Fire/Flash states. You also don't see the first pistol shot in the demo. And the ammo values in the demo are incorrect.

User avatar (0001972)
Torr Samaho (administrator)
2011-07-27 11:23
edited on: 2011-07-27 11:24

I finally found a problem that only seems to happen with "compat_oldweaponswitch 1". Please test if this improves the behavior. Note that this build has even more debug output crap in it.

User avatar (0001973)
unknownna (updater)
2011-07-27 12:05
edited on: 2011-07-27 12:26

> I finally found a problem that only seems to happen with "compat_oldweaponswitch 1". Please test if This improves the behavior.

Excellent. You finally fixed it. Well done.


> Note that this build has even more debug output crap in it.

The A_Lower message is repeatedly displayed when you're dead. I suppose that this is the intended behavior.

Now, the only major desync left is when you join games with a high ping (cl_startasspectator 1). The client thinks that it's lagging. The desyncs that occur after win/lose sequences seem to be timing issues rather than true desyncs. You shouldn't spend more time on this before 98e.

User avatar (0001976)
Torr Samaho (administrator)
2011-07-27 23:38

> Excellent. You finally fixed it. Well done.

Great, I'm very happy to hear that! I just cleaned, commented and committed the code to our repository. Please confirm with this build that the fix is still working as it should.

> The A_Lower message is repeatedly displayed when you're dead. I suppose that this is the intended behavior.

Yeah, I'm pretty sure that A_Lower is called continuously on dead players on purpose.

> Now, the only major desync left is when you join games with a high ping (cl_startasspectator 1). The client thinks that it's lagging.

Yeah, when a client thinks it's lagging while a weapon is raised or lowered desyncs are unavoidable. One has to prevent the client from lagging to fix this.

> You shouldn't spend more time on this before 98e.

I couldn't agree more :).
User avatar (0001977)
unknownna (updater)
2011-07-28 01:36

> I just cleaned, commented and committed the code to our repository. Please confirm with this build that the fix is still working as it should.

The fix still seems to be working as intended.
User avatar (0001985)
unknownna (updater)
2011-07-28 13:10
edited on: 2011-07-28 13:19

> One issue I noticed in playing the beta with some other people was this weird player sprite bug where the player appears locked in the bright firing sprite but he's not actually firing anything.

After some heavy testing I found another nasty player sprite and/or a coop spy issue and managed to reproduce it. Sometimes your client will think that other clients are firing their weapons when they truly aren't firing them. The weapon selection is desynced between the clients. It can look like your opponent is firing his chaingun when it's actually being selected on his end. You don't hear any attack sounds or see any bullet puffs, but decals are spawned. I recorded a demo of it with 3287.

User avatar (0001994)
Torr Samaho (administrator)
2011-07-29 01:39

> The weapon selection is desynced between the clients.

Can you elaborate how to reproduce this?
User avatar (0001999)
unknownna (updater)
2011-07-29 02:23

> Can you elaborate how to reproduce this?

I alternate between selecting the fist and chaingun while repeatedly tapping +attack in a fast manner. I sometimes allow my client to attack with the fist before selecting the chaingun, but I never allow my client to attack with the chaingun. I make sure that I lower the chaingun before it's fully raised on my end. After a while, the other client will start to think that the chaingun fully raised on your end.
User avatar (0002000)
Torr Samaho (administrator)
2011-07-29 02:35

Does this work any better in 98d?
User avatar (0002003)
unknownna (updater)
2011-07-29 02:52

I'm able to reproduce it in 98d as well.
User avatar (0002009)
unknownna (updater)
2011-07-30 05:32

I recorded 2 new demos with build 3287. It shows how it looks like on both ends.
User avatar (0002010)
unknownna (updater)
2011-07-30 12:02
edited on: 2011-07-30 12:22

> but can you confirm that the sync is better now when connecting with "cl_startasspectator 0"?

There's still a major desync left when you connect with "cl_startasspectator 0". I'm able to desync the weapons. Either the first SSG shot isn't registered by the server, or the rockets aren't spawned. And the client doesn't think that it's lagging. I don't understand how I somehow managed to overlook this desync.

Edit:

I recorded a demo of it with build 3287. It doesn't matter whether compat_oldweaponswitch is set to 1 or not.

User avatar (0002014)
Torr Samaho (administrator)
2011-07-30 13:16

> I'm able to reproduce it in 98d as well.

Then it is definitely a separate issue. Can you make a new ticket for this?

> There's still a major desync left when you connect with "cl_startasspectator 0". I'm able to desync the weapons.

It's seems to be very difficult for me to reproduce the issue. Can you reproduce this reliably? And isn't 98d even worse in this regard?
User avatar (0002018)
unknownna (updater)
2011-07-30 13:38

> Can you make a new ticket for this?

Yes. Done.


> Can you reproduce this reliably?

Yes. I'm doing this with an emulated ping of 300 ms.


> And isn't 98d even worse in this regard?

It is. The client thinks that it's lagging there, but it still shows the same symptoms.
User avatar (0002019)
Torr Samaho (administrator)
2011-07-30 14:00

> Yes. I'm doing this with an emulated ping of 300 ms.

Strange, I tried a ping of 300 and 700 and it only happens very rarely for me. Did you use any other special settings? I start the server with

skulltag.exe -file player_sprite_desync_test_02.wad -host +compat_oldweaponswitch 1 -deathmatch

> It is. The client thinks that it's lagging there, but it still shows the same symptoms.

So it's probably time to put this issue to rest for the time being. If 98e is currently better than 98d in every regard, IMHO we should try to release it ASAP instead of letting people wait even longer for further fine tunings.
User avatar (0002021)
unknownna (updater)
2011-07-30 14:21

> Did you use any other special settings?

I start the server through IDE with standard DM settings and compat_oldweaponswitch set to 0. I can also reproduce it with compat_oldweaponswitch set to 1.

> So it's probably time to put this issue to rest for the time being. If 98e is currently better than 98d in every regard, IMHO we should try to release it ASAP instead of letting people wait even longer for further fine tunings.

Yeah, it's alright. This desync doesn't affect the main gameplay that much.
User avatar (0012691)
unknownna (updater)
2015-06-14 06:03
edited on: 2015-06-14 06:03

I went through the whole report and can confirm that the main issues were once fixed. We didn't fix all of them. And there are some regressions in 2.0, but they have their own reports now. The other issues I'll create separate tickets for.

Quote from unknownna
After some heavy testing I found another nasty player sprite and/or a coop spy issue and managed to reproduce it. Sometimes your client will think that other clients are firing their weapons when they truly aren't firing them. The weapon selection is desynced between the clients. It can look like your opponent is firing his chaingun when it's actually being selected on his end. You don't hear any attack sounds or see any bullet puffs, but decals are spawned. I recorded a demo of it with 3287.

0000540: Weapon selection is desynced between clients


Issue Community Support
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-11-09 20:31 Xenaero New Issue
2010-11-09 20:40 Xenaero Note Added: 0000596
2010-11-09 21:33 Torr Samaho Note Added: 0000597
2010-11-09 21:33 Torr Samaho Status new => feedback
2010-11-09 22:23 Xenaero Note Added: 0000598
2010-11-09 22:23 Xenaero Status feedback => new
2011-02-03 01:31 Torr Samaho Note Added: 0000935
2011-02-03 02:23 Torr Samaho Status new => acknowledged
2011-02-03 10:46 unknownna Note Added: 0000938
2011-02-04 01:11 Torr Samaho Note Added: 0000952
2011-02-04 01:26 unknownna Note Added: 0000953
2011-02-04 02:23 Torr Samaho Assigned To => Torr Samaho
2011-02-04 02:23 Torr Samaho Status acknowledged => confirmed
2011-02-04 03:14 Torr Samaho Note Added: 0000954
2011-02-04 03:14 Torr Samaho Status confirmed => feedback
2011-02-04 11:36 unknownna Note Added: 0000956
2011-02-04 11:47 unknownna Note Edited: 0000956 View Revisions
2011-02-04 13:08 unknownna Note Edited: 0000956 View Revisions
2011-02-04 14:02 unknownna Note Edited: 0000956 View Revisions
2011-02-05 20:45 Torr Samaho Note Added: 0000966
2011-02-05 20:47 Torr Samaho Note Edited: 0000966 View Revisions
2011-02-06 18:57 AlexMax Note Added: 0000988
2011-02-07 01:55 Torr Samaho Note Added: 0000997
2011-02-07 04:40 Xenaero Note Added: 0001001
2011-02-07 04:40 Xenaero Status feedback => assigned
2011-02-09 22:30 Xenaero Note Added: 0001032
2011-02-10 01:20 Torr Samaho Note Added: 0001033
2011-02-10 01:21 Torr Samaho Status assigned => feedback
2011-02-10 01:56 unknownna File Added: 2011.02.10_02.48.25_player_sprite_desync_test.cld
2011-02-10 01:56 unknownna File Added: player_sprite_desync_test.wad
2011-02-10 02:07 unknownna Note Added: 0001034
2011-02-10 02:33 unknownna File Added: 2011.02.10_03.27.52_player_sprite_desync_test_02.cld
2011-02-10 02:33 unknownna File Added: player_sprite_desync_test_02.wad
2011-02-10 02:34 unknownna Note Edited: 0001034 View Revisions
2011-02-10 02:49 Torr Samaho Note Added: 0001035
2011-02-10 03:01 unknownna Note Added: 0001036
2011-02-10 03:03 unknownna Note Edited: 0001036 View Revisions
2011-02-10 13:41 unknownna Note Edited: 0001036 View Revisions
2011-02-10 13:44 unknownna Note Edited: 0001036 View Revisions
2011-02-11 12:57 Torr Samaho Note Added: 0001037
2011-02-11 13:55 unknownna Note Added: 0001039
2011-02-11 19:04 unknownna Note Edited: 0001039 View Revisions
2011-02-11 19:10 unknownna Note Edited: 0001039 View Revisions
2011-02-11 19:19 unknownna Note Edited: 0001039 View Revisions
2011-02-11 19:38 unknownna Note Edited: 0001039 View Revisions
2011-02-11 20:22 unknownna File Added: 2011.02.11_21.20.28_player_sprite_desync_test_03.cld
2011-02-11 20:22 unknownna File Added: player_sprite_desync_test_03.wad
2011-02-11 20:23 unknownna Note Edited: 0001039 View Revisions
2011-02-12 02:42 Torr Samaho Note Added: 0001044
2011-02-12 10:11 unknownna Note Added: 0001045
2011-02-12 14:55 Torr Samaho Note Added: 0001048
2011-02-12 15:15 unknownna Note Added: 0001049
2011-02-12 15:27 unknownna Note Edited: 0001049 View Revisions
2011-02-12 16:01 Torr Samaho Note Added: 0001051
2011-02-12 16:20 unknownna Note Added: 0001052
2011-02-12 16:25 unknownna Note Edited: 0001052 View Revisions
2011-02-12 16:42 Torr Samaho Note Added: 0001053
2011-02-12 16:46 unknownna Note Added: 0001054
2011-02-12 16:50 unknownna Note Edited: 0001054 View Revisions
2011-02-12 19:08 unknownna File Added: 2011.02.12_20.04.17_player_sprite_desync_test.cld
2011-02-12 19:11 unknownna Note Added: 0001055
2011-02-15 18:37 unknownna Note Added: 0001092
2011-02-15 18:40 unknownna File Added: coop_spy_bot.png
2011-02-15 18:41 unknownna File Added: coop_spy_player.png
2011-02-15 18:55 unknownna Note Edited: 0001092 View Revisions
2011-03-30 14:54 unknownna Note Added: 0001235
2011-03-30 14:59 unknownna Note Edited: 0001235 View Revisions
2011-03-30 15:47 unknownna File Added: 2011.03.30_17.42.49_player_sprite_desync_test_02.cld
2011-03-30 15:48 unknownna Note Edited: 0001235 View Revisions
2011-03-30 15:58 unknownna Reproducibility random => always
2011-04-10 16:15 Torr Samaho Note Added: 0001328
2011-04-10 16:45 unknownna Note Added: 0001329
2011-04-10 16:51 unknownna Status feedback => assigned
2011-04-10 17:44 Torr Samaho Note Added: 0001330
2011-04-10 18:17 unknownna Note Added: 0001331
2011-04-10 18:26 unknownna Note Added: 0001332
2011-04-10 18:31 Torr Samaho Note Added: 0001333
2011-04-10 18:42 unknownna Note Added: 0001334
2011-04-10 19:50 Torr Samaho Note Added: 0001335
2011-04-10 19:53 Torr Samaho Status assigned => feedback
2011-04-10 22:10 unknownna Note Added: 0001337
2011-04-10 22:10 unknownna Status feedback => assigned
2011-04-17 19:56 unknownna File Added: 2011.04.17_21.44.00_doom2.cld
2011-04-17 19:58 unknownna Note Added: 0001390
2011-04-17 20:41 unknownna Note Edited: 0001390 View Revisions
2011-04-23 21:15 unknownna Note Added: 0001415
2011-04-24 14:32 Torr Samaho Note Added: 0001436
2011-04-24 14:43 Torr Samaho Status assigned => feedback
2011-04-24 20:10 unknownna Note Added: 0001440
2011-04-24 20:14 unknownna File Added: 2011.04.24_22.07.17_player_sprite_desync_test_02.cld
2011-04-24 21:43 Torr Samaho Note Added: 0001449
2011-04-24 21:49 Torr Samaho Note Edited: 0001449 View Revisions
2011-04-24 22:26 unknownna Note Added: 0001453
2011-04-24 22:59 Torr Samaho Note Added: 0001455
2011-04-24 23:22 Torr Samaho Note Added: 0001456
2011-04-24 23:47 Torr Samaho Note Added: 0001457
2011-04-24 23:48 unknownna Note Added: 0001458
2011-04-24 23:53 Torr Samaho Note Added: 0001459
2011-04-24 23:55 unknownna Note Edited: 0001458 View Revisions
2011-04-25 00:12 unknownna Note Added: 0001460
2011-04-25 00:34 Torr Samaho Note Added: 0001461
2011-04-25 00:43 unknownna Note Added: 0001462
2011-04-25 00:51 unknownna File Added: 2011.04.25_02.49.05_player_sprite_desync_test_02.cld
2011-04-25 00:54 unknownna Note Edited: 0001462 View Revisions
2011-04-25 00:57 Torr Samaho Note Added: 0001463
2011-04-25 01:02 unknownna Note Added: 0001464
2011-04-25 02:15 Torr Samaho Note Added: 0001465
2011-04-25 02:25 Torr Samaho Note Edited: 0001465 View Revisions
2011-04-25 03:59 unknownna Note Added: 0001466
2011-04-25 22:11 unknownna Note Added: 0001469
2011-04-26 01:56 Torr Samaho Note Added: 0001474
2011-04-26 02:28 unknownna Note Added: 0001475
2011-04-26 23:47 unknownna Note Added: 0001482
2011-04-27 14:38 unknownna Note Added: 0001487
2011-04-28 07:41 unknownna Note Added: 0001491
2011-04-28 07:46 unknownna Note Edited: 0001491 View Revisions
2011-05-01 06:11 unknownna Note Added: 0001522
2011-05-01 06:52 unknownna Note Edited: 0001522 View Revisions
2011-05-01 15:29 Xenaero Note Added: 0001529
2011-05-01 15:29 Xenaero Status feedback => assigned
2011-05-08 10:14 unknownna Note Added: 0001563
2011-05-08 10:24 unknownna Note Edited: 0001563 View Revisions
2011-05-15 19:04 unknownna Relationship added parent of 0000444
2011-05-23 11:38 unknownna Relationship added related to 0000465
2011-07-09 20:11 unknownna Relationship added parent of 0000512
2011-07-09 20:12 unknownna Note Deleted: 0001487
2011-07-09 20:13 unknownna Note Deleted: 0001482
2011-07-09 20:13 unknownna Note Deleted: 0001563
2011-07-09 20:48 Xenaero Note Added: 0001842
2011-07-10 20:38 Torr Samaho Note Added: 0001859
2011-07-11 00:18 unknownna Note Added: 0001876
2011-07-11 01:21 Torr Samaho Note Added: 0001877
2011-07-11 01:39 unknownna Note Added: 0001878
2011-07-23 21:50 Xenaero Note Added: 0001934
2011-07-24 00:01 Torr Samaho Note Added: 0001935
2011-07-24 00:13 unknownna Note Added: 0001936
2011-07-24 00:18 unknownna Note Edited: 0001936 View Revisions
2011-07-24 00:53 Torr Samaho Note Added: 0001938
2011-07-24 01:14 Xenaero Note Added: 0001940
2011-07-24 12:18 Torr Samaho Note Added: 0001943
2011-07-24 13:51 Edward-san Note Added: 0001944
2011-07-24 19:40 Torr Samaho Note Added: 0001945
2011-07-24 21:34 Edward-san Note Added: 0001947
2011-07-24 22:39 Edward-san Note Edited: 0001947 View Revisions
2011-07-25 00:55 Torr Samaho Note Added: 0001950
2011-07-25 01:37 unknownna Note Added: 0001951
2011-07-25 01:38 unknownna Note Edited: 0001951 View Revisions
2011-07-25 01:42 unknownna Note Edited: 0001951 View Revisions
2011-07-25 01:45 unknownna Note Edited: 0001951 View Revisions
2011-07-25 01:51 Torr Samaho Note Added: 0001952
2011-07-25 01:52 Torr Samaho Note Edited: 0001952 View Revisions
2011-07-25 02:11 unknownna Note Added: 0001953
2011-07-25 02:12 unknownna File Added: compat_oldweaponswitch_1_no_ping.zip
2011-07-25 02:16 unknownna Note Edited: 0001953 View Revisions
2011-07-25 02:45 unknownna Severity minor => major
2011-07-27 11:23 Torr Samaho Note Added: 0001972
2011-07-27 11:23 Torr Samaho Note Edited: 0001972 View Revisions
2011-07-27 11:24 Torr Samaho Note Revision Dropped: 1972: 0000996
2011-07-27 11:24 Torr Samaho Note Edited: 0001972 View Revisions
2011-07-27 12:05 unknownna Note Added: 0001973
2011-07-27 12:26 unknownna Note Edited: 0001973 View Revisions
2011-07-27 23:38 Torr Samaho Note Added: 0001976
2011-07-27 23:38 Torr Samaho Status assigned => feedback
2011-07-28 01:36 unknownna Note Added: 0001977
2011-07-28 09:16 unknownna Relationship added related to 0000534
2011-07-28 13:10 unknownna Note Added: 0001985
2011-07-28 13:12 unknownna File Added: 2011.07.28_14.55.39_player_sprite_desync_test.cld
2011-07-28 13:19 unknownna Note Edited: 0001985 View Revisions
2011-07-29 01:39 Torr Samaho Note Added: 0001994
2011-07-29 02:23 unknownna Note Added: 0001999
2011-07-29 02:35 Torr Samaho Note Added: 0002000
2011-07-29 02:52 unknownna Note Added: 0002003
2011-07-30 05:31 unknownna File Added: player_sprite_desync_3287.zip
2011-07-30 05:32 unknownna Note Added: 0002009
2011-07-30 12:02 unknownna Note Added: 0002010
2011-07-30 12:21 unknownna File Added: 2011.07.30_14.19.17_player_sprite_desync_test_02.cld
2011-07-30 12:22 unknownna Note Edited: 0002010 View Revisions
2011-07-30 13:16 Torr Samaho Note Added: 0002014
2011-07-30 13:38 unknownna Note Added: 0002018
2011-07-30 13:40 unknownna Relationship added related to 0000540
2011-07-30 14:00 Torr Samaho Note Added: 0002019
2011-07-30 14:21 unknownna Note Added: 0002021
2011-08-07 13:44 unknownna Relationship added related to 0000544
2012-03-29 16:56 unknownna Note Deleted: 0001491
2012-06-09 13:22 Torr Samaho Category General => Bug
2012-10-02 02:20 unknownna Relationship added related to 0001094
2012-10-10 16:32 unknownna Relationship added parent of 0001116
2015-06-14 06:03 unknownna Note Added: 0012691
2015-06-14 06:03 unknownna Note Edited: 0012691 View Revisions
2015-06-14 06:04 unknownna Status feedback => resolved
2015-06-14 06:04 unknownna Fixed in Version => 2.0
2015-06-14 06:04 unknownna Resolution open => fixed
2015-06-20 17:47 Edward-san Relationship added related to 0002067
2018-09-30 22:54 Blzut3 Status resolved => closed






Questions or other issues? Contact Us.

Links


Copyright © 2000 - 2020 MantisBT Team
Powered by Mantis Bugtracker