Zandronum Chat on our Discord Server Get the latest version: 3.2
Source Code

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000835Zandronum[All Projects] Bugpublic2012-05-06 15:102018-09-30 20:24
Reporterunknownna 
Assigned ToTorr Samaho 
PriorityhighSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version98d 
Target Version1.1Fixed in Version1.1 
Summary0000835: Some monsters don't appear on the client-end after changemap map changes until it opens the console/menu
DescriptionAttached screenshots. The monsters appear once you open the console/menu.
Steps To Reproduce1. skulltag.exe -iwad plutonia.wad -host +map map32
2. Connect a client to the server.
3. "changemap map32" in the server console.
4. Exit the intermission screen.
Additional InformationThis also happens in 98e. It seems to be a packet issue.
Attached Filespng file icon Screenshot_Doom_20120506_170200.png [^] (130,458 bytes) 2012-05-06 15:10


png file icon Screenshot_Doom_20120506_170047.png [^] (161,223 bytes) 2012-05-06 15:10

- Relationships
related to 0000679closed "Connection interrupted" OMFG (hard to explain, please read on) 

-  Notes
User avatar (0003604)
TIHan (reporter)
2012-05-08 23:30
edited on: 2012-05-09 01:27

This is indeed quite scary. Looks like the client didn't receive all of the packets. When you open the console, it sends a command to the server and the server replies, but it also comes with the monster data that the client did not get.

Edit: I can confirm that this happens on level authentication.

User avatar (0003607)
TIHan (reporter)
2012-05-09 02:51

I still need more time to study this; but, increasing sv_maxpacketsize to 8192(max) seems to solve the issue. However, I doubt this is a good idea and should stay at the default 1024.

This issue is also related to when you join this level via by a hard map reset "map map32". You notice your screen hanging until you do an action.

The cause is that the packet we are trying to send is bigger than whatever the sv_maxpacketsize is. It will just send whatever information it can to the client. Hence the missing cyberdemons. Going to console fixes the issue as when the client receives the server's response, it notices that its packet is out of sequence and requests the server for the missing packets associated for the missing sequences.

Now, we are not even talking about an enormous amount of data here. The whole snapshot to this level was 11kb...

Here is the code that does this:

    // Make sure we have enough room for the upcoming message. If not, send
    // out the current buffer and clear the packet.
    pBuffer->ulCurrentSize = pBuffer->ByteStream.pbStream - pBuffer->pbData;
    if (( pBuffer->ulCurrentSize + ( ulSize + 5 )) >= SERVER_GetMaxPacketSize( ))
    {
        if ( debugfile )
            fprintf( debugfile, "Launching premature packet: %d\n", bReliable );

        // Lanch the packet so we can prepare another.
        SERVER_SendClientPacket( ulClient, bReliable );
    }


The information that gets lost if the packet size is greater than the max will not be handled unless the client tells the server it is missing packets.
User avatar (0003609)
TIHan (reporter)
2012-05-10 01:58

With a discussion with Torr, we've decided to hold this off until after 98e is released as it requires some re-design in unifying some code to effectively handle the problem. We feel we shouldn't change this structurally before the release of 98e.
User avatar (0005710)
Torr Samaho (administrator)
2013-01-06 19:21

I think I found a pretty simply way to fix this. Please test if this fixes the issue.
User avatar (0006236)
Arco (updater)
2013-04-05 21:19

Fixed in the latest verison.

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
2012-05-06 15:10 unknownna New Issue
2012-05-06 15:10 unknownna File Added: Screenshot_Doom_20120506_170200.png
2012-05-06 15:10 unknownna File Added: Screenshot_Doom_20120506_170047.png
2012-05-06 15:10 unknownna Status new => confirmed
2012-05-06 15:12 unknownna Additional Information Updated View Revisions
2012-05-06 15:45 TIHan Assigned To => TIHan
2012-05-06 15:45 TIHan Status confirmed => assigned
2012-05-08 23:30 TIHan Note Added: 0003604
2012-05-08 23:30 TIHan Status assigned => feedback
2012-05-09 01:27 TIHan Note Edited: 0003604 View Revisions
2012-05-09 02:51 TIHan Note Added: 0003607
2012-05-09 02:52 TIHan Priority normal => high
2012-05-09 02:52 TIHan Severity minor => major
2012-05-10 01:58 TIHan Note Added: 0003609
2012-05-10 01:58 TIHan Status feedback => acknowledged
2012-06-09 13:22 Torr Samaho Category General => Bug
2012-07-29 12:33 Torr Samaho Relationship added related to 0000679
2013-01-06 19:21 Torr Samaho Note Added: 0005710
2013-01-06 19:21 Torr Samaho Assigned To TIHan => Torr Samaho
2013-01-06 19:21 Torr Samaho Status acknowledged => needs testing
2013-01-06 19:21 Torr Samaho Target Version => 1.1
2013-04-05 21:19 Arco Note Added: 0006236
2013-04-05 21:43 Dusk Status needs testing => resolved
2013-04-05 21:43 Dusk Fixed in Version => 1.1
2013-04-05 21:43 Dusk Resolution open => fixed
2018-09-30 20:24 Blzut3 Status resolved => closed






Questions or other issues? Contact Us.

Links


Copyright © 2000 - 2025 MantisBT Team
Powered by Mantis Bugtracker