Source Code Project Mantis - FSSCP
View Issue Details
0001809FSSCPmultiplayerpublic2008-11-01 22:502008-11-09 00:11
ReporterFUBAR-BDHR 
Assigned Totaylor 
PrioritynormalSeverityminorReproducibilityrandom
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version3.6.9 
Target VersionFixed in Version3.6.10 
Summary0001809: Stats not saving with not enough player message when there are multiple players present
DescriptionThis seems to only happen as a client (standalone or not) or when hosting on a standalone and doesn't always happen. It does seem to occur more often then not. When you accept the stats after a mission you will receive a message that "not enough players were present at game start or end, stats will not be saved." We had 6 players at one point and the message still showed up. Never received it when doing regular hosting.
Additional InformationI received it using Taylor's multi_test build but some of the people reported getting it with recent Knightly builds as well. Shade and I did test this several times with both of us using the same build.
TagsNo tags attached.
Attached Filesjpg screen0021.jpg (50,483) 2008-11-01 22:50
http://scp.indiegames.us/mantis/file_download.php?file_id=1135&type=bug
jpg

jpg screen0024.jpg (59,802) 2008-11-01 22:50
http://scp.indiegames.us/mantis/file_download.php?file_id=1136&type=bug
jpg

Notes
(0010144)
taylor   
2008-11-02 00:32   
The Knightly builds don't contain the code for that, so I highly doubt they actually got the same message. :)

The user count check in the new code is broken though. It will be fixed in the next test build (need to verify some of these new fixes for your bug reports before commit).
(0010146)
FUBAR-BDHR   
2008-11-02 13:15   
Well basically they said stats weren't saving in the latest builds so they reverted to using older 3.6.10 builds. If the host accepts stats before the client he doesn't see the message for why the stats didn't save since it goes right back to the forming stage. So there may be 2 different problems causing stats not to save then. I take it the system in the multi_test will override the existing one when committed so if it is fixed then we should be OK.
(0010147)
taylor   
2008-11-02 14:30   
Well the new code does require that you accept the stats before it will send them to the server. This is required of all involved though, if using the newer code, since it will only send each persons stats after they have accepted. Knightly builds are still using the old code, so it's just multi_test build or the multiplayer test build I posted that have the new code. Knightly, and other builds based on the old code, still save automatically as soon as the debrief window loads. For logging purposes though, the new code does print out to the multi.log file whether stats saved or not, if it even gets that far.

But you do point out a possible bug that I need to look into however. The new code is supposed to give the client a chance to save stats or not before taking them out of the debrief, whether the host initiates the debrief exit or not. It's possible that part of the new code simply isn't working like I thought, which could explain the problem in the new code builds. I'll give it a look and include any fixes in the next test build.
(0010150)
FUBAR-BDHR   
2008-11-02 14:45   
It does give the client the chance to save them. It's only the message they can't see. Basically it moves so fast the clients sees the stats saved failed message but can't see the reason why. I would assume this only happens to the last client to hit accept since it jumps back to the forming menu then.
(0010162)
taylor   
2008-11-09 00:11   
Fixered.

Issue History
2008-11-01 22:50FUBAR-BDHRNew Issue
2008-11-01 22:50FUBAR-BDHRFile Added: screen0021.jpg
2008-11-01 22:50FUBAR-BDHRFile Added: screen0024.jpg
2008-11-02 00:32taylorNote Added: 0010144
2008-11-02 00:32taylorStatusnew => assigned
2008-11-02 00:32taylorAssigned To => taylor
2008-11-02 13:15FUBAR-BDHRNote Added: 0010146
2008-11-02 14:30taylorNote Added: 0010147
2008-11-02 14:45FUBAR-BDHRNote Added: 0010150
2008-11-09 00:11taylorStatusassigned => resolved
2008-11-09 00:11taylorFixed in Version => 3.6.10
2008-11-09 00:11taylorResolutionopen => fixed
2008-11-09 00:11taylorNote Added: 0010162