This is an old revision of the document!
Settings entries in the settings file of the server of Crossfire; usually located in the {prefix} /etc/crossfire directory.
The settings are read and compared by the function static void load_settings(void) in the source code file server/server/init.c .
A not matching settings entry should at the end throw an error message LOG(llevError,“Unknown value in settings file: %s\n”, buf); without early exiting and death of the server at it's start.
This setting variable needs to be a positive integer or a Zero (0) .
A negative value would
LOG(llevError, “load_settings: fastclock must be at least 0” “, %d is invalid\n”, lev); and fall back to the default set in
The only function that uses it, is static void block_until_new_connection(void) in server/socket/loop.c, and just tests it if it is greater than 0 . Setting the fastclock to something like 2 or 10 does not make the server “faster” .
Older servers until v1.11.0 used this variable one more in server/server/weather.c and also tests if it is set greater than zero; found in void tick_the_clock(void) to call the write_skymap function.
My impression was that the Computer's CPU used one whole Core 100% when setting fastclock to 1 .
So it seems not advisable to set it to anything else than 0 . But therefore the skymap is not painted in the var/crossfire/weather.ppm 300×300 pixels picture; it's field in the middle of the bottom row of the picture of 9 climate maps stays black.
The weather.ppm can be easily converted by ppmtoxpm weather.ppm >weather.xpm
to be viewed.
Unknown is the behaviour of the server, when the fastclock is set to something like X, *, NULL, TRUE, FALSE .