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