Chrisp

what #1 said..

Grand_Valley is by far the best custom map i´ve seen since Castle_Day. Really well made.. hopefully more will come ..... Really nice work. Keep it up.

Anyone know if its possibel to turn it off.. I really dont see the reason for it being enabled default on client side.

Just bought and installed a brandnew Soundcard. Creative SoundBlaster X-Fi Xtreme Audio PCI-e Running XP-Pro sp2 Using latest drivers The game doesnt seem to recognice it. (generic hard/software is my choises in settings now) Is it too new maybe being for PCI-e?

Same here... after patch 1.05 my game also stopped saving Audio config(hardware settings), it always starts as generic hardware. It was fixed in one of the earlier patches, but now it has been "unfixed" again...

Have 2 PC s running graw2 thru router without any connection problems, and playing at the same time on same server is not a problem. Did however have the problem after installing GRAW2 on second PC at first... It turned out we accidently had used the same key on both installations .. after a fresh install using the correct key it worked just fine.

As in.. there will be another patch to fix this patch?

After patch 1.05 Audio setting again started to reset itself to "Generic Hardware" instead of using my "Creative Soundblaster Audigy" every time i start the game...

Right now a server named "Joker" is running coop_retrieve version 1.05. Anyone know who is tha actual testers.. is it like maybe a beta for invited players or something?

haven'tried it that way Just tested to make sure, and it works like a charm.. all though it says "unknown" , it will connect to your server when/if it is up running. The downside tho, is that you cant tell if anyone is on the server or not....

I´m pretty sure that if the "attackforcez.servegame.com" is the actual adress, simply put it in the serverlist. It will not show as online, but if you know it´s online and you press connect, it will do so.. Feel free to correct me if I´m wrong.

Sorry.. Will do in future

says "continue to filefront".. try press it, but just ends up on same page- "continue to filefront".....no download? someone plz fix it.. would like to try it out.

just a thought, but having autoscreenshot, is AC really that needed? If its possibel to trade it for serversided mods, is it worth it?

Try this for finding out your CPU speed http://www.thecoolest.zerobrains.com/CoreTemp/ Core Temp works on Windows 2000, XP and 2003 (both 32bit and 64bit versions). "Core Temp lets you monitor Intel "Core Duo", "Core Solo" (Yonah), "Core 2 Duo", "Core 2 Extreme", "Core 2 Quad", " Pentium E1000" series, "Celeron 400" series (Allendale, Conroe, Merom, Kentsfield, Conroe-L respectively), "Xeon 3000/3200/5100/5300" series (Woodcrest, Clovertown respectively) and all AMD K8 (AMD64) series die temperature. The temperature readings are very accurate as the data is collected from a Digital Thermal Sensor (or DTS) which is located in each individual processing core, near the hottest part. This sensor is digital, which means it doesn't rely on an external circuit located on the motherboard to report temperature, its value is stored in a special register in the processor so any software can access and read it. This eliminates any inaccuracy that can be caused by external motherboard circuits and sensors and then different types of programs trying to read those sensors."

Sidenote: Happens with original maps only, aswell as custom maps and in all gamemodes.

Sat Oct 13 19:16:19 2007 Crash in application version: 30621.2989 Unhandled exception - access violation C STACK: graw2_dedicated (???) : ??? ??? (???) : ??? SCRIPT STACK: data\lib\units\ai\soldier\smovelogics.dsf(0) data\lib\managers\aihivebrain.dsf(0) data\lib\managers\aihivebrain.dsf(0) data\lib\managers\aihivebrain.dsf(0) data\lib\managers\aihivebrain.dsf(0) data\lib\managers\aihivebrain.dsf(0) data\lib\setups\setup.dsf(0) data\level\level.dsf(0) Renderer: normal Physics : normal

Stock maps only.. still happens.. Been able to figure out a couple of reasons why it happens tho.. Apparently if someone chrashes out or leave using alt+F4 the server keep trying sending data to the client. The worst cases I have noticed, are if they chrash/leave(using alt+F4) during mapchange.. I now made a post about it now in bug section. It clearly must be a bug that the server keep trying to send data to a client that is no longer connected, and keep doing so even 5-? minutes from disconnecting.

Been monitoring my server for a while, and been having quite a few times where the server is uploading max data and then some...(sending 50-100% more data than the actual upload available (1mb)) I have been able to narrow it down to happening if players chrash out of the game, or use alt+F4 to leave the server. One would think that when server doesnt get a reply back from a client, that it would stop uploading but it doesnt, it just keep sending huge amounts of data untill being restarted.(it mostly happens if its during a mapchange that the client chrash or leave(using alt+F4))

and yet another one.... Fri Oct 12 10:24:25 2007 Crash in application version: 30621.2989 data\lib\units\types\weapons\mountedbulletweapon.dsf(-1): cant find member: base_data in type <void> SCRIPT STACK: data\lib\units\types\weapons\mountedbulletweapon.dsf(0) data\lib\units\types\weapons\mountedbulletweapon.dsf(0) data\lib\units\types\weapons\mountedbulletweapon.dsf(0) Renderer: normal Physics : normal

hmm... new one, only thing different is that autoscreenshot has been turned on. Running Only Stock maps Coop_timber & Coop_sierra. --------------------------------------------------------------------------------------- Thu Oct 11 15:04:26 2007 Crash in application version: 30621.2989 Unhandled exception - access violation C STACK: graw2_dedicated (???) : ??? ??? (???) : ??? SCRIPT STACK: data\lib\script_network\networkmanager.dsf(0) data\lib\script_network\networkmanager.dsf(0) data\lib\setups\setup.dsf(0) data\level\level.dsf(0) Renderer: normal Physics : normal ---------------------------------------------------------------------- Fri Oct 12 06:52:07 2007 Crash in application version: 30621.2989 Unhandled exception - access violation C STACK: graw2_dedicated (???) : ??? ??? (???) : ??? SCRIPT STACK: data\lib\script_network\networkmanager.dsf(0) data\lib\script_network\networkmanager.dsf(0) data\lib\setups\setup.dsf(0) data\level\level.dsf(0) Renderer: normal Physics : normal

I remember the peekglitch in GR, but didnt think that was possible in GR:AW2 ?

Just a thought... Does the PC have AGP graphic card? If yes, Lowering "AGP Aperture size" in BIOS sometimes is a solution. Required AGP aperture size will become smaller as graphics card's memory increases in size. This is because most of the textures will be stored on the graphics card itself. So, graphics cards with 32MB of RAM or more will require a smaller AGP aperture than graphics cards with less RAM. What the "AGP aperture size" does, is that it allocates memory, so If you share too much RAM with your graphics card and an application takes advantage of that, you will have less RAM for other software, and possibly for background applications.

Should have done this from start, but didnt really consider custom maps being the problem after seing upload going crazy on an empty server.... However, last night playing coop with a few others we finished the mission and then server loaded a new map.. this was a custom map that not all had, so only 2 of us joined the new map loaded.. At the same time upload went crazy again, and we could almost not play because of high pings caused by the heavy upload from the server. I left the server, and then watched it uploading full speed for about 10 minn. hoping it would stop by itself, before restarting the server. Apparently if someone gets disconnected because they dont have the new (custom)map loaded it can cause the server to start uploading out of control. I have now Enabled statusscript again, but removed all custom maps from the server to see how that goes.

Actually it did send plaernames to gamespybrowser infobox.. GRIN then accidently removed it with patch 1.04. But they should be aware of it, and try fix it again. Dont think anyone figured out how to extract the playernames info for the serversript this thread were started about tho.