How to “live-beta” the new update mode
May 15, 2006If the 1.23.x networking changes were a significant improvement for you (and not a CTHLing nightmare); if you have a high-end broadband connection (384kbps minimum); if you consistently get under 150ms to "Main Pri" or "Main Alt" with our Connection Test tool; if you are comfortable with editing your config file: Then here are the instructions for you to try out the new update mode…
DO NOT TRY THIS AS A WAY TO SOLVE CTHL ISSUES, IT WILL MAKE THEM WORSE.
Be aware: This functionality is not officially supported, and the behavior is subject to change. If you make these changes and find yourself experiencing anomalous gamebehavior, you should revert to the "Medium" or "High" visibility setting before posting bug reports to CRS.
By following these steps you are choosing to live-beta this functionality while we continue to investigate ways to deliver it to our customers generally. If you have feedback on these settings, post your feedback in comments on this blog entry.
- Exit the game, and use Task Manager to make sure it isn't still shutting down in the background.
- Go to your WWII Online/Battleground Europe folder (typically c:\program files\battleground europe\ – probably somewhere entirely else on the Mac) and locate the file 'wwiiol.cfg'
- Back up your wwiiol.cfg file (hint: copy & paste it to your desktop or somewhere safe)
- Open the file in a plain text editor. Windows users: preferably notepad. Do not use Word or Wordpad.
- Locate the line that starts "visplayerlimit" and change it to read
visplayerlimit 4 - Save the file and close your editor.
- Log in to the training server and spawn at Antwerp or one of the newer towns, run/fly around, fire weapons, and if after 5 minutes you have not CTHLed you're ready to try the live server.
This new update mode includes:
- Packets upto 1400 bytes in size (including IP headers)
- 8 updates/second vs the normal 6
- Upto 34% more visible vehicles
This may result in a significant frame rate hit in very large battles or if you have high latency or connectivity issues. Until we are able to switch parts of our update system to UDP instead of TCP it may be impractical to provide this and other modes on a general basis.
Again: Use these instructions are your own risk. I provide no warranty of usability or support.
What if my pings fall outside those values but I want to give it a go anyway. Are you saying that it does not work for higher pings, or that the performance is liable to be really really bad ( but not definitely )?
I have a 6MB broadband connection, but am in the UK, running the test I get these results:
Test 1: Auth Pri -OK- 219ms
Test 2: Main Pri -OK- 172ms
Test 3: Main Alt -OK- 156ms
Test 4: Main PingPri -OK- 172ms
Test 5: Main PingAlt -OK- 172ms
Test 6: Main Chat -OK- 172ms
Test 7: Event Pri -OK- 187ms
Test 8: Event Alt -OK- 156ms
I have always used low vis limit never having a problem, in your post you say medium vis limit should be used if experiencing CTHL, should I upgrade to Med from Low, and will this cure the CTHL, I’ve had 2 CTHL’s with 1.23.2
Also i was running the test exe for 1.23.1 and WWIIOL updated to 1.23.2 while I had the test exe installed, should the original 1.23.1.exe be reinstated before updating to 1.23.2 or does it not make a difference?
Cheers
Allibone.
Liable but not guaranteed.
Allibone – yes, try Medium instead of Low. There is no reason you should be CTHLing with Low unless something is no-longer fitting in a packet – but I’m not seeing any errors logged that would explain that.
If you get CTHLed, please relog and report it along with your vis level setting so that we have an aproximate timestamp and can try and diagnose the logs to see what happened to your connection.
Exes shouldn’t make a difference, Alli. Patch should have overwritten either old version.
As a reference, I live about 200 miles from Bedford TX / CRS offices and have a 9 mb downstream and 1 mb upstream cable connection and got the following numbers from the test (ran it about 20 times and this was about average for me.)
Test Starting.
Test 1: Auth Pri -OK- 15ms
Test 2: Main Pri -OK- 15ms
Test 3: Main Alt -OK- 31ms
Test 4: Main PingPri -OK- 16ms
Test 5: Main PingAlt -OK- 16ms
Test 6: Main Chat -OK- 15ms
Test 7: Event Pri -OK- 16ms
Test 8: Event Alt -OK- 16ms
Connection tests completed OK.
Haven’t noticed cthls but I think I need to update video drivers bcause my machine froze a few times. (AMD 4000, 2gb of ram and dual 6800 GTS – so it should not be doing that!)
Im perfectly happy to give it a go if you want some feedback on higher latency connections. If you don’t then I’ll probably try it anyway and keep the results to myself.
Hey Oli,
tried it out seemed pretty good. Had a few hiccups but overall good.
My pings are in the 50-60ms range so I gave it a try. I got into a firefight playing infantry in a congested area around a depot and my framerate went under 20 and on occasion to single digits. I did enjoy the side effect of no despawn timer but have since reverted to High Visability limit.
When I’m on the 4 vis setting, I CTD after about 5 min ingame. Also, when I hit ESC to despawn, my despawn timer goes crazy. It will flash in rapid succession:
“64 seconds”
“3 seconds”
“Press OK to despawn”
“28 seconds”
“64 seconds”
Test Starting.
Test 1: Auth Pri -OK- 143ms
Test 2: Main Pri -OK- 141ms
Test 3: Main Alt -OK- 130ms
Test 4: Main PingPri -OK- 143ms
Test 5: Main PingAlt -OK- 143ms
Test 6: Main Chat -OK- 143ms
Test 7: Event Pri -OK- 143ms
Test 8: Event Alt -OK- 139ms
Connection tests completed OK.
Tried the new config out.
FPS about the same maybe improved, played for a bit but after 10 mins began to stutter/lose packets. reminiscent with sound bug appearing and packet counter losing packets, when i despawned the timer did a funky countdown from 60 seconds to 39 to 0 in about 50 milliseconds lol. ie no timer.
time gmt 20:15+ or -
settings
time between updates 5 seconds (noone has actually explained what this does really :D)
vis player Medium
man – i have a athlonxp 3200, 265 6800GT, gig ram and xp pro – 1mbs DSL. get about 50-75ms ping times.
i tried the vis limit 4, on the test server everythings fine, smooth no problems- logged onto the main server and flew over eindoven, battle on the ground and air- FPS dropped to 0 on several occations, and after a couple of minutes the screen just goes black and i CTD. dunno about CTHL errors as much as system resouce errors. vis 4 my do ok for ground guys, but it’s not for pilots
“settings: time between updates 5 seconds (noone has actually explained what this does really)”
cdrwolfe, that is how often the water reflections update. If you have it set at 1 second or more than you can see when it updates by moving while looking at the reflections.
Howdy Kfsone
I’m glad your switching to UDP “soon” instead of TCP.LOL,I’m been playing this game off and on since 2001 and always thought you guys used UDP.Curious,what other games use TCP,I know most use UDP.I’m off to try vis. limit 4.Holding my breath!
I tried on setting 4 and it worked great for about 10-15 minutes, then the game started getting slow, eventually dropping to 0-1 fps. Hitting esc to despawn results in an instant OK button, and the count down timer showing random numbers (76, 4, 15 23, 24, 42, etc.).
Switching back to low, med or high and the game goes back to normal.
Oli,
I love it, but can the view biasing be throttled somehow so air units don’t blink out so much when on the ground? I like seeing my guys fighting the bad guys overhead. It’s good for morale on the ground :)
err maybe that needs more thought. With potentially ~170 units vis capability, I think view biasing could be more flexible for those whose systems can handle it.
I love the Vis Limit 4 setting, but it causes me to CTD every time I’m in-game.
5-10 minutes after I spawn, Crashes to desktop. No error message no black screen just a Boot to desktop.
We’re making some headway with the CTHL/CTD issues at the moment. Managed to replicate them for the first time today. We’re basically resting up all the coders for an all-out assault on the issues that appear to be coming together to cause the CTHL.
I’ve also been assuming guilt, but it looks as though the result is the client handling data from the host in such a way that stutters that are already there get stretched out so long as to kill the host connection or cause a CTD.
With a tiny pinch of luck we’ll find that its a hard-coded size limit someplace that means data from the host is overwriting precious memory and causing all these ills – because when we reduce the packet sizes the bug affects a different group of people.
No progress on vis limit setting 4 yet – but we’ll get around to that after TOEs.