This is similar to the Not Smooth topic, but there's more in here to report.
The v2.4 client has vastly different effects / behaviour when connecting to v2.3 servers or v2.4 / v2.4+pro servers. When connecting to v2.4 servers, the client is shocking with the smooth frame rate. As with the poster in the afore-mentioned thread, I am looking at a FPS counter showing 300-400 fps, yet incur moments of a portion of a second where nothing moves. This can be quite frequent, yet is mostly observed when playing against a v2.4 or v2.4-pro server. Using the 2.4 client to play against a v2.3 server it's not as noticeable. These are always against dedicated servers, mind you.
I've tried playing with the dedicated server on the local machine, and on a different machine connected by a Gigabit LAN. No difference.
I've tried compiling my own nexuiz dedicated server for my 64-bit Fedora 7 system, and using the supplied 686 dedicated server on the separate system. No difference.
The server reports between 0.1% and 4.8% CPU usage when I rcon into it and issue the command "status", so it's unlikely to be a not-powerful-enough server.
I tried running at 640x480 with everything turned to "LOW", and the frame rate went sky high - but the stuttering was still there. I tried running at 1152x864 with graphics at medium and despite frame rates dropping to 50-70fps the stuttering was no better or worse.
It's better with a v2.3 server, so is there a communications difference with the newer server
I assume there is, as v2.3 clients don't get rocket explosions on a v2.4 server. Different protocol means additions that perhaps aren't fully tested
If anyone has any suggestions on what else to try in an effort to solve this, I'm willing to help, as we have a few machines here and some gamers with spare lunch hours.
Issue #2:
Occasionally, buttons appear to "get stuck" during the pauses observed above. This results in repeated button events, or cessation of events. Some examples include:
- Walking forward prior to event, but now despite the button remaining down, the player stops.
- Typing after pressing 'T' to chat, results in repeated letters on screen, or missing words.
Issue #3:
When a server is configured with the minplayers parameter (to introduce bots as soon as someone joins), that is the same as the maxplayers parameter, additional players are unable to join. When the minplayers parameter is less than the maxplayers parameter, other players are able to join and a bot is booted to maintain the number of players. Shouldn't this behaviour be mimicked when a human player joins and the num_players includes bots is at maxplayers
ie: At the moment, we have (pseudo code ): - Code: Select all
#Player join request
if( num_players == max_players )
{
request.report_server_full();
request.drop();
}
- Code: Select all
#Player join request
if( num_human_players == max_players )
{
request.report_server_full();
request.drop();
}
elsif( min_players > 0 )
{
# Then minplayers is set - check to see if the number of bots is > 0 so we can boot one.
if( num_bots > 0 )
{
active_bots.remove(1);
request.accept();
}
else
{
request.report_server_full();
request.drop();
}
}
else
{
///...
}
Issue #4:
Every now and then, the server screen (pick a server to connect to) for servers on the local LAN reports a ping of 9999. Just some times... Even the server on localhost. Strange.
Issue #5:
I would like the ability to manually connect to a server that's not listed. ie: A server that's on a non-standard port. If I'm running a v2.3 server on the standard port (26000), I can't run a v2.4 server on the same machine on a default port - so I select 26001. The client can't see it (because it's a non-standard port?) and there's no way to connect without resorting to the CLI and appending a +connect localhost:26001 to it. Minor annoyance, but it means getting other players to do the same if they want to try out the new v2.4 sever...
Issue #6:
Default compiled clients on my 64-bit Fedora 7 system are abismal. On the same map, with the same client in the same location, I observed the following differences in frame rate:
32-bit GLX client (supplied) - 15 fps
32-bit SDL client (supplied) - 9-11 fps
64-bit GLX client (supplied) - N/A (won't load)
64-bit SDL client (supplied) - N/A (won't load)
64-bit GLX client (compiled from source) - 100-120 fps.
That's a significant difference, I thought...
System specs? Athlon X2 5000+ with a GeForce 7600GS and 4GiB DDR2-800 RAM.. Not flash, but enough to give great game play on the 2.3 client.
I would have reported this in a Bugzilla if I could find one, but I couldn't. Hope this makes it's way to the developers in some way. If there's a more appropriate place for it, please let me know.
Cheers,
L.B.
it has nothing to do with protocol changes. In fact there were NONE!! However the timing and number of packets send to the server and the internal clientside movement has changed, which seems to lead to the current 'lagness' problems people report. The hotfix contains fixes in that area so it should be better/ok with it.
