Source Code Project Mantis - FSSCP
View Issue Details
0001827FSSCPmultiplayerpublic2008-11-20 21:092009-08-24 21:08
Assigned Totaylor 
PrioritynormalSeveritymajorReproducibilityhave not tried
PlatformOSOS Version
Product Version3.6.9 
Target VersionFixed in Version3.6.11 
Summary0001827: Strange multiplayer glitch results in awarding of medals and rank.
DescriptionOne of the strangest things I've seen in quite awhile. During TBP testing today I was in observer mode when all of a sudden a window flashed on the screen. Didn't catch what it said. When the mission ended I found myself being awarded the Epsilon Pegsi Liberation x2 , rank of Ensign, and Ace.

Looking at the logs it seems as if I logged out and back into FS2netD during the game. This was not on a standalone I was actually hosting.
Additional InformationRunning TBP in 3.6.10 from 11/09. Was playing in campaign mode.
TagsNo tags attached.
Attached Filesrar medal.rar (87,447) 2008-11-20 21:09
rar relogin.rar (23,257) 2008-11-22 02:04
log multi.log (115,550) 2009-02-13 21:41
txt medals_standalone.txt (6,342) 2009-08-21 18:43
rar multi_medals.rar (565,647) 2009-08-21 18:47

2008-11-22 02:07   
Had another similar occurrence in FS2 today. This time the game was still in the joining phase when everyone got a re-login to fs2netd. Logs from my hosting and one client in the new file.

Can't say this is the exact same problem for sure but it looks similar.
2009-02-13 21:42   
Pretty much confirmed that this is caused by a reconnect to fs2netd during a mission. Attached a multi.log from a recent mission. I wasn't running debug at the time unfortunately.
2009-02-13 22:53   
If that was the reason then it might be a server-side issue. There were different timeouts for client/session, and the session timeout was constant (it would always expire after a particular amount of time). In the v2.5 code for the server I rewrote the client and session code to merge the two and then have a single timeout that acted only on idle time.

In other words, all of these random logouts with the client having to connect again should be a thing of the past once the new code is in place. If this problem is really due to that bug then it should resolve itself once the new server code goes live.
2009-02-14 01:22   
Thats good to know. I don' think this is the only problem that relogin causes. I think it also causes the next missions stats to not be valid (even if it' a valid mission) for the host when it occurs in the lobby. So hopefully the upddate will cure at least 2 problems.
2009-02-21 23:08   
I know you already have an idea what is causing this one but I just noticed a new part of the problem. The reset happened while in game and when I went back to the lobby I was logged it with a 0 at the end of my name like I had 2 connections. Basically just a FYI in case it changes the the train of thought on the fix.
2009-08-21 18:43   
(Last edited: 2009-08-21 18:48)
This apparently just happened on a standalone for the first time. Amazingly it didn't just crash as usual. Attaching debugger call stack and variables just in case it helps track down the cause.

I'm also uploading the multi and fs2_open logs.

This was from 3.6.11. I believe the revision was 5524. 5520 at the oldest.

2009-08-22 01:14   
If that variable output is correct then I'm thinking that this is an initialization issue with the scoring struct. If it's not initialized properly then you would definitely get this error.

I'll try and get to this in the next couple of weeks (I need you to test a new build for me anyway), unless someone else gets the chance to track it down first.
2009-08-22 15:06   
Just realized that I might know exactly what causes this, and after a quick check I think that I'm correct. And it did turn out to be a bug which is triggered by the whole FS2NetD re-login thing.

The problem is that init_scoring_struct() doesn't properly init the struct for use. It does zero everything out like it should, but several of the values are required to be -1 instead of 0. scoring_level_init(), which is called at the start of any level for all users and resets the mission specific values, was hiding this oversight. When FS2NetD logs in it asks the server to get the stats for the user, calls init_scoring_struct() to reset it to default, then fills in the values stored on the server. Since it isn't initialized properly for in-mission use, you end up hitting the Assert() since it thinks that you were awarded a medal/rank by mistake. This does also point out another annoying bug as well: if you get logged out of FS2NetD in the middle of a mission then your stats for that mission up to that point get reset.

Both issues are simple to fix so I'll try and get it taken care of tomorrow.
2009-08-24 21:08   
Both issues should now be fixed in SVN. I haven't really had a chance to properly test it though. If it isn't fixed then reopen and I'll take another look.
2009-08-24 21:08   

Issue History
2008-11-20 21:09FUBAR-BDHRNew Issue
2008-11-20 21:09FUBAR-BDHRFile Added: medal.rar
2008-11-22 02:04FUBAR-BDHRFile Added: relogin.rar
2008-11-22 02:07FUBAR-BDHRNote Added: 0010251
2009-02-13 21:41FUBAR-BDHRFile Added: multi.log
2009-02-13 21:42FUBAR-BDHRNote Added: 0010674
2009-02-13 22:53taylorNote Added: 0010675
2009-02-14 01:22FUBAR-BDHRNote Added: 0010676
2009-02-21 23:08FUBAR-BDHRNote Added: 0010685
2009-08-21 18:43FUBAR-BDHRNote Added: 0011144
2009-08-21 18:43FUBAR-BDHRFile Added: medals_standalone.txt
2009-08-21 18:46FUBAR-BDHRNote Edited: 0011144
2009-08-21 18:47FUBAR-BDHRFile Added: multi_medals.rar
2009-08-21 18:48FUBAR-BDHRNote Edited: 0011144
2009-08-22 01:14taylorNote Added: 0011146
2009-08-22 15:06taylorNote Added: 0011148
2009-08-22 15:06taylorStatusnew => assigned
2009-08-22 15:06taylorAssigned To => taylor
2009-08-24 21:08taylorNote Added: 0011155
2009-08-24 21:08taylorStatusassigned => resolved
2009-08-24 21:08taylorFixed in Version => 3.6.11
2009-08-24 21:08taylorResolutionopen => fixed
2009-08-24 21:08taylorNote Added: 0011156