Today we want to address the topic of the core War Thunder game mechanics again and debunk the most "popular" myths that players have. We want to elaborate more about the methods that we use against forbidden modifications and their possible impact on game play. This Diary may be difficult to understand, but please consider what is written most seriously.
My replay shows that an ally/enemy misses their opponent, but still kills them or my replay shows that an ally/enemy disappears, stops in the air, jerks up/down etc. Is the player cheating?
All decisions, physics and hits are calculated on the server side. The client physically cannot turn a miss into a hit or fly and turn too fast. I.e. even if this could be done on the client side, on the server everything would nonetheless be how it should be. The described situation is not uncommon in replays – in reality, the client-side replay is more or less accurate only for the player himself and everything in his immediate vicinity. Everything far away or outside of your field of view is transmitted with heavy compression (or not at all). In connection with this, when you switch to an ally in a replay, especially an ally behind you or several kilometres from you, you can see all kinds of ‘unnatural’ things – these are simply compression errors.
Could this be somehow improved?
Since many events take place in the game, and up to 200 tanks and aircraft can be encountered in a single battle, reproducing them all with identical accuracy would be extremely ineffective in terms of the connection with the user. At the same time, distant and slow-moving objects relative to the player’s point of view can be reproduced more rarely without any losses. The game tries not to reproduce invisible enemy units at all, but it does reproduce allies for the sake of general understanding of the situation. This allows you to switch to them in the replay and see strange things.
Our main advice is to use server-side replays for viewing. In them, everything is more or less just as it happened from the point of view of the server. “More or less” because server replays are also recorded with a certain loss of quality (with an average position and orientation ~10-15 times per second) to optimize the size of the replay.
There’s an invulnerable player flying a plane – I hit it, I see explosions, but it doesn’t go down.
Shots and hit effects from a rapid-firing weapon take place on the client regardless of what is happening on the server. The reason for this is that for rapid-firing weapons (like machine guns) and fast moving targets (like aircraft), the time between hits and the time of fire contact is roughly equal to, or sometimes less, than the time the server receives the information. This means that the player would lose feedback and their ability to aim and correct their fire if these effects were played only when the server received the information. Even worse, sometimes this would entirely deprive the player of feedback. The player would fly past, but never receive information that he’d hit the target, and the effects would play after the target was out of view. Alternatively, entirely false feedback could take place – in which the player believes that he is correcting his fire and hitting, but in actual fact the effects from previous hits are being shown (with a ping of 100-120ms and a small packet loss – the lag can take up to half a second).
So that the player knows when a hit has taken place on the server side, lines are drawn around the sight when hits take place. This is a server hit (registers up to 8 hits). An attentive player can notice the lag between the shots and the server messages.
If you have doubts about how it all looks on the server side, watch the server replay.
Any aircraft should go down to hits from 37mm or larger cannons. I’m shooting only cannons, the game registers the hits – the aircraft doesn’t go down. How is that possible?
Firstly, make sure that you’re talking about server hits – in the case of a successful hit, the server hit lines should appear around the sight (on the condition that you’re firing only the cannons, this means that the hit is registered on the server).
Secondly, it isn’t necessarily true that a 37mm will take out any aircraft. Take a look online at the photos of a B-17 that returned from battle with traces of a direct hit from an 88mm anti-air shell, for example.
Thirdly, the 30mm is, of course, a great shell. But if it was an armour-piercing shell (and the standard reels of many aircraft are loaded with these next to their High Explosive shells), then it might just be a 4 centimetre hole that you punched in their aircraft. And if it isn’t a hole in the engine or the pilot, the aircraft will keep on flying.
I heard that the game tweaks the damage/hit/hit effect model to balance out the players/vehicles. Is that true?
Look at the player statistics. The game does nothing to ‘balance out’ the players apart from selecting equal players insofar as this is possible.
Moreover, this would be practically impossible and extremely difficult to calculate, because the trajectory of each bullet is calculated at every moment in time and to do something like this would require each bullet also containing a bunch of additional information which would then have to be analyzed. In reality, the game engine calculates hundreds and thousands of shots in the air in every frame of every battle and naturally, the less superfluous information, the faster this is (this will be clear to programmers and engineers – cache optimization and SIMD calculation).
Again, if you have any doubts, check out the server replays. As a rule, they’ll dispel all your doubts or allow you to identify an error in the damage model of a specific vehicle, or, as was the case very recently in 126.96.36.199, the shell movement calculation simulator in certain special cases (the main error was fixed very quickly, but only fully corrected a week later – and all thanks to server replays and reports).
I saw a shell go through hills and obstacles in the kill camera. That’s impossible!
The kill camera shows a rather simplified story. The only data fetched from the server is who shot the shell, how it was shot, the type of shell, at which point and at which angle it hit the armour, the damage it did and the type of the damage. In the case of a ricochet, data is also fetched about where the shell flew after the ricochet. Accordingly, in the animation the shell flies directly between the point it was released from and the point it hit – in reality, the trajectory always has a ballistic pattern.
In the killcamera/hitcamera, I saw an HE fragmentation shell make only a few fragments. That’s wrong, there should be dozens!
All the fragments and effects caused by the shell explosion that don’t deal damage to modules are not reproduced or drawn anywhere – not only to economize on traffic and computing power, but also so that the player can see exactly what happens on the damage camera.
I saw a cheater: a player firing with incredible accuracy, seeing everything in markerless mode, etc.
In markerless mode, players don’t really play for the feeling of competitiveness, fully honest gameplay or teamplay, but for the sake of atmospheric immersion, deliberately choosing a mode in which less information is available to them than could be so that they can feel like they’re in a World War II battle or close to it. Of course, even then they tried to know as much as possible and have a good idea of what was going on around them, but the technical options for receiving (radar, FLIR) and presenting (screens, HUDs) this information were as a rule severely limited.
However, in markerless modes, various forbidden client modifications can be used by dishonest, ill-intentioned or simply desperate players, since the client in these modes always has more information than is intended to be presented to the player.
So to start with, check the server-side replay. Bear in mind that the player may be playing with different quality settings or a different screen resolution, or correct and aim their fire with the help of other players if you don’t change your position.
Just in case, we’ll mention again that in War Thunder, it’s impossible to make ‘classic’ cheats like those for single-player games and games with client-side processing logic, such as: immortality/invulnerability, speedhacks, instakill, superpowerful weaponry, altered physics model characteristics for you or other players, etc. The so-called wallhack/maphack is possible to a limited extent (in markerless modes) along with automated aiming. But these can never be used in a game with others.
A cheater can use only that which is given to the game client by the server, and only using the control capabilities available to all players.
We’ll list all the main types of client modifications that can be used to gain an advantage, and how a non-expert can identify them:
- Turning off the display of trees/buildings/landscape (everything apart from the crown of trees and bushes, which either can’t be shot through, trigger a shell or have a chance to damage/divert it etc., so cheaters will generally modify the client to disable tree drawing in practice)
- Visual changes to vehicle models, drawing a marker above/around an enemy Since the client has the player’s tank, and its type and position is known, the game data can be changed in such a way that enemy vehicles are drawn, for example, with a bright color so that they can be seen through obstacles. Alternatively, using the capabilities of Windows, a process can be linked to the game to learn this information and draw a marker above the screen / create a ‘radar’ and other interface elements so familiar to our players based on the experience of playing in marker modes.
- Autoaim means automatically aiming the barrel/turret/aircraft at the target, calculating the ballistic sight and so on – there’s a separate point on this below.
You can spot a player who is using modifications to help see that which is not visible without modifications by their behavior. In the server replay, it is clear in the ‘player’ view where the player is looking, where they are aiming etc. You can also see all the other players. Through this, it is easy to notice when a cheater is ‘looking’ through houses and trees, i.e. following a moving enemy that should be invisible to the cheater.
If you are absolutely certain that a player is using unsanctioned modifications, report them on our website. Don’t make a video on YouTube or tweet about it, this doesn’t do much good, if any, since such ‘reports’ may be simply an incorrect interpretation (for example, if the client-side replay is used) or a manipulation with the aim of getting rid a player someone doesn’t like. In addition, it doesn’t necessarily get seen by the people who deal with cheaters. Use a special weapon that really helps you in this fight.
If you want to tell us about any forbidden modification or share anything else that you feel is important information about the types and methods of unfair gameplay, write to our tech support department or on our forum to the moderators or assistants (they will deliver your message to where it needs to go, and make sure it isn’t forgotten about).
Apart from reports?
Apart from reports, we use several different methods of automatically ‘catching’ forbidden modifications on the server side. But the majority of these methods don’t work with 100% reliability. In addition, there’s always the chance that new modifications might crop up.
The most reliable methods of fighting against cheaters are these two main ones:
- Consciousness and reports from honest players who defend the principles of fair game.
- Modes with markers (used in the main competition formats and in all aircraft modes) – the options for forbidden modifications and their influence on gameplay are significantly reduced.
A little extra about game design and its influence on the fight against forbidden modifications and cheaters:
If the server doesn’t transfer the data, then there’s no possibility of showing said data. Unfortunately, even if it were possible to calculate every frame for every player, this would still lead to an unacceptable level of lag, and that means tanks would start appearing from out of thin air. For this reason, the game must transfer opposing vehicles a little earlier than the player can see them. Nonetheless, to improve overall game quality and make life harder for cheaters, we’ve decided to change the current detection system to make it more aggressive at hiding models that shouldn’t be seen
Firstly, we reduced the parameters in the detection system that were the most ‘vulnerable’ and gave the highest effect from unsanctioned use through forbidden modifications. One of these parameters was “Unconditional detection distance”, i.e. the radius in which the client always has information about the position of all vehicles, including enemy vehicles. Before patch 1.65, this parameter was set quite high – roughly 360 metres. This value was chosen to ensure a minimum of situations in which enemy tanks suddenly appear in your field of view after a sharp camera rotation. We’ve improved the algorithm that checks the visibility at the edge of the player’s field of view, which allowed us to significantly improve this parameter and at the same time draw the enemy tank model as quickly as possible in the case of a sharp camera rotation by the player. In patch 1.65, this radius (for a maximum level crew) is reduced by approximately 5 times (this value may change again before the patch is released to the main server).
We’ve also reduced the maximum distance of “Detection in direction of view” in third person by 2 times (from 2km to 1200m). The old value allowed cheaters to gain information about the location of enemies within the third-person camera field of view practically always and on all maps, without having to switch to the optical sight or binoculars. Considering that checking the visibility in third person view is done from the point the camera is observing, which can be somewhat higher than the height of the tank itself, this also provided a noticeable advantage when using forbidden modifications.
At the same time, the distance at which a marker appears in modes with markers above enemies has been slightly decreased – from 1200 to 900 m.
Another parameter in the visibility settings that could give an advantage to cheaters are the detection distance multipliers when using binoculars and sights. For binoculars, this parameter was set at 2.6, meaning if we multiply this by 2 km, we get a value which covered more than the size of most in-game maps even diagonally. For the sight, it was 2.4. Since the speed of moving the field of view in the binoculars is not limited by the rotational speed of the turret, this also potentially gave an advantage, so we’ve reduced this multiplier quite significantly from 2.6 to 1.4.
The multiplier for the detection distance when using the sight has also been changed, but not as severely, from 2.4 to 2. This is because its movement speed is limited by the rotation of the turret or gun, and the point at which the visibility check takes place is the same point as the sight.
We’ll touch separately on two parameters; the detection distance multiplier of moving and shooting enemies. If one of these parameters was reduced, the distance multiplier for moving targets (from 1.5 to 1.1), then the other was, on the contrary, increased. With this change, we’re trying to provide more options for outflanking opponents and in general increasing the value of movement, at the same time reducing the advantages that can be given by using forbidden client modifications when playing the game in ‘sniper’ style – i.e. firing from great distances where ‘wallhack’ can easily detect targets. Such players will reveal themselves over a greater distance than players that move around the map more.
Another rather important change directed at increasing the security of markerless mode against the use of forbidden modifications will be a more detailed calculation of vegetation for layering visibility, with consideration for the shape of the crowns of trees and subsequent cover of certain crowns by others. This also makes it impossible to detect players behind thick vegetation even using such modifications, since the game client will have no information about a tank hidden in the forest.
I saw a sight twitching in a replay – the player was using an aimbot, a player can’t aim like that.
The positions of the aiming cursor are sent to the server several times per second (more than ten). This makes for significantly less fluid movement than in the client. This makes any movement of the sight circle look robotic and ‘twitchy’. On the whole, such behavior actually can’t be a sign of an external program manipulating the sight – cheaters have no problem emulating fluid circle movement, this does not affect it at all. After all, the gun still has to move at a finite speed.
I know there’s an aimbot that helps players kill other players. How do I identify a player using such modifications? How effective are they?
As for how effective these modifications are, that depends on the game mode.
Since the game client has information about the vehicle type and its position in order to draw the tank model, then in RB and SB tank modes (where there are no markers and the distance to the target is not displayed), aimbots can only help players that find enemies. In addition, at great firing distances the primitive ballistic calculator allows you to set a rough vertical barrel angle to approximately hit the target – i.e. you (the accuracy of the angle depends on many factors, in part whether you are moving etc.). At the same time, such a bot does not aim at vulnerable spots, since this is a complex task that a robot solves relatively poorly, but at great distances and with a high-angle trajectory, the shell has a chance of hitting the roof, where many tanks have weak armour. At short distances (300-500 metres or less) this rarely works well.
A characteristic sign of such an aimbot is firing without any ‘aiming’ at the enemy or measuring the aiming angle, firing at covered positions over a great distance, no evidence of searching for other angles after a miss or a hit.
In AB tank mode, aimbots don’t provide significant advantages over the ordinary aiming function and the ballistic computer (‘green cross’).
In aircraft modes, an aimbot is relatively useless – it only helps to fire at a relatively motionless (non-maneuvering) target, and when used with an extremely maneuverable aircraft (biplane). In most cases, an aimbot is significantly worse than a player in terms of figuring out where and how the enemy aircraft is going to fly (the lead compensation marker shows only where the aircraft will be if it doesn’t maneuver), and more importantly, it is incapable of properly setting up a maneuver for a good run at the target, taking into account its own aircraft’s energy, the opponent’s energy, etc.
Based on analyzed statistics, aimbots used in aircraft modes have lower than average scores (for this reason, punishments against aimbot users used to be relatively slight – from two weeks to a month for the first violation. They were already limiting their play without extra punishment from us).
In simulator modes, aimbots are completely useless on planes.
‘Autofire’ is a bot that presses the fire button when the sight aligns with the target in War Thunder. As far as we know, this is not used, since it causes more harm than good in all game modes. As for how to detect it – it’s obvious from the description of its action, but in practice a player using it makes their job harder rather than easier.
What do you do with cheaters?
We ban them. Currently the ban is permanent, as a rule. We don’t publish lists of bans, to avoid witch hunts. At the same time, since recently banned users have had the banned’ status on the site, so if you suspect/suspected someone, you can check their status.