This graph shows which files directly or indirectly include this file:
Go to the source code of this file.
Detailed Description
This file contains various #defines that select various options. Some may not be desirable, and some just may not work.
There are some options that are not selectable in this file which may not always be undesirable. An example would be certain treasures that you may not want to have available. To remove the activation code would make these items worthless - instead remove these from the treasure file. Some things to look for are:
prepare_weapon, improve_*: Allow characters to enchant their own weapons ench_armour: Allow characters to enchant their armor.
In theory, most of the values here should just be defaults, and everything here should just be selectable by different run time flags However, for some things, that would just be too messy.
Definition in file config.h.
Macro Definition Documentation
◆ ALWAYS_SHOW_HP
◆ ARMOR_MAX_ENCHANT
◆ ARMOR_SPEED_IMPROVEMENT
◆ ARMOR_SPEED_LINEAR
◆ ARMOR_WEIGHT_LINEAR
◆ ARMOR_WEIGHT_REDUCTION
◆ AUTOSAVE
| #define AUTOSAVE 5000 |
How often (in seconds) the player is saved if he drops things. If it is set to 0, the player will be saved for every item he drops. Otherwise, if the player drops and item, and the last time he was saved due to item drop is longer the SAVE_INTERVAL seconds, he is then saved. Depending on your playing environment, you may want to set this to a higher value, so that you are not spending too much time saving the characters. This option should now work (Crossfire 0.90.5) AUTOSAVE saves the player every AUTOSAVE ticks. A value of 5000 with MAX_TIME set at 120,000 means that the player will be saved every 10 minutes. Some effort should probably be made to spread out these saves, but that might be more effort than it is worth (Depending on the spacing, if enough players log on, the spacing may not be large enough to save all of them.) As it is now, it will just set the base tick of when they log on, which should keep the saves pretty well spread out (in a fairly random fashion.)
◆ BALANCED_STAT_LOSS
◆ BALSL_LOSS_CHANCE_RATIO
◆ BALSL_MAX_LOSS_RATIO
◆ BALSL_NUMBER_LOSSES_RATIO
◆ BANFILE
| #define BANFILE "ban_file" |
If you get a complaint about O_NDELAY not being known/undefined, try uncommenting this. This may cause problems - O_NONBLOCK will return -1 on blocking writes and set error to EAGAIN. O_NDELAY returns 0. This is only if no bytes can be written - otherwise, the number of bytes written will be returned for both modes. BANFILE - file used to ban certain sites from playing. See the example ban_file for examples.
◆ BANISHFILE
◆ BASE_WEAPON_SPEED
◆ BEAT_INTERVAL
| #define BEAT_INTERVAL 3 |
◆ CASTING_TIME
◆ CS_LOGSTATS
| #define CS_LOGSTATS |
CS_LOGSTATS will cause the server to log various usage stats (number of connections, amount of data sent, amount of data received, and so on.) This can be very useful if you are trying to measure server/bandwidth usage. It will periodially dump out information which contains usage stats for the last X amount of time. CS_LOGTIME is how often it will print out stats.
◆ CS_LOGTIME
◆ CSPORT
| #define CSPORT 13327 /* old port + 1 */ |
◆ DEATH_PENALTY_LEVEL
◆ DEATH_PENALTY_RATIO
◆ DEBUG
| #define DEBUG |
◆ DMFILE
| #define DMFILE "dm_file" |
◆ EMERGENCY_MAPPATH
| #define EMERGENCY_MAPPATH "/world/world_105_115" |
◆ EMERGENCY_X
◆ EMERGENCY_Y
◆ FREE_PLAYER_LOAD_PERCENT
◆ HIGHSCORE_DIR
◆ HIGHSCORE_LENGTH
| #define HIGHSCORE_LENGTH 1000 |
◆ LOGFILE
| #define LOGFILE "/var/log/crossfire/logfile" |
◆ MANY_CORES
| #define MANY_CORES |
This option creates more core files. In some areas, there are certain checks done to try and make the program more stable (ie, check parameter for null, return if it is). These checks are being done for things that should not happen (ie, being supplied a null parameter). What MANY_CORES does, is if one of these checks is true, it will dump core at that time, allowing for fairly easy tracking down of the problem. Better to fix problems than create thousands of checks.
◆ MAP_CLIENT_X
| #define MAP_CLIENT_X 25 |
This determines the maximum map size the client can request (and thus what the server will send to the client.
Client can still request a smaller map size (for bandwidth reasons or display size of whatever else).
The larger this number, the more cpu time and memory the server will need to spend to figure this out in addition to bandwidth needs. The server cpu time should be pretty trivial.
There may be reasons to keep it smaller for the 'classic' crossfire experience which was 11x11. Big maps will likely make the game at least somewhat easier, but client will need to worry about lag more.
I put support in for non square map updates in the define, but there very well might be things that break horribly if this is used. I figure it is easier to fix that if needed than go back at the future and have to redo a lot of stuff to support rectangular maps at that point.
MSW 2001-05-28
◆ MAP_CLIENT_X_DEFAULT
◆ MAP_CLIENT_X_MINIMUM
◆ MAP_CLIENT_Y
◆ MAP_CLIENT_Y_DEFAULT
◆ MAP_CLIENT_Y_MINIMUM
◆ MAP_DEFAULTRESET
◆ MAP_MAXRESET
| #define MAP_MAXRESET 7200 |
MAP_MAXRESET is the maximum time a map can have before being reset. It will override the time value set in the map, if that time is longer than MAP_MAXRESET. This value is in seconds. If you are low on space on the TMPDIR device, set this value to somethign small. The default value in the map object is MAP_DEFAULTRESET (given in seconds.) I personally like 1 hour myself, for solo play. It is long enough that maps won't be resetting as a solve a quest, but short enough that some maps (like shops and inns) will be reset during the time I play. Comment out MAP_MAXRESET time if you always want to use the value in the map archetype. Maximum time to reset.
◆ MAP_MAXTIMEOUT
| #define MAP_MAXTIMEOUT 1000 |
MAP_MAXTIMEOUT tells the maximum of ticks until a map is swapped out after a player has left it. If it is set to 0, maps are swapped out the instant the last player leaves it. If you are low on memory, you should set this to 0. Note that depending on the map timeout variable, the number of objects can get quite high. This is because depending on the maps, a player could be having the objects of several maps in memory (the map he is in right now, and the ones he left recently.) Each map has it's own TIMEOUT value and value field and it is defaulted to 300
Having a nonzero value can be useful: If a player leaves a map (and thus is on a new map), and realizes they want to go back pretty quickly, the old map is still in memory, so don't need to go disk and get it.
MAP_MINTIMEOUT is used as a minimum timeout value - if the map is set to swap out in less than that many ticks, we use the MINTIMEOUT value below. If MINTIMEOUT > MAXTIMEOUT, MAXTIMEOUT will be used for all maps. How many ticks till maps are swapped out.
◆ MAP_MINTIMEOUT
| #define MAP_MINTIMEOUT 500 |
◆ MAPDIR
| #define MAPDIR "maps" |
◆ MAX_ERRORS
| #define MAX_ERRORS 25 |
◆ MAX_PLAYER_SPEED
◆ MAX_TIME
| #define MAX_TIME 120000 |
◆ MAXSTRING
◆ MIN_PLAYER_SPEED
◆ MOTD
| #define MOTD "motd" |
Defining MEMORY_DEBUG disables Crossfire's object allocator, which allocates OBJ_EXPAND objects at a time and manages its own free list. It is faster at allocating lots of objects, but defeats memory debuggers and mitigation techniques by managing its own allocations and enabling use-after-free bugs.
Unfortunately, much of the code does not work without use-after-free because even checking if an object was freed requires looking in the object. Until these issues are fixed, Crossfire needs MEMORY_DEBUG unset in order to run without crashing frequently. If you want to have a Message Of The Day file, define MOTD to be the file with the message. If the file doesn't exist or if it is empty, no message will be displayed. (It resides in the CONFDIR directory)
◆ NO_EMERGENCY_SAVE
| #define NO_EMERGENCY_SAVE |
◆ NOT_PERMADETH
◆ OBJ_EXPAND
| #define OBJ_EXPAND 100 |
◆ OLD_HIGHSCORE
◆ PERM_EXP_GAIN_RATIO
| #define PERM_EXP_GAIN_RATIO 0.50f |
This determine how many entries are stored in the kill log. You can see this information with the 'party kills' command. More entries mean slower performance and more memory. IF this is not defined, then this feature is disabled. The PERM_EXP values adjust the behaviour of permenent experience. - if the setting permanent_experience_percentage is zero, these values have no meaning. The value in the settings file is the percentage of the experience that is permenent, the rest could be lost on death. When dying, the greatest amount of non-permenent exp it is possible to lose at one time is PERM_EXP_MAX_LOSS_RATIO - this is calculated as total exp - perm exp * loss ratio. The gain ratio is how much of experienced experience goes to the permanent value. This does not detract from total exp gain (ie, if you gained 100 exp, 100 would go to the skill total and 10 to the permanent value).
A few thoughts on these default value (by MSW) gain ratio is pretty much meaningless until exp has been lost, as until that point, the value in the settings file will be used. It is also impossible for the exp to actually be reduced to the permanent exp ratio - since the loss ratio is .5, it will just get closer and closer. However, after about half a dozen hits, pretty much all the exp that can be lost has been lost, and after that, only minor loss will occur.
◆ PERM_EXP_MAX_LOSS_RATIO
◆ PERM_FILE
| #define PERM_FILE "forbid" |
◆ PERMANENT_EXPERIENCE_RATIO
◆ PK_LUCK_PENALTY
◆ PLAYERDIR
| #define PLAYERDIR "players" |
If you want the players to be able to save their characters between games, define SAVE_PLAYER and set PLAYERDIR to the directories where the player-files will be put. Remember to create the directory (make install will do that though).
If you intend to run a central server, and not allow the players to start their own Crossfire, you won't need to define this.
◆ REAL_WIZ
◆ RECYCLE_TMP_MAPS
◆ REGIONS
◆ RESET_LOCATION_TIME
| #define RESET_LOCATION_TIME 3600 |
By selecting the following, whenever a player does a backup save (with the 'save' command), the player will be saved at home (EMERGENCY_MAP_* information that is specified later). If this is not set, the player will be saved at his present location. RESET_LOCATION_TIME is the number of seconds that must elapse before we fill return the player to his savebed location. If this is zero, this feature is disabled (player will resume where ever he was when he last logged off). If this is set to less than two hours, it will prevent players from camping out in treasure rooms. Do not comment this out - it must be set to something - if you comment this out, the program will not compile.
This will work to BACKUP_SAVE_AT_HOME at home above, but where the player where appear under what conditions is a little complicated depending on how the player exited the game. But if the elapsed time is greater than the value below, player will always get returned to savebed location location.
Set to one hour as default
◆ RESURRECTION
◆ SAVE_DIR_MODE
◆ SAVE_MODE
| #define SAVE_MODE 0660 |
If you have defined SAVE_PLAYER, you might want to change this, too. This is the access rights for the players savefiles. Given that crossfire runs in a client/server model, there should be no issue setting these to be quite restrictive (600 and 700). Before client/server, multiple people might run the executable, thus requiring that the server be setuid/setgid, and more generous permisisons needed. SAVE_MODE is permissions for the files, SAVE_DIR_MODE is permission for nay directories created.
◆ SEARCH_ITEMS
◆ SET_FRIENDLY_FIRE
◆ SET_TITLE
◆ SHUTDOWN_FILE
| #define SHUTDOWN_FILE "shutdown" |
◆ SIMPLE_EXP
◆ SOCKETBUFSIZE
| #define SOCKETBUFSIZE 1024*1024 |
◆ SPELL_ENCUMBRANCE
◆ SPELL_FAILURE_EFFECTS
◆ SPELLPOINT_LEVEL_DEPEND
◆ STARTMAX
| #define STARTMAX 500 |
◆ STAT_LOSS_ON_DEATH
◆ TEMPLATE_DIR
◆ TMPDIR
| #define TMPDIR "/tmp" |
Your tmp-directory should be large enough to hold the uncompressed map-files for all who are playing. It ought to be locally mounted, since the function used to generate unique temporary filenames isn't guaranteed to work over NFS or AFS On the other hand, if you know that only one crossfire server will be running using this temporary directory, it is likely to be safe to use something that is NFS mounted (but performance may suffer as NFS is slower than local disk)
◆ UNIQUE_DIR
| #define UNIQUE_DIR "unique-items" |
◆ WATCHDOG
| #define WATCHDOG |
WATCHDOG lets sends datagrams to port 13325 on localhost in (more-or-less) regular intervals, so an external watchdog program can kill the server if it hangs (for whatever reason). It shouldn't hurt anyone if this is defined but you don't have an watchdog program.
