screen view affect weapon collision

[PodBot]

At random times i ge this extremely anoying problem with my client, its a bit hard to explain but ill try...

lets say i am at the top of a map with the camera and im playing with the bomber. now without moving the camera i drop 4 bombs, and _stay_ at that position. The bombs will explode at the bottom of that screen (even if there is no wall/target there!). even if i drop the bombs and "move" the camera further down. So if i am over a base and unload 5-6 bombs, but at a position so that i cant actually see the base they will all explode at the exact spot where my camera was placed resulting with no bombs hitting at all. This also applies to the left and right side of the camera position.

and the gay part about all of this that its a very random bug, i´ve tried to replicate it without any success. (when i do have it, the only thing that helps is a client restart that mutch i know.

[PodBot]

further investigation reveals.... that this also occured on another players client.
but heres the funny part, it only occurs on my own server (its not a local server, but my other server.) The "other player" had a ping of 120-150 and i have a ping of 10-30.

When i change (or the other player) to lets say "official server #1" the "bug" is not showing. So it appears that this is a server side issue.

So, what differs the "official #1" from my server?

"EU-Swe-#2": Windows 2003 enterprise - SP2, Altitude running in "backround mode", bulk install. Only two services running and thats IIS (port 80/81) and a ventrilo server on port 3784.
Other than that theres nothing else running on it. Only one interface for wan access.

[lamster]

Sounds like a network/synch issue. For whatever reason, your client is periodically, randomly drifting out of synch with the server to the order of 100-500 ms. This could occur if something else running at higher priority on the server machine periodically grabs 100% cpu, preventing the server from updating, or if there is some issue with how I am checking time on headless windows instances (perhaps something with using the wrong hardware clock on multiple cores). I'll look into it, if it's a windows timer issue it may be fixed next patch.

[Karl]

Originally Posted by PodBot

"EU-Swe-#2": Windows 2003 enterprise - SP2, Altitude running in "backround mode", bulk install. Only two services running and thats IIS (port 80/81) and a ventrilo server on port 3784.

what do you mean by "background mode"

[PodBot]

To run your server without having a command prompt window open right click C:\Program Files\Altitude\jre\bin\javaw.exe->Send To->Desktop (create shortcut)
On the newly created shortcut right click->properties->Shortcut tab
Set "Target" field to
Code:

"C:\Program Files\Altitude\jre\bin\javaw.exe" -Xms64M -Xmx128M -Djava.library.path=native -Dem.launch.path=launch-server.xml -cp launch.jar em.update.client.launch.UpdateLauncher servers\generated_server.xml

set "Start in" field to
Code:

"C:\Program Files\Altitude"

Double clicking this new shortcut will now launch your Altitude server in the "background" I.E. there will not be any windows cluttering your desktop.

like that, so.. i guess not technically any different right?

[lamster]

I'm guessing the server is failing to find a high-resolution timer, and so it's falling back to a very unreliable low res timer which results in desynchronizations between the clients and server. To check this, start up your server and see if your log file contains
"WindowsOS warning"
probably followed by some stuff about a headless instance

To fix it, make sure the native files are where they should be: in the directory with "launch.jar" (normally C:/Progra~1/Altitude) there should be a directory called "native", and inside that directory there should be "lwjgl.dll".

Is that warning present on your servers with the desynch issue?

[PodBot]

I wasnt getting any errors at all.
I am going to check if the error exists still after patch, as soon as i can get the frikkin server to connect (new thread)

[PodBot]

still there post patch. files are all where theyre supposed to be :\
My servers are now back online, try it yourselfs.

[lamster]

very strange -- does the system timer on these boxes drift out of synch with official time?

[PodBot]

DATE/time.. ? hardware clocks? one of these syncronize with microsoft´s internet time server, while other is deactivated so it stays what it is.

[lamster]

Hmm -- I wonder whether deactivated clocks could cause my timer to use a lower granularity.

I meant date/time -- if you turn off network synchronization does it rapidly drift off the correct time? In one particularly strange round of debugging on a friend's laptop I found that buggy network drivers on windows can occasionally cause Windows system time to race (very seriously, leading to several minutes error after an hour of play) while the game is exchanging UDP data. Strangely, the system timer remained perfectly normal if the game was not exchanging UDP data with a remote target (eg I could leave the game open, or play the tutorial on localhost without the time drifting).

Perhaps something similar with a buggy UDP stack is going on here?

[PodBot]

i will try and loop thru some drivers and try to accelerate the bug if possible, gona try running this on a VMware session booting XP (on the server with the bug).
These occur on both windows 2008 (wo hyper) and win2003 sp3. 2 seperate sets of hardware and connections just making sure this is clear.

even if the syncronization would be an issue, it would not of happened unless the time "client" made a request for time sync on the internet time server. right?.. it has to change to get out of sync i reckon. I have logs that will show there hasnt been an update for the entire time ive tried to host the game server.

[Karl]

though this is a long short and 90% chance it's irrelevant I would be interested to know whether or not you have HPET enabled in your BIOS.

http://en.wikipedia.org/wiki/High_Precision_Event_Timer

[PodBot]

he following operating systems are known not to be able to use HPET: Windows XP, Windows Server 2003, and earlier Windows versions. Older Linux. Windows XP contains a driver for the HPET, but it is not functional.

The following operating systems are known to be able to use HPET: Windows Vista, Windows 2008, x86 based versions of Mac OS X, Linux 2.6 and FreeBSD.

I´ve got one server on 2003 and one on 2008, so best case scanario i have atleast one using it. However there are no such thing in my bios so i guess none, the 2003 i cant access from where i am, however as the site explained its not even funtional.

[PodBot]

win2003 - Report: NO MORE BUG!
win2008: - Report: NO IDEA, i scrapped it, will try it again later this month.