|
Notes |
|
|
(0003604)
|
|
TIHan
|
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.
|
|
|
|
(0003607)
|
|
TIHan
|
|
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. |
|
|
|
(0003609)
|
|
TIHan
|
|
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. |
|
|
|
|
|
I think I found a pretty simply way to fix this. Please test if this fixes the issue. |
|
|
|
(0006236)
|
|
Arco
|
|
2013-04-05 21:19
|
|
|
Fixed in the latest verison. |
|
Screenshot_Doom_20120506_170200.png (130,458) 2012-05-06 15:10