Connection problems what to check

I think, seen the problems of yesterday with the connection to see the possible solutions:

1 - there are case where the problems are related to ISP maintance,firewalls or similar, the biggest part of time they are temporary problems, but it can be the ISP blocks for some reason the standard port of game 31791 for a player; so in this case (the host) need to change the port used in the first screen of multiplayer page (press "port mapping" button for set the new value, it doesn't matter if it gives you error, the default is changed after that).

2 - using the lobby he matches are hosted using this nat server schema: http://www.raknet.net/raknet/manual/natpunchpanel3.jpg with a matrix server; I don't think is a proxy server (http://www.raknet.net/raknet/manual/natpunchpanel7.jpg). In theory the role of nat server is terminated after the contact between the host and the clients, but I'm not sure it maintain some sort of contact with the host and it is possible the number of players in the lobby has some sort of impact on the connection lost problem. So because it is not necessary use it if the host has the NAT open http://portforward.com/english/routers/port_forwarding/routerindex.htm , I think it should be better try to host bypassing the lobby and the nat server with the direct ip connection. Not sure if the host bypass the nat server in this case but the fact that yesterday for some time Martin cannot connect to me via lobby but it works immediatly with the direct ip, it indicates that in this case the client bypassed the nat server.

3 - because the modern antiviruses check also the net traffic is better deactivate them during the game: the same for firewall, ipblockers, malwarebytes and similia. The games use the UDP protocol not the TCP so this means that the host doens't sent signal about lost packets during the transmission nor they are sent again (that is why the game freeze, the host wait for a packet which will never come, and because all the PC are syncronized, all stopped for wait).

4 - WiFI connections are not the best to play games (because of UDP), they lost packets with more frequency than cable, so if possible use cable.

In addition DO NOT run Scourge of War in a window. ONLY RUN FULL SCREEN.

Hi Digby

We can do this for be sure, but technically speaking I have doubts about the link between the two things: first I think yesterday we were all in full screen (after you leaved we tried again and we proceed with almost 1:1 realtime for 30 minutes and we freezed without courier generated in that moment) second graphical part has not direct impact on the net routines, but only on the overall performance of single PC which indirectly can impact the CPU and can generate lag slowing it. Usually have a lower resolution reduces graphical requirements and the CPU% so it should help not create problems. When you generate a courier you send the same frame information (where frame has nothing to do with FPS, but is a packet of data sent via net) whatever your resolution\full screen is. You send and receive hundred of information also when you don't generate a courier order for maintain the game aligned.

Desyncronization is a very common problem, I remember how many time TW matches desyncronize or crash and they never solved the problem (NTW3 mod is played via tunngle because using steam server it crashes always).

I found also this old post: http://www.norbsoftdev.net/forum/technical-help-a-bug-post/54857-game-freeze-qbadrandsyncq ; I suppose it can be related also to problems with the map (perhaps if you play without and with Antietam you can have different numbers)

We had a long discussion with Norb over this issue more than a year ago - well before you joined the KS group Davide. Norb told us that we MUST run the game in full screen or else the windowed players wll cause this "bad frame in packet" error. This error shows up quite frequently and WE KNOW FROM NORB that the way to avoid it is to all run the game in full screen. Its something specific to courier free text messages and doesn't affect other MP setups.

But please, just run in full screen as we will not get these crashes any more. Trust me.

I was extremely cross last night when it became obvious that someone (no-one ever admits it - I wonder why?) was using a windowed game mode. I will not apologise for seeming to be angry over this because we know how to avoid it - Norb told us more than a year ago. Just use full screen and we avoid one more type of game crash that affects courier play.

Sorry I was not able to find the correct post in Norb forum, I found one of more than 2 years ago about the couriers crashes but there was no reference at the windowed mode. Are you sure the problem has been not corrected in a successive patches? I did a lot of multiplayer testing on courier messages with written texts on the 1.60 with the team at the time when there was the anomaly of courier to the wrong destination and always in windowed mode, never a freeze. I hosted the 13 people match of March in windowed mode and nothing froze.

I can assume there is\was a anomaly linked, but as you can see the bad packets can be generated by different reasons according to Norb, first at all the mods itself, not all the differences are checked during the loading. I repeat: yesterday at the second start we were all in full screen, no lag, no messages in creation at that moment and we froze in any case.

This was never discussed on the NSD forum and you won't find any posts related to it. It was something the KS group discussed direct with Norb privately. Niall, Martin, John, Kevin, Jeff and maybe Jack will remember this episode well. Norb made some changes (the "hit enter key to add a new line of text message" is one of the changes he added to help fix this) but he told us via e-mail to run the game in full screen mode when using couirers. You'll see this crash error when you set you sowgb.ini file under [Debug] to DbgLvl=2.

To be honest with you I just don't want to discuss this again, we found a fix for this long before you joined the KS group. PLAY IN FULL SCREEN AND THE PROBLEM IS FIXED.

Lets end this discussion there. I am really, really tired of talking this through with every new person who turns up and wants to re-invent the wheel, hence why I was so cross the other night to STILL find someone running a windowed mode with couriers despite this having been mentioned many times.

Digby is correct. When the KS group first started playing SOW, we had numerous bad packet errors that would crash the game. These almost always occurred when a courier message was sent. Norb spent some time trying to fix the issue. He created several patches to address the problem. The solution was smaller packet sizes and playing in full screen mode. It was Norb who suggested playing in full screen mode, by the way. We tested this and the results were very clear. We should always play in full screen mode.

The first crash Saturday was probably due to someone playing in windowed mode. The 2nd one apparently didn't involve couriers or windowed mode. It was just a rare crash that does occur for an unknown reason.

In any case, everyone needs to play in full screen mode. We should remind people of this prior to the game.

I think with Berthier we solved the problem of Secessionville: without Antietam the game freeze after a time more or less long: I suppose the problem are the graphical missing packages, probably some of them generate anomalies in the values when you march near to them. He took Antietam and we played for 30 minutes without problems and with many couriers exchanges, after two matches without Antietam during which it freezes in less than 5 minutes from the starting after few couriers.

Probably the same problem could happen in all the mod maps where are included some graphical objects present only in Antietam and one of players has not the module (perhaps this happened with the map of red river of some time ago when we froze two times in succession) and move near to them. I don't remember well but I think only Antietam has now graphical features included whcih can be present in the mod maps, not Chancellorsville, correct?

If we are pretty sure that the free add-on Seccessionville is using objects from the retail add-on Antietam then NSD should be told about this. I am sure it wasn't their intention that customers who wanted to play MP games on the Seccessionville map would have to buy the Antietam add-on, so the Seccessionville add-on should have the relevant Antietam objects included with it.

Little Powell actually gives a warning to the effect that the mod uses the Antietam graphics pack. Davide's interpretation of the 2nd crash is a reasonable explanation. We will need to warn players that Antietam is required whenever we use this map. This may not be the only mod that uses graphics from one of the addons. All KS players should be encouraged to purchase all the expansion packs, so we don't repeat last week's debacle.

Perhaps a complete list of needed expansion packs might be added for all to see. I am sure that some packs were published before some members "enlisted."

J

>If we are pretty sure that the free add-on Seccessionville is using objects from the retail add-on Antietam then NSD should be told about this.

Yes they told, that is why I checked. I don't think it supposed to generate desync, but there is a good probability the problem was related (perhaps some particular objects). I doubt Pipe Creek and Brandy Station included new graphical objects of this type, I have doubts about Chancellorsville