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?

[PCF]Adrian made another visit to #painkiller.euro this evening and passed on the following information:
————————————-
[18:45] * [PCF]Adrian has joined #painkiller.euro
[18:46] *[PCF]Adrian* Ok, hit me…
[18:46] * mute hits adrian badly
[18:46] *[PCF]Adrian* Let me feel the pain…
[18:46] * dmnk slaps [PCF]Adrian around a bit with a large trout
[18:46] * x4-rayfood slaps [PCF]Adrian around a bit with a large trout
[18:46] *x4-rayfood* 🙂
[18:46] *dmnk* 🙂
[18:46] * TeeJay stabs [PCF]Adrian in the face
[18:46] *[PCF]Adrian* Yeah we deserve that…

[18:47] *[PCF]Adrian* Anyway, in short… I WILL NOT be giving any dates, we’ve learnt the lesson, *but* we’re finishing 1.15 in about an hour.

[18:47] *[PCF]Adrian* The only good thing about 1.1 released in PL is that we’ve squashed a couple of more bugs and improved prediction code further.
[18:48] *[PCF]Adrian* So anyway, luckily DC has a hard time finding new bugs, so we keep our fingers crossed. Once again, no date, but IMHO it’s ready.

[18:48] *W4rh0g* Adrian
[18:48] *W4rh0g* do we all need to buy 3ghz pcs to play the game?
[18:49] *W4rh0g* I dont have a 3ghz pc for the prediction code
[18:49] *[PCF]Adrian* No you don’t. Average PC in the company is 1.7 GHz Athlon.
[18:49] *W4rh0g* yeah but yaten said it will grind on a 1.8ghz
[18:49] *[PCF]Adrian* Yaten is panicking 😉
[18:49] *[PCF]Adrian* For no reason 😉

[18:50] *[PCF]Adrian* Yaten just msged me they’re doing the installer. Ok, just dropped by to give your some progress info, gtg send the patch to DC, l8r all.

[18:50] *mute* Adrian, we saw this 1.15 server and the map was “dm6” as far i can remember. what about this map?
[18:50] *[PCF]Adrian* Yeah new map is in the works, DM_Fallen, but that’s for 1.2
[18:50] *[PCF]Adrian* Cheers.
[18:50] * [PCF]Adrian has quit IRC (Read error: EOF from client)
————————————
We’ll see whether DC find any bugs in this patch release. Fingers crossed that they’ve been reduced to an acceptable level.

Translation to english of the post made recently on the pk.pl forums:
————————————-
1st mail. 04.05.04 13:23

Hello

Few words about patch 1.1 (I know, there are lot of bugs but it could help)

1) It’s true that you can’t move the player while on your own server and prediction is on. This is my major bug and I’ve fixed it. Problem will be resolved in 1.15 (which is going to be out within a few days or after 3 AM tonight).

Fix: On a server, prediction must not be turned on. Clients with prediction enabled can connect to the server with prediction disabled without any problems. Just run the server without prediction enabled, turn clients prediction on and it should work. Server is identical with or without prediction in this case.

2) How does prediction work? Like in QW but Havok does great change. How big? It takes as much as 20% CPU power without prediction enabled. 20ms passes, 20ms of simulation ahead, 20% more CPU usage.
If prediction is enabled:
-let’s take a 50 fps server, packet frequency 20ms and ping 100ms. Every time a packet arrives, the game must take back these 100 ms and count physics again 100ms ahead. Each 20ms we count 100ms of physics. Havok takes 5 times normal!!!
And let’s take server 100 fps and ping 200… oho.
Even in QW physics takes 5 times normal, but counting it in QW is CPU cycles we can ignore so there is no lag.

Fix: (it could be, theoretical)
We can not do anything with ping, but update from server…
Even if server sends the information frequently, we have 4 parameters: updateparams_myplayer ‘delay’, analogical updateparams_players, updateparams_physicsitems and updateparams_projectiles. ‘delay’ tells us how frequently the server sends information to the client. Without prediction it should be 0.01, because delays are smaller. With prediction enabled client does not check server so frequently, so it could be that with 0.1 or 0.2 things can run beautiful. And this means that the data from the server reaches the client only 10 times per second, Havok does not ruin our PC and fps does not drop to 2. BTW: stronger PC, better effect of prediction. 3 GHz and up, prediction is acceptable as it is, but after tweaking updateparams it could run even on 800 Mhz.
If you have big fps drops, then turn prediction off. It will not help in this case.

3) There are bugs with voting too. Game drops to desktop. We’re chasing this bug as we searching this one with final table. I cannot guarantee what will be with these bugs. One of them has been harassing us for 2 months and we cannot track it. 🙁

4) English and Polish patches were completed at the same time. Polish was put on the web and English was stopped by Dreamcatcher after additional testing. Maybe if we are not in a hurry at 3 AM because „we must release”, next patches will be free of bugs.

2nd mail. (2 minutes later)

Aha, I think that Adrian will murder me for public statements. Why in this thread? Why on this webpage? Why not on other sites? Who is going to take offence? etc. It’s why I am giving hints here. Well. I don’t have time , I’m writing code, fixing bugs and I’ve read this thread by accident. It could be any other place where people talks about PK bugs.
All.
3rd mail 04.05.04 18:17

I think you’ll not be worried if I tell you that we test here on 1.8 GHz machine. It was high end machine when we were starting project. 🙂
Probably bug with desynchronization of server and client after 10 minutes of gaming on same map has been removed. With a large amount of effort but its effective. We see this while testing. 🙂 Unfortunately QW solution is now not possible. Too much to change. I’ll think about it later.

If it works on 3 GHz I am glad. Here we test it on LAN and it works great so far.
———————————–