2019-10-18 23:22 EDT


View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0001067FSSCPmultiplayerpublic2007-10-17 21:26
Reportermartellato 
Assigned Totaylor 
PrioritynormalSeverityfeatureReproducibilityalways
StatusresolvedResolutionfixed 
PlatformPCOSWindows XP ProfessionalOS VersionSP2
Product Version3.6.9 
Target VersionFixed in Version3.6.10 
Summary0001067: standalone problems with gamma over tcp
DescriptionI had the fortune today to try out running the gamma build as a standalone over tcp, while another person (DaBrain) who was also using gamma tried to play on my server. He was able to connect, name his game, and (I believe) select a mission. At some point shortly after, he crashed and I "refreshed".

Aside: When this "refresh" happens while I run -standalone using the standard gamma executable, a pop-up window shows all of the missions being reloaded; all i.p. connections are dropped.
When this happens while I’m using the gamma debug executable instead, he crashes and I get an assert failure.

Attached are some logs from both the standalone server (moi) and the client (DaBrain) from some of our. I should admit that I don't think we completely sycronized the logs that we are sending to you – that is, some of the content of his logs may contain trials that my logs don't contain. In addition, our computer clocks are set differently. If you would like other, more consistent logs to work with, I’d be happy to get you some better data.

That said, here's what I can tell you for sure about these logs... the standalone logs that are attached are from a single standalone run with the debug build. The "standalone-server_clipboard.txt" attachment contains what the debug build assert failure was when it halted.
I'll put my exact params for this run in the Steps To Reproduce section below:
Steps To Reproduce1. Turn off PXO
2. Run C:\Games\FreeSpace2\ fs2_open_3_6_9_debug_gamma.exe -standalone -multilog
3. Have a gamma client connect to your ip address
4. Have the gamma client create a game on your standalone server, and attempt to launch a game
TagsNo tags attached.
Attached Files
  • log file icon standalone-server_multi.log (5,010 bytes) 2006-09-24 01:09
  • log file icon standalone-server_fs.log (5,367 bytes) 2006-09-24 01:09
  • txt file icon standalone-server_clipboard.txt (721 bytes) 2006-09-24 01:09 -
    Assert: bm_bitmaps[bitmapnum].handle == handle
    File: c:\temp\fs2_open_3_6_9.gamma\code\bmpman\bmpman.cpp
    Line: 2586
    [This filename points to the location of a file on the computer that built this executable]
    
    Call stack:
    ------------------------------------------------------------------
        bm_lock()    player_set_squad_bitmap()    multi_process_valid_join_request()    process_join_packet()    process_packet_normal()    multi_process_bigdata()    multi_process_incoming()    multi_do_frame()    game_do_networking()    game_do_state_common()    game_do_state()    gameseq_process_events()    game_main()    WinMain()    WinMainCRTStartup()------------------------------------------------------------------
     
    
    txt file icon standalone-server_clipboard.txt (721 bytes) 2006-09-24 01:09 +
  • log file icon client_fs.log (94,238 bytes) 2006-09-24 01:09
  • log file icon client_multi.log (1,560 bytes) 2006-09-24 01:09

-Relationships
+Relationships

-Notes

~0006696

taylor (administrator)

The debug related standalone problems are known, and fixes are in the works. I'll end up getting you another test build in a few days to try the change out (I don't run Windows, so testing the standalone server, which is Windows-only, isn't a simple task for me).

The client crash, wasn't really a crash. It was a parsing related (I think) warning dialog, which had it's "Yes" button clicked, which means "stop operation and break into the debugger". Based on that I'd assume that it's a non-issue.

I'll have to check on the "refresh" issues though, but it looks like it's unrelated to the actual "refresh" proceedure and is just a side effect of other problems that I'm already working to fix.

~0006700

martellato (reporter)

Glad to hear that some stuff is already in the works. I'd be glad to help test this stuff out and report back. Thanks. :)

~0006710

taylor (administrator)

Ok, I think I've gotten most of the changes in sync with CVS now. I'll post a link to a new test build in a few hours.

~0006711

taylor (administrator)

Give this build a try and let me know what's still broken (it's fresh 3_6_9 CVS):
http://icculus.org/~taylor/fso/testing/rc7dot7.rar

~0006751

taylor (administrator)

Let's see what this one does...
http://icculus.org/~taylor/fso/testing/rc7dot8.rar

~0006763

martellato (reporter)

Great, happy to try it out. Fyi, I don't have any solid test results for you from dot7. I logged some activity from players who joined a dot7 game hosted on NetD, and left with 2 minutes. But I wouldn't be able to tell if they left intentionally or because of a crash, so the info didn't seem very useful..

If I can get some solid data for you on dot8, then I'll post it up.

Some related questions... if I'm using dot8:
-Can I see 3.6.9 rc7 games on NetD?
-Can 3.6.9rc7 clients see a dot8 game that I host on NetD?

...Just wondering what the rules are with the game screening feature. If I know that only the right candidates are connecting to my games, then I don't need to worry about tracking what build everyone is using... Thanks!

~0006764

taylor (administrator)

"No" and "No" to your questions. We changed the version number back to the retail value, so games from other builds won't show up in this one, and games from this build won't show up to other builds. Irritating, but it was necessary to do this at some point for the new PXO code, and now was as good a time as any.

You'll need to use 7dot7+ on both sides for it to work. This will be the same for all future builds too however, so we just have to wait for everyone to catch up and start using the correct builds. Since this is only the second build with this change I don't really expect a ton of people to be using it yet, but I'm trying to get the word out.

~0006945

taylor (administrator)

Just marking as feedback those bugs which should either be fixed in the next available build from me, or need to be tested as fixed in the next available build.

(There are so many new bugs right now, it's easier for me to keep up with the fixed or almost-fixed bugs this way.)

~0008571

taylor (administrator)

This should be fixed now, but check again with this build just to make sure:
http://www.hard-light.net/forums/index.php/topic,49939.0.html

If there is no update indicating that it's still broken I'll just assume that it's fixed (I can't replicate the problem).

~0008573

taylor (administrator)

Assuming that this is:

Fixered.
+Notes

-Issue History
Date Modified Username Field Change
2006-09-24 01:09 martellato New Issue
2006-09-24 01:09 martellato File Added: standalone-server_multi.log
2006-09-24 01:09 martellato File Added: standalone-server_fs.log
2006-09-24 01:09 martellato File Added: standalone-server_clipboard.txt
2006-09-24 01:09 martellato File Added: client_fs.log
2006-09-24 01:09 martellato File Added: client_multi.log
2006-09-24 05:32 taylor Note Added: 0006696
2006-09-24 08:06 martellato Note Added: 0006700
2006-09-24 17:41 taylor Note Added: 0006710
2006-09-24 20:33 taylor Note Added: 0006711
2006-09-30 05:42 taylor Note Added: 0006751
2006-10-01 08:23 martellato Note Added: 0006763
2006-10-01 13:38 taylor Note Added: 0006764
2006-10-21 00:30 taylor Note Added: 0006945
2006-10-21 00:30 taylor Status assigned => feedback
2007-10-15 07:20 taylor Note Added: 0008571
2007-10-17 21:26 taylor Status feedback => resolved
2007-10-17 21:26 taylor Fixed in Version => 3.6.10
2007-10-17 21:26 taylor Resolution open => fixed
2007-10-17 21:26 taylor Note Added: 0008573
+Issue History