Andreas Vogl wrote: >> 1) Weather effects - not sure exactly what they were going to >> be, garbled was going to work on that. > > > So this code for map-overlays has somehow made it into > CVS and at least it seems to consume memory and appears a lot in > the logs. Is it true that there is no use for it till today? > Are there still plans by anyone (Garbled?) to keep developing on > this particular part in the future? Since the code isn't really used for anything, it shouldn't consume any memory (save for the few K of compiled code.). I eventually see replacing some of the unique map code with this - the files it generates are in 'standard map format', where as the unique items files are not - this means you could load overlay maps into the editor just to see status or if something is messed up. > > I'm not so sure about that one. Wouldn't that consume a lot > of effort storing all this information about roading somewhere? > And the outcome might be road-tiles appearing everywhere, > including places where they are unwanted, potentially burrying > some nice maps around cities. > Roads would look totally uneven, making players loose orientation... The way I would do it: 1) Store number of times this space has been visited in the lowest floor space. This actually wouldn't cost much - since check_walk_on is called whenever something moves onto a space, and it looks at all the objects on the space to see if any have walk_on set, just put code in there to increment the counter. 2) The weather code, which periodically runs, would be modified to do the following (this doesn't need to be in weather - anything the periodically 'visits' the maps could do this: a) reduce the visit count set in #1 below (decompose space). b) Look at above value, and do one of the following: If space has high enough visit count, and doesn't already have a 'path like' object, at one. If space visit count is too low and it current has a path, remove the path. The trickiest part is the adding and removing of paths, and the spaces around need to be examined to see their state to know what type of path to add. For example, if you have spaces like: 123 456 789 (presume the spaces around those all have high enough visit counts to warrant paths) If space 2, 4, 5 have high enough visit counts, then on 4 you would add a horizontal path, and 5 a curved path (from 4 to 2), and 2 a vertical patch. If in addition to the above, 6 was also high enough, then 6 would get a horizontal path, and 5 T path. If for example 4 and 5 only had enough visit values, then 4 would get the horizontal, and 5 and horizontal dead end. If my math is right, and we only do 4 directions, 24 path objects would be needed - however, most of those are just rotations or mirrors - what you really need is a straight, dead end, curve, T, and 4 way - this is only 5 images. The hardest part is dealing at the map edges (tiled with others) - you need to know what that tiled map is doing on your connected spaces to know how you should arrange your spaces. Probably the best way to do this is for say map A to make all its paths. For spaces along the edges that tile with another map, it looks at the adjoining space on that tiled map, and see what to do (make an path in that direction or not). If we are changing the behaviour on the map we are updating, we also update the one on the tiled map to link in right - when the tiled map gets processed for its weather, it might further redo these (as some of those spaces get aged out). The 'biggest' thing is to try to do this processing when the server is idle, or mostly idle (eg, player hanging out in town), not when someone is in the middle of a combat.