Bug Tracker – Full Text Bug Listing

Bug 18

Summary: Incorrect sector data on connect
Product: Odamex Reporter: Dylan McIntosh <Embryonic138>
Component: Server & ClientAssignee: Denis Lukianov <denis>
Status: RESOLVED FIXED    
Severity: major CC: blair.cahue, Ralphis
Priority: P2    
Version: (old) 0.0.1   
Hardware: x86 (Windows, Linux, etc)   
OS: All   
Bug Depends on: 220    
Bug Blocks: 424, 122, 620    
Attachments: Better sector prediction

Description Dylan McIntosh 2005-10-04 22:15:23 UTC
Extra data is needed to describe the state of movable sectors upon connection.

Causes client/server mapstate disagreement.
Comment 1 Denis Lukianov 2005-10-09 16:55:11 UTC
I've resolved switch texture problems in bug 34. Now buttons appear correctly to
new clients. Please check if there is still a problem and give a reproduceable
example.
Comment 2 Denis Lukianov 2006-01-28 23:26:38 UTC
3-way switches do not appear correctly, as demonstrated by toke's test map
Comment 3 Mike Lightner 2006-02-02 21:48:04 UTC
Bug accepted.
Comment 4 Denis Lukianov 2006-02-25 09:26:57 UTC
Improved switch texture sync in r953, see bug 36
Comment 5 Mike Lightner 2006-02-25 20:10:57 UTC
Toke claims this was fixed a while ago, marked as fixed unless someone sees otherwise.
Comment 6 Dean Joseph 2006-02-25 20:18:32 UTC
Movable sectors appear to be fixed, according to AlexMax.
Comment 7 Dean Joseph 2006-02-25 20:21:39 UTC
Scratch that, UDM3 MAP31 appears to have weird effects upon reconnect.
Comment 8 Dean Joseph 2006-02-25 22:16:31 UTC
http://deathz0r.unidoom.org/oda/wtflift.avi

Demostrates client/server desync on UDM3 MAP31. The second half of the video is related to bug 132, but I don't think the capture was good enough to get a decent video for that part.
Comment 9 Denis Lukianov 2006-02-26 08:15:09 UTC
Does this desync happen on connect or some other time during the game?
Comment 10 Dean Joseph 2006-02-26 16:41:27 UTC
This happens sometime after reconnecting.
Comment 11 Alexander Mayfield 2006-09-19 17:25:59 UTC
Still broken as of 1513.
Comment 12 Alexander Mayfield 2006-09-19 17:37:06 UTC
To elaborate, sectors in motion still seem to pose a problem.  If they have already been triggered, then they are triggered when the map is reconnected to.  I even had one experience where a platform that was supposed to raise clientside didn't actually raise, (the first swtich in Doom 2 map29 bugged on me once, not consistantly) but reconnecting fixed it.
Comment 13 Dean Joseph 2006-11-06 21:10:50 UTC
Moving crushers do not appear to clients who connect after being activated in r1962.
Comment 14 Dean Joseph 2006-11-06 21:15:18 UTC
Severity changed to major.
Comment 15 Alexander Mayfield 2007-03-31 20:22:49 UTC
Crushers are still consistantly broken as of r177.
Comment 16 Russell Rice 2007-11-30 18:30:00 UTC
Crushers are still broken, tested r503
Comment 17 KBlair 2010-01-16 00:39:57 UTC
As of r1434 (of both client and server) and using Windows XP Home SP2, under localhost, the crushers are still broken. A good way to reproduce this is to start a server on MAP06 of Doom II, connect with a client, go down the lift to the barons/spider mastermind, and press the switch to the immediate right. Then, before the crusher starts to rise, reconnect.

After reconnecting, going down the lift reveals that crusher being in the same state as it was at the time of reconnecting, however, you can pass below it. Just like if you could if this was a true single player game. It seems the game is transferring the location of the ceiling, however, it's not resuming the sector action.
Comment 18 Russell Rice 2010-10-07 01:38:11 UTC
Created attachment 226 [details]
Better sector prediction

Patch against 0.6-dev

I've been working on this for a couple of days (and a couple of years if you count how many times I've whined in #odamex-dev :P)

Tested mostly on udm3.wad map31 (it has a big moving platform) and its almost there. Turn on _PRED_DBG for additional consistency information.

Currently there is only a slight desync that is barely noticeable when traveling on a moving platform, it sorta glitches in rendering and can be seen on the output with _PRED_DBG

Incompatible with 0.5 due to new network data, so watch out.

I'd love some help with this.
Comment 19 Ralph Vickers 2011-06-12 20:41:49 UTC
Russ fixed this in 0.6-dev branch with his patches in revisions r2121 through r2128. Marking closed finally! Great work Russell