Issues found on Dogfight Network Game

[ghost]

• time is not synched
• ammo setting depends on client setting (as probably some other things)
• clients can spawn bots
• exit zone is sometimes visible
• for some reason (might have been network configuration) only opening games from one of the two computers worked. When I tried to open a game and the other computer joined it mostly crashed with

INFO  [MAIN ] [mainmenu.c:355] JoinLANGame(): joining LAN game...
INFO  [NET  ] [net_client.c:157] NetClientTryConnect(): Connecting client to 192.168.2.103:37554...
Connected.
INFO  [MAIN ] [gamedata.c:110] CampaignLoad(): loaded campaign/dogfight
fish: “./cdogs-sdl” terminated by signal SIGSEGV (Address boundary error)

• at least parts of the loaded map depend on the map files on both players computer, for example, the amount of max ammo of a weapon

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[noerw]

The general issue is that clients load their own resources of maps (map + weapons) & game-settings (ammo, ..).
Those have to be loaded from the server to ensure each player plays under the same conditions

[cxong]

These should be separate issues; here are some initial comments:

• time sync: not sure what you mean 100%, but if you mean the general latency, this is true as there is no latency compensation yet, so anything >100ms ping will be terrible, just like old school 90's internet games. This usually shouldn't happen on LANs, unless someone is downloading. See Improved network multiplayer #384
• ammo settings: need to implement
• client bots: can't reproduce, unless you mean the co-op AI players, then this is intentional - they're just AI-controlled players
• exit zone: need to fix
• connection crash: can't reproduce; if you can provide steps to reproduce, or debug/trace logs, or even core dump + stack trace that would be really helpful
• map loading: for now I'm assuming maps with the same path are identical, but otherwise it'll involve quite a few new features, like downloading a map across the network, or checking the integrity of maps. Until (and if) there's a lot of users making custom maps, I'm not sure if this is worth implementing - maybe just outputting an error if it detects the two maps don't match.

[ghost]

time sync: not sure what you mean 100%, but if you mean the general latency, this is true as there is no latency compensation yet, so anything >100ms ping will be terrible, just like old school 90's internet games. This usually shouldn't happen on LANs, unless someone is downloading.

I don't mean the latency, I mean the time the game is running, shown at the clock in the top-center of the screen. Isn't that supposed to be equal for every player?

connection crash: can't reproduce; if you can provide steps to reproduce, or debug/trace logs, or even core dump + stack trace that would be really helpful

Besides logging with DEBUG, is there another option one has to use to log stack traces?

[cxong]

To generate core dumps: http://stackoverflow.com/questions/17965/how-to-generate-a-core-dump-in-linux-when-a-process-gets-a-segmentation-fault
To get a stack trace from the core dump: http://stackoverflow.com/questions/5745215/getting-stacktrace-from-core-dump

[ghost]

@cxong Thanks, I'll look into that at the next opportunity.

[cxong]

By the way, I think if you configure the project with DEBUG_PROFILE=1, the resulting core dumps should show you exactly which source file and line in the stack trace; this should make it much easier to spot the problems.

[ghost]

Thanks. The problem is, I don't know the next opportunity to test
network gaming.

BTW: Does this setting also affect the editor? If so, I could provide
you with more information regarding the remaining problem of
#407

Best regards
Sauer2

On 06.05.2016 14:04, Cong wrote:

By the way, I think if you configure the project with
|DEBUG_PROFILE=1|, the resulting core dumps should show you exactly
which source file and line in the stack trace; this should make it
much easier to spot the problems.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#405 (comment)

[cxong]

yes; I wasn't aware #407 was an editor problem?

[ghost]

Oh, sorry, I meant #408 instead.

On 06.05.2016 15:04, Cong wrote:

yes; I wasn't aware #407
#407 was an editor problem?

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#405 (comment)

[cxong]

Looks like I missed a problem here; about the time sync issue, that's the mission timer, which starts from 0 for the player. So if someone hosts a game and then a client joins later, the client's mission timer will be smaller than the host's, because it starts from 0 from when the client joins.

Although they're not synced, in theory they should tick at the same speed.

I guess in multiplayer scenarios the timer should be taken from the server - maybe on connect, the host sends their current timer value and then the client just starts counting independently from that. The timer doesn't really affect anything else yet, it's just informative.