MantisBT - Zandronum
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002033Zandronum[All Projects] Bugpublic2014-12-22 20:222018-09-30 23:10
ReporterLeonard 
Assigned ToTorr Samaho 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformMicrosoftOSWindowsOS VersionXP/Vista/7
Product Version1.3 
Target Version1.4Fixed in Version2.0 
Summary0002033: Problems while in "requesting snapshot" state.
DescriptionThe client loads the map before requesting a snapshot.
This is problematic because the map will be loaded but the client won't have a body yet until he actually receives the snapshot.
Because of this, while being in the "requesting snapshot" state, you can hide the console by bringing the menu (gamestate set to GS_LEVEL) and it will cause a massive HOM.
Even worse is if after that you open the automap, you instantly crash.
You don't even need to open up the menu to get a HOM, if you have con_alpha < 1, a HOM will always appear and it's even worse for people like me who have con_alpha set to 0: instant full screen HOM everytime you connect.
Steps To Reproduce
Additional InformationI thought myself how we could fix this issue:
-Setting the gamestate to GS_FULLCONSOLE again might not even work and could cause problems.
-Setting gameaction to bring the fullconsole won't fix the problem since the console will still have alpha applied to it.
-Making the client spawn on himself while waiting for the snapshot sounds like a total mess.

Here's the solution I've come up with:
Load the map in client_BeginSnapshot instead.

I tested this myself and it works flawlessly.
I will make a pull request shortly after making this ticket.
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2014-12-22 20:22LeonardNew Issue
2014-12-22 20:37LeonardNote Added: 0011085
2014-12-23 20:49Torr SamahoNote Added: 0011087
2014-12-23 20:50Torr SamahoStatusnew => feedback
2014-12-24 16:31LeonardNote Added: 0011088
2014-12-24 16:31LeonardStatusfeedback => new
2014-12-28 21:46LeonardNote Added: 0011110
2014-12-28 21:49Torr SamahoNote Added: 0011111
2014-12-28 21:49Torr SamahoAssigned To => Torr Samaho
2014-12-28 21:49Torr SamahoStatusnew => needs testing
2014-12-28 21:52Torr SamahoStatusneeds testing => needs review
2014-12-29 15:14LeonardNote Added: 0011127
2014-12-29 17:21Torr SamahoNote Added: 0011130
2014-12-29 17:22Torr SamahoStatusneeds review => feedback
2014-12-29 17:46cobaltStatusfeedback => needs testing
2014-12-29 17:46cobaltTarget Version => 1.4
2014-12-29 17:46cobaltDescription Updatedbug_revision_view_page.php?rev_id=6196#r6196
2014-12-29 17:46cobaltAdditional Information Updatedbug_revision_view_page.php?rev_id=6198#r6198
2014-12-29 17:46cobaltNote Added: 0011131
2014-12-29 17:49Torr SamahoNote Added: 0011132
2014-12-31 10:15Torr SamahoNote Added: 0011145
2014-12-31 10:56Torr SamahoNote Added: 0011146
2014-12-31 13:58LeonardNote Added: 0011153
2015-01-01 17:02Torr SamahoNote Added: 0011163
2015-01-01 18:13ArcoNote Added: 0011170
2015-01-01 18:13ArcoStatusneeds testing => resolved
2015-01-01 18:13ArcoFixed in Version => 2.0
2015-01-01 18:13ArcoResolutionopen => fixed
2018-09-30 23:10Blzut3Statusresolved => closed

Notes
(0011085)
Leonard   
2014-12-22 20:37   
'https://bitbucket.org/Torr_Samaho/zandronum-stable/pull-request/117/fixed-the-client-could-potentially-crash/diff [^]'
(0011087)
Torr Samaho   
2014-12-23 20:49   
Thanks for your patch! I don't think that moving the map loading to the beginning of the snapshot is the proper strategy though. I expect this to make it even more difficult for the client to join large maps. The problem is that the server will be sending a large amount of packets in the snapshot, but the client will be completely blocked from receiving packets while loading the map. The reason for the old way was to give the client time to load the map, before the server sends all the information.

Nevertheless, what you report is a bug and definitely should be fixed. A better way to fix this, would be to properly prevent the client from rendering the map before the snapshot is fully received. "viewactive = false;" is supposed to take care of this, but apparently it doesn't work as intended.
(0011088)
Leonard   
2014-12-24 16:31   
I see.
I thought it was a good idea since the same thing happens with normal map changes (server_AuthenticateLevel) where the server tells the client to load the map at the same time it sends the snapshot.
(0011110)
Leonard   
2014-12-28 21:46   
Updated the pull request.
(0011111)
Torr Samaho   
2014-12-28 21:49   
Thanks, looks much better! I'll have to look at this in detail and will report back or pull right away.
(0011127)
Leonard   
2014-12-29 15:14   
I just realised this doesn't apply to client demos.
Will update the pull request in a short while.
(0011130)
Torr Samaho   
2014-12-29 17:21   
Please see my bibucket comment on how to shorten the code. Other than that, the patch looks good.
(0011131)
cobalt   
2014-12-29 17:46   
Issue addressed by commit 42d4faa97c04: Fixed: The client could potentially get HOMs while requesting a snapshot. (fixes 2033)
Committed by Leonard on Monday 29 December 2014 18:07:21

Changes in files:
 docs/zandronum-history.txt | 1 +
 src/c_console.cpp | 12 +++++++++---
 src/d_main.cpp | 7 ++++++-
 3 files changed, 16 insertions(+), 4 deletions(-)
(0011132)
Torr Samaho   
2014-12-29 17:49   
Pulled, rebased and compressed. I also went ahead and replaced
( NETWORK_GetState( ) == NETSTATE_CLIENT ) || ( CLIENTDEMO_IsPlaying( ) == true )

by
NETWORK_InClientMode()
in the NoWipe code fragment and sneaked "(fixes 2033)" into the log message.
(0011145)
Torr Samaho   
2014-12-31 10:15   
Now that I merged this with 2.0 I noticed severe display problems in the console while the snapshot is received in the software renderer. We'll need to fix this ASAP.
(0011146)
Torr Samaho   
2014-12-31 10:56   
I have found a way that seems to fix the problem.
(0011153)
Leonard   
2014-12-31 13:58   
Ah sorry I didn't test the fix with software, I always use opengl.
Your fix seems to have broken for people with vid_hw2d set to 1.
I made a pull request that fixes the issue in all cases (with any vid_renderer and vid_hw2d values)
(0011163)
Torr Samaho   
2015-01-01 17:02   
Strange, on my system the fix worked with "vid_hw2d 1" and the software renderer. Apparently, there are some system dependent issues. I took a different approach now to fix this: Instead of copying more and more code snippets from "case GS_FULLCONSOLE:", the code now jumps there and uses the normal full console rendering code.
(0011170)
Arco   
2015-01-01 18:13   
Issue fixed in r150101-1703.