View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001809 | FSSCP | multiplayer | public | 2008-11-02 02:50 | 2008-11-09 05:11 |
Reporter | FUBAR-BDHR | Assigned To | taylor | ||
Priority | normal | Severity | minor | Reproducibility | random |
Status | resolved | Resolution | fixed | ||
Product Version | 3.6.9 | ||||
Fixed in Version | 3.6.10 | ||||
Summary | 0001809: Stats not saving with not enough player message when there are multiple players present | ||||
Description | This 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 Information | I 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. | ||||
Tags | No tags attached. | ||||
2008-11-02 02:50
|
|
2008-11-02 02:50
|
|
|
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). |
|
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. |
|
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. |
|
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. |
|
Fixered. |
Date Modified | Username | Field | Change |
---|---|---|---|
2008-11-02 02:50 | FUBAR-BDHR | New Issue | |
2008-11-02 02:50 | FUBAR-BDHR | File Added: screen0021.jpg | |
2008-11-02 02:50 | FUBAR-BDHR | File Added: screen0024.jpg | |
2008-11-02 04:32 | taylor | Note Added: 0010144 | |
2008-11-02 04:32 | taylor | Status | new => assigned |
2008-11-02 04:32 | taylor | Assigned To | => taylor |
2008-11-02 18:15 | FUBAR-BDHR | Note Added: 0010146 | |
2008-11-02 19:30 | taylor | Note Added: 0010147 | |
2008-11-02 19:45 | FUBAR-BDHR | Note Added: 0010150 | |
2008-11-09 05:11 | taylor | Status | assigned => resolved |
2008-11-09 05:11 | taylor | Fixed in Version | => 3.6.10 |
2008-11-09 05:11 | taylor | Resolution | open => fixed |
2008-11-09 05:11 | taylor | Note Added: 0010162 |