LAN games work perfectly and are very fun. However the netgames over the Internet are often problematic: unless the host has a high speed connection, the clients will soon get out of sync and client/host won't communicate correctly. Whatever we try the same thing happens. Peoples are correctly connected to eachother but positions, damages/collisions and crush data aren't updated at all.
I guess this is probably a vague question but do you have any idea what might cause this? I suppose the game is expecting a specific latency between both the clients and the host, and the internet connection can't match this transmission speed so clients instantly get out of sync. Maybe this timeout is hardcoded?
Related to this, I remember Matt Sullivan saying in an interview (it's at SCi's old site I think) that TCP/IP would be supported. Was there ever a TCP/IP featured build or patch actually made? That could have been very useful at the moment!
I know there is few that can be done to improve the multiplayer experience but at least we are trying!
Matt Edmunds from Stainless replies:
I wrote all the low level comms code, and even I can't remember! We don't have access to the source currently.
I vaguely remember the Windows (not DOS) version of Carma2 using TCP/IP (via Winsock), but I could easily be misremembering, as Winsock supports IPX/SPX too. Perhaps I was merely experimenting and it never made it.
To be honest, it's probably not the protocol that's the problem anyway - if you're can wrapping and unwrapping it correctly at each end.
The network synchronisation code was disgustingly complicated, and made use of the Action Replay system to reposition everything when the host machine issued its view of the world. I didn't write that part!
The problem might simply be that the main loop of the game is running too fast, exposing unintended consequences! Obviously it was written in the days when no processor was faster than 200MHz (or thereabouts). The main loop spins as fast as the processor will allow, completely independent of frame rate. If you can find a way of slowing it down, it could help. Maybe hook into the GetNextMessage() function somehow?!