1 |
TECHNICAL INFORMATION ABOUT MAPS: |
2 |
|
3 |
This documented is intended to convey technical information on how |
4 |
crossfire deals with the map objects and objects placed on the maps. For |
5 |
the most part, I only intend document how the new code works, and not |
6 |
go too much into history on the older methods. A lot of the map |
7 |
code was re-written in early July 2001, which changed how many things are |
8 |
dealt with. |
9 |
|
10 |
Mark Wedel |
11 |
July 7, 2001 |
12 |
|
13 |
------------------------------------------------------------------------------ |
14 |
THE MAP HEADER: |
15 |
|
16 |
The map header is the section at the start of the map file that |
17 |
describes the maps characteristics. The values are described below. |
18 |
|
19 |
The map variables now make some sense, and are only stored in the |
20 |
map structure itself. I still include the old value (the 'was') so |
21 |
if you are looking at old maps, you know what they mean. Generally |
22 |
speaking, the values in the map files themselves match the same element |
23 |
name in the map structure. |
24 |
|
25 |
'width','height', was 'x','y': Size of the map. |
26 |
|
27 |
'enter_x', 'enter_y', was ('hp','sp') = (x,y) of the destination on the |
28 |
new map. These are only used if the exit does not have a specific |
29 |
location set. |
30 |
|
31 |
'reset_timeout', was 'weight': stores the number of seconds that need |
32 |
to elapse before this map will be reset. Ie, if 1800, it means this |
33 |
map expires after 30 minutes. This value is not modified once loaded - |
34 |
instead reset_time is used to track this. The value 0 means to use |
35 |
a default timeout (MAP_DEFAULTRESET). |
36 |
|
37 |
'swap_time', was 'value': This controls how many ticks must elapse |
38 |
after the map has not been used before it gets swapped out. |
39 |
swapping out is different than reset, as a swapped out map will |
40 |
get loaded back into memory if someone re-visits it before it is due to |
41 |
reset. |
42 |
|
43 |
'difficulty', was 'level' stores the map difficulty. If not set to |
44 |
anything, the server code will try to come up with some difficulty value. |
45 |
|
46 |
'fixed_resettime', was 'stand_still': If nonzero, the map reset time will not |
47 |
be updated when someone enters/exits the map. Thus, once the map has |
48 |
been loaded, it will reset in 'reset time' no matter what access |
49 |
happen. This is useful for shops and towns, which are constantly |
50 |
accessed, but should be reset periodically. |
51 |
|
52 |
'darkness', was 'invisible'. Light/darnkess of map (overall). If 0, |
53 |
all of map is fully bright. |
54 |
|
55 |
'unique' - if set, this entire map is unique. Exactly unique to what |
56 |
will depend on how it was created (it could be a per player |
57 |
unique map, or maybe a common map that is just permanent for |
58 |
all the players. |
59 |
|
60 |
'outdoor' - if set, this is a hint that this is an outdoor map. |
61 |
If this is not set, weather and dawn/dusk will not occur on this |
62 |
map. It is highly advised that this be set appropriately. |
63 |
|
64 |
tile_path_<x> - Used with map tiling. <x> is a number, 1 is north, |
65 |
2 is east, 3 south, 4 west. This determines what map is tiled |
66 |
in that direction. See the section below for more information about |
67 |
map tiling. |
68 |
|
69 |
'shopitems', 'shopgreed', 'shoprace', 'shopmin', 'shopmax' - the type of thing |
70 |
the shop trades in, see doc/Developers/shops for more details |
71 |
|
72 |
'temp' - The base temperature in farenhiet for this map. The temperature |
73 |
is modified by the season and weather conditions. In a map without |
74 |
weather effects, this temperature will be used as the static |
75 |
temperature for the entire map. This can be useful to make an ice |
76 |
cave actually cold. |
77 |
|
78 |
'pressure' - This should really never be set on a map. The pressure in |
79 |
millibars. |
80 |
|
81 |
'humid' - Again, should rarely be set on a map. The humidity in percent. |
82 |
|
83 |
'windspeed' - Rarely set. The windspeed in kph/h. |
84 |
|
85 |
'winddir' - Rarely set. Direction of wind, 1-8, 1 is north, clockwise. |
86 |
|
87 |
'sky' - The sky conditions for this map. See weather.h. Don't set this |
88 |
unless you really know what you are doing. |
89 |
|
90 |
------------------------------------------------------------------------------ |
91 |
THE MAP OBJECTS: |
92 |
|
93 |
The objects within the map are saved in standard 'object save' form |
94 |
(same as is used for the players objects). Other files document the |
95 |
actual meaning, but the general form is: |
96 |
|
97 |
arch <some name> |
98 |
x <some value> |
99 |
y <some value> |
100 |
<other object specific values> |
101 |
end |
102 |
|
103 |
Note that x and y are in fact optional. If not present, the values |
104 |
default to zero. |
105 |
|
106 |
Multipart objects: |
107 |
|
108 |
Multipart objects pose a tricky problem, in that they have to |
109 |
appear together in the map file - this makes proper handling of |
110 |
layers hard to deal with. |
111 |
|
112 |
In old map code, all the single spaces objects were saved, and |
113 |
then all the multi part objects were saved. This effectively |
114 |
means that the multi part objects always ended up on top. The multipart |
115 |
objects were saved with all their parts. For example: |
116 |
|
117 |
slaying shops/magicshop |
118 |
hp 14 |
119 |
sp 14 |
120 |
x 1 |
121 |
y 13 |
122 |
end |
123 |
More |
124 |
arch store_magic_2 |
125 |
name Magic Shop |
126 |
slaying shops/magicshop |
127 |
hp 14 |
128 |
sp 14 |
129 |
x 2 |
130 |
y 13 |
131 |
end |
132 |
<snip - there are really two more parts> |
133 |
|
134 |
This method does not work very well with the map tiling however (how do you |
135 |
reasonably deal with a monster that may be straddling the two maps?) Current |
136 |
code now only saves the head of the object. When the map is loaded, the |
137 |
objects on the map are examined to see what objects need to have more objects |
138 |
added on. Additional parts linked in are put just above floor level when |
139 |
linked in, so things like shops won't hide items that someone drops on them. |
140 |
For monsters, this linking shouldn't be a problem - once they start moving, |
141 |
they will get relinked as normal (on top). |
142 |
|
143 |
The effect of saving only the head does have the effect of not being |
144 |
able to customize the non head parts of the object. This generally should not |
145 |
be a problem (in the case of shops/building, the exit code now knows to look |
146 |
only at the head for valid information). The case where this may not work as |
147 |
well as expected is for buildings where setting the no_pass to non |
148 |
archetype defaults will get lost. |
149 |
|
150 |
------------------------------------------------------------------------------ |
151 |
Map Tiling: |
152 |
|
153 |
Map tiling is a feature that lets multiple maps be connected, effectively |
154 |
forming a much larger single map. This is most useful for the outdoor |
155 |
world maps, where it is not practical to have on massive map, but |
156 |
the old style tiling method (copying areas of the adjoining map to the next |
157 |
one) are not very efficient. |
158 |
|
159 |
The transfer of objects from one map to another tiled map are automatic. |
160 |
Presuming the proper macros are used (out_of_map, get_map_..), minimal extra |
161 |
work is necessary for everything to work right |
162 |
|
163 |
Notes: |
164 |
Tiled maps must be the same width/height along the side they are tiled with. |
165 |
If map1 has a height of 15, and you want to tile along one of the sides, the |
166 |
map(s) it gets tiled with along that side should also be 15. Given |
167 |
the following diagram (not to scale): |
168 |
|
169 |
|
170 |
+---x1----+----x2---+ |
171 |
| | | |
172 |
| map1 | map2 y2 |
173 |
y1 | | |
174 |
| | | |
175 |
+---------+---------+ |
176 |
|
177 |
x1 is the width of map1, y1 is its height. |
178 |
x2 is the width of map2, y2 is its height. |
179 |
map1 will tile map2 as indicated in the above diagram. |
180 |
|
181 |
Given that, the following must be true: |
182 |
y1 must equal y2 |
183 |
x1 must be greater than 12 |
184 |
x2 must be greater than 12 |
185 |
x1 and x2 do not need to be equal |
186 |
|
187 |
The value is derived as being half the maximum viewable area. The reason |
188 |
for this is that the line of sight code (and likely some other code) will only |
189 |
look one map away from a source coordinate. While the values can be less |
190 |
than 12, they should be at least 12 if the map tiles with another one in |
191 |
that direction. If the map is an 'end' map (ie, no further tiling in a |
192 |
specific direction), then having a value less than 12 should work just fine. |
193 |
|
194 |
Note that tiles maps do not have to be symmetric - several maps |
195 |
could tile to a common map. That common map can only tile back to one of |
196 |
those. And example of where this might be used is for a courtyard of |
197 |
a multi floor house - that courtyard should be visible (and be the same) |
198 |
from all the levels, but you can only go from the courtyard to first floor |
199 |
rooms off the courtyard. This may not be ideal (ie, if flying, you should |
200 |
be able to go to any floor), but this tiling for elevation is just an |
201 |
example that can be used. |