This weekend was particularly productive, mainly because I provided a test version to some players who seemed happy with the progress.
As you may imagine, from tweaking the code I ended up with a version very far away from PK++. This step change is not ideal for testing properly, so it is important to trickle the changes into PK++ over a length of time.
My main objective was to put a lot of the netcode fixes into PK++. This is mainly concerned with interpolation, and determining where issues are in PK netcode and gameplay.
Before I add more, understand that interpolation is important because it allows players to run at much lower data rates from the server. This is important:
1. If you want the game to be stable with lots of players on the server.
2. If you want to add lots of monsters.
3. If you have demos of low quality and want to watch it smoothly.
Firstly before anything else in added a netgraph. This plots (much like Q3), ping over time (indicating packet loss too), as well as interpolation deltas (basically indicating how much interpolation is taking place). Testing indicated that PK suffers from a degree of flux in ping, with occasional lags due to certain events. On the whole though it didnt look that bad. Command is \drawlatencygraph 1. Obviously there is a lot of processing for this, so fps is damaged.
Next for interpolation, I wrote three methods. The first is linear interpolation for each player. I decided that it is possible that lagging players on bad connection might not update the server at the same rate, so would still move badly if interpolation was done on a per-game-frame basis. Instead what I decided to do was look for updates on players themselves, and have each player in their own interpolation space-time. The second and third methods are quadratic, and the average of linear and quadratic, respectively. At very low update rates I would suspect the quadratic to be slightly better (mainly on vertical movement). Command is \interpolation 1/2/3. Testing showed that it was playable at \serverframerate 15 (equivalent to snaps), although 30 was playable. Remember \netstats 1 to view what is going on.
Here I also added timenudge (which qw and q3 players will know). This moves the interpolation forward or backwards in time. A positive timenudge can allow more for variations in ping, whereas a negative timenudge may draw the players closer to their actual position.
Next I added an option to interpolate from the previous position or from the last interpolation position. What I found was that the last interpolated position method gave worse results.
Next I added a method to automatically adjust timenudge for latency variation. Although this was damped quite heavily, it looks to be unstable on first testing at certain times. I would be a nice method if it works.
Next I tweaked teleport behaviour on the client. Up until now on higher pings, teleporting would either result in a judder or double teleport. Teleporting is now entirely predicted on the client, so server updates are ignored (mistakes are captured in synchronisation frames anyway). Likewise the jumppad was updated. Both methods help reduce the feeling of lag on the client which is important for movement. Weapon prediction needs to be completed, and possibly zero ping at some stage soon.
Console commands were altered slightly so that settings could be edited. This will mean less actual code, and less inconsistency between what is seen in the console between commands.
Finally I will update you on my next task – looking at rendering framerate. I was aware testing that my fps dropped heavily in FFA once it got above 10 players. Without players on the server I get 190fps on sacred, but it can drop as low as 40 in FFA. As a quick test it seems that 90fps of the drop might be from drawing items which arent required for rendering (which can be fixed by hiding things you cannot see), and 60fps from the game ticks themselves (although admittedly I was testing with bots). I have already done some work on improving ticks, so will migrate that across and test. I would suggest that even saving 10 or 20 fps might have a real impact on game playability.
For a test version I will provide this soon, but please do not expect too much yet since it is work in progress and most of the work is elsewhere and yet to be transferred. You can download a test version always here:
LScripts.pak
which you pop into \Data\ (remember to back up the old one. Then run normal (not PK++), or alternatively rename this file to PKPlus.pak and use PK++. Please set \interpolationnosmooth 1 though or you will have issues. If you do not understand it, or have issues, I am not yet helping you fix them until I reach a beta test phase. You are welcome to paste feedback though, positive or negative (if it is negative – remember it is work in progress!). Also fixes/bugs/suggestions are more than welcome, either here or direct email to kerberos99@hotmail.com
I am grateful for any help from now on, be it images/sounds/code/testing/ideas. I am more than willing to accept help in any way since my free time is limited.
Have fun and happy fragging!
