C
C
com/iortcw/iortcw/master/MP/misc/
wolf128.png)
## iortcw
The intent of this project is to provide a baseline RTCW which may be used
for further development and fun.
Some of the major features currently implemented are:
* SDL backend
* OpenAL sound API support (multiple speaker support and better sound
quality)
* Full x86_64 support
* VoIP support, both in-game and external support through Mumble.
* MinGW compilation support on Windows and cross compilation support on Linux
* AVI video capture of demos
* Much improved console autocompletion
* Persistent console history
* Colorized terminal output
* Optional Ogg Vorbis support
* Much improved QVM tools
* Support for various esoteric operating systems
* cl_guid support
* HTTP/FTP download redirection (using cURL)
* Multiuser support on Windows systems (user specific game data
is stored in "My Documents\RTCW")
* PNG support
* Many, many bug fixes
The map editor and associated compiling tools are not included. We suggest you use
a modern copy from http://icculus.org/gtkradiant/.
The original id software readme that accompanied the RTCW source release is named
README.txt and is contained within the source tree of both MP and SP games.
It is also possible to cross compile for Windows under *nix and Cygwin using MinGW.
Your distribution may have mingw32 packages available. You will need to install
'mingw-w64'.
The defaults for these variables differ depending on the target platform.
### Console
* sv_banFile - Name of the file that is used for storing the server bans
red-cyan glasses: 1
red-blue: 2
red-green: 3
green-magenta: 4
To swap the colors for left and right eye just add 4 to the value for the
wanted color combination. For red-blue and red-green you probably want to enable
r_greyscale
###### Help! iortcw won't give me an fps of X anymore when setting com_maxfps!
iortcw now uses the select() system call to wait for the rendering of the next
frame when com_maxfps was hit. This will improve your CPU load considerably in
these cases. However, not all systems may support a granularity for its timing
functions that is required to perform this waiting correctly. For instance, iortcw
tells select() to wait 2 milliseconds, but really it can only wait for a multiple
of 5ms, i.e. 5, 10, 15, 20... ms. In this case you can always revert back to the
old behaviour by setting the cvar:
com_busyWait 1
sv_dlURL is the base of the URL that contains your custom .pk3 files
the client will append both fs_game and the filename to the end of
this value. For example, if you have sv_dlURL set to
"http://yoursite.org", fs_game is "main", and the client is
missing "test.pk3", it will attempt to download from the URL
"http://yoursite.org/main/test.pk3"
1 - ENABLE
Server operators who are concerned about potential "leeching" from their HTTP
servers from other iortcw servers can make use of the HTTP_REFERER that iortcw sets
which is "ioQ3://{SERVER_IP}:{SERVER_PORT}". For example, Apache's mod_rewrite can
restrict access based on HTTP_REFERER.
On a sidenote, downloading via UDP has been improved and yields higher data rates
now. You can configure the maximum bandwidth for UDP downloads via the cvar
sv_dlRate. Due to system-specific limits the download rate is capped at about 1
Mbyte/s per client, so curl downloading may still be faster.
When iortcw is built with USE_CURL_DLOPEN=1 (default), it will use the value of the
cvar cl_cURLLib as the filename of the cURL library to dynamically load.
You can revert to the old single-user behaviour by setting the fs_homepath cvar to
the directory where iortcw is installed. For example:
or
SDL > 1.2.9 does not support disabling dead key recognition. In order to send dead
key characters ( e.g. ~, ', `, and ^ ), you must key a Space ( or sometimes the
same character again ) after the character to send it on many international
keyboard layouts.
The SDL client supports many more keys than the original RTCW client. For example
the keys: "Windows", "SysReq", "ScrollLock", and "Break". For non-US keyboards, all
of the so called "World" keys are now supported as well as F13, F14, F15, and the
country-specific mode/meta keys.
On many international layouts the default console toggle keys are also dead keys,
meaning that dropping the console potentially results in unintentionally initiating
the keying of a dead key. Furthermore SDL 1.2's dead key support is broken by
design and RTCW doesn't support non-ASCII text entry, so the chances are you won't
get the correct character anyway.
If you use such a keyboard layout, you can set the cvar cl_consoleKeys. This is a
space delimited list of key names that will toggle the console. The key names are
the usual RTCW names e.g. "~", "`", "c", "BACKSPACE", "PAUSE", "WINDOWS" etc. It's
also possible to use ASCII characters, by hexadecimal number. Some example values
for cl_consoleKeys:
Note that when you elect a set of console keys or characters, they cannot then be
used for binding, nor will they generate characters when entering text. Also, in
addition to the nominated console keys, Shift-ESC is hard coded to always toggle
the console.
QuakeLive mouse acceleration ( patch and this text written by TTimo from
id )...I've been using an experimental mouse acceleration code for a while, and
decided to make it available to everyone. Don't be too worried if you don't
understand the explanations below, this is mostly intended for advanced players:
* sensitivity
* cl_mouseAccel
* cl_mouseAccelOffset
Once you setup your sensitivity to feel comfortable and accurate enough for low
mouse deltas with no acceleration ( cl_mouseAccel 0 ), you can start increasing
cl_mouseAccel and tweaking cl_mouseAccelOffset to get the amplification you want
for high deltas with little effect on low mouse deltas.
cl_mouseAccel is a power value. Should be >= 1, 2 will be the same power curve as
style 0. The higher the value, the faster the amplification grows with the mouse
delta.
Mouse acceleration is tricky to configure, and when you do you'll have to re-learn
your aiming. But you will find that it's very much worth it in the long run.
If you try the new acceleration code and start using it, I'd be very interested by
your feedback.
* 64-bit mods
If you wish to compile external mods as shared libraries on a 64bit platform, and
the mod source is derived from the id RTCW SDK, you will need to modify the
interface code a little. Open the files ending in _syscalls.c and change every
instance of int to intptr_t in the declaration of the syscall function pointer and
the dllEntry function. Also find the vmMain function for each module ( usually in
cg_main.c g_main.c etc. ) and similarly replace the return value in the prototype
with intptr_t (arg0, arg1, ...stay int).
Add the following code snippet to q_shared.h:
#ifdef Q3_VM
typedef int intptr_t;
#else
#include <stdint.h>
#endif
Have you finished the daunting task of removing all dependencies on the RTCW game
data? You probably now want to give your users the opportunity to play the game
without owning a copy of RTCW, which consequently means removing cd-key and
authentication server checks.
However, before you start compiling your own version of iortcw, you have to ask
yourself: Have we changed or will we need to change anything of importance in the
engine?
If your answer to this question is "no", it probably makes no sense to build your
own binaries. Instead, you can just use the pre-built binaries on the website. Just
make sure the game is called with:
in any links/scripts you install for your users to start the game. The binary must
not detect any original RTCW game pak files. If this
condition is met, the game will set com_standalone to 1 and is then running in
stand alone mode.
If you want the engine to use a different directory in your homepath than e.g. "My
Documents\RTCW" on Windows or ".wolf" on Linux, then set a new name at startup by
adding
to the command line. You can also control which game name to use when talking to
the master server:
So clients requesting a server list will only receive servers that have a matching
game name.
Example line:
While a lot of work has been put into iortcw that you can benefit from free of
charge, it does not mean that you have no obligations to fulfill. Please be aware
that as soon as you start distributing your game with an engine based on our
sources we expect you to fully comply with the requirements as stated in the GPL.
That includes making sources and modifications you made to the iortcw engine as
well as the game-code used to compile the .qvm/.so files for the game logic freely
available to everyone. Furthermore, note that the "RTCW Game Source License"
prohibits distribution of mods that are intended to operate on a version of RTCW
not sanctioned by id software.
This means that if you're creating a standalone game, you cannot use said license
on any portion of the product. As the only other license this code has been
released under is the GPL, this is the only option.
This does NOT mean that you cannot market this game commercially. The GPL does not
prohibit commercial exploitation and all assets (e.g. textures, sounds, maps)
created by yourself are your property and can be sold like every other game you
find in stores.
"com_protocol"
and
"com_legacyprotocol"
The reason for this is that some standalone games increased the protocol number
even though nothing really changed in their protocol and the iortcw engine is still
fully compatible.
In order to harden the network protocol against UDP spoofing attacks a new network
protocol was introduced that defends against such attacks.
Unfortunately, this protocol will be incompatible to the original RTCW 1.4 which is
the latest official release from id.
The cvar "com_protocol" denotes the protocol version for the new hardened protocol,
whereas the "com_legacyprotocol" cvar denotes the protocol version for the legacy
protocol.
Mods that use a standalone engine obviously do not require dual protocol support,
and it is turned off if the engine is compiled with STANDALONE per default. If you
desire backwards compatibility to older versions of your game you can still enable
it in q_shared.h by defining
LEGACY_PROTOCOL
1) improve logging to allow statistical tools to index players by more than just
name
2) granting some weak admin rights to players without requiring passwords
texturetypes="tga jpg"
to
### Contributing
The focus for iortcw is to develop a stable base suitable for further development
and provide players with the same RTCW experience they've had for years. As such
iortcw does not have any significant graphical enhancements and none are planned at
this time. However, improved graphics and sound patches will be
accepted as long as they are entirely optional, do not require new media and are
off by default.
### Credits
Maintainers
* Donny Springer <[email protected]>
* Zack Middleton <[email protected]>
* James Canete <[email protected]>