add missing "\n"s to some Printf()-like calls (in Rend2)
drop erroneous "\n"s from some Error()-like calls (in Rend2)
drop erroneous "\n" from a Com_Error() call (in vm_sparc.c)
In CTF, rail or plasma gun/ammo were not predicted for pickup depending on what team player is on. The rail and plasma values are the same as PW_REDFLAG and PW_BLUEFLAG.
In 1FCTF, only neutral flag, BFG, and BFG ammo were predicted for pickup. WP_BFG is equal to PW_NEUTRALFLAG.
[As with GNU/kFreeBSD, it's treated as "Linux": all three use the GNU libc
and runtime linker, which is mostly what matters for ioquake3. -smcv]
Bug-Debian: http://bugs.debian.org/679330
Reviewed-by: Simon McVittie <smcv@debian.org>
As usual, the order of precedence is: user override, pkg-config,
or assume they're in standard locations.
In particular, Opus isn't in the default search path on Debian.
We didn't add CURL_CFLAGS to CLIENT_CFLAGS on all platforms, and didn't
use CURL_LIBS at all, so if "pkg-config --libs" returned "-L... -lcurl"
or even "/.../libcurl.a", it wouldn't work.
This lets us find a library in a non-standard library directory
(via -L in the pkg-config metadata), and allows overrides similar to
the Autoconf convention, e.g.
make FREETYPE_CFLAGS=-I/opt/freetype/include \
FREETYPE_LIBS="-L/opt/freetype/lib -lfreetype"
If pkg-config didn't work, assume that Freetype is in the default
location.
Linux distributions that want to link dependencies externally will
generally want to link (almost) every dependency externally; similarly,
minimal-dependency builds that want to use the embedded copies of
dependencies will generally want to do so for (almost) every dependency.
Make it easier to choose one of those by setting USE_INTERNAL_LIBS=0
or USE_INTERNAL_LIBS=1, respectively.
The default can still be overridden per-dependency; for instance,
"make USE_INTERNAL_LIBS=0 USE_INTERNAL_OPUS=1" will use the system
version of everything except Opus.
[The lcc source] overrides the libc memmove() with its own implementation,
but that implementation fails to follow the specification. In particular,
it returns NULL rather than memmove()'s first parameter.
GCC now optimizes based on this aspect of the specification, so things go
wrong at runtime.
[Text & patch from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56881#c8]
Fix setting CVAR_VM_CREATED flag on cvars created using set[asu] commands (including archived cvars from cfg) and trap_Cvar_Set.
trap_Cvar_Register called Cvar_Get which cleared CVAR_USER_CREATED flag, but CVAR_VM_CREATED wasn't set because the cvar already existed.
