Fix a hole in the launcher script; changelog update.
Expired bans aren't correctly displayed.
Fix a possible hang in string token replacement.
Changelog update.
Add reload sounds for human weapons
Merge branch 'master' into reloadsounds
Fix crash in which we try to memset() a NULL pointer.

CG_ClearLerpFrame was not updated to deal with the separation of refSkeleton struct from the centity struct. If the model is an md3 model and not an md5 model, the skeleton is unused and thus does no harm.
Update README.txt

add missing dependencies
Prevent a crash when an md5 death animation is not loaded.

This should not be necessary as in release conditions, there will always be a death animation md5anim file available; however, when testing, that might not always be the case. This will allow for a better testing experience.
Merge branch 'reloadsounds'
Merge pull request #107 from tshirtman/patch-1

Update README.txt
Allow for the MD5 human to use separate backward animations. Do not merely reverse the forward animations.
Use one file for fonts for both renderers.

The code is identical save for 2 lines (one for the respective renderer's include file and one for shader registration). This method is cleaner because it uses and existing define already passed for the GL3 renderer instead of making a new define. Further, it cuts down unnecessary files.
Add Gireen's New HUD to the repo to replace the old trem HUD
Add support for md3 weapon animations.
The frames for each animation must be specified in an animation.cfg in the same order as the weaponAnimNumber_t.
This commit adds:
 - A function to parse the animation.cfg
 - Fixes a logic error that assumes all weapon animations are md5 weapon animations, preventing md3 weapon animations from working.
remove the URL functionality, which is a security hole that allows "rm -rf /"

the engine permits modules to write files to the game directory. it also provides /setenv and /openurl.

as part of /setenv, CL_Setenv_f() attempts to use putenv(), however, it does so WRONGly: it hands a stack-based variable to putenv(), meaning that the variable's memory is likely to be garbled by stack operations later. Sys_SetEnv() is not used.

as part of /openurl, Sys_OpenUrl() launches the given URL in a browser. if the BROWSER environment variable is set, then the function tries to run the program specified by BROWSER, as the browser. as a fallback mechanism, other common browser names are also tried. Sys_OpenUrl() is called by CL_OpenUrl_f(). Sys_OpenUrl() uses Sys_Fork() on UNIX-like systems.

Sys_Fork() takes a program path, tries to set the program's executable bit on the filesystem, and then tries to run the program.

an auto-downloaded ui module can act maliciously to execute "rm -rf /", or any other shell script desired. to do this (the description is given for only UNIX-like systems): first, the module should write the desired shell script to a newly created file; the system-path of the file can be determined by examining the fs_homepath and fs_game cvars. using /setenv, the module should then set the BROWSER environment variable to the system-path of the file. finally, the module can launch the "newly installed browser" using /openurl (with an arbitrary argument), which will set the executable bit of the said shell script file, and the script will be executed.

there is actually some additional trickery required to make these steps work. the bug in /setenv, described above, requires the ui module to call /setenv using EXEC_NOW, while being deep in the stack (for example, a sequence of nested, recursive function calls can be used), to place the said stack variable where its memory will likely survive. there is actually another bug in /setenv, which forces a space character to be appended to the given value, and thus the module has to choose, for the shell script, a file name that has a space at the end.

the engine also has additional support for opening a URL in a browser, in the form of a ui module callback.

on UNIX-like systems, the intended behavior is the following: the ui module open-URL callback translates to an invocation of the user-supplied "openurl.sh" script, if the script is found to be executable; the following directories are searched, in order: the current working directory, the homepath, and the basepath. excluding bugs and bad configurations on the user's side, the engine cannot place an openurl.sh script to these places. however, if such a script is placed by the user, the ui module can execute shell code as part of the system call to the openurl.sh script, with the use of shell-special characters. however, due to a bug, the callback translates to roughly a no-op (see the UNIX-like version of Sys_StartProcess() below).

on Windows, the callback translates to a system call. to exploit this, batch files can be written and then executed.

(note: Sys_OpenURL is not to be confused with Sys_OpenUrl, and vice versa.)

as part of the open-URL callback functionality, the Sys_OpenURL() implements the said intended behaviors. on UNIX-like systems, the subfunctions used are Sys_StartProcess() and Sys_DoStartProcess(). this Sys_StartProcess(), in the only way it is ever invoked, stores a command line in the static exit_cmdline string, and then shuts down the engine; nothing else uses exit_cmdline. thus, Sys_StartProcess() does not work at all on UNIX-like systems. the Windows version of Sys_StartProcess() is unused. Sys_OpenURL() is called by CL_OpenURL().

yet another obscure feature allows the server to direct a client to any URL, when the client tries to download a file from the server.

the feature is hit when DL_FLAG_URL is used by the server (although, as of recent times, the server never does so). when used, the client calls Sys_OpenURL() with the server-specified URL.

to close this security hole, the full set of the URL opening functionalities, along with the buggy environment variable setting functionality, is removed. such functionalities don't belong in the game engine anyway. in historic times, their existence and lack of security was permissible only because the engine only supported native libraries as modules, which is an all-encompassing security hole. the following are removed: /setenv, /openurl, CL_Setenv_f(), Sys_SetEnv(), Q_putenv(), CL_OpenUrl_f(), CL_OpenUrl(), CL_OpenURL(), Sys_OpenUrl(), Sys_OpenURL(), trap_openURL(), DL_FLAG_URL, Sys_Fork(), Sys_StartProcess(), Sys_DoStartProcess(), exit_cmdline, and some code in CL_ParseDownload().

even with this security hole fixed, it is estimated that this project still has supercardinally infinite open security holes.

the UI_OPENURL constant, etc. are actually not removed, to retain the ABI. these are to be removed later.
remove some remaining code related to temporary paths and PIDs

this is a prologue to the "Remove insecure pid file code. (ref. CVE-2012-3345)" commit
remove/simplify a bunch of path-related functions

installPath is only written, by Sys_SetDefaultInstallPath(), and is never read. these can be removed. the only use of Sys_SetDefaultInstallPath() is ``Sys_SetDefaultInstallPath( DEFAULT_BASEDIR );'', which is to be removed. the DEFAULT_BASEDIR macro can actually resolve to calls to Sys_StripAppBundle() and Sys_BinaryPath(), but these calls do not have side-effects. DEFAULT_BASEDIR and Sys_StripAppBundle() are left unused, and thus can also be removed. The only use of Sys_BinaryPath() can be inlined.

Sys_SetDefaultLibPath() is not used, and thus libPath always remains the empty string. these can be removed, and Sys_DefaultLibPath() can be simplified. Sys_DefaultBasePath() is a bogus, droppable declaration.

after the above steps, no functions of the form Sys_SetDefault<which>Path() exist. it makes sense to have a Sys_Default<which>Path() function for each <which> in {Base, Home, Lib, App}. however, Sys_SetDefaultBasePath() is instead called Sys_SetDefaultInstallPath(). the latter is renamed to the former.
remove some remnants of dushbag's backdoors
remove Sys_Chmod()

this function is unused, and doesn't belong to the engine anyway