It makes little sense to centralise the definitions for things like
Steam, GoG, etc.. These paths are only useful in the case where the user
has derived the data from such a store, has installed ioq3 in a separate
location, and we want it do be able to find said data. If a derivative
project has deployed (binaries and all) on e.g. Steam then for them
fs_basepath will already be correct, and fs_steampath is not useful.
Sys_BinaryPathRelative takes a parameter which is path concatenated with
Sys_BinaryPath, and resolved to a canonical path. The intended use case
is to facilitate the situation where you want the game data directory to
exist outside the same directory in which the binary lives, but relative
to it. More specifically, if you want to distriute multiple binaries for
different architectures, in the same tree, this allows for a means of
having said binaries in architecture subdirectories, with a shared data
directory, e.g.:
ioq3/x86/ioquake3.exe etc.
ioq3/x86_64/ioquake3.exe etc.
ioq3/baseq3/pak0.pk3 etc.
Here, when building you would define DEFAULT_RELATIVE_BASEDIR=".." by
appending it to the build system CFLAGS, and then the executables will
by default look in their parent directory for the data.
FARPROC is defined with an empty parameter list, which newer versions of GCC consider equivalent to (void). Compilation fails when qSHGetFolderPath gets called with arguments.
There is a copy to clipboard option but the error itself wasn't printed
to the console so it wasn't copied to the clipboard.
Unix-like platforms print it to the console so it's written in
crashlog.txt.
Newer mingw-w64 changed default Windows version compatibility.
Need to specify older behavior for EnumProcesses() to avoid "missing
K32EnumProcesses()" runtime error.
The mod list on Windows would search the root of the drive if
fs_basepath, fs_homepath, fs_steampath, or fs_gogpath are blank ("")
(which is usually the case).
The issue is in the low-level Sys_ListFiles() but it only affects the
mod menu, on Windows. It cannot be abused by console commands to
list system files outside of the virtual filesystem.
---
If a directory at the root of the drive of the working directory
contained a pk3 file, the directory was listed in the mods menu. The
virtual filesystem doesn't add blank directory names to the search path
so it cannot load mods from the drive root. (Unless of course you set a
fs_*path cvar to "C:\".)
Sys_ListFiles() with blank directory caused Windows to use "\*" for the
search path and "\" prefix means root of drive. Unix opendir("") failed
so nothing was listed for blank directory.
Sys_ListFilteredFiles() with blank directory _and_ specifying subdirs
could access any directory (on Windows and Unix-like) but no code uses
this or makes it accessible.
These functions are only used for initializing the virtual filesystem
and listing mods. They are not accessible by anything else such as a
console command. Only the mods menu, on Windows, is affected.
Unlike the Steam and GOG support I'm not doing a registry search as I don't see anything in the registry that would show us the path. If we find more official ways to search for it later we can address that, in the meantime the path is just hardcoded to where it's installed by default.
Windows API ignores all trailing spaces and periods which can get around
Quake 3 file system restrictions. QVM opening 'uix86.dll.' actually
opens 'uix86.dll' which allows QVM to write native code.
This is done in the low-level Sys_FOpen() instead of the function
directly used by VMs ( FS_FOpenFileByMode() ) in case there are engine
commands now or in the future that can read or write arbitrary files.
Reported by Noah Metzger (Chomenor).
Windows' Sys_ListFiles would add files that contain the extension anywhere,
not only at the end of the file name.
Example: "word.pk3omghacks" use to be loaded as a pk3 file.
This makes pasting in client console and UI edit fields work on X11 and OS X.
Sys_GetClipboardData is only used by client, so returning NULL in dedicated is fine.
- Clean up ftol()/snapvector() mess
- Make use of SSE instructions for ftol()/snapvector() if available
- move ftol/snapvector pure assembler to inline assembler, this will add x86_64 and improve support for different calling conventions
- Set FPU control word at program startup to get consistent behaviour on all platforms
* com_standalone now read-only
* add new cvars com_basegame, com_homepath
* standalone now automatically detected when com_basegame is set to something different than baseq3 and no id pak pk3s are found
* This fixes https://bugzilla.icculus.org/show_bug.cgi?id=4699
- Replace a few hardcoded string literals with macros
- Add checks for Team Arena PK3s to FS_CheckPak0()
