Configuration
Command-Line Options
In the file actioncube_server.bat (or the respective .sh file in linux) you can add or change command line options:
-wX sets desired screen width to X, default is -w640
-hY sets desired screen height to Y, default is -h480
-t runs windowed
-uN sets the server upstream bandwidth to N bytes per second. only set this parameter if you know what you are doing, specifying a wrong value is worse than not specifying it at all.
-nN sets the server description, for people pinging the server. usually does not need to be set if you have a descriptive domain name already, but if you set it, keep it short as it may otherwise be truncated, i.e. -nBobsInstagibServer
-iIP sets the server ip to IP. this option is only useful for people running on machines with multiple network interfaces.
-mM sets the master server to use for either server (registering) and client (updating) to M. M is the base url of the master server and has to end in a / and without a http:// prefix, the default is wouter.fov120.com/cube/masterserver/. If you want your server to be private and not report to the masterserver, use -mlocalhost.
-pPASS sets the server password to PASS. Only clients that use the command "password PASS" will be able to connect.
-cN sets the maximum number of players that can play on this server to N (default 4). If more players try to connect they will get a "server full" message.
-xM sets the master password.
-rC sets the maprotation file, e.g. -rconfig/maprot.cfg
General console commands and configuration
soundvol n
menuitem A
scales all particles by percentage P.
To use overbright lighting, your card needs to support the "EXT_texture_env_combine" extension (Nvidia from TNT1 and upwards, ATI from rage128/radeon and upwards, but not on voodoos afaik). Overbright lighting uses a different lighting model (lights that overlap "add" rather use the biggest of the two, and lightsources have an exponential rather than linear model), so lighting may look different depending on how the mapper placed the lights. Maps should be made with additive/exponential lighting in mind, however, because soon everyone will have a card that supports this extension.
Do not confuse "lightscale" with "gamma", they have different effects. It is best to leave "lightscale" at the default and tune gamma to get the right brightness level for your situation, but you can tune the other way around if you find the saturation level of a certain gamma level more important. changing the lightscale will have an effect on the distribution of lightsources (higher lightscale will make them more like spotlights). Generally, gamma needs to be lower compared to older cube releases.
Console Language
Cube's console language is similar to console languages of other games (e.g. Quake), but is a bit more powerful in that it is almost a full programming language.
What is similar to quake is the basic command structure: commands consist of the command itself, followed by any number of arguments seperated by whitespace. you can use "" to quote strings with whitespace in them (such as the actions in bind/alias), and whereever a command is required you can also use ; to sequence multiple commands in one.
What is new compared to quake is that you can evaluate aliases and expressions. You can substitute the value of an alias as an argument by prefixing it with a "$" sign, i.e.: echo The current value of x is $x You can even substitute the values of console variables this way, i.e $fov gives the current fov. Some aliases are set automatically, for example $arg1 to $argN are set if you supply arguments when you execute an alias.
There are two alternative ways to "" to quote a string: () and []. They work in the same way as "", with the difference that they can be nested infinitely, and that they may contain linefeeds (useful for larger scripts). () is different from [] in that it evaluates the commands contained in it _before_ it evaluates the surrounding command, and substitutes the results. () bracketed strings are called expressions, and combined with some commands made especially for "programming", you have a minimal language:
- A B
* A B
div A B
mod A B
Example: echo x squared is (* $x $x)
< A B
> A B
strcmp A B
Example: if (< $x 10) [ echo x is $x ] [ echo x is too big ]
Example: loop 10 [ echo $i ]
Example (same as the loop): alias i 0; while [ (< $i 10) ] [ echo $i; alias i (+ $i 1) ]
0 when the player looks at the floor, and 2 when looking at the ceiling.
How The Cube Engine Works
The cube engine is simplicity itself. The whole map consists of a large 2D array of "cubes", each with a floor and ceiling height, textures (for floor/ceiling/wall) and other properties. These cubes are grouped 2x2 at a time recursively into a "quad tree", which is used hold bigger cubes which can be rendered faster. For those who have edited doom, this is very similar to having a lot of square sectors but at overlapping sizes. This is results in a map that can have no room over room (yet), and is pretty cubic, except for the odd slope/slant here and there.
The floor size of a single unit (single cube) is similar to about 16x16 units in games such as doom & quake, so a staircase step is usually 1 unit, a wall 8 units high etc.
Cube renders this world by first determining which cubes are visible using a "dynamic occlusion culling" algorithm and frustrum culling. You can see the effect of this when you switch to edit mode (E), and then fly out above a map: you'll see parts of the map dropping away as you move. The remaining cubes are then rendered in their most efficient size (i.e. cube will render a mixture of 1x1 2x2 4x4 etc. size cubes, depending on wether they have the same properties: height, texturing etc.).
If you are on a fast machine, or you are playing a simple/small map, cube will simply render all of these visible cubes (this is indicated by LOD at its maximum of 250 on the hud). Cube can however make complex maps run fast even on slower computers by a technique called LOD: this will render cubes that are further away using bigger approximations (2x2 and up), even the properties of the constituent cubes don't match exactly. This reduces the amount of polys to be rendered tremendously, and thus allows even slow machines to have a consistent frame rate (cube will adapt the LOD figure every frame to aim for the fps you specify). The downside is of course that if the approximations are visible closeup, this can lead to ugly graphical glitches (this is called "popup" because it changes as you move). So in the end the choice is up to you: good fps or constant visual quality (most engines only cater for the latter).