Competition StaffServant of the TribalLordsTWL Contributor
2002-11-26 14:45
isn't raptures server a single processor? I thought they used the same hosting company we do (gaminghost=)and i thought gaminghost moved all their servers to single processor after the last patch?
Basically what I guess happened is that z&Z may have overwritten one of the scripts that GarageGames changed during the patch, and as a result of that, a certain preference setting having to do with in-game timing got lost. This pref setting would in likelihood have called the setPerfCounterEnable() code to change the way in which T2 does timing on systems which exhibit the stuttering bug.
The console function is still in the tribes2.exe though, so just manually setting it does the job.
I would suggest that all server admins having the stuttering problem put the line:
setPerfCounterEnable(0);
into gamedata\base\autoexec.cs
Many thanks to JimBodSkins too, for guiding my thought process and research, and contributing USEFUL ideas.
Cheers,
TheRoDent. [TM] The RoDent Scripter, Admin http://tribes2.za.net/
Just as an adittional note, the stutter is caused by combinations of Motherboard chipsets, and PCI buses. It's not necessarily restricted to dual processor machines, however it seems that dual mobo's more often use these affected chipsets.
Any CLIENT that has this kind of problem when doing hosting on his own PC, might want to try the setting too.
YMMV (Your mileage may vary) though...
[TM] The RoDent Scripter, Admin http://tribes2.za.net/
Can we get a list of servers that have tried this fix. This way we could go in and try it out. Also shouldnt all servers do this fix even if they do not expierence this issue?
On machines not exhibiting the problem, setPerfCounterEnable(1) will actually provide a higher resolution timer for the game to determine ticks in, but I reckon leaving it at setPerfCounterEnable(0) is probably the safest bet for everyone. It works just as well on 0.
[TM] The RoDent Scripter, Admin http://tribes2.za.net/
I am happier than you will ever know to announce that setperfcounterenable(0); does in fact stop the server stutter. (On my server, although it looks good and will probably have the same effect on the others).
Our team (and the community) was severely harmed and almost killed by this. Let's all get this in place and move forward.
This in all likelyhood means that the rerelease can go forward now with the expectation of not only returns to the game but new players. Myself, DoFear, MasterGnr and others were discussing this issue on Sunday. That is, putting policies, attitudes etc in place to train, blend, reintroduce players to the community. ZOD mentioned the possibility of doing a mod intended to flatten the learning/training curve for new players. I think with Rodents discovery, these things can now happen. And I encourage them.
Thanks again Rodent. Anything I could do to help was entirely my pleasure. The entire community owes you and should show it's appreciation. I do. BTW, Mr. Rodberg, you might consider a gesture of thanks from Sierra.
This fix should work for any AMD/Intel Dual/Single system hosting a server that exhibits the problem.
The problem is that the timer GarageGames used on Windows systems is known to have problems under Win2000.
They DID fix it in the latest patch, but as I've already explained, I'm guessing that during the merge process of z&Z's code something got overwritten. This has caused the preference setting for the choice of timer to be lost.
The function still exists in the core it was just not known. Through some digging in the Tribes2 executable, various discussions with Jim around timing and how highres timers worked, I found the function and tried it. It works.
Other network related lag issues, such as packet size and rate will obviously NOT be solved by changing this setting, but the "frame-skipping-stuttering" problem will be solved by this.
If only Sierra, or GarageGames had documented the preference setting and the new function to enable a different timer properly in the patchnotes, it might not have take this long to discover.
GarageGames aren't that bad after all. They've so far fixed whatever Sierra contracted them to do, and I still believe that they're a great bunch of guys.
However, Sierra's communication methods and handling of the entire patch issue and bugs has been lacking.
Now, if only I can convince you guys that having the TeamRabbit server-side files causes the slowdown in CTF map loading I'll be happy. Removing em makes everyone with lower-end systems get into the CTF maps easily, and without timeouts.
Regardless, I hope this allows us to continue with some awesome T2 playing, and also secures a whole HORDE of newbies. That, imo is also what this game needs.
I'd like to get that same feeling of awe when I started playing T2 the first time again. The buzz, the excitement, the competition and the cameraderie.
Kick ass...
[TM] The RoDent Scripter, Admin http://tribes2.za.net/
Will this address the in game timer not tracking with real time. I found some servers can take 31 minutes or more in real time to run a 30 minute clock. I was concerned that this may give a slight floaty feeling which some were initially reporting.
Will this address the in game timer not tracking with real time. I found some servers can take 31 minutes or more in real time to run a 30 minute clock. I was concerned that this may give a slight floaty feeling which some were initially reporting.
Roflmao, thats nice that one little line did all this damage...
(¯`·.¸.:| Aur|ora 7-Man / 14-Man Classic |:.¸.·´¯) (¯`·.¸.In my younger years, I was very conceited. But that's all changed, because now, I'm perfect.¸.·´¯)
Ok, im glad to hear this fix really works. Now maybe you can help me a second Rodent. When im playing a game, mainly TR2, the first game is fine, but when the next map loads, and i start playing, the game is all jumpy, but its not ping, its just jumpy and stuttery, would this fix the problem or is this just for fixing the problem with SERVERS? Thanks. Post edited by |taint| at 11/26/2002 5:51:09 PM
Looks like it works also on the Blueyonder servers...
We did a quick test and it worked. We are now updating server files, and are hoping it will keep working if we do a final update
TheRoDent has identified the fix to our dual AMD stagger problem which has renedered our server useless since 29026. This fix also has been found to fix the Dual Intel "Stagger" problem as well. Funny that it took a devoted player to figure this out..Thanks RoDent
At the console, type: setperfcounterenable(0);
Client stagger goes away immediately!!!
If you would like it in script form, get this script and put it in your "Autoexec" folder in Base.
times like these it boggles me mind as to what lenghts players go to in order to fix a game for the community...and i thank thee for all the work so that i may enjoy my tribes experience, espcially my friday night forays into inebriated tribing.
times like these it boggles me mind as to what lenghts players go to in order to fix a game for the community...and i thank thee for all the work so that i may enjoy my tribes experience, espcially my friday night forays into inebriated tribing.
Same here man. This is the exact reason I do admin stuff.
Roceh, coder of T2TV, has probably identified what is causing the demo lockups. He's hacked his T2.exe and figured out how to prevent demos from freezing from the client end. It's simply some new code that GG added to the T2 engine that T2 doesn't like. He's already watched some T2TV casts that were 'corrupted' by the old patch without any lockups.