Entr0p1cLqd

An interesting thread. Glad it didn't descend into some mad flame war about the merits (or not) of console gaming etc. The vast majority of casual gamers that I know don't actually buy that many games. In fact, I'd go as far as to say they probable get 1 or two a year. These are the sort of guys that buy the odd game for when they have mates round for beer and they want a laugh. The games they are playing are years old. In fact, thinking about it, the only people I know that buy loads of games and burn through them at a rate of knots are the hardcore gamers. I do think that the consoles are getting a big boost at the moment. That's partly because there's more money to be made there, but also because most development studios haven't got their workflow up to speed with the amount/detail of content required for the next gen games. This also has a knock on effect - they _know_ that the next gen consoles will run their game beautifully. They know that actually, 30 FPS is fine for a console game (might not be the case now HD games are coming out, but there you go). But in terms of PC gaming, 60 FPS is assumed to be required (even if it's not), and goodness knows what sort of hardware environment it's going into. It's just a more hostile environment. Currently, if they released a fully optimised X-Box360 game on the PC, running all the bells and whistles, only the top-end machines are going to be able to run it in all their glory. And in terms of market-share, top-end machines are a tiny percentage. Still, give it a couple of years and we'll see PC gaming back on track. After all, M$ needs to find some way of getting us all to buy Vista

I assume you are running an Internet server rather than a LAN game over Hamachi. My initial thoughts would be as follows: Make sure that all of your clients have a maximum upload setting of 128Kbps. Make sure your upload speed matches the bandwidth you have available. A standard DSL connection only has 256Kbps upload capability. Drop your detail settings (just in case). Make sure that all other applications that use the Internet are not running (e.g. browsers, i-tunes, bit-torrent, MSN, Yahoo Messenger, etc etc you get the idea) The other thing to do would be to run the following command from the server to each of the client IP addresses (replace the 123.234.345.232 with their IP address): ping -n 50 123.234.345.232 This will ping the machine specified 50 times. Look for peaks in the ping times as this can indicate an unstable connection. Make a note of when players get disconnected/dropped. Do they always tend to drop at the same points in the map? If so what are they? This behaviour would normally indicate a lack of upload bandwidth.

Introduction Those of you that frequent this board will know that I've been trying to reliably host a co-op GRAW server with two people behind the same firewall/router with very limited success. The server and client set-up is detailed in the post below (can't be bothered to type it all in again): http://www.ghostrecon.net/forums/index.php...st&p=412263 Anyway, Colin (thanks very much) very kindly verified my game settings (I've since tweaked the graphics back to what they were btw), and gave me enough enthusiasm to try again. The other thing we did was to ensure that the clients (those connecting to the server) set their upload speed to 128Kbps (it's in the server browser if I remember rightly). The only basis I had for the change was that it programmatically assigns half the client's available bandwidth to each person (they have a 256 Kbps upload stream). The very first time we tried it, on the Saturday afternoon, it worked first time. Everything was cool. Awesome .. problem solved. 5 hours later it was broken. No configuration changes had taken place. The eureka moment After some pondering I figured I'd check my firewall. I know that GRAW is set-up for access through the firewall as I can host games. But you never know right? Anyway, looking at the firewall I could see that incoming UDP packets to port 15250 (which is one that GRAW listens on) were being blocked. This was odd since one of the players from behind the firewall was already connected OK to my server. So, to resolve this I added the IP address of the router to Zone Alarm's trusted zone, and lo and behold the second player was able to connect. Zone Alarm configuration steps For those of you that need step by step instructions on configuring Zone Alarm, here's how you do it. Double-click on the Zone Alarm tray icon to open up the Firewall configuration screen. Select the "Alerts and Logs" option from the left-navigation. Look for a line with a protocol of UDP, and a destination IP address of <your IP>:15250 Right-click on the line in the log and select the "Add To Zone -> Trusted" option. Enter a description like "Temp GRAW Rule" and click OK. You should be good to go. I alt-tab'd GRAW to set the rule up, but you could just as easily close the game down to do it. I don't really understand why this works. I'm not even 100% sure it works all of the time. However, it did work on Saturday and Sunday night for me. If I discover anything else I'll add it to this thread.

OK, from looking at the evidence I would say that the route from Australia to the GameSpy servers (located wherever they are) is broken. Try the following: 1. Start a DOS session (Start .. Run .. Cmd) 2. Type nslookup www.gamespyarcade.com and press enter. If you get a "Unknown host" or "non-existant domain" error then it means that the DNS entry for the address (www.gamespyarcade.com) is been dropped for some reason. If you get an IP address (I get 207.38.10.155) try typing the following at the DOS prompt. tracert www.gamespyarcade.com (and press enter) This will start to trace the route across the Internet to the address. I'm guessing that at some point you'll start to see a load of non-returned data. The last IP address listed is the point before the network connectivity is broken. I'm guessing if you do some digging you may find a bunch of other sites that are not responding. Pretty much in this situation all you can do is wait.

Sorry, can't help you out with BattleLAN I'm afraid. Just got done doing some more co-op testing with my friends on the same LAN, and I must confess I am now more puzzled than before. I'll talk through the whole set-up and see if that triggers any ideas. Set-up PC's Client1 and Client2 are on the same LAN behind a NAT capable firewall/modem/router (don't know exactly what I'm afraid). Both have unique copies of GRAW installed and have their own GameSpy profiles. There are no port-forwards set up on the router. The PC's have IP addresses assigned via the DHCP server on the router. The Server is behind a modem/router (Netgear DG814). All required ports (and then some) are forwarded on to the server. The server PC in this instance has a fixed IP address on the internal LAN. Connection to Server If Client1 connects first it will connect to the Server OK. When Client2 attempts to connect it fails. The Server is alerted with a "GameSpy .. Connection Problems .. OK" dialog box. If Client2 connects first it will connect to the Server OK. When Client1 attempts to connect it fails. The Server is alerted with a "GameSpy .. Connection Problems .. OK" dialog box. Very, very, very occasionally both machines will connect OK. Although we've never managed this under 1.21, we have managed to get two games on 1.16 working OK. Connecting to official server If Client1 and Client2 attempt to connect to an official DM server they can. They can both play the game OK. Initial thoughts Since Client1 and Client2 can connect to an official Ubisoft server, the implication is that there is a problem with the configuration of the Server. If I hadn't checked the port-forwards on the router about 100 times I would think that it was a port-forward issue. So, I'm thinking that: The port forwards, as listed within the support docs, are incorrect and there are some missing. The game is trying to use a port on the local machine for communication that is in use, and rather than simply opening the next port along on a failure it always tries to use the same port. If it is the second one, then GRIN (or GameSpy via GRIN) need to specify the ports on the local server machine that must be free for the game to work. However, that seems like a bit of a long shot to me. And figuring out which app. is using the ports that need to be available could be tricky. I don't have lsof for windows. So, does anyone have any ideas?

I'm guessing you are thinking about Hamachi (or something similar). The only way we managed to get that to work was to set the game up as a LAN game. We couldn't get more than two players on there reliably when we did that though. The third player would normally get disconnected when something "big" happened (like the tanker getting blown up and the enemies spawning in).

Wait till you try and play a co-op game where two clients are behind the same firewall. I've had it working (1.16 patch) once or twice but most of the time some crappy gamespy "Connection Problems" dialog pops up when the second person from behind the firewall tries to join. We've pretty much given up now, and since co-op was the reason we bought the game are feeling a bit sick. Especially as we all have unique copies of the game. At some point we'll try with the latest patch, but to be honest I see no reason to believe that it will work.

Didn't work. We've managed to play a couple more times since last weekend, but we don't have a reliable way of making it work. Last night was a case in point. The evil "Connection Problems" popup was giving us pain so we all quit the game, waited 5 minutes, re-started and it was fine. It's crap. I'm hoping the next patch will resolve things ..

Thanks for the thought. I'll give it a go. If that's the case then GameSpy is pretty fundamentally broken for anyone who shares a house.

OK, but will you be able to do the same tomorrow? We have managed to get it working once using the steps I originally outlined above. But 24 hours later with not config. changes it doesn't work. How have you got the two machines and firewall/server configured? I'd have some confidence in my ability to sort the problem out if there was a log of the issue or a more meaningful error message. I mean "Connection Problems" means ###### all particularly when there are so many possible break points. Is it GaySpy that's generating the error, and if so, what does that error really mean? Is the issue on the creation of (presumably) the connected UDP socket from the client to the server? Is the client able to send but not receive data or is it the other way around? Is the connection droping packets causing some sort of handshaking issue? I wouldn't mind if there was a command line option to turn some form of network logging on so I could see exactly where the problem was. At least with Unreal Engine based games you normally get enough logging on both sides (server and client) to be able to figure out what the hell is going on. With GRAW there's nothing except a meaningless error message. I'd submit an official bug report to Ubisoft but I've experienced their shoddy excuse for technical support before and I know I'd just be wasting my time.

OK, you know my above post - the one that details how to make the co-op mode work when two of the players are behind the same firewall ... well, it's ######. I've just wasted 45 minutes of my life trying to get something that worked last night to work again tonight. No changes have been made to any firewalls or machines in between times. I am now at a complete loss as to explain just what the ###### is going on. The only unknown in the whole thing is ######ty gamespy. I don't know whether they are changing their auth. rules on a daily basis or what - but whatever is going on is too bloody weird for words. So, for tonights efforts, the two players behind the firewall tried to connect. Once one of them was connected, the other was prevented from joining by the "GameSpy Connection Problems" pop up. The players VPN'd into the place they work and - for reasons I don't understand - were both able to connect to the server's "launch screen" even though it appeared (from an Ethereal trace) that both players were coming from the same IP address. In this case, once the "Launch" button was pressed the two players failed to reach the load-out screen (not suprising given the VPN tbh). So, what the bloody hell is going on then? Is this something that only works on the evening of the first Sunday of every month or what? The British public transport network is more reliable than the co-op networking in this game. And that's saying something.

Firstly, are you both running the 1.10 patch? It helps a lot. Does he always get disconnected during a change in objective? Taking the first level as an example, is he disconnected at any of the following points: After the tanker has been blown up. When the garage has been reached. After the garage has been entered on the way up to the roof. At any other time when enemies are created. If so, it's likely to be a bandwidth issue. There is an option (possibly introduced in the 1.10 patch) that allows you to set the upstream bandwidth. Make sure this is set correctly. Other things, is he sharing an Internet connection with anyone else? If they are pulling down files/watching videos while he is playing then that might account for it.

I haven't finished the single player game yet but what I've played so far seems fairly reasonable. I'll not bother to re-iterate all the complaints about the team's AI. I can more or less work around it. A quick-save rather than checkpoint-save would have been nice though. However, having spent a fair bit of time playing the co-op game I can honestly say that there are aspects of it that are flawed. Whoever is the commander cannot get killed without terminating the mission. This means that they inevitably wind up behind any action. This would be fine if they actually had input into the game they are hosting, but in reality they do not. As a commander you can set way points, and give orders till you are blue in the face but you can guarantee that the other players in the game already know where the bad guys are and/or have their own "tried and tested" routes through a given level. This means that the role of the commander is simply to "not get killed" while the squad has all the fun. At best you can mark snipers and targets using the yellow Waypoint marker. Which since you can only have 1 waypoint is somewhat limiting. But at least you can put it anywhere. So, for co-op I think I'd make the following changes: Add a 1 or 2 use "med-kit" item that can be carried instead of extra ammo/grenades. This would heal a team member in the event of damage. Allow the commander to mark multiple targets to attack anywhere on the map (4 would be sufficient) even if they are not visible via the "red diamonds". This will allow the commander to mark snipers. Giving the commander a "permanent" drone might be an easy fix here. Create a server option that gives the "team" a number of lives. When all these lives are used up the mission is over. It doesn't matter if they were all used by the same player or shared between the players. The squad should live and die as a team with this option set.

Oh yeah, Now that we got the three player co-op working we managed to crash it. Since I can't see any obvious "place your crash logs here" post I'll stick it here: --- Crash in application version: grpcrc1.10 data\lib\units\ai\soldier\soldierai.dsf(-1): cant find member: force_logic in type <void> SCRIPT STACK data\lib\units\ai\soldier\soldierai.dsf(0) data\lib\units\ai\soldier\soldierai.dsf(0) data\lib\units\extensions\humandamage.dsf(0) data\lib\units\extensions\humandamage.dsf(0) data\lib\units\types\weapons\bulletweapon.dsf(0) data\lib\units\types\weapons\bulletweapon.dsf(0) data\lib\units\extensions\huskinventory.dsf(0)

Have you checked that everyone is using the same version of GRAW? Just a thought.