| 1 |
root |
1.1 |
/* |
| 2 |
|
|
* static char *rcsid_config_h = |
| 3 |
elmex |
1.1.1.2 |
* "$Id: config.h,v 1.70 2006/03/07 18:46:25 cavesomething Exp $"; |
| 4 |
root |
1.1 |
*/ |
| 5 |
|
|
|
| 6 |
|
|
/* |
| 7 |
|
|
CrossFire, A Multiplayer game for X-windows |
| 8 |
|
|
|
| 9 |
|
|
Copyright (C) 2002 Mark Wedel & Crossfire Development Team |
| 10 |
|
|
Copyright (C) 1992 Frank Tore Johansen |
| 11 |
|
|
|
| 12 |
|
|
This program is free software; you can redistribute it and/or modify |
| 13 |
|
|
it under the terms of the GNU General Public License as published by |
| 14 |
|
|
the Free Software Foundation; either version 2 of the License, or |
| 15 |
|
|
(at your option) any later version. |
| 16 |
|
|
|
| 17 |
|
|
This program is distributed in the hope that it will be useful, |
| 18 |
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of |
| 19 |
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the |
| 20 |
|
|
GNU General Public License for more details. |
| 21 |
|
|
|
| 22 |
|
|
You should have received a copy of the GNU General Public License |
| 23 |
|
|
along with this program; if not, write to the Free Software |
| 24 |
|
|
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. |
| 25 |
|
|
|
| 26 |
|
|
The authors can be reached via e-mail at crossfire-devel@real-time.com |
| 27 |
|
|
*/ |
| 28 |
|
|
|
| 29 |
|
|
/* This file contains various #defines that select various options. |
| 30 |
|
|
* Some may not be desirable, and some just may not work. |
| 31 |
|
|
* |
| 32 |
|
|
* There are some options that are not selectable in this file which |
| 33 |
|
|
* may not always be undesirable. An example would be certain |
| 34 |
|
|
* treasures that you may not want to have available. To remove the |
| 35 |
|
|
* activation code would make these items worthless - instead remove |
| 36 |
|
|
* these from the treasure file. Some things to look for are: |
| 37 |
|
|
* |
| 38 |
|
|
* prepare_weapon, improve_*: Allow characters to enchant their own |
| 39 |
|
|
* weapons |
| 40 |
|
|
* ench_armour: Allow characters to enchant their armor. |
| 41 |
|
|
* |
| 42 |
|
|
* In theory, most of the values here should just be defaults, and |
| 43 |
|
|
* everything here should just be selectable by different run time |
| 44 |
|
|
* flags However, for some things, that would just be too messy. |
| 45 |
|
|
*/ |
| 46 |
|
|
|
| 47 |
|
|
/* There are 4 main sections to this file- |
| 48 |
|
|
* Section 1 is feature selection (enabling/disabling certain features) |
| 49 |
|
|
* |
| 50 |
|
|
* Section 2 is compiler/machine dependant section (stuff that just |
| 51 |
|
|
* makes the program compile and run properly, but don't change the |
| 52 |
|
|
* behavior) |
| 53 |
|
|
* |
| 54 |
|
|
* Section 3 is location of certain files and other defaults. Things in |
| 55 |
|
|
* this section generally do not need to be changed, and generally do |
| 56 |
|
|
* not alter the play as perceived by players. However, you may |
| 57 |
|
|
* have your own values you want to set here. |
| 58 |
|
|
* |
| 59 |
|
|
* Section 4 deals with save file related options. |
| 60 |
|
|
*/ |
| 61 |
|
|
|
| 62 |
|
|
/******************************************************************* |
| 63 |
|
|
* SECTION 1 - FEATURES |
| 64 |
|
|
* |
| 65 |
|
|
* You don't have to change anything here to get a working program, but |
| 66 |
|
|
* you may want to on personal preferance. Items are arranged |
| 67 |
|
|
* alphabetically. |
| 68 |
|
|
* |
| 69 |
|
|
* Short list of features, and what to search for: |
| 70 |
|
|
* CS_LOGSTATS - log various new client/server data. |
| 71 |
|
|
* DEBUG - more verbose message logging? |
| 72 |
|
|
* MAP_CLIENT_X, MAP_CLIENT_Y - determines max size client map will receive |
| 73 |
|
|
* MAX_TIME - how long an internal tick is in microseconds |
| 74 |
|
|
* MANY_CORES - generate core dumps on gross errors instead of continuing? |
| 75 |
|
|
* PARTY_KILL_LOG - stores party kill information |
| 76 |
|
|
* WATCHDOG - allows use of an external watchdog program |
| 77 |
|
|
* |
| 78 |
|
|
***********************************************************************/ |
| 79 |
|
|
|
| 80 |
|
|
/* Use balanced stat loss code? |
| 81 |
|
|
* This code is a little more merciful with repeated stat loss at lower |
| 82 |
|
|
* levels. Basically, the more stats you have lost, the less likely that |
| 83 |
|
|
* you will lose more. Additionally, lower level characters are shown |
| 84 |
|
|
* a lot more mercy (there are caps on how much of a stat you can lose too). |
| 85 |
|
|
* On the nasty side, if you are higher level, you can lose mutiple stats |
| 86 |
|
|
* _at_once_ and are shown less mercy when you die. But when you're higher |
| 87 |
|
|
* level, it is much easier to buy back your stats with potions. |
| 88 |
|
|
* Turn this on if you want death-based stat loss to be more merciful |
| 89 |
|
|
* at low levels and more cruel at high levels. |
| 90 |
|
|
* Only works when stats are depleted rather than lost. This option has |
| 91 |
|
|
* no effect if you are using genuine stat loss. |
| 92 |
|
|
* |
| 93 |
|
|
* The BALSL_.. values control this behaviour. |
| 94 |
|
|
* BALSL_NUMBER_LOSSES_RATIO determines the number of stats to lose. |
| 95 |
|
|
* the character level is divided by that value, and that is how many |
| 96 |
|
|
* stats are lost. |
| 97 |
|
|
* |
| 98 |
|
|
* BALSL_MAX_LOSS_RATIO puts the upper limit on depletion of a stat - |
| 99 |
|
|
* basically, level/max_loss_ratio is the most a stat can be depleted. |
| 100 |
|
|
* |
| 101 |
|
|
* BALSL_LOSS_CHANCE_RATIO controls how likely it is a stat is depleted. |
| 102 |
|
|
* The chance not to lose a stat is |
| 103 |
|
|
* depleteness^2 / (depletedness^2+ level/ratio). |
| 104 |
|
|
* ie, if the stats current depleted value is 2 and the character is level |
| 105 |
|
|
* 15, the chance not to lose the stat is 4/(4+3) or 4/7. The higher the |
| 106 |
|
|
* level, the more likely it is a stat can get really depleted, but |
| 107 |
|
|
* this gets more offset as the stat gets more depleted. |
| 108 |
|
|
* |
| 109 |
|
|
*/ |
| 110 |
|
|
/* GD */ |
| 111 |
|
|
|
| 112 |
|
|
#define BALSL_LOSS_CHANCE_RATIO 4 |
| 113 |
|
|
#define BALSL_NUMBER_LOSSES_RATIO 6 |
| 114 |
|
|
#define BALSL_MAX_LOSS_RATIO 2 |
| 115 |
|
|
|
| 116 |
|
|
|
| 117 |
|
|
/* Don't edit these values. They are configured in lib/settings. These are |
| 118 |
|
|
Simply the defaults. */ |
| 119 |
|
|
|
| 120 |
|
|
#define BALANCED_STAT_LOSS FALSE |
| 121 |
elmex |
1.1.1.2 |
#define PERMANENT_EXPERIENCE_RATIO 25 |
| 122 |
|
|
#define DEATH_PENALTY_RATIO 20 |
| 123 |
|
|
#define DEATH_PENALTY_LEVEL 3 |
| 124 |
root |
1.1 |
#define SET_TITLE TRUE |
| 125 |
|
|
#define SIMPLE_EXP TRUE |
| 126 |
|
|
#define SPELLPOINT_LEVEL_DEPEND TRUE |
| 127 |
|
|
#define SPELL_ENCUMBRANCE TRUE |
| 128 |
|
|
#define SPELL_FAILURE_EFFECTS FALSE |
| 129 |
|
|
#define REAL_WIZ TRUE |
| 130 |
|
|
#define RECYCLE_TMP_MAPS FALSE |
| 131 |
|
|
#define RESURRECTION FALSE |
| 132 |
|
|
#define SEARCH_ITEMS TRUE |
| 133 |
|
|
#define NOT_PERMADETH TRUE |
| 134 |
|
|
#define EXPLORE_MODE FALSE |
| 135 |
|
|
#define STAT_LOSS_ON_DEATH FALSE |
| 136 |
|
|
#define PK_LUCK_PENALTY 1 |
| 137 |
|
|
#define CASTING_TIME FALSE |
| 138 |
|
|
#define SET_FRIENDLY_FIRE 5 |
| 139 |
|
|
#define ARMOR_MAX_ENCHANT 5 |
| 140 |
|
|
#define ARMOR_WEIGHT_REDUCTION 10 |
| 141 |
|
|
#define ARMOR_WEIGHT_LINEAR TRUE |
| 142 |
|
|
#define ARMOR_SPEED_IMPROVEMENT 10 |
| 143 |
|
|
#define ARMOR_SPEED_LINEAR TRUE |
| 144 |
|
|
|
| 145 |
|
|
/* you can edit the ones below */ |
| 146 |
|
|
|
| 147 |
|
|
|
| 148 |
|
|
/* CS_LOGSTATS will cause the server to log various usage stats |
| 149 |
|
|
* (number of connections, amount of data sent, amount of data received, |
| 150 |
|
|
* and so on.) This can be very useful if you are trying to measure |
| 151 |
|
|
* server/bandwidth usage. It will periodially dump out information |
| 152 |
|
|
* which contains usage stats for the last X amount of time. |
| 153 |
|
|
* CS_LOGTIME is how often it will print out stats. |
| 154 |
|
|
*/ |
| 155 |
|
|
#ifndef WIN32 /* ***win32 we set the following stuff in the IDE */ |
| 156 |
|
|
#define CS_LOGSTATS |
| 157 |
|
|
#endif |
| 158 |
|
|
#ifdef CS_LOGSTATS |
| 159 |
|
|
#define CS_LOGTIME 600 |
| 160 |
|
|
#endif |
| 161 |
|
|
|
| 162 |
|
|
/* DEBUG generates copious amounts of output. I tend to change the CC options |
| 163 |
|
|
* in the crosssite.def file if I want this. By default, you probably |
| 164 |
|
|
* dont want this defined. |
| 165 |
|
|
*/ |
| 166 |
|
|
#ifndef WIN32 /* ***win32 we set the following stuff in the IDE */ |
| 167 |
|
|
#ifndef DEBUG |
| 168 |
|
|
#define DEBUG |
| 169 |
|
|
#endif |
| 170 |
|
|
#endif |
| 171 |
|
|
/* |
| 172 |
|
|
* This option creates more core files. In some areas, there are certain |
| 173 |
|
|
* checks done to try and make the program more stable (ie, check |
| 174 |
|
|
* parameter for null, return if it is). These checks are being done |
| 175 |
|
|
* for things that should not happen (ie, being supplied a null parameter). |
| 176 |
|
|
* What MANY_CORES does, is if one of these checks is true, it will |
| 177 |
|
|
* dump core at that time, allowing for fairly easy tracking down of the |
| 178 |
|
|
* problem. Better to fix problems than create thousands of checks. |
| 179 |
|
|
*/ |
| 180 |
|
|
|
| 181 |
|
|
#define MANY_CORES |
| 182 |
|
|
|
| 183 |
|
|
/* |
| 184 |
|
|
* This determines the maximum map size the client can request (and |
| 185 |
|
|
* thus what the server will send to the client. |
| 186 |
|
|
* Client can still request a smaller map size (for bandwidth reasons |
| 187 |
|
|
* or display size of whatever else). |
| 188 |
|
|
* The larger this number, the more cpu time and memory the server will |
| 189 |
|
|
* need to spend to figure this out in addition to bandwidth needs. |
| 190 |
|
|
* The server cpu time should be pretty trivial. |
| 191 |
|
|
* There may be reasons to keep it smaller for the 'classic' crossfire |
| 192 |
|
|
* experience which was 11x11. Big maps will likely make the same at |
| 193 |
|
|
* least somewhat easier, but client will need to worry about lag |
| 194 |
|
|
* more. |
| 195 |
|
|
* I put support in for non square map updates in the define, but |
| 196 |
|
|
* there very well might be things that break horribly if this is |
| 197 |
|
|
* used. I figure it is easier to fix that if needed than go back |
| 198 |
|
|
* at the future and have to redo a lot of stuff to support rectangular |
| 199 |
|
|
* maps at that point. |
| 200 |
|
|
* |
| 201 |
|
|
* MSW 2001-05-28 |
| 202 |
|
|
*/ |
| 203 |
|
|
|
| 204 |
|
|
#define MAP_CLIENT_X 25 |
| 205 |
|
|
#define MAP_CLIENT_Y 25 |
| 206 |
|
|
|
| 207 |
|
|
/* |
| 208 |
|
|
* If you feel the game is too fast or too slow, change MAX_TIME. |
| 209 |
|
|
* You can experiment with the 'speed <new_max_time> command first. |
| 210 |
|
|
* The length of a tick is MAX_TIME microseconds. During a tick, |
| 211 |
|
|
* players, monsters, or items with speed 1 can do one thing. |
| 212 |
|
|
*/ |
| 213 |
|
|
|
| 214 |
|
|
#define MAX_TIME 120000 |
| 215 |
|
|
|
| 216 |
|
|
/* Polymorph as it currently stands is unbalancing, so by default |
| 217 |
|
|
* we have it disabled. It can be enabled and it works, but |
| 218 |
|
|
* it can be abused in various ways. |
| 219 |
|
|
*/ |
| 220 |
|
|
#define NO_POLYMORPH |
| 221 |
|
|
|
| 222 |
|
|
|
| 223 |
|
|
/* This determine how many entries are stored in the kill log. You |
| 224 |
|
|
* can see this information with the 'party kills' command. More entries |
| 225 |
|
|
* mean slower performance and more memory. IF this is not defined, then |
| 226 |
|
|
* this feature is disabled. |
| 227 |
|
|
*/ |
| 228 |
|
|
/* |
| 229 |
|
|
#define PARTY_KILL_LOG 20 |
| 230 |
|
|
*/ |
| 231 |
|
|
|
| 232 |
elmex |
1.1.1.2 |
/* |
| 233 |
|
|
* The PERM_EXP values adjust the behaviour of permenent experience. - if |
| 234 |
|
|
* the setting permanent_experience_percentage is zero, these values have |
| 235 |
|
|
* no meaning. The value in the settings file is the percentage of the |
| 236 |
|
|
* experience that is permenent, the rest could be lost on death. When dying, |
| 237 |
|
|
* the greatest amount of non-permenent exp it is possible to lose at one time |
| 238 |
|
|
* is PERM_EXP_MAX_LOSS_RATIO - this is calculated as |
| 239 |
|
|
* total exp - perm exp * loss ratio. The gain ratio is how much of experienced |
| 240 |
|
|
* experience goes to the permanent value. This does not detract from total |
| 241 |
|
|
* exp gain (ie, if you gained 100 exp, 100 would go to the skill total and |
| 242 |
|
|
* 10 to the permanent value). |
| 243 |
root |
1.1 |
* |
| 244 |
|
|
* A few thoughts on these default value (by MSW) |
| 245 |
|
|
* gain ratio is pretty much meaningless until exp has been lost, as until |
| 246 |
elmex |
1.1.1.2 |
* that poin, the value in the settings file will be used. |
| 247 |
root |
1.1 |
* It is also impossible for the exp to actually be reduced to the permanent |
| 248 |
|
|
* exp ratio - since the loss ratio is .5, it will just get closer and |
| 249 |
|
|
* closer. However, after about half a dozen hits, pretty much all the |
| 250 |
|
|
* exp that can be lost has been lost, and after that, only minor loss |
| 251 |
|
|
* will occur. |
| 252 |
|
|
*/ |
| 253 |
|
|
/* GD */ |
| 254 |
|
|
|
| 255 |
|
|
#define PERM_EXP_GAIN_RATIO 0.10f |
| 256 |
|
|
#define PERM_EXP_MAX_LOSS_RATIO 0.50f |
| 257 |
|
|
|
| 258 |
|
|
/* |
| 259 |
|
|
* WATCHDOG lets sends datagrams to port 13325 on localhost |
| 260 |
|
|
* in (more-or-less) regular intervals, so an external watchdog |
| 261 |
|
|
* program can kill the server if it hangs (for whatever reason). |
| 262 |
|
|
* It shouldn't hurt anyone if this is defined but you don't |
| 263 |
|
|
* have an watchdog program. |
| 264 |
|
|
*/ |
| 265 |
|
|
#ifndef WIN32 /* ***win32 disable watchdog as win32 default */ |
| 266 |
|
|
#define WATCHDOG |
| 267 |
|
|
#endif |
| 268 |
|
|
|
| 269 |
|
|
|
| 270 |
|
|
/* Enable the new material code - it needs some work. You can |
| 271 |
|
|
* enable this, and things will work, just you'll see a whole |
| 272 |
|
|
* bunch more materials show up, and thus a whole bunch more materials |
| 273 |
|
|
* in your inventory, and the sorting for them isn't really good. |
| 274 |
|
|
*/ |
| 275 |
|
|
|
| 276 |
|
|
/* |
| 277 |
|
|
#define NEW_MATERIAL_CODE |
| 278 |
|
|
*/ |
| 279 |
|
|
|
| 280 |
|
|
/*********************************************************************** |
| 281 |
|
|
* SECTION 2 - Machine/Compiler specific stuff. |
| 282 |
|
|
* |
| 283 |
|
|
* Short list of items: |
| 284 |
|
|
* COMPRESS_SUFFIX - selection of compression programs |
| 285 |
|
|
* O_NDELAY - If you don't have O_NDELAY, uncomment it. |
| 286 |
|
|
* |
| 287 |
|
|
***********************************************************************/ |
| 288 |
|
|
|
| 289 |
|
|
/* |
| 290 |
|
|
* If you compress your files to save space, set the COMPRESS_SUFFIX below |
| 291 |
|
|
* to the compression suffix you want (.Z, .gz, .bz2). The autoconf |
| 292 |
|
|
* should already find the program to use. If you set the suffix to |
| 293 |
|
|
* something that autoconf did not find, you are likely to have serious |
| 294 |
|
|
* problems, so make sure you have the appropriate compression tool installed |
| 295 |
|
|
* before you set this. You can look at the autoconf.h file to see |
| 296 |
|
|
* what compression tools it found (search for COMPRESS). |
| 297 |
|
|
* Note that this is used when saving files. Crossfire will search all |
| 298 |
|
|
* methods when loading a file to see if it finds a match |
| 299 |
|
|
*/ |
| 300 |
|
|
|
| 301 |
|
|
#ifndef COMPRESS_SUFFIX |
| 302 |
|
|
/* #define COMPRESS_SUFFIX ".Z" */ |
| 303 |
|
|
#endif |
| 304 |
|
|
|
| 305 |
|
|
/* If you get a complaint about O_NDELAY not being known/undefined, try |
| 306 |
|
|
* uncommenting this. |
| 307 |
|
|
* This may cause problems - O_NONBLOCK will return -1 on blocking writes |
| 308 |
|
|
* and set error to EAGAIN. O_NDELAY returns 0. This is only if no bytes |
| 309 |
|
|
* can be written - otherwise, the number of bytes written will be returned |
| 310 |
|
|
* for both modes. |
| 311 |
|
|
*/ |
| 312 |
|
|
|
| 313 |
|
|
/* |
| 314 |
|
|
#define O_NDELAY O_NONBLOCK |
| 315 |
|
|
*/ |
| 316 |
|
|
|
| 317 |
|
|
|
| 318 |
|
|
/*********************************************************************** |
| 319 |
|
|
* Section 3 |
| 320 |
|
|
* |
| 321 |
|
|
* General file and other defaults that don't need to be changed, and |
| 322 |
|
|
* do not change gameplay as percieved by players much. Some options |
| 323 |
|
|
* may affect memory consumption however. |
| 324 |
|
|
* |
| 325 |
|
|
* Values: |
| 326 |
|
|
* |
| 327 |
|
|
* BANFILE - ban certain users/hosts. |
| 328 |
|
|
* CSPORT - port to use for new client/server |
| 329 |
|
|
* DMFILE - file with dm/wizard access lists |
| 330 |
|
|
* LOGFILE - where to log if using -daemon option |
| 331 |
|
|
* MAP_ - various map timeout and swapping parameters |
| 332 |
|
|
* MAX_OBJECTS - how many objects to keep in memory. |
| 333 |
|
|
* MAX_OBJECTS_LWM - only swap maps out if below that value |
| 334 |
|
|
* MOTD - message of the day - printed each time someone joins the game |
| 335 |
|
|
* PERM_FILE - limit play times |
| 336 |
|
|
* SHUTDOWN - used when shutting down the server |
| 337 |
|
|
* SOCKETBUFSIZE - size of buffer used internally by the server for storing |
| 338 |
|
|
* backlogged messages. |
| 339 |
|
|
* TMPDIR - directory to use for temp files |
| 340 |
|
|
* UNIQUE_DIR - directory to put unique item files into |
| 341 |
|
|
* USE_CALLOC for some memory requests |
| 342 |
|
|
*********************************************************************** |
| 343 |
|
|
*/ |
| 344 |
|
|
|
| 345 |
|
|
/* |
| 346 |
|
|
* BANFILE - file used to ban certain sites from playing. See the example |
| 347 |
|
|
* ban_file for examples. |
| 348 |
|
|
*/ |
| 349 |
|
|
|
| 350 |
|
|
#ifndef BANFILE |
| 351 |
|
|
#define BANFILE "ban_file" |
| 352 |
|
|
#endif |
| 353 |
|
|
|
| 354 |
|
|
/* CSPORT is the port used for the new client/server code. Change |
| 355 |
|
|
* if desired. Only of relevance if ERIC_SERVER is set above |
| 356 |
|
|
*/ |
| 357 |
|
|
|
| 358 |
|
|
#define CSPORT 13327 /* old port + 1 */ |
| 359 |
|
|
|
| 360 |
|
|
|
| 361 |
|
|
/* |
| 362 |
|
|
* DMFILE |
| 363 |
|
|
* A file containing valid names that can be dm, one on each line. See |
| 364 |
|
|
* example dm_file for syntax help. |
| 365 |
|
|
*/ |
| 366 |
|
|
|
| 367 |
|
|
#ifndef DMFILE |
| 368 |
|
|
#define DMFILE "dm_file" |
| 369 |
|
|
#endif |
| 370 |
|
|
|
| 371 |
|
|
|
| 372 |
|
|
/* LOGFILE specifies which file to log to when playing with the |
| 373 |
|
|
* -daemon option. |
| 374 |
|
|
*/ |
| 375 |
|
|
|
| 376 |
|
|
#ifndef LOGFILE |
| 377 |
|
|
#ifdef WIN32 /* change define path */ |
| 378 |
|
|
#define LOGFILE "var\\crossfire.log" |
| 379 |
|
|
#else |
| 380 |
|
|
#define LOGFILE "/var/log/crossfire/logfile" |
| 381 |
|
|
#endif |
| 382 |
|
|
#endif |
| 383 |
|
|
|
| 384 |
|
|
/* |
| 385 |
|
|
* MAP_MAXTIMEOUT tells the maximum of ticks until a map is swapped out |
| 386 |
|
|
* after a player has left it. If it is set to 0, maps are |
| 387 |
|
|
* swapped out the instant the last player leaves it. |
| 388 |
|
|
* If you are low on memory, you should set this to 0. |
| 389 |
|
|
* Note that depending on the map timeout variable, the number of |
| 390 |
|
|
* objects can get quite high. This is because depending on the maps, |
| 391 |
|
|
* a player could be having the objects of several maps in memory |
| 392 |
|
|
* (the map he is in right now, and the ones he left recently.) |
| 393 |
|
|
* Each map has it's own TIMEOUT value and value field and it is |
| 394 |
|
|
* defaulted to 300 |
| 395 |
|
|
* |
| 396 |
|
|
* Having a nonzero value can be useful: If a player leaves a map (and thus |
| 397 |
|
|
* is on a new map), and realizes they want to go back pretty quickly, the |
| 398 |
|
|
* old map is still in memory, so don't need to go disk and get it. |
| 399 |
|
|
* |
| 400 |
|
|
* MAP_MINTIMEOUT is used as a minimum timeout value - if the map is set |
| 401 |
|
|
* to swap out in less than that many ticks, we use the MINTIMEOUT value |
| 402 |
|
|
* velow. If MINTIMEOUT > MAXTIMEOUT, MAXTIMEOUT will be used for all |
| 403 |
|
|
* maps. |
| 404 |
|
|
*/ |
| 405 |
|
|
|
| 406 |
|
|
/* How many ticks till maps are swapped out */ |
| 407 |
|
|
#define MAP_MAXTIMEOUT 1000 |
| 408 |
|
|
/* At least that many ticks before swapout */ |
| 409 |
|
|
#define MAP_MINTIMEOUT 500 |
| 410 |
|
|
|
| 411 |
|
|
/* |
| 412 |
|
|
* MAP_MAXRESET is the maximum time a map can have before being reset. It |
| 413 |
|
|
* will override the time value set in the map, if that time is longer than |
| 414 |
|
|
* MAP_MAXRESET. This value is in seconds. If you are low on space on the |
| 415 |
|
|
* TMPDIR device, set this value to somethign small. The default |
| 416 |
|
|
* value in the map object is MAP_DEFAULTRESET (given in seconds.) |
| 417 |
|
|
* I personally like 1 hour myself, for solo play. It is long enough that |
| 418 |
|
|
* maps won't be resetting as a solve a quest, but short enough that some |
| 419 |
|
|
* maps (like shops and inns) will be reset during the time I play. |
| 420 |
|
|
* Comment out MAP_MAXRESET time if you always want to use the value |
| 421 |
|
|
* in the map archetype. |
| 422 |
|
|
*/ |
| 423 |
|
|
|
| 424 |
|
|
/* Maximum time to reset. */ |
| 425 |
|
|
#define MAP_MAXRESET 7200 |
| 426 |
|
|
/* Default time to reset. */ |
| 427 |
|
|
#define MAP_DEFAULTRESET 7200 |
| 428 |
|
|
|
| 429 |
|
|
/* |
| 430 |
|
|
* MAX_OBJECTS is no hard limit. If this limit is exceeded, crossfire |
| 431 |
|
|
* will look for maps which are already scheldued for swapping, and |
| 432 |
|
|
* promptly swap them out before new maps are being loaded. |
| 433 |
|
|
* If playing only by yourself, this number can probably be as low as |
| 434 |
|
|
* 3000. If in server mode, probably figure about 1000-2000 objects per |
| 435 |
|
|
* active player (if they typically play on different maps), for some guess |
| 436 |
|
|
* on how many to define. If it is too low, maps just get swapped out |
| 437 |
|
|
* immediately, causing a performance hit. If it is too high, the program |
| 438 |
|
|
* consumes more memory. If you have gobs of free memory, a high number |
| 439 |
|
|
* might not be a bad idea. Each object is around 350 bytes right now. |
| 440 |
|
|
* 25000 is about 8.5 MB |
| 441 |
|
|
*/ |
| 442 |
|
|
|
| 443 |
|
|
#define MAX_OBJECTS 100000 |
| 444 |
|
|
|
| 445 |
|
|
/* |
| 446 |
|
|
* Max objects low water mark (lwm). If defined, the map swapping strategy |
| 447 |
|
|
* is a bit different: |
| 448 |
|
|
* 1) We only start swapping maps if the number of objects in use is |
| 449 |
|
|
* greater than MAX_OBJECTS above. |
| 450 |
|
|
* 2) We keep swapping maps until there are no more maps to swap or the number |
| 451 |
|
|
* of used objects drop below this low water mark value. |
| 452 |
|
|
* |
| 453 |
|
|
* If this is not defined, maps are swapped out on the timeout value above, |
| 454 |
|
|
* or if the number of objects used is greater than MAX_OBJECTS above. |
| 455 |
|
|
* |
| 456 |
|
|
* Note: While this will prevent the pauses noticed when saving maps, there |
| 457 |
|
|
* can instead be cpu performance penalties - any objects in memory get |
| 458 |
|
|
* processed. So if there are 4000 objects in memory, and 1000 of them |
| 459 |
|
|
* are living objects, the system will process all 1000 objects each tick. |
| 460 |
|
|
* With swapping enable, maybe 600 of the objects would have gotten swapped |
| 461 |
|
|
* out. This is less likely a problem with a smaller number of MAX_OBJECTS |
| 462 |
|
|
* than if it is very large. |
| 463 |
|
|
* Also, the pauses you do get can be worse, as if you enter a map with |
| 464 |
|
|
* a lot of new objects and go above MAX_OBJECTS, it may have to swap out |
| 465 |
|
|
* many maps to get below the low water mark. |
| 466 |
|
|
*/ |
| 467 |
|
|
|
| 468 |
|
|
/*#define MAX_OBJECTS_LWM MAX_OBJECTS/2*/ |
| 469 |
|
|
|
| 470 |
|
|
/* |
| 471 |
|
|
* Turning on MEMORY_DEBUG slows down execution, but makes it easier |
| 472 |
|
|
* to find memory corruption and leaks. Currently, the main thing |
| 473 |
|
|
* that happens with this activated is that one malloc is done for |
| 474 |
|
|
* each object - thus whatever debugging mechanism the malloc library |
| 475 |
|
|
* (or other debugging tool provides, like purify), it can track this |
| 476 |
|
|
* individual malloc. Default behaviour when turned off is that |
| 477 |
|
|
* enough memory is malloced for a large group of objects so malloc does |
| 478 |
|
|
* not need to be called as often. |
| 479 |
|
|
* This should only be turned on if some form of memory debugging tool |
| 480 |
|
|
* is being used - otherwise, turning this on will cause some performance |
| 481 |
|
|
* hit with no useful advantage. |
| 482 |
|
|
*/ |
| 483 |
|
|
|
| 484 |
|
|
/*#define MEMORY_DEBUG*/ |
| 485 |
|
|
|
| 486 |
|
|
|
| 487 |
|
|
/* |
| 488 |
|
|
* If you want to have a Message Of The Day file, define MOTD to be |
| 489 |
|
|
* the file with the message. If the file doesn't exist or if it |
| 490 |
|
|
* is empty, no message will be displayed. |
| 491 |
|
|
* (It resides in the CONFDIR directory) |
| 492 |
|
|
*/ |
| 493 |
|
|
|
| 494 |
|
|
#define MOTD "motd" |
| 495 |
|
|
|
| 496 |
|
|
/* |
| 497 |
|
|
* You can restrict playing in certain times by creating a PERMIT_FILE |
| 498 |
|
|
* in CONFDIR. See the sample for usage notes. |
| 499 |
|
|
*/ |
| 500 |
|
|
|
| 501 |
|
|
#define PERM_FILE "forbid" |
| 502 |
|
|
|
| 503 |
|
|
/* |
| 504 |
|
|
* If you want to take the game down while installing new versions, or |
| 505 |
|
|
* for other reasons, put a message into the SHUTDOWN_FILE file. |
| 506 |
|
|
* Remember to delete it when you open the game again. |
| 507 |
|
|
* (It resides in the CONFDIR directory) |
| 508 |
|
|
*/ |
| 509 |
|
|
|
| 510 |
|
|
#ifndef SHUTDOWN_FILE |
| 511 |
|
|
#define SHUTDOWN_FILE "shutdown" |
| 512 |
|
|
#endif |
| 513 |
|
|
|
| 514 |
|
|
|
| 515 |
|
|
/* |
| 516 |
|
|
* SOCKETBUFSIZE is the size of the buffer used internally by the server for |
| 517 |
|
|
* storing backlogged messages for the client. This is not operating system |
| 518 |
|
|
* buffers or the like. This amount is used per connection (client). |
| 519 |
|
|
* This buffer is in addition to OS buffers, so it may not need to be very |
| 520 |
|
|
* large. When the OS buffer and this buffer is exhausted, the server |
| 521 |
|
|
* will drop the client connection for falling too far behind. So if |
| 522 |
|
|
* you have very slow client connections, a larger value may be |
| 523 |
|
|
* warranted. |
| 524 |
|
|
*/ |
| 525 |
|
|
|
| 526 |
|
|
#define SOCKETBUFSIZE 128*1024 |
| 527 |
|
|
|
| 528 |
|
|
/* |
| 529 |
|
|
* Your tmp-directory should be large enough to hold the uncompressed |
| 530 |
|
|
* map-files for all who are playing. |
| 531 |
|
|
* It ought to be locally mounted, since the function used to generate |
| 532 |
|
|
* unique temporary filenames isn't guaranteed to work over NFS or AFS |
| 533 |
|
|
* On the other hand, if you know that only one crossfire server will be |
| 534 |
|
|
* running using this temporary directory, it is likely to be safe to use |
| 535 |
|
|
* something that is NFS mounted (but performance may suffer as NFS is |
| 536 |
|
|
* slower than local disk) |
| 537 |
|
|
*/ |
| 538 |
|
|
|
| 539 |
|
|
/*#define TMPDIR "/home/hugin/a/crossfire/crossfire/tmp"*/ |
| 540 |
|
|
#ifdef WIN32 /* change define path tmp */ |
| 541 |
|
|
#define TMPDIR "tmp" |
| 542 |
|
|
#else |
| 543 |
|
|
#define TMPDIR "/tmp" |
| 544 |
|
|
#endif |
| 545 |
|
|
|
| 546 |
|
|
|
| 547 |
|
|
/* Directory to use for unique items. This is placed into the 'lib' |
| 548 |
|
|
* directory. Changing this will cause any old unique items file |
| 549 |
|
|
* not to be used. |
| 550 |
|
|
*/ |
| 551 |
|
|
#define UNIQUE_DIR "unique-items" |
| 552 |
|
|
|
| 553 |
|
|
/* |
| 554 |
|
|
* If undefined, malloc is always used. |
| 555 |
|
|
* It looks like this can be oboleted. However, it can be useful to |
| 556 |
|
|
* track down some bugs, as it will make sure that the entire data structure |
| 557 |
|
|
* is set to 0, at the expense of speed. |
| 558 |
|
|
* Rupert Goldie has run Purify against the code, and if this is disabled, |
| 559 |
|
|
* apparantly there are a lot of uninitialized memory reads - I haven't |
| 560 |
|
|
* seen any problem (maybe the memory reads are copies, and the destination |
| 561 |
|
|
* doesn't actually use the garbage values either?), but the impact on speed |
| 562 |
|
|
* of using this probably isn't great, and should make things more stable. |
| 563 |
|
|
* Msw 8-9-97 |
| 564 |
|
|
*/ |
| 565 |
|
|
#define USE_CALLOC |
| 566 |
|
|
|
| 567 |
|
|
|
| 568 |
|
|
/* |
| 569 |
|
|
* These define the players starting map and location on that map, and where |
| 570 |
|
|
* emergency saves are defined. This should be left as is unless you make |
| 571 |
|
|
* major changes to the map. |
| 572 |
|
|
*/ |
| 573 |
|
|
|
| 574 |
|
|
#ifdef WIN32 /* change define path city */ |
| 575 |
|
|
|
| 576 |
|
|
# define EMERGENCY_MAPPATH "\\city\\city" |
| 577 |
|
|
# define EMERGENCY_X 15 |
| 578 |
|
|
# define EMERGENCY_Y 19 |
| 579 |
|
|
#else |
| 580 |
|
|
# define EMERGENCY_MAPPATH "/city/city" |
| 581 |
|
|
# define EMERGENCY_X 15 |
| 582 |
|
|
# define EMERGENCY_Y 19 |
| 583 |
|
|
#endif |
| 584 |
|
|
|
| 585 |
|
|
|
| 586 |
|
|
/* |
| 587 |
|
|
* These defines tells where, relative to LIBDIR, the maps, the map-index, |
| 588 |
|
|
* archetypes highscore and treaures files and directories can be found. |
| 589 |
|
|
*/ |
| 590 |
|
|
|
| 591 |
|
|
#define MAPDIR "maps" |
| 592 |
|
|
#define TEMPLATE_DIR "template-maps" |
| 593 |
|
|
#define ARCHETYPES "archetypes" |
| 594 |
|
|
#define REGIONS "regions" |
| 595 |
|
|
#define HIGHSCORE "highscore" |
| 596 |
|
|
#define TREASURES "treasures" |
| 597 |
|
|
#define BANISHFILE "banish_file" |
| 598 |
|
|
|
| 599 |
|
|
#define MAX_ERRORS 25 /* Bail out if more are received during tick */ |
| 600 |
|
|
#define STARTMAX 500 /* How big array of objects to start with */ |
| 601 |
|
|
#define OBJ_EXPAND 100 /* How big steps to use when expanding array */ |
| 602 |
|
|
|
| 603 |
|
|
#define HIGHSCORE_LENGTH 1000 /* How many entries there are room for */ |
| 604 |
|
|
|
| 605 |
|
|
#define ARCHTABLE 5003 /* Used when hashing archetypes */ |
| 606 |
|
|
#define MAXSTRING 20 |
| 607 |
|
|
|
| 608 |
|
|
#define COMMAND_HASH_SIZE 107 /* If you change this, delete all characters :) */ |
| 609 |
|
|
|
| 610 |
|
|
|
| 611 |
|
|
|
| 612 |
|
|
/*********************************************************************** |
| 613 |
|
|
* Section 4 - save player options. |
| 614 |
|
|
* |
| 615 |
|
|
* There are a lot of things that deal with the save files, and what |
| 616 |
|
|
* gets saved with them, so I put them in there own section. |
| 617 |
|
|
* |
| 618 |
|
|
***********************************************************************/ |
| 619 |
|
|
|
| 620 |
|
|
/* |
| 621 |
|
|
* If you want the players to be able to save their characters between |
| 622 |
|
|
* games, define SAVE_PLAYER and set PLAYERDIR to the directories |
| 623 |
|
|
* where the player-files will be put. |
| 624 |
|
|
* Remember to create the directory (make install will do that though). |
| 625 |
|
|
* |
| 626 |
|
|
* If you intend to run a central server, and not allow the players to |
| 627 |
|
|
* start their own crossfire, you won't need to define this. |
| 628 |
|
|
* |
| 629 |
|
|
*/ |
| 630 |
|
|
|
| 631 |
|
|
#ifndef PLAYERDIR |
| 632 |
|
|
#define PLAYERDIR "players" |
| 633 |
|
|
#endif |
| 634 |
|
|
|
| 635 |
|
|
/* |
| 636 |
|
|
* If you have defined SAVE_PLAYER, you might want to change this, too. |
| 637 |
|
|
* This is the access rights for the players savefiles. |
| 638 |
|
|
* Given that crossfire runs in a client/server model, there should |
| 639 |
|
|
* be no issue setting these to be quite restrictive (600 and 700). |
| 640 |
|
|
* Before client/server, multiple people might run the executable, |
| 641 |
|
|
* thus requiring that the server be setuid/setgid, and more generous |
| 642 |
|
|
* permisisons needed. |
| 643 |
|
|
* SAVE_MODE is permissions for the files, SAVE_DIR_MODE is permission |
| 644 |
|
|
* for nay directories created. |
| 645 |
|
|
*/ |
| 646 |
|
|
#define SAVE_MODE 0660 |
| 647 |
|
|
#define SAVE_DIR_MODE 0770 |
| 648 |
|
|
|
| 649 |
|
|
/* NOTE ON SAVE_INTERVAL and AUTOSAVE: Only one of these two really |
| 650 |
|
|
* needs to be selected. You can set both, and things will work fine, |
| 651 |
|
|
* however, it just means that a lot more saving will be done, which |
| 652 |
|
|
* can slow things down some. |
| 653 |
|
|
*/ |
| 654 |
|
|
|
| 655 |
|
|
/* How often (in seconds) the player is saved if he drops things. If it is |
| 656 |
|
|
* set to 0, the player will be saved for every item he drops. Otherwise, |
| 657 |
|
|
* if the player drops and item, and the last time he was saved |
| 658 |
|
|
* due to item drop is longer |
| 659 |
|
|
* the SAVE_INTERVAL seconds, he is then saved. Depending on your playing |
| 660 |
|
|
* environment, you may want to set this to a higher value, so that |
| 661 |
|
|
* you are not spending too much time saving the characters. |
| 662 |
|
|
* This option should now work (Crossfire 0.90.5) |
| 663 |
|
|
*/ |
| 664 |
|
|
|
| 665 |
|
|
/*#define SAVE_INTERVAL 300*/ |
| 666 |
|
|
|
| 667 |
|
|
/* |
| 668 |
|
|
* AUTOSAVE saves the player every AUTOSAVE ticks. A value of |
| 669 |
|
|
* 5000 with MAX_TIME set at 120,000 means that the player will be |
| 670 |
|
|
* saved every 10 minutes. Some effort should probably be made to |
| 671 |
|
|
* spread out these saves, but that might be more effort than it is |
| 672 |
|
|
* worth (Depending on the spacing, if enough players log on, the spacing |
| 673 |
|
|
* may not be large enough to save all of them.) As it is now, it will |
| 674 |
|
|
* just set the base tick of when they log on, which should keep the |
| 675 |
|
|
* saves pretty well spread out (in a fairly random fashion.) |
| 676 |
|
|
*/ |
| 677 |
|
|
|
| 678 |
|
|
#define AUTOSAVE 5000 |
| 679 |
|
|
|
| 680 |
|
|
/* Often, emergency save fails because the memory corruption that caused |
| 681 |
|
|
* the crash has trashed the characters too. Define NO_EMERGENCY_SAVE |
| 682 |
|
|
* to disable emergency saves. This actually does |
| 683 |
|
|
* prevent emergency saves now (Version 0.90.5). |
| 684 |
|
|
*/ |
| 685 |
|
|
|
| 686 |
|
|
#define NO_EMERGENCY_SAVE |
| 687 |
|
|
|
| 688 |
|
|
/* By selecting the following, whenever a player does a backup save (with |
| 689 |
|
|
* the 'save command), the player will be saved at home (EMERGENCY_MAP_* |
| 690 |
|
|
* information that is specified later). IF this is not set, the player |
| 691 |
|
|
* will be saved at his present location. |
| 692 |
|
|
*/ |
| 693 |
|
|
|
| 694 |
|
|
/*#define BACKUP_SAVE_AT_HOME*/ |
| 695 |
|
|
|
| 696 |
|
|
/* RESET_LOCATION_TIME is the number of seconds that must elapse before |
| 697 |
|
|
* we fill return the player to his savebed location. If this is zero, |
| 698 |
|
|
* this feature is disabled (player will resume where ever he was |
| 699 |
|
|
* when he last logged off). If this is set to less than two hours, |
| 700 |
|
|
* it will prevent players from camping out in treasure rooms. |
| 701 |
|
|
* Do not comment this out - it must be set to something - if you |
| 702 |
|
|
* comment this out, the program will not compile. |
| 703 |
|
|
* |
| 704 |
|
|
* This will work to BACKUP_SAVE_AT_HOME at home above, but where the player |
| 705 |
|
|
* where appear under what conditions is a little complicated depending |
| 706 |
|
|
* on how the player exited the game. But if the elapsed time is greater than |
| 707 |
|
|
* the value below, player will always get returned to savebed location |
| 708 |
|
|
* location. |
| 709 |
|
|
* |
| 710 |
|
|
* Set to one hour as default |
| 711 |
|
|
*/ |
| 712 |
|
|
|
| 713 |
|
|
#define RESET_LOCATION_TIME 3600 |
| 714 |
|
|
|