This is, perhaps, the very first questions, about which it would be desirable to talk, because these points are important, and learning to play, having changed settings later, can be problematic.
The mod itself: latest version at the moment Newer version availability you can check here Installation is no different from the usual mod for Q3.
To earn autodownloading maps it is necessary to change dl_source to "http://ws.q3df.org/getpk3bymapname.php/%m" and set cl_allowDownload 0.
We will consider the points regarding config.
About binds of movement and switching weapons nothing certain can be advised, as it works well in almost any form and therefore gets done as it is convenient to you.
Unless cg_autoswitch can be immediately put in a value of 1 or 2, as this feature is useful for very many maps (though there are a few ill planned maps, where it should be disabled, but there are no much of these ones).
Graphics settings are not critical in the case if your machine keeps stable 125 fps (r_picmip 0 for teh win); if your computer is weak, then it makes sense to increase the FPS, dropping graphics at a worse quality.
Also it is worth to disable vertical sync, as it provides notable delay of video response. Might be turned on in the driver by default.
Accepted standard for a shot and jump - left and right mouse buttons, respectively. Of course, you can bind these important actions in another way, but then it is very likely to have problems with strafe, roketjumps and plasmaclimb.
Another important Defrag bind - rocketjump script.
bind key "+moveup;+attack"
This is the only non-critical script, and it is used by many players; you can play without it, you can use it - the decision belongs to you and the administration of the competition/servers. Incidentally, it may be difficult to learn to play without a script, if it is banned.
Mouse preferences.
Sensitivity - a difficult question, because any movement are necessary - and fast, and accurate. Ballance is needed.
The most simple and universal way to measure sensitivity - in centimeters of mouse movement, required to rotate on 360 degrees in the game.
Take a ruler and measure :D
The method avoids depending on the software and the mouse resolution.
Optimal, in my opinion, the values are between 8 and 25 centimeters.
If you want to calculate the value of sensitivity, proceeding from centimeters, or vice versa, use the following formula: sens = 41563 / (dpi * sm), respectively sm = 41563 / (dpi * sens).
This is suitable provided that m_pitch and m_yaw have the default value of 0.022 and the system mouse sensitivity multiplier is 1.
To disable system influence on mouse input in dfengine and similar engines put in_mouse 3.
Acceleration - cl_mouseaccel - good enough in the value 0; in deathmatch, where you need a combination of sharp turns and precise aiming, acceleration works well; in defrag linear relationship between the movement of the mouse across the pad and change of the direction of look in q3 works better, since precision is required in every movement.
However, there are examples of players who skillfully act with accel, even the big one. Certainly we can say that a small value of accel does not much harm.
Input filtering - m_filter - uncritical parameter, but it is more convenient to play at a high sensitivity with a value of 1. This enables viewing direction values interpolation; introduces additional average values between ones, that were really entered by means of a mouse.
Physics settings.
I've got to say that, as in any other sport, is logical that players should have equal opportunities.
So there are regulated settings of physics, and and the demos which have been recorded at these settings are legitimate only.
Variables actually responsible for physics are set by default:
sv_cheats 0
timescale 1
g_speed 320
g_gravity 800
g_knockback 1000
The following variables initially weren't intended for physics control:
sv_fps 125
com_maxfps 125
g_synchronousClients 1
pmove_fixed 0
However, such dependence was found.
Therefore, for clarity, I'll write more about them.
sv_fps - Server frame rate - ie the frequency with which physics is computed.
The matter is that each frame in q3 is a calculation, based on the just entered data.
Ie you enter data (keypresses, the mouse position), they are counted, the condition of the player changes.
And process runs so many times per second, how many FPS setting is.
Why value 125 is chosen?
When calculating each frame comes to rounding velocity vectors to integers. In q3, unlike conventional methods, the rounding occurs by mathematical rules, i.e. not always in the smaller side, but depending on the number after the decimal point.
In this situation there is an opportunity to force errors of rounding to accumulate in the big party.
That is why the number 125 is selected as one of a number of values at which the behavior of physics is the most favorable for higher jumps and better acceleration performance.
com_maxfps 125 - is a restriction of the maximum value of video and poll of input frequencies; is chosen equal to fps value for lack of divergences in physics and video calculation with input on good computers.
g_synchronousClients - this parameter is responsible for client-server synchronization.
Value 0: The server uses the FPS of the video from the client to determine the frequency calculation, in which case sv_fps plays no role, the frequency starts to match the frequency of the video, and physics depends on the actual fps.
Value 1: The frequency is determined by sv_fps, it is possible to make the physics behave most favorably, and that we need.
pmove_fixed - when you turn this function, stable 125fps calculation mode is emulated.
This feature is specifically designed to run on slower machines with g_synchronousClients 0, ie it disables usage of the FPS value from the client to determine the calculation frequency.
g_synchronousClients mode 0 is required for online play, as at value 1 there is a delay between the data input and the response of the video, depending on the ping.
However mode pmove_fixed 1 works imperfectly, there may be bugs with triggers and weapons at low fps, so for listen (offline) defrag server pmove is not used. The actual difference of a mode with pmove is notable with the weapons - in the small range of sharp angles to surfaces feedback slightly differs.
As for online games, there should be the following values for the reasons explained above.
g_synchronousClients 0
pmove_fixed 1
pmove_msec 8
Last variable defines what fps mode is emulated pmove mode.
Value is specified in milliseconds and determines frame length.
1000 msec/8msec = 125Hz - which is what we needed.
It is likely that you do not understand something of these explanations (or perhaps nothing at all, that is even more likely =))), but do not despair.
It is enough to remember that g_synchronousClients 0 + pmove_fixed 1 is almost the same as g_synchronousClients 1 + pmove_fixed 0, first used online, the second - offline.
Connection settings are also relevant for online - influence physics with the weapon and comfortable perception of game
rate 25000
snaps 125
cl_maxpackets 125
To a heap a question of why all legitimate records in defrag share totally on 0.008.
That happens so because we have 125 cycles per second, and respectively the time step is 8 milliseconds (there are, however, maps-exceptions from this rule where result plus 0.004 is multiple of 0.008; that occurs if the player respawns in the timer or teleports into it).
Well, the physics stuff is sorted out, let's go further.
Bind for restart.
On defrag maps it is necessary to come back somehow to start after the track is passed or suddenly there was a wish to start anew.
It is possible to use for this purpose the kill command, binded to a comfortable key.
Alternative, suitable only for playing offline - map_restart 0
For convenient demos viewing you might want to bind keys to change the playback speed; often it is necessary to rewind or look at something closely.
Three values of timescale is enough, for example 0.2, 1 and 5, although you can use a more gradual change.
Statistics display.
There is nothing concrete to advise, statistics, useful for one player, can appear excess garbage on the screen for another.
Therefore I explain how to activate them, and you decide which ones you need.
df_chs0_Draw - displays keyspresses which are stored in demos, starting with the defrag version 1.7.
Very useful for understanding how a particular trick is made.
1 - enables for demos and during the game.
2 - only for demos.
df_chs1_Draw and df_chs2_Draw - two blocks of statistics, each has 8 slots.
Enabling respectively df_chs1_Info1-8 № and df_chs2_Info1-8 №, where № - numbers of stats listed in DeFRaG\DOCS\list-[CHS-Info].txt, and can be output to the console with command \info
It's possible to define the mapping of more than one info by each slot: enable df_chs1(2)_EnableCombos and enter wanted numbers in the information unit, separated by whitespaces.
For many stats it is possible to show digits after decimal point by adding to the stat number the number of digits equal to the required number of decimal places.
There is an alternative derivation of these infos through say and echo commands, which will have no impact on FPS and will not clog the screen.
It is very convenient to display the history of jumps velocity, accels, etc.
Format is: bind key "varcommand say(echo) $chsinfo(№)"
Savepos.
Very useful feature of defrag for tricks and practicing of df maps; allows to recover the stored position and speed of the player.
Therefore there is nothing surprising that almost all trick demos are recorded with sv_cheats 1; seyvpoz operates only in this mode.
Changing of significant variables is displayed via console, so no one will cheat with them, but returning to the starting position zillion times can bother.
Following settings:
seta saveposname variablename - to establish position preservation in the variable "variablename"
bind key "savepos" - save the current position
bind anotherkey "vstr variablename" - restore the saved position
For those who can not wait to play, ready to offer example config with the above and other useful settings.
It also includes console filter of excessive information (for mappers and other developers it is not excessive).
How to configure a non-standard video resolution (for example for widescreen monitor)
r_mode -1
r_customwidth - width
r_customheight - height
vid_restart
cg_fov in Q3 tied to the horizontal resolution, so when you go to wide format, old fov is small.
Probably, it is possible to calculate equivalent fov somehow, but there is an easier way: take a screenshot (command screenshot) with old settings, then without moving in game, change the settings on a new meaning and pick cg_fov so that vertically it was visible exactly the same as in the screenshot.
More utility: private messages on an online server.
\tell player_id message
Check id with \info players
Actually is a Q3 feature, but only defrag has info players.
Map may have several spawns; how to appear always on the necessary one:
\respawnpoint set (near it)
\respawnpoint clear - reset bind to spawn
And finally, a bit about the equipment.
As for hard, the more powerful - the better, it's obvious.
But as the mouse, you can learn to play well on almost any, better, if it has an ergonomic shape, even better if it is optical/laser.
Then there is a chance to learn to play not only well, but excellently with minimal losses for real life.
Of course, you can have fun in Defrag without following all these tips: this is just my opinion on these issues.
