Q2PRO-X 1.6 Beta 5 by ly — Q2PRO-X 1.6 Beta 5 Network God Guide
The complete guide in HTML. The original DOCX is available from its documentation card.
Q2PRO-X 1.6 Beta 5 by ly
Q2PRO-X 1.6 Beta 5 Network God Guide
Project author: ly
A player-first guide: observation, plain-language explanation and safe actions
English edition • Q2PRO-X 1.6 Beta 5 by ly • 2026-10-10
Contents
The entries are links: click one to jump to that section.
Demo playback and Network God in beta 2
Welcome: this guide is written for the player
1. What Q2PRO-X Network God is
2. A safe first run in two minutes
3. Where to open the system and how to drive it
4. The four modes in plain words
5. How to read the status strip
6. The big overview: six tabs with no riddles
8. If players stutter, teleport or move in jerks
9. If shots feel late or commands are lost
10. How to find a background Steam, torrent or Windows download
11. Telling the internet, the server and a computer freeze apart
12. How recommendations, applying and reverting work
13. Jitter Shield: a smoother display of other players
14. Connection Guardian: limited recovery from a broken link
15. How Network God relates to the other Q2PRO-X network features
16. The Network Lab: practising under controlled bad conditions
17. Tailoring the HUD and the big window
18. Reports: how to record a problem without revealing too much
19. A detailed tour of the menu
20. Ready-made scenarios: "saw it → understood it → did it → checked it"
21. Frequently asked questions
22. Safety, honesty and the effect on performance
23. A user's reference of factory values
Appendix A. Console variables and commands
Appendix B. How the system is built inside — a simple explanation
Appendix C. The player's large glossary
Demo playback and Network God in beta 2
During DM2 and MVD2 playback, Network God disables its HUD, network-fact collection, diagnostics, corrections, Guardian, Jitter Shield and Network Lab. The selected mode is not overwritten and becomes available again after playback. Demo formats and network protocols are unchanged.
Welcome: this guide is written for the player
The emblem of the Q2PRO-X Network God subsystem.
Network God is the part of Q2PRO-X 1.6 Beta 5 that helps you understand why online play sometimes feels bad. It watches the connection, translates measurements into ordinary language and shows what can be done about them. With your permission it can also apply one limited, safe change for a while, check the result, and put everything back if nothing improved.
You do not need to know how internet protocols work to read this. If you can start Q2PRO-X, pick a server or type /connect, you already know enough. Every new word is first explained in plain terms and then repeated in the large glossary at the end.
| The main idea. Start in Diagnostics mode. It only observes and explains. It changes no settings, adds no delay and does not interfere with the game. |
|---|
How this guide is arranged
The main body moves from simple to detailed:
1. Turn on safe observation in two minutes.
2. Learn to read the overall status, the colours and the short messages.
3. Work through the six tabs of the big overview.
4. Find your scenario: high ping, players stuttering, packet loss, a background download, or the computer freezing.
5. Only then meet the additional modules and the automation.
The appendices at the end are for readers who want every setting, every console command and the internal design. You do not have to read them to use Network God every day.
| About the screenshots. The images show one particular user configuration. The slider values in them help you recognise a screen, but they do not always match the factory values. The text beside them always states what is on by default. |
|---|
Contents, with no technical riddles
| Section | What you get |
|---|---|
| 1. What Network God is | An understanding of why it exists and what not to expect from it |
| 2. First run | A safe setup in two minutes |
| 3. Where to open it | Exact paths through the game menu |
| 4. The four modes | What exactly changes for the player |
| 5. The status strip | The meaning of the circles, the colours and the TRAF label |
| 6. The big overview | A plain explanation of all six tabs |
| 7–11. Problems in the game | Step-by-step actions for the usual symptoms |
| 12. Recommendations | How to apply, verify and revert a change |
| 13–17. Additional modules | Jitter Shield, Guardian, LagHax, prediction, Ping Adaptation, AutoPort and the Lab |
| 18–19. HUD and reports | Appearance, saving and privacy |
| 20–22. The full reference | Every user setting and troubleshooting |
| Appendices | The console, the internal design and the large glossary |
1. What Q2PRO-X Network God is
In an ordinary game you see one ping number. It is useful, but it does not answer every question. Two matches with the same 40 ms ping can feel completely different: in one everything is smooth, in the other opponents stutter, shots respond unevenly and the connection occasionally stalls. The cause may be in the internet, on the server, in a background download on your own computer, or even in a brief freeze of the game itself.
Network God gathers those signs in one place and answers four human questions:
1.1. An example from ordinary play
Imagine an opponent who occasionally moves in jerks.
Without diagnostics it is easy to start changing rate, prediction, graphics and a dozen other settings at random. Afterwards it is hard to tell what helped and what added a new problem.
With Network God the order is different:
1. The system observes real play for a while.
2. It checks whether data from the server arrives evenly.
3. Separately, it notices whether the jerks coincided with a freeze of your own computer.
4. An explanation in ordinary words appears in the overview.
5. If there is a safe action, exactly one is offered — not a list of random tweaks.
6. After it is applied, the result is verified. If it did not help, the temporary change is reverted.
1.2. What the system can do
1.3. What the system cannot do and does not promise
| An honest limit. Sometimes the diagnosis correctly reports: "there is a problem, but there is no safe client-side change for it." That is a useful result. It saves you from pointlessly cycling through settings. |
|---|
1.4. Why the name is loud and the behaviour is careful
The name Network God brings many Q2PRO-X network capabilities together under one understandable interface. Inside, however, the system behaves conservatively: it observes first, then explains, changes no more than one setting at a time, and always remembers the original value.
When the feature is off, the new intelligent layer collects nothing and changes nothing. Manual settings for LagHax, prediction, Ping Adaptation and the other older features stay exactly as the player chose them.
2. A safe first run in two minutes
This section is the recommended path for a first acquaintance. It needs no console commands.
2.1. Connect to an ordinary remote server
You can pick a server in the browser or use the familiar /connect address:port. For a first run, do not use a local map: single player is not analysed by the system, and on a local deathmatch server the feature and its interface are hidden by default.
2.2. Open the Network God menu
Use one of the exact paths:
2.3. Choose the Diagnostics mode
In the Mode row, select Diagnostics. This mode is safe by construction: it measures and explains, but changes no network settings.
The current Network God main menu. For a first run it is enough to select the Diagnostics mode, leave Restart measurements automatically enabled, and open the network overview. The compact panel settings live behind the On-screen status… row.
Leaving Restart measurements automatically set to Yes is recommended. This option does not restart the game and does not change the network by itself. If you changed an important network setting yourself, loaded a profile carrying such settings, or ran net_restart, Network God simply forgets measurements made under the old conditions and starts clean observation again.
2.4. Let the system see real play
Return to the match and play for at least 20–30 seconds. It is better to move, shoot and receive ordinary world updates. On a quiet server collection can take longer, because the system needs not only seconds but also a sufficient number of real measurements.
The first "collecting data" or "observing" messages are normal. They are neither a hang nor an error. The system deliberately refuses to draw a confident conclusion from the first few packets.
2.5. Open the big overview
Press Open network overview…. If you assigned an overview key, you can use it instead. The key shown in the menu refers to your own configuration, so this guide does not assume that it must be F11 for everybody.
Start with the Summary tab. Look at the top status line and the What to do now block. Then open Events and What to do.
2.6. What counts as a successful first result
A successful result does not have to contain a fix. On a healthy connection these signs are normal:
| Do not hunt for a button for its own sake. If the system says there is nothing to change, do not raise the sensitivity merely to make a suggestion appear. An empty plan on a good network is correct behaviour. |
|---|
3. Where to open the system and how to drive it
3.1. The main menu and the in-game menu
The same entry point is available both before connecting and during play:
Online play setup… → Network & Predict → Q2PRO-X Network God…
The page is divided into understandable groups:
3.2. The big overview
The overlay is a large window over the game. It does not pause a match on a remote server, so open it in a safe place or while spectating.
Controls:
| Action | Key or mouse |
|---|---|
| Move between tabs | Tab, Shift+Tab or a mouse click |
| Scroll the page | Mouse wheel, Page Up, Page Down |
| Jump to the start or the end | Home, End |
| Copy the available text | Ctrl+C or the Copy button |
| Close without changing settings | Esc or the cross |
| Open the settings menu | The Settings button at the top |
| Go to the server list | The Servers button at the bottom |
3.3. A short status inside the game itself
If you do not want to open the large window, enable On-screen status…. You can show only the strip of circles, only the text, or both. The HUD is a small on-screen indicator that diagnoses nothing by itself: it displays a state that is already prepared.
Auto-hide when healthy is on by default. After connecting, the panel shows the progress of the initial check, then leaves a fully green result on screen for a while and hides. Ordinary periodic checks continue in the background, but on their own they no longer bring the hidden panel back.
The panel returns only for an understandable reason:
With a real problem present, the timer does not hide the status. Once the problem is gone, a green result again stays on screen for the configured number of seconds and then hides. Opening the big overview must not remove the compact panel: both can be read at the same time.
3.4. The console is optional
Every main action is available through the menu. The console commands are collected in an appendix for testers and advanced users. An ordinary player does not need to memorise variable names.
4. The four modes in plain words
4.1. Off — nothing new happens
This is the factory state. Network God collects no new statistics, looks for no problems, checks no applications and changes no parameters. If the on-screen HUD is left enabled separately, it may display OFF, but that does not start observation.
Note that switching Network God off does not reset the manual settings of the older Q2PRO-X modules. If you enabled LagHax or Ping Adaptation yourself in their own menus, they keep living by their own rules.
4.2. Diagnostics — the best first choice
The system watches the connection, shows events, explains them and lets you save a report. It applies nothing.
Choose this mode when:
4.3. Ask first — the system proposes, the player decides
After enough observation, one action card may appear. It states:
Nothing happens until you press Apply. After applying, a Revert command is available.
This is the recommended mode for a player who has already met the diagnostics and wants to control every step.
4.4. Automatic — permitted changes only
This mode does not receive unlimited rights. Before it is enabled, Q2PRO-X shows a separate confirmation of the permission list. The automation may use only the entries enabled on the Permissions page.
Even in automatic mode:
4.5. A short comparison
| Mode | Observes | Advises | Changes by itself | Who it suits |
|---|---|---|---|---|
| Off | No | No | No | Anyone who does not need the feature right now |
| Diagnostics | Yes | Explains the state | No | Everyone, for a first run |
| Ask first | Yes | Yes | Only after the player presses | Anyone who wants full control |
| Automatic | Yes | Yes | Only what is permitted, and with verification | Anyone who has configured the permissions and understands the cost of actions |
| No mode ever switches by itself the Q2PRO/R1Q2 movement feel, fixedmove, player prediction, weapon prediction, or the mode and target of Ping Adaptation. |
|---|
5. How to read the status strip
The strip is not a "Network God readiness percentage". It is a sequence of stages. Not every stage has to be active: if the connection is healthy and there is nothing to change, the apply and verify stages calmly stay grey.
The compact status strip in game. Seven circles show the working stages; TRAF on the right separately shows the load on the computer.
5.1. The seven circles
| Label | Full name | What it tells you |
|---|---|---|
| LINK | Link | Whether there is a working connection to a server |
| OBS | Observation | Whether enough clean measurements have accumulated |
| DIAG | Diagnosis | Whether the system has understood what is happening |
| PLAN | Plan | Whether there is a safe, useful action |
| APPLY | Apply | Whether one chosen change is being performed |
| VERIFY | Verify | Whether the result is being compared against the original state |
| GUARD | Guard | Whether a revert or a limited connection recovery is needed |
5.2. Colours and glyphs
Colour is never the only carrier of meaning: there is a glyph beside it.
| Appearance | Plain meaning | What to do |
|---|---|---|
| Grey "−" | The stage is off, unnecessary or still waiting | Usually nothing |
| Blue ">" | The stage is running right now | Wait for it to finish |
| Green "+" | All is well, or the verification succeeded | Keep playing |
| Yellow "!" | Attention, more data or more time is needed | Open the overview and read the explanation |
| Red "×" | A serious problem, a failed verification or a revert | Open Events and What to do |
| Purple "S" | The data was produced by the Lab | Do not confuse it with the real internet |
5.3. Why PLAN, APPLY and VERIFY may be grey
If the network is fine, there is nothing to plan, apply or verify. Grey stages in that case mean not a fault but the absence of unnecessary work.
5.4. What TRAF means
TRAF is a separate indicator of background load on the computer. It is not an eighth control stage.
A red TRAF does not prove that this particular load spoiled the match. There is a separate 30-second impact check for that.
6. The big overview: six tabs with no riddles
The title, the overall status and the mode are always visible at the top of the window. The control hints and the quick-action buttons are at the bottom. Hovering the mouse over a figure opens a detailed tooltip; this help is on by default.
6.1. Summary — start here
An ordinary player does not need to memorise every number. Look at the state caption, and hover over any line you do not understand.
The Summary tab: the overall state, the server, the real and the final ping, receive and transmit.
The summary answers four questions.
Where am I connected
The address, the readable server name, the map, the mod and the protocol are shown. If the server has not reported its name yet, only the address may be visible for a while.
What is the connection doing now
The top card says OK, Attention, Problem or Collecting data. Below it is the What to do now phrase. That is the main human conclusion, not merely a colour.
Why two pings are shown
With no artificial delay in play, those two figures are usually equal or close. The Jitter Shield buffer is not added here, because it applies only to how other players are shown.
What is happening in both directions
The Receive — from the server to me block helps you see whether world updates arrive evenly and whether any are missing. The Transmit — from me to the server block shows how often, and in what volume, the client sends its commands.
6.2. Events — what the system noticed
The Events tab: cards for the detected states plus a separate warning about background load.
An event is not necessarily a failure. It may be:
Every event carries a confidence level:
| Level | What it means for the player |
|---|---|
| Not enough data | Observation does not yet allow an honest conclusion |
| Probably | There is a sign, but the coincidence may be chance |
| Confident | The sign repeated and is backed by sufficient measurements |
| Certain | A direct fact was received, not a statistical guess |
The Go to the answer button takes you to the tab where the next step is explained.
6.3. What to do — the help centre
The What to do tab: an understandable action, the reason for waiting, or an honest answer that there is nothing to change right now.
This tab deliberately does not show dozens of tips at once.
Four normal states are possible:
1. There is nothing to change. The connection is healthy, or no safe client-side action is required.
2. Collection is under way. It states what data is still needed and how the observation is progressing.
3. There is an external recommendation. Pausing a Steam download and running a comparison, for example.
4. There is a temporary Q2PRO-X change. In the permitting modes a card appears with "current → proposed", the benefit, the cost, the verification and the revert.
The word waiting must always come with a reason: time is still accumulating, more events are needed, a cooldown between actions is in effect, there is no permission, or the proposed cost is too high.
6.4. Modules — what is really running
The Modules tab: the actual state of the related network features and of home-network observation.
LagHax, prediction, Ping Adaptation, NetAutoPort, Jitter Shield, Connection Guardian and home-network observation are collected here.
An important rule: a stored value and real operation are not the same thing. A parameter may be enabled but have no effect on a local server or in an unsuitable mode. This tab tries to show the actual state.
If you need to change one module, press its Settings… button. Do not change several modules at once when you are trying to compare a result.
6.5. Lab — artificial impairment only
The Lab tab: the parameters and counters of a deliberately created bad network.
There is no diagnosis of the real internet here. The Lab deliberately delays, drops or reorders some game data for practice and testing. While it runs, the interface is marked with the purple word SYNTHETIC, and the ordinary automation does not intervene.
If you do not know why you would want the Lab, leave it off.
6.6. Help — the legend always at hand
The Help tab: the modes, the stages, the colours, the glyphs and the difference between the two kinds of ping.
Help restates the meaning of the modes, the seven stages, the colours, the glyphs and the two pings. It is useful during a first acquaintance and changes no settings.
7. If the ping is high
7.1. First decide: is it steady or jumping?
A high but steady ping and a jumping ping are different problems.
Open Summary and Events. Look not only at the average figure but at the human description of the spread.
7.2. What can be done about a steady high ping
1. Make sure the expected server is selected, not a distant address.
2. Compare another server in the same region.
3. If you use a VPN or a game proxy, compare the route with and without it.
4. Use Q2PRO-X prediction for a more responsive display of your own actions, if it suits your server and mod.
5. Do not expect command duplication or the Jitter Shield to reduce geographical delay.
Ping Adaptation, on the contrary, adds delay deliberately. It exists to level conditions or to practise, not to reduce a real ping.
7.3. What can be done about spikes
1. Enable Continuous check for background traffic.
2. Wait for a sustained result rather than a single spike.
3. Check the Events tab for local freezes.
4. If the display of other players stutters, look at the Jitter Shield.
5. If the system names a possible program, run the 30-second impact check.
6. Change one thing at a time and compare inside the same match or on the same server.
7.4. What not to do
8. If players stutter, teleport or move in jerks
8.1. Three different causes of a similar symptom
Server updates arrive unevenly
Your computer receives correct positions, but the intervals between them differ. Other players' models can then move in jerks even at a moderate average ping.
Data is being lost
One or several updates never arrive. With a burst of losses the jerk is more noticeable than with a rare single loss.
The client itself freezes
If Q2PRO-X stopped drawing frames for a moment because of shader compilation, the disk, the CPU or the GPU, everything on screen jumps too. That is not necessarily the internet.
8.2. The checking order
1. Open Events.
2. Find the message about arrival spread, losses or a local freeze.
3. If there is little data, keep playing for 20–60 seconds.
4. If uneven display of remote players is confirmed specifically, try the Jitter Shield in Auto mode.
5. Leave the factory maximum of 60 ms and the 95% percentile at first.
6. Compare the smoothness against the small perceived lag of the models.
8.3. What the Shield does not fix
It does not reduce ping, does not restore lost data and does not affect server-side hit registration. It only makes the display of other players smoother, at the cost of a small visual time reserve.
If the jerk coincided with a local freeze, the cause must be looked for in the computer or the renderer, not in a bigger buffer.
9. If shots feel late or commands are lost
9.1. Separate display delay from a genuinely lost command
A high ping by itself makes the server's answer arrive later. Q2PRO-X prediction can show part of your own actions immediately, but the server still remains the sole judge of a hit.
A different situation is the server directly reporting that it never received one of the player's commands. On a compatible Q2PRO path a small amount of command duplication can then help.
9.2. What command duplication means
It is not a copy of all internet traffic and not a double shot. The client attaches a limited backup copy of a recent movement/action command, so a single loss has less chance of destroying it.
The automation may raise the value by exactly one step, only when there is a direct sign of outgoing command loss, and only if the extra traffic stays inside a safe budget.
9.3. Step by step
1. Open the What to do tab.
2. Make sure the card talks about lost commands specifically and not about incoming losses.
3. Read the cost in extra traffic.
4. In Ask first mode, press Apply.
5. Wait for the verification window.
6. If things got worse, or there is no benefit, press Revert; on a failed verification the system does it for you.
| Command duplication is not a universal cure for every lag. If server updates are lost on their way to you, an outgoing backup command solves a different problem. |
|---|
10. How to find a background Steam, torrent or Windows download
A background transfer is especially dangerous when it fills the queue of your home link. Upload to the internet sometimes spoils a game even sooner than a large download does.
Observation is off by default and consists of two independent permissions:
The background-traffic menu. Continuous check and Application analysis are enabled separately.
10.1. The recommended first test
1. Enable Continuous check.
2. Leave the factory thresholds: download 1024 KiB/s, upload 256 KiB/s, confirmation 10 seconds.
3. Play for at least 20–30 seconds.
4. Look at TRAF and at the Events tab.
5. If the load is sustained, enable Application analysis as well if you wish.
The factory thresholds are a starting point, not a measurement of your subscription speed. If your link is very slow or very fast, you can tune them later.
10.2. How to read the levels
| Level | What happened | The player's reaction |
|---|---|---|
| Low | The background transfer is small | Do nothing |
| Raised | The transfer is noticeable but unstable | Keep watching |
| High | The threshold is exceeded for a prolonged time | Check the source and the impact |
| Critical | The load is sustained and very large relative to the threshold | Pause the transfer and compare the match |
Short spikes from a browser, Steam or Windows must not flash red: the system waits for the configured confirmation time.
10.3. What a detected Steam or torrent means
It is a possible source with open network activity, not a verdict. Q2PRO-X does not attribute an exact number of bytes to a program and does not claim it is guilty until the game figures have been compared before and after.
If no application is found, the overall load may still be real. Windows may have restricted access to the information, the program may use an unknown path, and the source may be another device on the home network that a client on this computer cannot see directly.
10.4. The 30-second impact check
1. On the card, press Check the impact — 30 s.
2. Immediately pause the suspected download yourself.
3. Keep playing normally.
4. After 30 seconds, read the result.
The results:
10.5. What Q2PRO-X does and does not see
The system can inspect the operating system's network-connection tables to a limited degree and match them against a known program category. It neither records nor shows:
The data is not sent to the internet. Observation works locally, and only while it is enabled.
11. Telling the internet, the server and a computer freeze apart
One and the same visible jerk can be born in three different places. A correct diagnosis saves hours of pointless configuration.
11.1. Signs of a problem on your computer
What to do: open the performance HUD, check the CPU, GPU and disk, background tasks, compilation and the renderer settings. Do not raise network buffers merely because of a local freeze.
11.2. Signs of the home network or the route
What to do: check background traffic, the cable or Wi-Fi against your actual connection type, the router, the route with and without a VPN, and another server or region.
11.3. Signs of a server problem
What to do: compare another server, save a report and hand it to the administrator. A client cannot fix server overload.
11.4. Why the system sometimes writes "unknown"
Honest diagnostics do not guess at a culprit. If a local freeze, a route change and a background load all coincided, the data may be insufficient. Continue observing under calmer conditions, or repeat a reproducible episode.
12. How recommendations, applying and reverting work
This section matters especially before moving from Diagnostics into Ask first or Automatic.
12.1. One setting at a time
Network God does not try to change five parameters at once. Simultaneous changes would look busy, but they would destroy the point of verification: it would be impossible to tell what helped.
The order is always the same:
1. Collect the baseline measurements.
2. Choose one permitted action.
3. Remember the player's original value.
4. Apply the new value temporarily.
5. Wait until the transitional state is over.
6. Compare the relevant figure and check that nothing else got worse.
7. Keep the temporary result for the current session, or restore the original value.
12.2. How to read an action card
A good card answers seven questions.
| Card line | In ordinary language |
|---|---|
| Detected | Which problem the system saw |
| Evidence | Which real observations the conclusion rests on |
| Current → proposed | What exactly changes temporarily |
| Benefit | Which visible or measurable effect is expected |
| Cost | What you pay: traffic, or a small visual delay |
| Verification | How long to wait and which figure is compared |
| Revert | Which degradation forces the original value back |
If any line is missing or unclear, do not press Apply blindly. Open the tooltip, or stay in Diagnostics.
12.3. The Apply button
In Ask first mode it starts only the stated temporary change. It is neither a save of a complete profile nor a permission for future actions.
During verification the strip shows the APPLY and VERIFY stages. Do not change the same parameter by hand before the comparison ends: an explicit player action counts as authoritative and ends the experiment.
12.4. The Revert button
It removes the current temporary change and restores the value that was in place before the experiment. Changing the mode, the server or the session must likewise never leave an old temporary control in place on a new connection.
12.5. The Keep button
This is a separate, deliberate save of the accepted compatible value alone. It must not silently save every network parameter. Q2PRO-X shows a confirmation before saving.
If you are merely testing, play long enough with the temporary result first. Do not save a value after a single lucky episode.
12.6. What the cooldown between actions means
After one change, the system must not immediately swing the parameter back and forth again. The cooldown lets the connection settle and keeps automatic help from becoming a source of jerks itself. The factory cooldown is 30 seconds.
12.7. Why an action may not be offered
The What to do tab must name the specific reason. Meaningless waiting with no explanation is not normal interface behaviour.
12.8. Automatic-mode permissions
The automation permissions. Every right is enabled separately; the screenshot shows one user's values, not the mandatory defaults.
| Permission | Default | What is really permitted |
|---|---|---|
| Adaptive LagHax | Yes | Temporarily use the accepted adaptive mode when a confirmed rise in corrections is observed |
| Command duplication | Yes | On a compatible path, add one limited step of redundancy for lost commands |
| Jitter Shield | No | Automatically choose only the display buffer for other players, inside the configured maximum |
| AutoPort on the next connection | No | Check the port once before the next connection, never in the middle of a match |
| Connection Guardian | No | Make a limited attempt to restore a genuinely broken connection |
Even an enabled permission does nothing in Off and Diagnostics modes. For full automatic mode the list is confirmed separately.
13. Jitter Shield: a smoother display of other players
13.1. The simple idea
The server sends player positions in portions. If those portions arrive unevenly, an opponent's model can slow down and then catch up. The Jitter Shield holds a small time reserve for the display of remote players alone, and thereby smooths the unevenness out.
It is like a short video buffer: a few milliseconds of reserve help to present the sequence more evenly.
13.2. What the Shield never delays
It touches only where other players are shown on screen.
13.3. The price of smoothness
An opponent's model may be shown a few milliseconds later. 20 ms is two hundredths of a second. The larger the buffer, the easier it is to hide strong unevenness — and the more noticeable the visual lag becomes.
That is why the maximum is a ceiling, not a target.
The Jitter Shield settings: automatic or fixed buffer, its maximum, and the sensitivity to rare spikes.
13.4. Auto mode
This is the recommended first choice. Q2PRO-X estimates the unevenness of data arrival and picks the buffer it needs, never exceeding the configured maximum.
If the network is even, the actual buffer may stay at 0 ms even with the Shield enabled. That is correct behaviour: the system does not add delay merely to demonstrate that it is working.
13.5. Fixed mode
Always uses the stated value. It suits a controlled comparison, or a player who already knows the reserve they want. A value of 0 shows other players exactly as before.
13.6. The 90%, 95% and 99% percentile
The term sounds complicated, but the meaning is simple:
Imagine 100 measurements sorted from the most even to the least even. The 95% value aims at roughly the fifth measurement from the worst end, so one random extreme cannot govern everything.
13.7. The recommended check
1. Make sure the event talks about uneven arrival and not about a local freeze.
2. Enable the Shield in Auto mode.
3. Leave the maximum at 60 ms and the percentile at 95%.
4. Watch for several minutes, especially during an active firefight.
5. Compare the smoothness against the possible visual lag.
6. If the price is more noticeable than the benefit, lower the maximum or switch the Shield off.
13.8. Safe resets
On a teleport, a respawn, a map change or a new connection, the old transitional state is discarded. When there is little history, ordinary display is used rather than an invented buffer.
14. Connection Guardian: limited recovery from a broken link
The Guardian is not there for an ordinary high ping. It steps in only when the server has genuinely stopped answering while Q2PRO-X and the computer keep working normally.
The Connection Guardian settings: a safe silence threshold, the number of attempts, and the pause before recovery.
14.1. When the Guardian may start
14.2. When the Guardian must do nothing
The Guardian does not work around server decisions and does not create an endless reconnection loop.
14.3. The silence threshold
The factory value of 0 means an automatic safe threshold, computed from the server's real update rate. That is the best first choice.
A manual value is given in milliseconds. Too short a threshold could mistake an ordinary pause for a broken link, so values below one second are still clamped to a safe boundary.
14.4. Attempts and the initial pause
Three attempts are allowed by default. Before the first one the system waits 1000 ms, that is one second. The next pause grows, so the server is not bombarded with repeated connections.
The HUD and the overview show the reason, the countdown and the attempt number. The cancel button ends the recovery for the current case.
14.5. The recommended choice
Leave the Guardian off if you have no occasional drops. If your connection really does die silently now and then:
1. Enable the Guardian's manual master.
2. Leave the automatic threshold, three attempts and the 1000 ms pause.
3. On the next occurrence, check whether a correct reason was named.
4. If the server refused explicitly, make sure no retries happened.
15. How Network God relates to the other Q2PRO-X network features
Network God does not replace the client's long-standing capabilities. It shows their state, accounts for their influence and, in strictly limited cases, may temporarily use a permitted mode.
15.1. LagHax
What it is
The client shows your movement in advance instead of waiting for every server answer. When the server's truth differs, a correction occurs. LagHax makes such corrections less unpleasant and more controllable.
What the player notices
Movement can feel steadier under network corrections. This is not knowledge of the future and not a change to server physics.
What Network God may do with it
With a separate permission it may temporarily enable the accepted adaptive mode when measurements show a rise in corrections. Once it disengages, the player's setting comes back.
When not to touch it
If movement already feels good and there is no event about corrections, do not change LagHax just to alter one colour in the HUD.
15.2. Player and weapon prediction
What it is
Prediction is the immediate local display of what the server will probably confirm: your movement, your shot or a related effect. Thanks to it, the controls do not feel completely late under network delay.
An important boundary
The server remains authoritative. Prediction does not turn a miss into a hit and does not reveal a hidden opponent.
The role of Network God
It shows and accounts for the actual state of prediction, but never switches it automatically. The choice of prediction depends on the server, the mod and the player's preference.
15.3. Ping Adaptation
What it is
Ping Adaptation deliberately delays outgoing game data in order to reach a chosen final ping. That is useful for levelling conditions with an opponent, or for practice.
What the overview shows
The real ping stays a separate figure. The added delay is shown separately, and the final ping reflects the sum the client actually works with.
What Network God does not do
It does not enable Ping Adaptation, does not change its target and does not adjust its mode automatically. It only makes sure a deliberate delay is not mistaken for a bad route.
15.4. NetAutoPort
What it is
Some network paths can behave differently with different local ports. AutoPort quickly tests the options before connecting and picks the best measured answer.
The automation permission
Network God may only schedule the existing one-shot check before the next connection. It does not start a full search in the middle of a match, and it respects AutoPort's own master switch.
An honest limit
Not every server or home route will show a noticeable difference. The result of one specific check is no guarantee for all future connections.
15.5. Command duplication
This mechanism is already explained in section 9. It concerns the player's outgoing commands, not all traffic. The automation is limited to one step and to a budget for the extra transmission.
15.6. Movement feel and fixedmove
These parameters strongly affect subjective control. Network God may show them for context, but never switches them automatically. The player remains the owner of the Q2PRO/R1Q2 choice and of the movement mode.
16. The Network Lab: practising under controlled bad conditions
The Lab is meant for testing and practice. It deliberately spoils the network according to a chosen scenario. It is the only part where a loss, a reorder or an extra delay is created on purpose.
The Network Lab menu. Every kind of artificial impairment is zero by default, and starting it is a separate command.
16.1. When the Lab is useful
16.2. What can be simulated
| Setting | Plain explanation |
|---|---|
| Direction | Spoil the path from the client, to the client, or both |
| Delay | Add a constant number of milliseconds |
| Delay spread | Make the arrival uneven |
| Spread shape | Decide how often rare large peaks occur |
| Loss | Deliberately drop a fraction of the data |
| Loss model | Lose singly, or in bursts |
| Reorder | Occasionally deliver data out of order |
| Bandwidth | Cap the artificial throughput |
| Repeatability seed | Repeat the same random scenario |
16.3. What the repeatability seed is
Random impairment is normally different every time. A repeatability seed lets you obtain the same sequence of decisions and compare two configurations honestly.
A value of 0 picks a random seed for the current run and shows it. Write the displayed seed down if you want to repeat a successful or a problematic test.
16.4. Starting it safely
1. It is better to start on a local test server.
2. The Network God mode must be at least Diagnostics.
3. Configure the impairment.
4. Press Start.
5. Make sure the overview reads SYNTHETIC.
6. After the test press Stop and check that the purple marking is gone.
On a remote server a separate permission and a confirmation for the current session are required. The Lab must never start there by itself.
16.5. Important limits
17. Tailoring the HUD and the big window
17.1. What to show
The On-screen status… menu offers four options:
The HUD is off by default. Enabling it is not required for the diagnostics to work.
The current On-screen network status menu: the panel style, auto-hiding a healthy result, the hide delay, the placement, the size, the opacity, the palette and the animation.
17.2. Auto-hiding a healthy result
The Auto-hide when healthy option is on by default. Its purpose is to stop occupying the screen once the connection has been checked and everything is fine.
The correct sequence looks like this:
1. After connecting, the panel is visible and shows the progress of the check.
2. While there is not enough data, it stays on screen.
3. If the check finished with no problems, every stage turns green.
4. The green result stays visible for the Hide delay.
5. The panel then hides, while the diagnostics keep running.
A background re-scan, the next observation period and a map change inside the same connection are not reasons to show a healthy panel again. It comes back on a real problem, on a new connection, on net_restart, or on a local change to a critical network setting that starts a fresh clean measurement.
If a problem appears after the auto-hide, the panel returns and does not disappear while the state stays problematic. Once everything is normal again, a new hide-delay countdown starts.
If you disable Auto-hide when healthy, the chosen strip and text stay on screen permanently. The Hide delay value applies only when auto-hide is enabled. The factory delay is 5 seconds; 1 to 60 seconds is allowed.
17.3. Short and detailed text
The short variant occupies one line. The detailed variant adds a second line with the diagnosis confidence, the active change and the display buffer for other players.
For a first acquaintance the detailed text is convenient. For everyday play on a small screen, the short text or the strip alone works better.
17.4. Horizontal or vertical
A horizontal strip reads better along the top or bottom edge. A vertical one suits the side of a wide screen. The meaning of the stages does not change.
17.5. Anchor and offsets
The anchor is the corner or edge midpoint the HUD is attached to. The X and Y offsets move it relative to that place.
There are nine options: four corners, four edge midpoints and the centre. The factory position is bottom right.
The Edit position… command lets you drag the HUD with the mouse. Reset layout returns the position, the size and the opacity to their factory values.
17.6. Scale and opacity
The scale affects this HUD only. Opacity changes visibility, while the colours and the glyphs keep meaning the same thing.
17.7. Palettes
The glyphs "−", ">", "+", "!", "×" and "S" remain under every palette.
17.8. Animation
You can choose smooth, reduced, or completely static. Turning animation off removes the pulsing and the transitions but hides no information.
17.9. The big overview
The background opacity and the scale of the large window are configured separately. Hover tooltips are on by default. If the text looks small, raise the overview scale first rather than the game's system resolution.
18. Reports: how to record a problem without revealing too much
The Service and modules menu: copying, saving a report, restoring settings and links to the related network features.
18.1. When a report is genuinely useful
Save one after a reproducible event:
One random spike with no context is usually of little use.
18.2. Copying
The Copy report button places readable localised text on the clipboard. That variant is convenient to send in Telegram or paste on a forum.
18.3. Saving
The Save report button creates two local files:
Both files describe the same session and must not contradict each other.
18.4. What is worth writing next to the files
18.5. Protecting the server address
By default, the literal server address is not included in a report: a stable anonymised designation is used instead. If a tester needs the exact address, you can enable the corresponding row temporarily before saving.
18.6. What never reaches a report
There is no automatic sending to the internet. A report is created only on your command.
19. A detailed tour of the menu
This section is for readers who want to understand every visible row without starting from a console variable name.
19.1. The main page
Mode
What changes: it selects the level of the system's involvement, from fully off to permitted automation.
When to change it: Diagnostics for a first run; Ask first after you know the feature; Automatic after you have reviewed the permissions.
Default: Off.
Open network overview
Opens the large window with six tabs. Opening it changes no settings.
Overview key
Lets you assign a convenient key for opening it. The specific key in the screenshot is one user's choice, not a mandatory standard.
Disable on a local server
What changes: on a local deathmatch server the system does not work at all.
Default: Yes. Single player is always excluded, regardless of this row.
On-screen status
Opens the settings of the compact strip and text described in section 17.
19.2. Automation policy
The policy governs caution in the thresholds, not rights.
| Policy | When to choose it | What to expect |
|---|---|---|
| Cautious | Minimal intervention matters | Waits longer and demands stronger confirmation |
| Balanced | The everyday general-purpose choice | A medium reaction pace |
| Responsive | Conditions change quickly | Notices a sustained signal earlier, but gains no new rights |
The factory value is Cautious.
Minimum observation
The minimum time before a proposal is possible. The factory value is 20 seconds. Time alone is not enough: if the server sends little data, the system also waits for the required number of measurements.
Restart measurements automatically
What changes: if, during the current connection, a local setting changed that governs how data is exchanged with the server or what the collected figures mean, every earlier measurement is discarded. The system then builds a clean baseline again.
Such changes include, for example, new values of rate, of the packet exchange rates, of Ping Adaptation, of LagHax, of movement and weapon prediction, of the network port, and the explicit net_restart command. An ordinary ping fluctuation, or a command sent by the server, does not trigger an automatic restart.
What the player sees: a New measurement started card appears in the overview together with its reason, and the HUD reads NETWORK GOD | NEW MEASUREMENT with fresh progress. This is neither a network failure nor a reconnect; it is the service state of a clean re-analysis.
If the compact panel had hidden itself earlier after a successful check, such a local restart shows it again. An ordinary periodic background check with no network-setting change does not.
Why this is needed: otherwise one statistics window would mix data from before and after the change. The transition itself could then be mistaken for packet loss, a ping spike or a regression.
Default: Yes. It is worth disabling only for a deliberate comparative test, when the player intentionally wants measurements from two different modes inside one window. For ordinary play this is not recommended.
Cooldown between actions
The minimum interval between applied changes. The factory value is 30 seconds. Reducing it is worthwhile only for a deliberate test; otherwise settings may be judged during a transitional state.
19.3. Background traffic
Continuous check
What changes: during a network session, the overall background download and upload of this computer are measured at a limited rate.
When to enable it: with ping spikes, with a suspected download, or for long unobtrusive observation.
Default: No.
Application analysis
What changes: after a confirmed load, a limited search for a possible familiar program or service is performed.
When to enable it: only together with the continuous check, when you need a possible source.
Default: No.
Download threshold
The sustained incoming background rate above which a warning begins. The factory value of 1024 KiB/s is roughly 1 MiB/s.
Upload threshold
The sustained outgoing background rate. The factory value of 256 KiB/s is roughly a quarter of a MiB/s. Upload is separated because it can fill the queue of a home link quickly.
Load confirmation
How many consecutive seconds the threshold must be exceeded. The factory value is 10 seconds. Short spikes are ignored.
19.4. Permissions
Their detailed meaning is in section 12. A permission is the right to one specific temporary action, not an order to perform it right now.
19.5. Shield, Guardian and Lab
Each link leads to a menu of its own. Their manual masters are off by default. The Lab additionally requires an explicit start command even when non-zero slider values are stored.
19.6. Service
Reset observation only after conditions changed fundamentally — after switching a VPN, or after a large download finished, for example. Do not reset after every short peak: the system would then never accumulate any history.
20. Ready-made scenarios: "saw it → understood it → did it → checked it"
20.1. Everything green, no advice
Saw: the status reads OK, the link, observation and diagnosis stages are green, the plan stage is grey.
Understood: there is no active problem and no useful client-side action right now.
Did: changed nothing and kept playing.
Checked: if a subjective defect is still there, waited for it to repeat and looked at the events at exactly that moment.
20.2. The ping is high but barely moves
Saw: a high real ping, a small spread, no losses.
Understood: distance or route is likely; a random client slider will not shorten geography.
Did: compared the nearest server, the route with and without a VPN, and checked prediction; did not enable packetdup as a "ping reducer".
Checked: compared the real figures and the feel on the same map, not at random points of different servers.
20.3. The ping jumps while Steam is downloading
Saw: TRAF turned orange or red, the possible source is Steam, and the ping spread grew at the same time.
Understood: the coincidence is suspicious, but a program's name does not yet prove the cause.
Did: started "Check the impact — 30 s" and paused the download personally.
Checked: read the comparison result. If the game did not improve, did not declare Steam guilty on the strength of its name.
20.4. Other players move in jerks
Saw: an event about uneven arrival of updates, with no local freeze.
Understood: correct positions arrive unevenly; a small reserve may help the display.
Did: enabled the Jitter Shield in Auto mode, maximum 60 ms, 95%.
Checked: compared smoothness against the possible visual lag for several minutes. With a noticeable price, lowered the maximum or switched the Shield off.
20.5. The whole game freezes for a second
Saw: the entire screen stopped, the FPS possibly dropped, and the event is marked as a local freeze.
Understood: the network interval is contaminated by a computer delay; blaming the route would be dishonest.
Did: checked shader compilation, the disk, the CPU and GPU, background tasks and the performance HUD.
Checked: repeated the scene under the same graphics conditions. Did not enable an extra network buffer to cure a renderer freeze.
20.6. The server reported that my commands were lost
Saw: an exact event about outgoing commands and a proposal of limited duplication.
Understood: this is about backing up a command, not about all traffic.
Did: in Ask first mode, read the cost and applied one step.
Checked: waited for the result; with no benefit, reverted the value.
20.7. The server suddenly went silent
Saw: the Guardian shows the reason, the countdown and the recovery attempt.
Understood: the client keeps working while there is no answer from the server.
Did: allowed a limited attempt, or cancelled it with the button.
Checked: on a kick, ban, password, full server or my own disconnect, made sure the Guardian is not trying to work around the refusal.
20.8. I need to practise with a bad ping
Saw: the ordinary connection is too good for a test.
Understood: a deliberately bad but repeatable environment is needed.
Did: on a local test, started the Lab with a delay and wrote down the repeatability seed.
Checked: the purple SYNTHETIC marking is visible everywhere; after stopping, it was gone.
20.9. I need to send a problem to a tester
Saw: a repeatable event, or a contradiction between the interface and the behaviour.
Understood: one screenshot of a number may not be enough.
Did: saved the TXT and JSON, attached a video or screenshot, and described the server, the map, the mod, the time and my actions.
Checked: permitted the exact server address separately when needed, and published no password or private data.
20.10. After loading a config, collection started again
Saw: after loading a personal profile, or after changing a network setting by hand, the HUD shows New measurement and the observation progress restarted.
Understood: the config changed one or more critical local settings. The old figures no longer describe the current conditions, so they were deliberately forgotten. This is neither a broken config nor a new network problem.
Did: left Restart measurements automatically enabled and reset nothing by hand.
Checked: played another 20–30 seconds at least and waited for the new observation progress to finish.
21. Frequently asked questions
Why does collection take longer than 20 seconds?
20 seconds is only the minimum time. The system also needs a sufficient number of real measurements. On a quiet server, while spectating, or with frequent local freezes, a clean baseline takes longer to build.
Why is What to do empty?
Because there is no safe, useful action. That is normal on a healthy connection, with a high ping caused by distance, or when a problem is not yet proven.
Why does Diagnostics mode fix nothing?
By design: it only measures and explains. Manual application needs Ask first mode; permitted automation needs Automatic.
Can Network God reduce my ping?
It can help remove an unnecessary local load, choose a better path, or tune client behaviour. It cannot shorten physical distance or the delay of a remote server.
Does the system add lag of its own?
Ordinary diagnostics add no artificial delay. Delay is created deliberately only by Ping Adaptation, which you enable separately, and by an explicitly started Lab. The Jitter Shield adds a small reserve to the display of other players alone.
Is this a cheat?
No. The system reveals no hidden entities, does not aim, does not shoot, does not change server physics and does not predict an opponent's future actions. It measures the client's connection and manages permitted network settings.
Why did my LagHax or Ping Adaptation stay on after I switched Network God off?
Because those are independent features with their own manual settings. Off disables the Network God intelligent layer; it does not erase the player's choices.
The Shield is on but the buffer is 0 ms — why?
Auto mode found no unevenness that needs a reserve, or has not accumulated history yet. Zero is a safe result, not a fault.
Why is TRAF grey?
Either the continuous check is off, or the first complete measurement interval has not finished yet.
Why is Steam not detected while it is downloading?
Application analysis may be off, Windows may have withheld part of the information, the check may still be running, or the current activity did not fall into the limited snapshot. The overall load counter works independently of the program name.
Why is TRAF red while the game plays fine?
A high transfer does not always fill the queue of your particular link. Run the 30-second comparison; do not close programs blindly.
Why does the Guardian not reconnect?
An explicit disconnect, a server refusal, a local freeze, a map load, the Lab, AutoPort or an exhausted attempt limit are all possible. The reason must be visible in the overview.
Why does the Lab not start on a remote server?
It is forbidden by default. You must permit remote starting separately and confirm the warning in the current session. That barrier protects a real match from accidental impairment.
Can I keep diagnostics on through a long match?
Yes. The system is designed for continuous, unobtrusive observation. Heavy operations are not performed every frame, and the additional system analysis is enabled separately.
Should application analysis stay on permanently?
No. It is useful when a background load is confirmed and you need to guess at the source. For ordinary diagnostics it is fine to leave it off.
Does Q2PRO-X send statistics to the developers?
No. Network God has no automatic telemetry. Copying and saving a report happen only on the player's command.
Why is the server address hidden in a report?
That is privacy protection by default. When needed, the exact address can be permitted separately before saving.
Does this work in single player?
No. Single player has no remote game connection to analyse. On a local deathmatch server, the full disable and the hiding of the interface are also on by default.
What happens while watching a demo?
A demo is not a live network connection. No network actions and no automatic changes are performed. Do not use demo playback as evidence about the quality of your current internet.
Do I have to reset observation on every map change?
No. The connection lifecycle separates incompatible data by itself. A manual reset is needed after a fundamental change of conditions inside the same session, when you specifically want a new independent baseline.
Why did the panel come back after the auto-hide?
The normal reasons are a new connection, net_restart, a local change to an important network setting with automatic measurement restart enabled, or a real problem being detected. An ordinary periodic background scan and a map change inside the same connection must not bring a fully green panel back. If it appeared for none of those reasons and the overview shows no problem, save a screenshot and a report — that is a defect, not expected behaviour.
What if the text advises opening a tab that does not exist?
In the current interface the tabs are Summary, Events, What to do, Modules, Lab and Help. Save a screenshot and a report: a wrong reference is an interface defect, not your mistake.
22. Safety, honesty and the effect on performance
22.1. When the system is off
In Off mode there is no continuous collection, no diagnosis, no application search, no temporary changes and no artificial delay. Only the static OFF text of a separately enabled HUD is possible.
22.2. When diagnostics are on
Short network events are written into a bounded memory, and the conclusions are recomputed at a limited rate. Opening the overlay reads a prepared snapshot; it does not begin re-analysing every packet.
The work with Windows — the route, the network adapter and the optional application analysis — is performed outside the hot game frame. The continuous check and the application analysis are off by default; while they are off, there is no repeated system query.
22.3. The measured budget and an honest caveat
In the accepted development package, the off mode, ordinary diagnostics, traffic observation and application analysis were compared against each other. In those paired tests the average difference stayed inside a strict budget of 1% or 0.05 ms per frame, and no sustained degradation of rare heavy frames was found.
That is the result of one specific build and test scenario, not a promise of identical FPS on every computer. If you see a reproducible drop, it needs the same route, one demo scene, identical settings and a before/after report.
22.4. Fairness in online play
Every decision stays on the client side and changes neither the protocol nor the server. The server continues to decide the world, movement and hits. The modules improve diagnostics, local display or the safe delivery of permitted commands, but they never grant forbidden information.
22.5. An error must lead to a safe state
If the connection identity changed, if the data went stale, if the Lab queue broke, or if verification could not prove a benefit, the artificial intervention is removed. A new session must never inherit a temporary decision from an old server.
23. A user's reference of factory values
This section collects the settings a player sees. The console variable names are deliberately moved to the next appendix.
23.1. Core and observation
| Menu name | Default | Allowed | What it means in practice |
|---|---|---|---|
| Mode | Off | 4 modes | The level of the system's involvement |
| Policy | Cautious | 3 policies | How quickly a sign is accepted as sustained |
| Minimum observation | 20 s | 5–120 s | No action is proposed before this |
| Cooldown between actions | 30 s | 5–300 s | Protection against frequent switching |
| History depth | 180 s | 30–600 s | How many recent events the report and the feed show |
| Disable on a local server | Yes | No or Yes | Do not run the feature locally at all |
| Hide on a local server | Yes | No or Yes | Hide the overview and the HUD without necessarily stopping collection |
23.2. The big overview and the HUD
| Name | Default | Allowed | What it means in practice |
|---|---|---|---|
| Overview opacity | 0.92 | 0.2–1.0 | Background opacity of the large window |
| Overview scale | 1.0 | 0.5–2.0 | Size of the window's text and elements |
| Overview tooltips | Yes | No or Yes | An explanation of a figure on hover |
| What to show | Nothing | Strip, text or both | The style of the compact status |
| Auto-hide when healthy | Yes | No or Yes | Hide the panel after a completed green check; background scans do not bring it back |
| Hide delay | 5 s | 1–60 s | How long to keep the green result before hiding |
| Anchor | Bottom right | 9 positions | Which edge the offsets are measured from |
| Offset X | 0 | −600…600 | Horizontal correction |
| Offset Y | 0 | −400…400 | Vertical correction |
| HUD scale | 1.0 | 0.5–2.0 | Size of the strip and the text |
| HUD opacity | 0.90 | 0.2–1.0 | Visibility of the compact status |
| Orientation | Horizontal | Horizontal or vertical | A row or a column |
| Text | Short | Short or detailed | One or two lines |
| Stage labels | Yes | No or Yes | Names under the circles |
| Palette | Normal | 3 palettes | The colour scheme |
| Animation | Smooth | 3 modes | Transitions and pulsing |
23.3. Background traffic
| Name | Default | Allowed | What it means in practice |
|---|---|---|---|
| Continuous check | No | No or Yes | Overall background download and upload |
| Application analysis | No | No or Yes | A possible known program after the load is confirmed |
| Download threshold | 1024 KiB/s | 64–65536 | The sustained incoming threshold |
| Upload threshold | 256 KiB/s | 16–65536 | The sustained outgoing threshold |
| Load confirmation | 10 s | 5–60 s | Protection against alarming on a short spike |
23.4. Automation permissions
| Permission | Default | The practical limit |
|---|---|---|
| Adaptive LagHax | Yes | Only the temporary accepted adaptive mode |
| Command duplication | Yes | One limited step, on a compatible path |
| Jitter Shield | No | Only the display of other players, never above the maximum |
| AutoPort on the next connection | No | Only a one-shot check before the next connect |
| Connection Guardian | No | Only a limited, proven disconnection |
23.5. Jitter Shield
| Name | Default | Allowed | What it means in practice |
|---|---|---|---|
| Jitter Shield | No | No or Yes | The main manual switch |
| Buffer mode | Auto | Auto or fixed | Chosen from the data, or a constant number |
| Fixed buffer | 20 ms | 0–200 ms | The reserve in manual mode |
| Maximum buffer | 60 ms | 0–200 ms | The ceiling of the automatic choice |
| Spread percentile | 95% | 90, 95, 99% | How rare a spike still counts |
23.6. Connection Guardian
| Name | Default | Allowed | What it means in practice |
|---|---|---|---|
| Connection Guardian | No | No or Yes | The main manual switch |
| Silence threshold | 0, automatic | 0 or 1000–30000 ms | When silence may be treated as a broken link |
| Attempts | 3 | 1–10 | The maximum for one case |
| Initial pause | 1000 ms | 250–10000 ms | The wait before the first attempt |
23.7. Network Lab
| Name | Default | Allowed | What it means in practice |
|---|---|---|---|
| Direction | Both | Outgoing, incoming, both | Which path to spoil deliberately |
| Delay | 0 ms | 0–1000 ms | A constant addition |
| Spread | 0 ms | 0–500 ms | Unevenness |
| Spread shape | Uniform | 3 shapes | The distribution of rare peaks |
| Loss | 0% | 0–50% | The fraction of data removed |
| Loss model | Independent | Single or bursts | The structure of the losses |
| Burst length | 3 | 1–32 | The average run of losses |
| Reorder | 0% | 0–50% | The fraction delivered out of order |
| Reorder window | 2 | 2–8 | How far the reordering reaches |
| Bandwidth | 0, no limit | 0 or 8–100000 kbit/s | The artificial throughput |
| Repeatability seed | 1 | 0–2147483647 | The same sequence of random decisions |
| Allow on a real server | No | No or Yes | Permit only the confirmation request |
Appendix A. Console variables and commands
This section is not needed for ordinary play. It exists for exact reproduction, for testers, and for readers who already understand the menu. Start your configuration through the interface: it shows the ranges and the localized hints.
A.1. Core variables
| Variable | Default | Range | What it corresponds to in the menu |
|---|---|---|---|
| cl_network_god_mode | 0 | 0–3 | Mode: off, diagnostics, ask first, automatic |
| cl_network_god_policy | 0 | 0–2 | Cautious, balanced, responsive policy |
| cl_network_god_observe_sec | 20 | 5–120 | Minimum observation |
| cl_network_god_auto_rebaseline | 1 | 0 or 1 | Restart measurements after a local change to a critical network setting |
| cl_network_god_cooldown_sec | 30 | 5–300 | Cooldown between actions |
| cl_network_god_history_sec | 180 | 30–600 | History depth |
| cl_network_god_local_off | 1 | 0 or 1 | Disable completely on a local server |
| cl_network_god_overlay_local_off | 1 | 0 or 1 | Hide the interface locally |
| cl_network_god_report_include_server | 0 | 0 or 1 | Include the literal address in a report |
A.2. Overlay and HUD
| Variable | Default | Range | Purpose |
|---|---|---|---|
| cl_network_god_overlay | 0 | 0 or 1 | The stored open state of the overview |
| cl_network_god_overlay_alpha | 0.92 | 0.2–1.0 | Overview opacity |
| cl_network_god_overlay_scale | 1.0 | 0.5–2.0 | Overview scale |
| cl_network_god_overlay_hints | 1 | 0 or 1 | Hover tooltips |
| cl_network_god_overlay_x | −1 | a coordinate or −1 | Window X position; −1 means automatic |
| cl_network_god_overlay_y | −1 | a coordinate or −1 | Window Y position; −1 means automatic |
| cl_network_god_overlay_w | 0 | 0 or a width | Stored width; 0 means automatic |
| cl_network_god_overlay_h | 0 | 0 or a height | Stored height; 0 means automatic |
| cl_network_god_hud | 0 | 0–3 | Nothing, strip, text, both |
| cl_network_god_hud_auto_hide | 1 | 0 or 1 | Automatically hide a completed healthy status; background rescans do not show it again |
| cl_network_god_hud_auto_hide_sec | 5 | 1–60 s | How long the green result stays before hiding |
| cl_network_god_hud_anchor | 8 | 0–8 | One of the nine anchors |
| cl_network_god_hud_x | 0 | −600…600 | X offset |
| cl_network_god_hud_y | 0 | −400…400 | Y offset |
| cl_network_god_hud_scale | 1.0 | 0.5–2.0 | HUD scale |
| cl_network_god_hud_alpha | 0.90 | 0.2–1.0 | HUD opacity |
| cl_network_god_hud_orientation | 0 | 0 or 1 | Horizontal or vertical |
| cl_network_god_hud_text_detail | 0 | 0 or 1 | Short or detailed text |
| cl_network_god_hud_labels | 1 | 0 or 1 | Stage labels |
| cl_network_god_hud_palette | 0 | 0–2 | Normal, high contrast, colour-blind |
| cl_network_god_hud_motion | 2 | 0–2 | No animation, reduced, smooth |
A.3. Background traffic and permissions
| Variable | Default | Range | Purpose |
|---|---|---|---|
| cl_network_god_traffic_monitor | 0 | 0 or 1 | Continuous check of the overall load |
| cl_network_god_traffic_app_scan | 0 | 0 or 1 | Analysis of a possible program |
| cl_network_god_traffic_rx_kbps | 1024 | 64–65536 | Download threshold in KiB/s |
| cl_network_god_traffic_tx_kbps | 256 | 16–65536 | Upload threshold in KiB/s |
| cl_network_god_traffic_sustain_sec | 10 | 5–60 | Confirmation time |
| cl_network_god_auto_laghax | 1 | 0 or 1 | Permission for adaptive LagHax |
| cl_network_god_auto_packetdup | 1 | 0 or 1 | Permission for command duplication |
| cl_network_god_auto_jitter_shield | 0 | 0 or 1 | Permission for the Jitter Shield |
| cl_network_god_auto_autoport | 0 | 0 or 1 | Permission for AutoPort before the next connect |
| cl_network_god_auto_guardian | 0 | 0 or 1 | Permission for the Guardian |
A.4. Shield and Guardian
| Variable | Default | Range | Purpose |
|---|---|---|---|
| cl_network_god_jitter_shield | 0 | 0 or 1 | The Shield's manual master |
| cl_network_god_jitter_mode | 0 | 0 or 1 | Auto or fixed |
| cl_network_god_jitter_fixed_ms | 20 | 0–200 | The fixed buffer |
| cl_network_god_jitter_max_ms | 60 | 0–200 | The Auto maximum |
| cl_network_god_jitter_percentile | 95 | 90, 95, 99 | Sensitivity to rare spikes |
| cl_network_god_guardian | 0 | 0 or 1 | The Guardian's manual master |
| cl_network_god_guardian_silence_ms | 0 | 0 or 1000–30000 | Automatic or manual silence threshold |
| cl_network_god_guardian_attempts | 3 | 1–10 | Maximum attempts |
| cl_network_god_guardian_backoff_ms | 1000 | 250–10000 | The initial pause |
A.5. The Lab
| Variable | Default | Range | Purpose |
|---|---|---|---|
| cl_network_lab_direction | 2 | 0–2 | Outgoing, incoming, both |
| cl_network_lab_delay_ms | 0 | 0–1000 | Artificial delay |
| cl_network_lab_jitter_ms | 0 | 0–500 | Artificial spread |
| cl_network_lab_jitter_distribution | 0 | 0–2 | Spread shape |
| cl_network_lab_loss_pct | 0 | 0–50 | Loss percentage |
| cl_network_lab_loss_model | 0 | 0 or 1 | Independent or bursts |
| cl_network_lab_burst_mean | 3 | 1–32 | Average burst length |
| cl_network_lab_reorder_pct | 0 | 0–50 | Reorder percentage |
| cl_network_lab_reorder_window | 2 | 2–8 | Reorder window |
| cl_network_lab_bandwidth_kbps | 0 | 0 or 8–100000 | Artificial link limit |
| cl_network_lab_seed | 1 | 0–2147483647 | Repeatability seed |
| cl_network_lab_allow_remote | 0 | 0 or 1 | Permit the remote-start confirmation |
A.6. Commands
| Command | When to use it |
|---|---|
| network_god_toggle | Open or close the big overview |
| network_god_open | Open the overview, closing an overlapping menu correctly |
| network_god_open_modules | Open the Modules tab directly |
| network_god_info | Get the service state for a defect report |
| network_god_waitinfo | Learn the exact reason a plan is waiting or refused |
| network_god_diagnose | Refresh the prepared diagnosis with no artificial network probe |
| network_god_apply <id> | Apply one specific confirmed action |
| network_god_undo | Remove the temporary change |
| network_god_keep | Open the confirmation for saving a compatible value |
| network_god_reset_session | Restore the temporary value and clear the current session's baseline |
| network_god_report_copy | Copy the text report |
| network_god_report_save | Save the TXT and JSON files |
| network_god_traffic_check | Start the 30-second background-traffic comparison |
| network_god_hud_edit | Drag the HUD |
| network_god_hud_reset | Reset the HUD layout |
| network_god_guardian_cancel | Cancel recovery of the current disconnection |
| network_lab_start | Request that the Lab start |
| network_lab_stop | Stop the Lab safely |
| network_lab_info | Show the parameters and the synthetic counters |
The debug variables are meant for developers. Do not enable a permanent log without a tester's request: it does not improve the connection.
Appendix B. How the system is built inside — a simple explanation
This section is optional. It is here if you want to understand why the interface can trust some data and reject other data.
The extended architectural diagram of Network God. It is intended for developers; its meaning is retold in plain words below.
B.1. One centre of facts
Q2PRO-X does not create a second parallel internet client. It places short marks at the existing send and receive points: when a command was ready, when the data really left, when the answer arrived and when a new server frame appeared.
B.2. A small history and a prepared snapshot
The most recent measurements are kept in a memory of bounded size. The interface receives an already-prepared snapshot. Scrolling a tab therefore does not recompute the network statistics and does not decide which setting to change.
In engineering texts such a prepared, unchangeable set is called an *immutable snapshot*. For a player it is enough to remember: it is a photograph of the state at that moment.
B.3. The doctor and the planner
The "doctor" matches facts against rules and forms a diagnosis. A separate planner decides whether a permissible action exists. A diagnosis need not have a cure: a remote server and a geographical route are not fixed by a client slider.
B.4. The safety governor
In the source code it is called the Safety Governor. Its everyday job is simple:
B.5. One order for artificial delay
Ping Adaptation and the Network Lab can both delay data deliberately. They must not wrap one packet twice independently. The internal Transport Arbiter defines one order and one final send point. That is what lets the real path and the artificial addition be measured separately.
B.6. Separate work with Windows
Checking the route, the network adapter and a possible application is done by an infrequent background task, not inside every game frame. A late result belonging to an old connection is discarded.
B.7. Why a connection has a "generation"
After moving to a different server, old data must not be mixed with the new game. The internal generation number is a label for one specific network session. It is not shown as a user setting and requires no action.
Appendix C. The player's large glossary
Every definition answers three questions: what it is, how you notice it, and whether anything needs to be done.
ACK — acknowledgement
What it is: the answer by which the client learns that one specific transmission arrived and was accounted for.
How the player notices it: not directly; exact acknowledgements are what the measurement of the real round trip is built on.
What to do: nothing. The term is only needed to understand a report.
Automatic measurement restart
What it is: automatic removal of stale network statistics after the player changed important local conditions of online play.
How the player notices it: they see New measurement, the reason for the restart, and fresh observation progress.
What to do: nothing; let the system accumulate data again. In ordinary play, leave the option enabled.
AutoPort, or NetAutoPort
What it is: a quick test of local network-port options before connecting.
How the player notices it: before the next connection a short probe may run and the option with the best answer may be chosen.
What to do: enable it only when needed; AutoPort never starts in the middle of a match.
Baseline
What it is: a sufficient set of clean measurements taken before a setting is changed.
How the player notices it: at the start they see "collecting data" and the observation progress.
What to do: play a little and do not reset the history without a reason.
Cooldown
What it is: the minimum time from one change to the next.
How the player notices it: the plan reports that it is waiting for the cooldown to end.
What to do: wait; do not reduce it outside a deliberate test.
Cvar — console variable
What it is: a named Q2PRO-X setting that can be changed in the menu or in the console.
How the player notices it: the menu shows a human name, and the tooltip sometimes carries the technical one.
What to do: prefer the menu; the console is for exact testing.
Endpoint
What it is: the combination of network address and port a connection is established with.
How the player notices it: as the server address name:port.
What to do: check that you are connected to the expected server. The addresses of third-party programs never reach a report.
Fail-open — remove the intervention safely
What it is: on an error, stop delaying or filtering data artificially and return the ordinary path.
How the player notices it: the Lab or a temporary change stops while normal delivery continues.
What to do: save a report if this happened unexpectedly.
FPS — frames per second
What it is: the game's drawing rate, not the quality of the internet.
How the player notices it: a low FPS makes the whole screen less smooth and can look like a network jerk.
What to do: compare the event against the performance HUD and do not confuse a local freeze with ping.
Guardian — Connection Guardian
What it is: limited recovery when the server has genuinely gone silent.
How the player notices it: they see the reason, a countdown and the attempt number.
What to do: enable it for real disconnections; it does not work around a kick, a ban, a password or your own disconnect.
HUD — on-screen indicator
What it is: a small piece of text or a strip over the game image.
How the player notices it: the stage circles and a short message stay visible in the match.
What to do: set its position and size, or leave it off.
Hysteresis — protection against flicker
What it is: raising an alarm requires a stronger signal than calmly holding it and clearing it.
How the player notices it: the status does not jump between red and green on every short fluctuation.
What to do: usually nothing; wait for a sustained result.
Jitter — uneven arrival
What it is: data arrives at unequal intervals.
How the player notices it: the ping jumps, or other players move in jerks.
What to do: check background downloads, losses and local freezes; with confirmed uneven display, try the Shield.
Jitter Shield
What it is: a small time reserve for the smooth display of remote players.
How the player notices it: opponents move more evenly but may be shown a few milliseconds later.
What to do: use Auto first, cap the maximum, and compare the price against the benefit.
JSON
What it is: a structured text format convenient for programmatic analysis.
How the player notices it: it is saved next to the readable TXT report.
What to do: attach it to a tester along with the TXT; there is no need to edit it by hand.
KiB/s
What it is: kibibytes per second; one KiB is 1024 bytes.
How the player notices it: as the unit of the background download and upload thresholds.
What to do: remember that 1024 KiB/s is roughly 1 MiB/s.
LagHax
What it is: the client system that handles corrections to a predicted position.
How the player notices it: movement can feel calmer under network corrections.
What to do: configure it in its own menu; Network God may use Adaptive temporarily only with permission.
LUID
What it is: an internal Windows identifier for a network interface.
How the player notices it: not at all; the code needs it so adapters with identical names are not confused.
What to do: nothing. If the term appears in an ordinary tooltip, that tooltip is too technical.
MAD
What it is: a statistical measure of the ordinary spread around a central value, resistant to single peaks.
How the player notices it: not necessarily at all; the system uses it to tell ordinary unevenness from a spike honestly.
What to do: read the human conclusion instead of computing MAD by hand.
Median
What it is: the central value after the measurements are sorted.
How the player notices it: it survives one enormous random spike better than a plain average does.
What to do: in a detailed analysis, compare the median against the rare slow values.
Netchan
What it is: the internal part of the Quake II network protocol that tracks ordering, acknowledgements and reliable data.
How the player notices it: only through the resulting loss, reorder or backlog events.
What to do: nothing directly; this is a technical-report term.
Network Doctor
What it is: the internal logic that turns measurements into a diagnosis.
How the player notices it: the OK, Latency spikes, Loss and other explanation cards.
What to do: read the evidence and the confidence level; the Doctor itself changes no settings.
Network God
What it is: the single centre of observation, explanation and safe network actions in Q2PRO-X.
How the player notices it: the menu, the big overview, the HUD and the reports.
What to do: start with Diagnostics.
Network Lab
What it is: the deliberate creation of delay, spread, loss and other impairment.
How the player notices it: the purple SYNTHETIC label and a degradation matching the settings.
What to do: start it only for a test; stop it when you are done.
Packet
What it is: a small portion of data the client and the server exchange over the network.
How the player notices it: they never see an individual packet, but they notice the result of its delay or loss.
What to do: go by the events, not by one counter.
Packetdup — command duplication
What it is: a limited backup copy of the player's recent outgoing command.
How the player notices it: when one transmission is lost, the server can still receive the command from the next one.
What to do: apply it only with a direct sign of lost outgoing commands and an acceptable traffic price.
p95 and p99
What it is: nearly the slowest values. p95 means about 95 of 100 measurements were no worse than that boundary; p99 means 99 of 100.
How the player notices it: a large gap between the ordinary value and p95/p99 means rare strong peaks.
What to do: do not be alarmed by one peak; check whether the tail repeats and whether it matches the symptom.
Ping
What it is: the response time between client and server, usually in milliseconds.
How the player notices it: a larger ping makes the server's confirmed reaction arrive later.
What to do: look not only at the number but at its stability, at losses and at the route.
Ping Adaptation
What it is: deliberately adding delay up to a chosen target.
How the player notices it: the final ping is higher than the real one by the amount added.
What to do: use it for levelling or practice, not to reduce ping.
Prediction
What it is: the immediate local display of the expected result of your own action, before the server answers.
How the player notices it: movement and shooting look more responsive under delay.
What to do: choose compatible settings in the prediction menu; the server remains authoritative.
Requested, Effective, Observed
What it is: requested is what the player chose; effective is what is really in use right now; observed is the evidence that the branch actually ran.
How the player notices it: the Modules tab may show an enabled setting as inactive in an unsuitable session.
What to do: do not treat a stored "Yes" as proof of actual operation.
Reorder
What it is: packets arrived out of the expected order.
How the player notices it: processing delays or jerks are possible; a reorder is not a loss.
What to do: look at the frequency and the accompanying events.
Rollback — the revert
What it is: removing a temporary change and restoring the original setting.
How the player notices it: the guard stage or a message reports the revert.
What to do: read the reason; do not immediately apply the same change by hand.
RTT
What it is: the full round trip, from sending to acknowledgement.
How the player notices it: in the interface it is usually called the ping.
What to do: do not confuse it with one-way time, which cannot be known exactly without server support.
RX and TX
What it is: RX is receive, or download to the computer; TX is transmit, or upload from the computer.
How the player notices it: as two separate background-traffic rates.
What to do: watch a sustained upload especially, because it can fill a home link.
Safety Governor
What it is: the internal part that permits exactly one temporary change and owns the verification and the revert.
How the player notices it: through the apply, verify and guard stages.
What to do: nothing directly; use the Apply and Revert buttons.
Seed — repeatability seed
What it is: a number that determines the Lab's sequence of random decisions.
How the player notices it: the same seed yields a repeatable impairment scenario.
What to do: write the seed down for an honest comparison of two configurations.
Server
What it is: the remote program that defines the game world and makes the final decisions.
How the player notices it: they connect to an address and receive the map, the players and the rules.
What to do: remember that a client cannot fix an overloaded remote server.
Settle — the wait after a change
What it is: a short pause while the transitional state ends, before the comparison.
How the player notices it: the apply stage is still active although the value has already changed.
What to do: do not judge the result in the first millisecond.
Snapshot
What it is: a prepared set of the latest figures, made for the interface.
How the player notices it: the overlay opens without a repeated heavy analysis of the history.
What to do: nothing.
Synthetic
What it is: impairment created deliberately by the Lab, not by the real internet.
How the player notices it: the purple colour and the letter "S".
What to do: do not use such a report as a diagnosis of your provider.
Transport Arbiter
What it is: the internal ordering that stops Ping Adaptation and the Lab from independently delaying the same packet twice.
How the player notices it: the real and the artificial delay are displayed separately.
What to do: nothing directly.
TXT
What it is: an ordinary readable text report.
How the player notices it: it is easy to open and to send in a chat.
What to do: attach it together with the JSON after a reproducible problem.
UDP
What it is: a fast kind of network exchange, often used by games, which by itself does not guarantee delivery of every portion.
How the player notices it: not directly; the game protocol on top of it looks after the required ordering and acknowledgements.
What to do: nothing.
VPN and proxy
What it is: an intermediate route that traffic takes to the server.
How the player notices it: the ping and the stability can get better or worse depending on the route.
What to do: compare one server with and without the VPN; do not treat a VPN as a guaranteed accelerator.
Verify
What it is: the comparison window after a temporary change.
How the player notices it: the VERIFY stage and a message about the result being collected.
What to do: play under comparable conditions and wait for the conclusion.
Worker — background task
What it is: infrequent system work performed away from the hot game frame.
How the player notices it: a route or application check may show a "waiting" status for a while.
What to do: wait for the result; a late answer belonging to an old connection is discarded.
Automatic mode
What it is: the mode in which the system itself applies only the actions permitted in advance.
How the player notices it: the plan, apply and verify stages may pass with no separate press.
What to do: review the permission list first and understand the cost of every entry.
Buffer
What it is: a small reserve of data or time held before display.
How the player notices it: movement can become smoother but slightly later.
What to do: use the smallest sufficient size.
Download and upload
What it is: a download comes from the network to the computer, an upload goes from the computer to the network.
How the player notices it: Steam usually creates a download; seeding a torrent or a cloud sync can create an upload.
What to do: with a sustained load, run the comparison with the transfer paused.
Interpolation
What it is: the smooth display of a position between two points the server confirmed.
How the player notices it: other players do not move in steps from update to update.
What to do: usually nothing; the Jitter Shield only shifts the moment of that display carefully.
Final ping
What it is: the delay the client accounts for in total, including the permitted deliberate layers.
How the player notices it: it can be higher than the real ping under Ping Adaptation or the Lab.
What to do: check which addition is enabled; do not mistake the difference for a sudden provider problem.
Client
What it is: the Q2PRO-X running on your machine.
How the player notices it: it takes your input, draws the world and talks to the server.
What to do: remember that client-side improvements do not change server rules.
Local server
What it is: a server running on the same computer, or inside the current client.
How the player notices it: an almost zero network path, with no real internet between client and server.
What to do: do not use it to test your provider; Network God is disabled locally by default.
Local freeze, or stall
What it is: a long frame or a client stop caused by the CPU, the GPU, the disk, compilation or another local reason.
How the player notices it: the whole screen freezes, and sometimes the FPS drops.
What to do: look for a performance problem; the system excludes the contaminated interval from blaming the network.
Route
What it is: the chain of network nodes between you and the server.
How the player notices it: two servers at a similar distance can have a different ping and stability.
What to do: compare another server, another provider, a VPN or a proxy.
Millisecond
What it is: one thousandth of a second. 20 ms is 0.02 seconds; 100 ms is 0.1 seconds.
How the player notices it: as the unit of ping and of buffers.
What to do: judge it together with stability, not by magnitude alone.
Mod
What it is: a set of game rules and server code, such as OpenFFA or OpenTDM.
How the player notices it: the modes, the commands, the scoring and the network specifics change.
What to do: name the mod in a report; the behaviour of a feature can depend on it.
Overlay
What it is: a large window over the game, which is not ordinary console text.
How the player notices it: as the six Network God tabs.
What to do: open it at a safe moment in the match and close it with Esc.
Revert
What it is: the same as rollback: restoring a temporarily changed setting.
How the player notices it: a red guard stage, or a separate message about the revert.
What to do: read the reason and save a report if it was unexpected.
Packet loss
What it is: one portion of network data never reached the point where it was needed.
How the player notices it: a jerk, a missing update or a lost command; a single loss is sometimes unnoticeable.
What to do: look at the direction, the frequency and the bursts, not only at the overall percentage.
Loss burst
What it is: several losses in a row.
How the player notices it: usually a stronger and longer jerk than rare single losses cause.
What to do: check the home queue, Wi-Fi versus cable against the facts, and the route.
Bandwidth
What it is: how much data a link can carry per unit of time.
How the player notices it: when the queue fills, the ping grows even before the nominal speed is reached.
What to do: stop the large transfer and compare.
Protocol
What it is: the rules of exchange between client and server.
How the player notices it: some capabilities are available only on a compatible protocol path.
What to do: do not force an unsupported action; name the protocol in a report.
Real ping
What it is: the genuine path from the physical send to the exact server answer.
How the player notices it: as the Real ping line in the summary.
What to do: compare it against the final ping to see the deliberate client-side addition.
Ask first mode
What it is: the system proposes one change but waits for the player's decision.
How the player notices it: a card with an Apply button.
What to do: read the benefit, the cost, the verification and the revert before pressing.
Server frame
What it is: the next server-confirmed state of the world.
How the player notices it: other players move and the world changes on those updates.
What to do: do not confuse the server update rate with your monitor's FPS.
Connection
What it is: the current live exchange session between the client and one specific server.
How the player notices it: it begins on connect and ends on disconnect.
What to do: remember that a new server means a new independent baseline.
Diagnosis confidence
What it is: how sufficiently and how unambiguously a conclusion is supported.
How the player notices it: the caption "probably", "confident" or "certain".
What to do: do not take a strong decision on a preliminary signal.
Background traffic
What it is: network data belonging to other processes on the computer, beside the Q2PRO-X game stream.
How the player notices it: through the TRAF indicator and the load card.
What to do: confirm that it is sustained, then run the impact check.
Gateway
What it is: the first network node through which the computer reaches the home or external network — usually the router.
How the player notices it: usually not directly; its reachability helps separate a local problem from the rest of the route.
What to do: with a local problem, check the router and the connection up to it.
24. Pocket reminder
1. For a first run, choose Diagnostics.
2. Play for at least 20–30 seconds; on a quiet server collection takes longer.
3. Start with Summary, then open Events and What to do.
4. An empty plan on a healthy network is a good result.
5. Change one setting at a time.
6. A high steady ping is not the same as loss and is not cured by a random buffer.
7. The Jitter Shield touches only the display of other players.
8. A red TRAF is a reason to compare, not an automatic accusation of a program.
9. The Lab must always be marked SYNTHETIC.
10. The Guardian does not work around a kick, ban, password, full server or your own disconnect.
11. After a reproducible problem, save the TXT and the JSON.
12. When in doubt, return to Diagnostics: it changes nothing.
| In summary. The strength of Network God is not a promise to magically fix any internet connection. It looks after the player differently: it separates facts from guesses, explains the problem in understandable words, shows the cost of an action, keeps you in control, and verifies whether things really did get better. |
|---|