[bf1942] DICE update: in-house Linux server

Daniel Valois ninzor at packet-kids.com
Tue Mar 18 16:02:03 EST 2003


my server does the zoom thing
is rtr gonna work with this version?

----- Original Message ----- 
From: "cuban" <cuban at hoodedmaniac.com>
To: <bf1942 at icculus.org>
Sent: Tuesday, March 18, 2003 2:54 PM
Subject: RE: Re[2]: [bf1942] DICE update: in-house Linux server


> IF anyone needs reproducing of the bungee bug I can provide a server
> that does it. You need at least 3 or 4 players though.
> 
> cuban
> 
> -----Original Message-----
> From: Ryan C. Gordon [mailto:icculus at clutteredmind.org] 
> Sent: Tuesday, March 18, 2003 12:03 PM
> To: Fredriksson, Andreas
> Subject: Re[2]: [bf1942] DICE update: in-house Linux server
> 
> 
> More details:
> 
> > - Panzerabwehr/Bazooka reloads twice (remaining ammo gets decreased
> > twice too)
> 
> Not sure what causes this; possibly a timing issue (the i/o thread is
> disabled in the Linux server and it polls the UDP socket in the main
> loop
> instead, but you can reenable it if you feel there aren't any race
> conditions).
> 
> > - When running a Road to Rome map, nobody can connect to the server
> 
> Apparently the server wasn't responding (or responding incorrectly) to
> the
> CD key GameSpy query for RtR, so the win32 client hangs at that point. I
> recall someone saying they got around this by replacing the GameSpyHost
> library with the one from 1.2. Possibly a mismerge bug on my part.
> 
> > - There's a bug (i call it "Bungee"-effect), that let the player turn
> > back some degrees when turning or pulling the player back some
> > steps/meters when running/driving
> 
> The current speculation is that the server is rejecting a large portion
> of
> a given client's packets, so they get to move forward due to client-side
> prediction and get snapped back when the server updates them again...but
> they DO move forward a little with each update, so some amount of
> packets
> _are_ getting through. Look around for stuff about "ActionBuffer".
> 
> This doesn't happen to everyone, and I couldn't reproduce it. There
> isn't an obvious connection between those that have this problem. Might
> also be a timing thing (i.e. - timestamps are strange on the Linux/win32
> side and confuses the other.)
> 
> I would _love_ to hear the solution to this one.
> 
> > - When trying to zoom, the view jumps back to normal view immediately
> 
> Probably the same bug as the "bungie" bug and the reload-twice bug.
> 
> > - Don't know if it still exists, but it was in the 1.3 build:
> > Within the servernames or the welcome messages, spaces must be
> > replaced with underscores
> 
> This is probably a mismerge on my part, as spaces apparently worked in
> 1.2. I threw a hack in there to allow underscores to work as spaces.
> Look
> for the details in Bugzilla.
> 
> > By the way:
> > There's a feature in the linux builds that should be build in the
> > windows server:
> > the server password can be changed via the remote console on linux
> > servers with game.serverpassword
> > On windows servers I just get an errormessage...
> 
> Uh...this wasn't my doing. Not sure why this works on Linux, or if this
> guy is just wrong.
> 
> However, there are some other things (being able to set the gamespy/ASE
> port via the .ini files, fixing ASE and GameSpy opening the same port,
> etc) that _should_ go back to the win32 codebase. Also, the #ifdef
> DEDICATED sections could be very useful for win32 servers, since it
> removes the overhead of the window interface and reliance on DirectX,
> etc,
> making it a stdio app. This hasn't been tried on Windows, and will take
> more cleaning up, but a lot of windows admins had asked about it.
> 
> --ryan.
> 
> 
> 



More information about the Bf1942 mailing list