2019-10-23 13:24 EDT


View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0001809FSSCPmultiplayerpublic2008-11-09 00:11
ReporterFUBAR-BDHR 
Assigned Totaylor 
PrioritynormalSeverityminorReproducibilityrandom
StatusresolvedResolutionfixed 
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 Files

-Relationships
+Relationships

-Notes

~0010144

taylor (administrator)

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 (developer)

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 (administrator)

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 (developer)

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 (administrator)

Fixered.
+Notes

-Issue History
Date Modified Username Field Change
2008-11-01 22:50 FUBAR-BDHR New Issue
2008-11-01 22:50 FUBAR-BDHR File Added: screen0021.jpg
2008-11-01 22:50 FUBAR-BDHR File Added: screen0024.jpg
2008-11-02 00:32 taylor Note Added: 0010144
2008-11-02 00:32 taylor Status new => assigned
2008-11-02 00:32 taylor Assigned To => taylor
2008-11-02 13:15 FUBAR-BDHR Note Added: 0010146
2008-11-02 14:30 taylor Note Added: 0010147
2008-11-02 14:45 FUBAR-BDHR Note Added: 0010150
2008-11-09 00:11 taylor Status assigned => resolved
2008-11-09 00:11 taylor Fixed in Version => 3.6.10
2008-11-09 00:11 taylor Resolution open => fixed
2008-11-09 00:11 taylor Note Added: 0010162
+Issue History