|
Atrinik Server 2.5
|
Go to the source code of this file.
Defines | |
| #define | DATADIR "./lib" |
| #define | MAPDIR "../maps" |
| #define | LOCALDIR "./data" |
| #define | PLAYERDIR "players" |
| #define | PLUGINDIR "./" |
| #define | DMFILE "dmfile" |
| #define | BANFILE "bans" |
| #define | TMPDIR LOCALDIR"/tmp" |
| #define | UNIQUE_DIR "unique-items" |
| #define | BALANCED_STAT_LOSS 0 |
| #define | BALSL_LOSS_CHANCE_RATIO 4 |
| #define | BALSL_NUMBER_LOSSES_RATIO 6 |
| #define | BALSL_MAX_LOSS_RATIO 2 |
| #define | CS_LOGSTATS 0 |
| #define | CS_LOGTIME 600 |
| #define | MAP_CLIENT_X 17 |
| #define | MAP_CLIENT_Y 17 |
| #define | MAX_TIME 125000 |
| #define | REAL_WIZ |
| #define | RECYCLE_TMP_MAPS 0 |
| #define | STAT_LOSS_ON_DEATH 0 |
| #define | CSPORT 13327 |
| #define | MAP_DEFAULTTIMEOUT 500 |
| #define | MAP_MAXTIMEOUT 10000 |
| #define | MAP_MAXRESET 7200 |
| #define | MAP_DEFAULTRESET 7200 |
| #define | MEMORY_DEBUG 0 |
| #define | USE_CALLOC |
| #define | EMERGENCY_MAPPATH "/emergency" |
| #define | EMERGENCY_X 0 |
| #define | EMERGENCY_Y 0 |
| #define | ARCHETYPES "archetypes" |
| #define | TREASURES "treasures" |
| #define | SETTINGS "settings" |
| #define | HIGHSCORE "highscore" |
| #define | MAX_ERRORS 25 |
| #define | OBJECT_EXPAND 2500 |
| #define | HIGHSCORE_LENGTH 1000 |
| #define | ARCHTABLE 8192 |
| #define | MAXSTRING 20 |
| #define | SAVE_MODE 0660 |
| #define | AUTOSAVE 5000 |
| #define | NO_EMERGENCY_SAVE |
| #define | SOCKET_VERSION 1055 |
| #define | COMPRESS_DATA_PACKETS 0 |
| #define | COMPRESS_DATA_PACKETS_SIZE 128 |
This file contains various #defines that select various options. Some may not be desirable, and some just may not work.
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.
| #define ARCHETYPES "archetypes" |
| #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 an 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. 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).
| #define BALANCED_STAT_LOSS 0 |
Use balanced stat loss code? This code is a little more merciful with repeated stat loss at lower levels. Basically, the more stats you have lost, the less likely that you will lose more. Additionally, lower level characters are shown a lot more mercy (there are caps on how much of a stat you can lose too). On the nasty side, if you are higher level, you can lose multiple stats _at_once_ and are shown less mercy when you die. But when you're higher level, it is much easier to buy back your stats with potions. Turn this on if you want death-based stat loss to be more merciful at low levels and more cruel at high levels. Only works when stats are depleted rather than lost. This option has no effect if you are using genuine stat loss.
The BALSL_.. values control this behavior. BALSL_NUMBER_LOSSES_RATIO determines the number of stats to lose. the character level is divided by that value, and that is how many stats are lost.
BALSL_MAX_LOSS_RATIO puts the upper limit on depletion of a stat - basically, level/max_loss_ratio is the most a stat can be depleted.
BALSL_LOSS_CHANCE_RATIO controls how likely it is a stat is depleted. The chance not to lose a stat is depleteness^2 / (depletedness^2+ level/ratio). ie, if the stats current depleted value is 2 and the character is level 15, the chance not to lose the stat is 4/(4+3) or 4/7. The higher the level, the more likely it is a stat can get really depleted, but this gets more offset as the stat gets more depleted.
| #define COMPRESS_DATA_PACKETS 0 |
If 1, all data packets that are longer than COMPRESS_DATA_PACKETS_SIZE will be compressed by zlib using the best compression available before being sent. The client will then decompress the previously compressed data and treat it normally.
This option is useful for bandwidth-limited servers, as it has nearly no CPU impact, but halves the bandwidth usage of most common data packets.
| #define COMPRESS_DATA_PACKETS_SIZE 128 |
Only data packets longer than this will be compressed if COMPRESS_DATA_PACKETS is 1. This option shouldn't be too high, since in such case it would have little effect, and not too low either, in which case it would do more harm than good.
The default of '128' is a reasonable value, as such data packets will get compressed by zlib nicely (a data packet of size 20 would actually be bigger when compressed).
| #define CS_LOGSTATS 0 |
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 periodically dump out information which contains usage stats for the last X amount of time. CS_LOGTIME is how often it will print out stats.
| #define CSPORT 13327 |
| #define DATADIR "./lib" |
| #define EMERGENCY_MAPPATH "/emergency" |
| #define HIGHSCORE "highscore" |
| #define HIGHSCORE_LENGTH 1000 |
| #define LOCALDIR "./data" |
| #define MAP_CLIENT_X 17 |
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.
| #define MAP_DEFAULTTIMEOUT 500 |
MAP_DEFAULTTIMEOUT is the default number 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).
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.
| #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 something small.
The default value in the map object is 7200 (2 hours).
Comment out MAP_MAXRESET time if you always want to use the value in the map archetype.
| #define MAX_ERRORS 25 |
| #define MAX_TIME 125000 |
| #define MEMORY_DEBUG 0 |
| #define NO_EMERGENCY_SAVE |
| #define OBJECT_EXPAND 2500 |
| #define REAL_WIZ |
Calling this REAL_WIZ is probably not really good. Something like MUD_WIZ might be a better name.
Basically, if REAL_WIZ is defined then the WIZ/WAS_WIZ flags for objects are not set - instead, wizard created/manipulated objects appear as normal objects. This makes the wizard a little more mudlike, since object manipulations will be usable for other objects.
| #define RECYCLE_TMP_MAPS 0 |
Set this if you want the temporary maps to be saved and reused across Atrinik runs. This can be especially useful for single player servers, but even holds use for multiplayer servers. The file used is updated each time a temp map is updated. Note that the file used to store this information is stored in the LIB directory. Running multiple Atrinik servers with the same LIB directory will cause serious problems, simply because in order for this to really work, the filename must be constant so the next run knows where to find the information.
| #define SAVE_MODE 0660 |
This is the access rights for the players savefiles.
I think it is usefull to restrict access to the savefiles for the game admin. So if you make Atrinik set-uid, use 0600.
If you are running the game set-gid (to a games-group, for instance), you must remember to make it writeable for the group (ie 0660).
| #define STAT_LOSS_ON_DEATH 0 |
Set this to 0 if you don't want characters to loose a random stat when they die - instead, they just get deplete.
Setting it to 1 keeps the old behavior. This can be changed at run time via -stat_loss_on_death or +stat_loss_on_death. In theory, this can be changed on a running server, but so glue code in the wiz stuff would need to be added for that to happen.
| #define TMPDIR LOCALDIR"/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 Atrinik 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).
| #define UNIQUE_DIR "unique-items" |
| #define USE_CALLOC |
If undefined, malloc is always used. It looks like this can be obsoleted. However, it can be useful to track down some bugs, as it will make sure that the entire data structure is set to 0, at the expense of speed.
Rupert Goldie has run Purify against the code, and if this is disabled, apparently there are a lot of uninitialized memory reads - I haven't seen any problem (maybe the memory reads are copies, and the destination doesn't actually use the garbage values either?), but the impact on speed of using this probably isn't great, and should make things more stable. Msw 8-9-97
1.7.4