OK i did my 4th fresh install can u pleaze help me z0dd...x maps still doesnt work keep gettin unable to load the interior errors. i havent even dled the new x pak2 beta this time so idont know what is goin on...is there a support file im missing or somethin? my specs r 533 p3 312 ram voodoo3...i kno i kno i need to upgrade but that shouldnt be the problem
Actually i had the same problem before. For me i had a bad memory stick, as soon as i replaced it all was well. Post edited by -DeVast- at 11/22/2002 1:56:19 PM
kreiv-Xy: if you use tricon client try uninstalling it. that ALWAYS made me ue when i tried to get in my console.
Then you are missing a file in the client install.
look in base/textures/gui for a file called shellScrollYellow.png if its not there you will UE everytime you try to open console.
actually itmay not be the .png, the problem i had was part of the coding. I removed the part of the coding that delt with the console gui and i stoped UEing. maybe that was just me though.
did a fresh install, most stuff works fine now, still slower load times but i can deal with that.
however we had a 6vs6 tr2 scrim tonight, on a 25026 server. me and 4 other guys noticed we had no 'hit' sounds. The little 'dink' sound when you hit someone with some weapon/mine/turret. It wasnt there. Server was running TR2 1.1 beta 12
Getting a terrain mismatch on Lakefront when connecting with 25034 client to 25026 v2 server. Neither log says which terrain, and both are using identical classic_maps_v1.vl2.
I was running 25026 successfully with this map when a teammate reported this, so I patched my system up and repeated the error.
Getting a terrain mismatch on Lakefront when connecting with 25034 client to 25026 v2 server. Neither log says which terrain, and both are using identical classic_maps_v1.vl2.
I was running 25026 successfully with this map when a teammate reported this, so I patched my system up and repeated the error.
Server is "(MA) Public Version 2".
delete all your dso's and try again...there is issues with lake...scab and a couple other maps.
Has anyone figured out what is causing the video stutter? Is it script-based or is it just a problem with the patch?
I believe there may be two issues here that seem to be getting crossed up.
#1. Server Lag issues that causes "stutter". Some reports say that changing the network settings on the server to DSL levels will fix this particular bandit.
#2. Client Lag issue caused by some sounds. This one is a beast. It is especially apparent in TR2 where there are a lot of sounds going on. Certain sounds cause the client to "lag" for just a second. Fresh installs are not a solution. Switching to EAX audio *MAY* reduce, but not eliminate the problem on some systems.
Though server network settings do have an effect on general game smoothness and play, it doesn't help with the 'timing' problem on dual processor machines.
Dual processor machines seem to get their game simulation 'ticks' or frames messed up (probably due to an inaccurate timer) and everyone in the game then gets a jerky game.
Yes, client side lag is a problem, and always has been. The first few seconds of any map is normally choppy, whilst the textures get cached, and long sound loops can cause problems with underpowered machines.
[TM] The RoDent Scripter, Admin http://tribes2.za.net/
Rodent, I have to agree that the time base has been altered. It occurs to me that given the importance of a timebase in an engine like this and the relationship between gravity and time (acceleration) that design assumptions were likely made early on in order to simplify the calculations involving the acceleration of gravity. That is, an implied connection between the calculations of gravity and the engines time base or "tick".
One of the significant changes made by GG was a modification to gravity. (variable gravity) It is possible that this is interfering with core design issuses in versions 24834 and earlier. I dont know what they changed, but it is possible that changes were made not in the calculations but in the time base to accomplish variable gravity. (Or the calculations with adjustments to the time base) And Like you, it appears to me that the error is in the time base.
The only other thing I can imagine is that a critical section exists that is invalidating L2 cache on SMP systems. But that at this point seems unlikely as this problem has been reported on single CPU systems.
Timing issues need to be adamantine and not based on "median" systems. Otherwise you can only expect them to function on "median" systems.
The gravity is an interesting theory, however the stutter seems to happen during normal panning/movement too. That would indicate to me that it's possibly just the event timer that goes awry.
I've got this stuttering problem on a Dual XEON at the moment, but it definately seems OS/machine related. If I reboot the machine, 3 tribes servers will run just fine on it for approximately 3-4 days. At some point, the stuttering will occur, and an immediate reboot of the machine will FIX the problem, guaranteed.
The linux version, is built using libsdl (www.libsdl.org)
libsdl is a cross platform multimedia library. Whilst digging throught the sourcecode I came across this interesting annotation in the win32 timer code for libsdl:
Disabled QueryPerformanceCounter(), due to problems on Win2K
It's been completely hacked out due to reported problems in Windows 2000. On linux of course, it uses other methods of getting a high-res timer.
After digging around some more, I found various mentions (specifically in benchmark programs) of Win2K systems with certain hardware/chipsets failing to carry the 24th bit during it's cycles. These sytems scored too high, or erraticly during benchmarks. It seems that queryperfcounter() isn't as stable as Microsoft might suggest.
Quoted from a win32 game progamming FAQ:
queryperfcounter():
A higher resolution counter, whose frequency and accuracy varies from OS to OS, and from CPU to CPU. You need to use QueryPerformanceFrequency() to discover the frequency. On a single processor NT platform the counter frequency is 1+ MHz, so is accurate to microseconds. On a multiprocessor system it uses the RDTSC opcode to measure CPU clock ticks. Good for low level performance measurement, although the switch to kernel mode adds enough overhead to hamper profiling of small routines.
To game engine developers QueryPerformanceCounter() must seem to be a GREAT option of getting a high resolution timer. Unfortunately, it seems to vary in stability depending on chipset, and number of CPU's.
During my development of a LAG inducing UDP proxy for Tribes2, I must say that I found GetClockTicks() and QueryPerformanceCounter() to provide inaccurate timing. The best I found were the winmm.lib routines provided by the kernel mmlib.dll API. The resolution is fine enough, and the same on all platforms I found so far. (well the proxy worked on the same dual server, and always induced the same lag)
All of this, brings me to a final question: Did GarageGames ACTUALLY implement "$pref::useHighPerformanceCounter" to "enable usage of the QueryPerformanceCounter code" ?
From my digging around the tribes2 executables, I can say that I can't find any reference to it. I think they might have built it into the code to enable/disable this code (so that another method for clicks can be used) but I think they forgot the actual preference setting for it.
This might explain why this preference setting does NOTHING.
I've tried it with 1, and 0 and it made no difference, but then again, I only stutter occasionally, and haven't been able to reproduce it tonite.
Jim, as an experiment (just a hunch) try and run the Windows 2000 performance monitor, and add ALL the CPU performance monitors to a graph.
From what I've picked up, it might change the resolution of the system timer and perhaps stabilise the QueryPerformanceCounters() timer.
Anyhow, long, boring read, but let's start fiddling around. I'm pretty sure we'll be able to get it sorted using some 'alternative' means, even if it means shimming the kernel DLL functions to fake a steady QueryPerformanceCounter() (which is doable)
It appears that if an APM BIOS is active, that the TSC isnt necessarily accurate as the APM BIOS can alter the value. The TSC can actually stop counting cycles.
The linux Kernel takes special measures to compute precision times if APM BIOS is present.
Also, on some systems, RDTSC is only usefull after the execution of an instruction like CPUID due to the possibility of intructions being executed out of order. (CPUID forces completion prior to RDTSC). Other issues can effect the accuracy of TSC as well.
Also, are you certain that QueryPerformanceCounter() is meaningfull outside NT/2k kernels? (It is available in CE, but apparently must be implemented).
This seems to be the crux of the matter. I've compiled the test program and am going to try it on my server to see if it exhibits this QueryPerformanceCounter() drift problem when the stuttering occurs. I'd suggest trying the same on your machine to determine if this is the issue.
An alternative to QueryPerformanceCounter() is GetClockTicks() which isn't as fine-grained but reportedly more stable.
This could explain why some single processor machines also exhibit this stuttering problem, due to the PCI bus problem described in the MS knowledge base article.
I've uploaded a copy of the test program at http://tribes2.za.net/timer.exe if other server operators would want to test their equipment.
If there's no problem, the program simply sits there, eating 100% cpu. If timer drift is detected it will print messages to that effect.
[TM] The RoDent Scripter, Admin http://tribes2.za.net/
Further, I am running both 24834 and 25034 on the same system concurrently on different ports. 24834 is smooth like a baby's butt while 25034 stutters. Also, the physics seem slightly different.
Sorry, I forgot something. We need to keep in mind that this problem was introduced POST 24834. It wasnt inherited. This was a delta to the engine presumably added by GG. (And either modified or corrected with the Linux port.)
Is the person that did the Linux port available for comment?
Cdynamix\tribes2_beta\GameData>strings Tribes2.exe | grep Perf
Performed %d LOS calls
QueryPerformanceCounter
QueryPerformanceFrequency
OK, now the same against the 25034 .exe:
Cdynamix\Tribes2\GameData>strings Tribes2.exe | grep Perf
Performed %d LOS calls
setPerfCounterEnable
QueryPerformanceFrequency
QueryPerformanceCounter
The interesting one here is "setPerfCounterEnable".
It seems to be a NEW console function introduced in 25034, which I'm guessing enables, or disables the Win2k problematic QueryPerformanceCounter() timing code.
The patchnotes for 25034 mentions a $pref::useHighPerformanceCounter which enables the use of "QueryPerformanceCounter" code.
However, the 25034 tribes2.exe doesn't seem to reference this variable anywhere, so I'm guessing that the plan was to look at this preference setting during startup in some sort of script, and then call the console function with the appropriate boolean for the preference setting.
I haven't been able to find a single reference in any console_start, autoexec or any of the other scripts that call setPerfCounterEnable(0) or otherwise. So I'm guessing that this script change didn't get included in the patch, or perhaps z&z overwrote this change with one of their changes in console_start.cs by simply replacing their version of it.
JimBodskins, since you have continual stuttering problems on your machines (mine's STILL not doing it) would you care to try this?
On your dedicated server console, simply do a
setPerfCounterEnable(0); or setPerfCounterEnable(1); and see whether the problem goes away. My hunch is that the script that was supposed to apply this setting from the prefs setting got overwritten during the merge process between Sierra, and Z&Z.
Cheers, RoDent
[TM] The RoDent Scripter, Admin http://tribes2.za.net/