Today, I got the chance to catch up with Yar, the Lead Programmer of the upcoming Painkiller MOD; Chains.MOD, and ask him a few questions. Theres alot of speculation over this MOD, as weve seen a couple of good looking screenshots, showing off the new hud and stuff. Heres what Yar had to say:

pkeuro: Hi Yar, could you please firstly tell us a little about the team currently hard at work on the Chains.MOD, and what visions lie behind the creation of this MOD?

Yar: So, our team currently includes 4 people: I am the lead programmer – client side, kAzu – 2nd Lead programmer & bussines, Soft – server side, gameplay programmer and StR4y – 2d graphics. Our target is to create a mod similar to Q3 OSP – with lots of features, tweaks and bug fixes. Painkiller is a very good game but it requires some tweaks – like advanced hud configuration, remote console, admin/referee, pause match or lock teams.

pkeuro: How will the Chains.MOD help create a new experience and improve Painkiller?

Yar: Chains.MOD is adding a lot of features. eg. ammolist, timer, time & date, team scores on hud in tdm (and you can set position, size & turn on/off all of them) setable position of messages, team reports – with hp/armor ammo etc and much more – this will create a more player-friendly game and make it easier to adjust Painkiller to our requirements. Maybe we will tweak weapons a little to improve balance also. This is all very important to create good multiplay in my opinion. 🙂

pkeuro: Some say mods destroyed the Q3 community by fragmentation, are you doing anything to prevent this happening again with Painkiller?

Yar: We really dont want scene fragmentation.

pkeuro: What is the current status of development, and when do you think your MOD will be ready for release?

Yar: “Public release will be probably be in 1 week.” This is all i can say 😛

pkeuro: Thanks for your time Yar, and good luck.

Yar: NP. Luck will be useful ;] Thanks.

Extras: Screenshot1 | Screenshot2

well Ive done some more playing with the settings and I think it feels a lot better now.

Just a bit of understanding first: Lots of small packets work well for digitial connections, but for adsl where processing latency is higher, and bandwidth more limited, lots of small packets are as benefitial. Latency increases reciprocally as remaining bandwidth decreases (the amount it does this depends on the technology)

However, splitting the rate up into lots of small quickly transmitted packets means that updates occur more quickly.

Hence there is always a compromise between processing latency and update rate.

Settings
========

What I noticed is that maxpacketsize affects server to client number of packets and packet size. The server rate is split up by the maximum packet size this way. The range is 20-1400, 20 gives nearly 200 packets per second, which will is unusable. Setting high values, the update rate drops to around 50/s (obviously it wont drop below server fps*). This is much more acceptable considering that the servers typically run at 45fps. This is still a lot more than Q3s 20fps. I would suggest you experiment with this value, since large packets may not be handled well by your network or routing.

*yet? Like snaps

What concerns me a lot here is that the default is 300. Well this might be ideal for servers with only a few players, but as soon as the server starts getting busy, your packets will get fragmented, and more packets mean more overhead, which means more bandwidth which means even higher latency (as well as the increased update latency).

NetUpdateSendPeriod which is controlled by ActionUpdatePeriod from command line – this is analogous to cl_maxpackets in Q3 except that it is 1000/(the value). 10ms = 100 maxpackets. As always higher update rates, mean lower update latency at the expense of increased bandwidth and the associated increase in latency with that. Play with this value, but you will find that the range over which you can play with it realistically is only, perhaps, 8-12.

Cfg.PushLatency is analogous to negative cl_timenudge in Q3. Like in Q3, it is important to get this setting correct, and requires experimentation.

I also used the new prediction, but it is important to get your basic connection settings correct first of all before using the patch of prediction. Prediction should just *help* but you need to have a playable connection without it first to get the best effect from it.

This is what seemed to work well for me:

Cfg.NetUpdateMaxPacketSize = 700
Cfg.NetUpdateSendPeriod = 10
Cfg.PlayerPrediction = true
Cfg.NewPrediction = true
Cfg.PushLatency = 25

Let me know what works well for you

Doughboy1er Will Be Collecting Demos For the new up and coming film for PAINKILLER (Frag Film.)The Name of the film is going to be – Faces of Destruction 5 God Needs A Painkiller

For Those Who are Interested In joining the Video
Contact
AIM: Doughboy1er
MSN: Doughboy1er@hotmail.com
IRC: EntertheGame @ #Painkiller ( Nick Doughboy1er )

THE PROBLEM
===========

The mouse lag issue [1][2] for Direct3D games is a known issue and can be seen in many Direct3D renderable games such as Halflife, UT, etc. [3][4][5]

The lag is due to the buffering that your video card is doing. Since they have eliminated any synchronization calls in the video card instruction buffer, it keeps on taking input from the CPU until the buffer is full. So your video card at any point in time may be rendering a frame that you fed it 1-3 frames beforehand, which would explain the mouse lags when at lowered framerates. In this way the CPU (via mouse events) is lagged from what is seen on the screen. [6][7]

Okay so why dont you see this in Single Player? In single player the game speed is slowed as your FPS drops, so the events take the same number of frames and appear smooth. This is typically done on every SP console game also. This effectively means that your CPU is slowed to be in sync. with your GPU. In MP this CANNOT happen, since time is constant and global (otherwise one client would time-lag the whole server, although this happens on listen servers 😉 ).

GRAPHICS CARD DEVELOPERS
========================

ATI acknowledge the problem and their fix for Direct3D games with mouse lag is…. to use OpenGL or software rendering 🙂..unless the developer forces GPU-CPU sync. themselves at the point of rendering rather than pre-rendering. This is effectively removing the pre-rendering buffer as we do in the fix.

http://www.ati.com/support/infobase/3308.html <- Unreal http://www.ati.com/support/infobase/3655.html <- Halflife (NOTE: In OpenGL you can call glFinish() to synchronise CPU and GPU after each frame. Most OpenGL games have this option) NVIDIA offer some advice to developers on the subject in their developer FAQ. http://developer.nvidia.com/object/General_FAQ.html#G4

Saying The most obvious solution would be to lock the back buffer for each frame in Direct3D, which is essentially fix presented on Pkeuro. This ensures that all pending graphics commands are completed by the GPU before the CPU moves on..

Thats why UT2003/4 had to resort having a reduce mouse lag options which is basically forces syncronisation between the CPU and the GPU, overriding the pre-rendering buffer limit.

The pkeuro fix will work for Direct3D games for this reason. You may experience a slight FPS drop, since nvidias need for a large amount of pre-rendering is based on the fact their pre-rendering code is not optimised for D3D so much. That said fps-lag is much more playable than mouse-lag.

THE FIX
=======

Click Here.

References
==========

[1] Savage General
[2] ESR
[3] Battlezone 2
[4] Unreal
[5] ElderScrolls
[6] Developer Forum #1
[7] Developer Forum #2

One of the main criticisms of PK is the simplified movement. While being complex compared to 95% of games out there, compared to QW/CPM the movement in PK is relatively simple. That being said, there are some good features about it, and some complex things that can be done. However, with things like the in-built Forward Rocket-Jump option, the options are decreased.

The way the FRJ works in PK, is by firing a rocket directly behind you. By looking down towards the floor, you set the angle the rocket will come out of your ass. Therefore, by looking directly ahead, the rocket flies out directly behind you. So not only does it remove the skill of FRJ’ing manually (which is fairly difficult), it also removes the skill of doing a 180 and continuing bunnyhopping so you can fire behind you (also difficult). To be honest, these are the two hardest manouevres possible and the only challenge presented by the PK movement system, so in my opinion the FRJ bind should be disabled on the servers (which it currently is not).

PK offers something unique that most games out there don’t, a (somewhat) higher level of depth and complexity and potential skill – why take that away? Isn’t that what attracted us to PK in the first place?