[bf1942] DICE update: in-house Linux server

[KLM - 515TEM]

don't forget about the foreshooting of the tanks and artillery. If you hold
fire when in a tank or arty it should just fire when reloaded (this is what
win servers do), but linxded pulls the cannon as it shot the projectile, but
than (when aiming high - pulled) it really fires. So no constant bombing is
possible, unless you wait until reloaded and half a second after push the
fire button...

and btw, Ryan, I think it's great this email slipped to us... it's sweet...


regards,
Klemen


P.S.: I am glad to see now, that the Ryan-DICE connection will work great...
and can't wait the time when BF crushes Counter-Strikes success.   ;)





----- Original Message -----
From: "Ryan C. Gordon" <icculus at clutteredmind.org>
To: "Fredriksson, Andreas" <bf1942 at icculus.org>
Sent: Tuesday, March 18, 2003 7:02 PM
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.
>
>
>