It was a wrong (and maybe stupid) assumption, that the config dir
(~/.yq2) is always the first element of the search path. When there's
at least one pak file in the config dir, it's added at a random
location. Work around this by probing all directories. This fixes
issue #107.
Moving the check under the "do we have the file localy" check prevents
spurious "Refusing to download a path with .." messages with some game
data. The tank commander skin is one example. This change has no
security impact since FS_LoadFile() just opens and closes the file.
While at it tighten the condition to prevent pathes with colons (this
condition is added at the server side, too) and pathes starting with
slashes and dots.
When the keypad was activated key presses were processed twice.
Once as a normal char event and once as a key event (not marked
as special). The key event to console character translation
function turned the key event into a second character...
The savegame list is generated by calling FS_FOpenFile() for each
possible savegame name. When a file handle is returned the savegame
exists, otherwise the savegame slot is empty. But FS_FOpenFile()
searches in every directory known to the VFS. If a savegame file
isn't found in $moddir but in baseq2, the file in baseq2 is opened
and a baseq2 savegame is displayed in the mods / addons savegame menu.
The fix is compromise between a clean solution and invasiveness:
- Refactor FS_FOpenFile() to include FS_FOpenFileRead(). FS_FOpenFile()
was used only to open read only files, limit its's possibilities to
do exactly that.
- Introduce a new flag "gamedir_only" to FS_FOpenFile(). When true
only the gamedir directories are searched and not other directories
like baseq2.
- Change all callers to FS_FOpenFile()s new signature.
- Use the new gamedir_only flag to limit the searchpath for savegames
to the gamedir.
This icon was supplied by Ryan as SVG. I've converted the raw SVG in a
PNG with size 512x512 (for Linux / Unix desktops) and an ICO (for
Windows). The ICO contains the levels 16x16 to 512x512 and should be
usable on high DPI screens.
The ImageMagick command to generate the ICO was:
convert quake2.png -bordercolor white -border 0 \
\( -clone 0 -resize 16x16 \) \
\( -clone 0 -resize 32x32 \) \
\( -clone 0 -resize 48x48 \) \
\( -clone 0 -resize 64x64 \) \
\( -clone 0 -resize 96x96 \) \
\( -clone 0 -resize 128x128 \) \
\( -clone 0 -resize 256x256 \) \
\( -clone 0 -resize 512x512 \) \
-delete 0 quake2.ico
This closes issue #106.
This makes it behave a little more like -basedir in Quake 1 and
fs_basepath in ioquake3.
This lets "+set basedir" take precedence over the SYSTEMDIR,
which is useful if you have the demo and full-game data installed
in different base directories to be able to test the demo for
regressions.
Without this change the conditionals at g_misc.c:199 and 381 wouldn't
trigger until level.framenum reach it's previous value, resulting in
much to few debris or gibs being thrown. This fixes#104.
Many thanks to maraakate for the analysis and the idea how to fix it.
OpenAL sources are reused in Quake2, so if a source has once been used
for a sound coming from the view entity, it'd stay relative, unless
told not to.
So now I set source's AL_SOURCE_RELATIVE to AL_TRUE or AL_FALSE in
AL_PlayChannel(), depending on the source coming from the player or not.
Thanks a lot to Tommi Teistelä for identifying the problem and pushing
me in the right direction!
This reverts commit 123e409a2e.
This commit breaks several float calculations in subtiles ways. For
example grenates drift to the left. In fact, it's another example why
I'm so hesitant to merge anything that's not a fix for a clearly
reproducable bug. This fixes#99.
should hopefully fix#93, which seemed to be caused by ^ and ` being
bound to toggleconsole in default.cfg (as shipped with Q2) *and*
in code, so it'd be called twice and cancel each other out.
It even warns if someone tries to bind those keys and includes an ugly
hack to *not* warn when it's done in default.cfg, to minimize confusion.
OGG_OpenName(): add ogg_ignoretrack0 cvar to set whether we respect
default playback behaviour when track 0 is requested to be played via
standard cd audio playback.
Submitted by: ewe2
This work was submitted by Dmitry Antipov. We stick to macros instead of
inline functions since they're in line with the rest of the code base.
This patch removes several unused functions and tranfers most of the
rest into macros.
As suggested by Daniel, use the same hack as dhewm3: The user defines a
path prefix and CMake does the rest. So this is enough to build on
Windows: cmake -G Unix\ Makefiles -DYQUAKE2LIBS=C:/MinGW/32/LIBS ..
This is a working CMake based build system for Windows:
- While this should work with system wide installed libraries, it's
still highly recommended to use the latest version of our official
Windows build environment.
- It was tested with out official build environment on Windows 7 with
32 bit and 64 bit builds
- You'll need something in the lines of this nice and short command:
cmake -G Unix\ Makefiles \
-DSDL2_LIBRARY=C:/MinGW/32/LIBS/lib/libSDL2.dll.a \
-DSDL2_INCLUDE_DIR=C:/MinGW/32/LIBS/include \
-DZLIB_INCLUDE_DIR=C:/MinGW/32/LIBS/include \
-DZLIB_LIBRARY=C:/MinGW/32/LIBS/lib/libz.a \
-DOGG_LIBRARY=C:/MinGW/32/LIBS/lib/libogg.dll.a \
-DOGG_INCLUDE_DIR=C:/MinGW/32/LIBS/include \
-DVORBIS_LIBRARY=C:/MinGW/32/LIBS/lib/libvorbis.dll.a \
-DVORBIS_INCLUDE_DIR=C:/MinGW/32/LIBS/include \
-DVORBISFILE_LIBRARY=C:/MinGW/32/LIBS/lib/libvorbisfile.dll.a \
-DVORBISENC_LIBRARY=C:/libvorbisenc.dll.a \
-DOPENAL_LIBRARY=C:/MinGW/32/LIBS/lib/libOpenAL32.dll.a \
-DOPENAL_INCLUDE_DIR=C:/MinGW/32/LIBS/include ..
Yes, forward slashes! Backslashes will break!
