TECHNICAL INFORMATION ABOUT MAPS: This documented is intended to convey technical information on how crossfire deals with the map objects and objects placed on the maps. For the most part, I only intend document how the new code works, and not go too much into history on the older methods. A lot of the map code was re-written in early July 2001, which changed how many things are dealt with. Mark Wedel July 7, 2001 ------------------------------------------------------------------------------ THE MAP HEADER: The map header is the section at the start of the map file that describes the maps characteristics. The values are described below. The map variables now make some sense, and are only stored in the map structure itself. I still include the old value (the 'was') so if you are looking at old maps, you know what they mean. Generally speaking, the values in the map files themselves match the same element name in the map structure. 'width','height', was 'x','y': Size of the map. 'enter_x', 'enter_y', was ('hp','sp') = (x,y) of the destination on the new map. These are only used if the exit does not have a specific location set. 'reset_timeout', was 'weight': stores the number of seconds that need to elapse before this map will be reset. Ie, if 1800, it means this map expires after 30 minutes. This value is not modified once loaded - instead reset_time is used to track this. The value 0 means to use a default timeout (MAP_DEFAULTRESET). 'swap_time', was 'value': This controls how many ticks must elapse after the map has not been used before it gets swapped out. swapping out is different than reset, as a swapped out map will get loaded back into memory if someone re-visits it before it is due to reset. 'difficulty', was 'level' stores the map difficulty. If not set to anything, the server code will try to come up with some difficulty value. 'fixed_resettime', was 'stand_still': If nonzero, the map reset time will not be updated when someone enters/exits the map. Thus, once the map has been loaded, it will reset in 'reset time' no matter what access happen. This is useful for shops and towns, which are constantly accessed, but should be reset periodically. 'darkness', was 'invisible'. Light/darnkess of map (overall). If 0, all of map is fully bright. 'unique' - if set, this entire map is unique. Exactly unique to what will depend on how it was created (it could be a per player unique map, or maybe a common map that is just permanent for all the players. 'nosmooth' - if set, no faces in this map will be smoothed. 'outdoor' - if set, this is a hint that this is an outdoor map. If this is not set, weather and dawn/dusk will not occur on this map. It is highly advised that this be set appropriately. tile_path_ - Used with map tiling. is a number, 1 is north, 2 is east, 3 south, 4 west. This determines what map is tiled in that direction. See the section below for more information about map tiling. 'shopitems', 'shopgreed', 'shoprace', 'shopmin', 'shopmax' - the type of thing the shop trades in, see doc/Developers/shops for more details 'temp' - The base temperature in farenhiet for this map. The temperature is modified by the season and weather conditions. In a map without weather effects, this temperature will be used as the static temperature for the entire map. This can be useful to make an ice cave actually cold. 'pressure' - This should really never be set on a map. The pressure in millibars. 'humid' - Again, should rarely be set on a map. The humidity in percent. 'windspeed' - Rarely set. The windspeed in kph/h. 'winddir' - Rarely set. Direction of wind, 1-8, 1 is north, clockwise. 'sky' - The sky conditions for this map. See weather.h. Don't set this unless you really know what you are doing. ------------------------------------------------------------------------------ THE MAP OBJECTS: The objects within the map are saved in standard 'object save' form (same as is used for the players objects). Other files document the actual meaning, but the general form is: arch x y end Note that x and y are in fact optional. If not present, the values default to zero. Multipart objects: Multipart objects pose a tricky problem, in that they have to appear together in the map file - this makes proper handling of layers hard to deal with. In old map code, all the single spaces objects were saved, and then all the multi part objects were saved. This effectively means that the multi part objects always ended up on top. The multipart objects were saved with all their parts. For example: slaying shops/magicshop hp 14 sp 14 x 1 y 13 end More arch store_magic_2 name Magic Shop slaying shops/magicshop hp 14 sp 14 x 2 y 13 end This method does not work very well with the map tiling however (how do you reasonably deal with a monster that may be straddling the two maps?) Current code now only saves the head of the object. When the map is loaded, the objects on the map are examined to see what objects need to have more objects added on. Additional parts linked in are put just above floor level when linked in, so things like shops won't hide items that someone drops on them. For monsters, this linking shouldn't be a problem - once they start moving, they will get relinked as normal (on top). The effect of saving only the head does have the effect of not being able to customize the non head parts of the object. This generally should not be a problem (in the case of shops/building, the exit code now knows to look only at the head for valid information). The case where this may not work as well as expected is for buildings where setting the no_pass to non archetype defaults will get lost. ------------------------------------------------------------------------------ Map Tiling: Map tiling is a feature that lets multiple maps be connected, effectively forming a much larger single map. This is most useful for the outdoor world maps, where it is not practical to have on massive map, but the old style tiling method (copying areas of the adjoining map to the next one) are not very efficient. The transfer of objects from one map to another tiled map are automatic. Presuming the proper macros are used (out_of_map, get_map_..), minimal extra work is necessary for everything to work right Notes: Tiled maps must be the same width/height along the side they are tiled with. If map1 has a height of 15, and you want to tile along one of the sides, the map(s) it gets tiled with along that side should also be 15. Given the following diagram (not to scale): +---x1----+----x2---+ | | | | map1 | map2 y2 y1 | | | | | +---------+---------+ x1 is the width of map1, y1 is its height. x2 is the width of map2, y2 is its height. map1 will tile map2 as indicated in the above diagram. Given that, the following must be true: y1 must equal y2 x1 must be greater than 12 x2 must be greater than 12 x1 and x2 do not need to be equal The value is derived as being half the maximum viewable area. The reason for this is that the line of sight code (and likely some other code) will only look one map away from a source coordinate. While the values can be less than 12, they should be at least 12 if the map tiles with another one in that direction. If the map is an 'end' map (ie, no further tiling in a specific direction), then having a value less than 12 should work just fine. Note that tiles maps do not have to be symmetric - several maps could tile to a common map. That common map can only tile back to one of those. And example of where this might be used is for a courtyard of a multi floor house - that courtyard should be visible (and be the same) from all the levels, but you can only go from the courtyard to first floor rooms off the courtyard. This may not be ideal (ie, if flying, you should be able to go to any floor), but this tiling for elevation is just an example that can be used.