The best way to learn how to use the WebCore is by example. See the documentation for more information.
The requested URL is always shown first; if a page uses one or more WebCore templates, those are shown afterwards.
00 <?php
01 include_once ('quake/init.php');
02
03 $Page->title->subject = 'Understanding the Lagometer';
04
05 $Page->location->append ("Quake III Arena", "./");
06 $Page->location->append ("Lagometer");
07
08 $Page->start_display ();
09 ?>
10 <div class="main-box">
11 <div class="text-flow">
12 <p>The lagometer is a small graph you can display in the bottom-right corner
13 of your screen. Turn it on with the variable <span class="field">CG_LAGOMETER</span>.</p>
14 <p>You can bind a key to show/hide this graph with this script:</p>
15 <pre><code>set lag_on "set CG_LAGOMETER 1; set tog_lag
16 vstr lag_off"
17 set lag_off "set CG_LAGOMETER 0; set tog_lag vstr lag_on"
18 set tog_lag vstr lag_on
19 bind "M" tog_lag</code></pre>
20 <p>There are two graphs in the lagometer, one above the other.</p>
21 <h3>Upper graph</h3>
22 <p>The upper graph advances one pixel for every rendered frame on the client
23 side. Blue lines below the baseline mean that the frame is interpolating
24 between two valid snapshots. Yellow lines above the baseline mean the
25 frame is extrapolating beyond the latest valid time. The length of the
26 line is proportional to the time.</p>
27 <p>Basically, blue is good: it's based on two snapshots received from the
28 server, so the frame will not be revoked. Yellow means that the client
29 is predicting what will happen, but hasn't received a snapshot to corroborate
30 it yet. If the next snapshot comes in and doesn't correspond to the prediction,
31 the prediction is revoked and the client is update with the snapshot data.
32 This results in the skipping you experience where you'll end up somewhere
33 very different from where you thought you were (and often with less health
34 than you thought, because you were shot on the server, but the client
35 couldn't predict that happening for you).</p>
36 <p>The upper graph indicates the consistency of your connection. Ideally,
37 you should always have blue bars of only a pixel or two in height. If
38 you are commonly getting big triangles of yellow on the graph, your connection
39 is inconsistent.</p>
40 <h3>Lower graph</h3>
41 <p>The lower graph slides one pixel for every snapshot received from the
42 server. By default, snapshots come 20 times a second, so if you are running
43 >20 fps, the top graph will move faster, and vice versa. A red bar means
44 the snapshot was dropped by the network (indicating packet loss). Green
45 and yellow bars are properly received snapshots, with the height of the
46 bar proportional to the ping. A yellow bar indicates that the previous
47 snapshot was intentionally supressed to stay under the rate limit.</p>
48 <p>In a heavy firefight, it is normal for modem players to see yellow bars
49 in the bottom graph, which should return to green when the action quiets
50 down. If you are getting several red bars visible, you may want to look
51 for a server that drops less packets.</p>
52 <h3>Fine-tuning the network</h3>
53 <p>Straight from the Carmack:</p>
54 <blockquote class="quote quote-block">
55 <p>There are a few tuning variables for people trying to optimize their
56 connection:</p>
57 <p>The most important one is <span class="field">rate</span>,
58 which is what the connection speed option in the menu sets. We are fairly
59 conservative with the values we set for the given modem speeds: 2500 for 28.8,
60 3000 for 33, and 3500 for 56k. You may actually be connecting faster than that,
61 and modem compression may be buying you something, so you might get a better play
62 experience by increasing the values slightly. If you connect at 50000 bps,
63 try a rate of 5000, etc. I err on the conservative side, because too low of
64 a rate will only make the movement of other things in the world choppy,
65 while too high of a rate can cause huge amounts of lag. Note that the optimal
66 rate will be somewhat lower than a rate for QW or Q2, because I now include
67 the UDP packet header length in the bandwidth estimate.</p>
68 <p>You can ask for a different number of snapshots by changing
69 the <span class="field">snaps</span> variable, but there isn't a lot of benefit
70 to that. Dedicated servers run at 40hz, so stick to divisors of that: 40, 20 (default),
71 10. A snaps of 40 will usually just cause you to hit your rate limit a lot faster.
72 It may be useful for tuning rate, if nothing else.</p>
73 <p>You can adjust the local timing point with <span class="field">
74 cg_timenudge <value></span>, which effectively adds local lag to try to make
75 sure you interpolate instead of extrapolate. If you really want to play on a server
76 that is dropping a ton of packets, a timenudge of 100 or so might make the game smoother.</p>
77 </blockquote>
78 </div>
79 </div>
80 <?php $Page->finish_display (); ?>
81
82