On 7/4/05, Mark Wedel <[EMAIL PROTECTED]> wrote: > Nicolas Weeger wrote: > >>2) Does anyone right now really use the magic map command? One thought > >>I've had would be to change it - instead of just sending the colors, it > >>instead sends the faces of everything (or maybe limit it to just the > >>floor/wall/other non living stuff?) this would probably make it useful. > > > > > > Yes, I use it often, to spot monsters on maps, and such. > > Sending faces could make more detailed maps. > > Also, maybe we could implement automapping? So player knows some maps > > already visited, and keep that knowledge between sessions. Maybe with > > a 'forget' factor, losing some details :) > > Yes, sending faces would make it more detailed - perhaps arguably too > detailed. OTOH, maybe not that bad if you go by the basis that for many maps > if > you've been there before, you sort of know what is around anyways. Certainly > by > sending faces, the client could use it to fill in a bunch of fog of war > spaces. > > As far as automapping, that can almost be done automatically on the client. > The real issue why it can't easily be done right now is that we hide the > coordinates that the player is on when they change maps. This is done because > without doing so, so maps become much simpler (if you can see where all the > teleporters are taking you, very easy to see where you need to go and where > you've been). > > A real example of this would be the electric church in brest. If > coordinates > are sent each time you fall through a bit, working your way through the maze > would be very easy. > > That said, while playing, it can be very annoying to step on a teleporter > and > have your entire known map go away, even when you step back through again. So > it really becomes balance on convenience vs trying to be secure. > > More random thoughts on client caching fog maps: > > 1) If some coder was really clever, they could automatically try to figure out > what map, and thus what cached fog map to use, based on data they see. A > simple > example is scorn - see 4 signs, a fountain, etc, and you'd easily identify > that > as scorn, and could load up the appropriate data. Many dungeons would be much > trickier because the data isn't as consistent or could be more ambiguous (and > client would have to catch that - did it guess the wrong map, or did someone > cast an earthwall?)
The current map can be gotten through the "mapinfo" command, though figuring out where you are located on a map, is more difficult; since you can make several locations look the same. > 2) If client was to cache maps, it'd need some logic, just like the server, to > time out maps that player hasn't visited for a while. For example, you don't > want megabytes of random maps stored away, which by definition, the player > can't > visit again. > > 3) Related to above, for random maps, map name may not be good enough to know > if > the right version is in use. Think of this case - server starts up, player > logs > in and goes to random dungeon (gets random0001). Server restarts, player > repeats - gets the same name, but since map is random it is not the same map. > Yet at the same time, there is some desire to remember random maps, like say > when going down through a random dungeon - if for some reason you leave and > come > back, would be handy to be able to see where you've been before and make it > that > much easier to get through. If the map's path (as returned by "mapinfo") ends in "random????", check to see if the suroundings match what was cached. > 4) Client caching maps wouldn't have to be that complicated, and wouldn't take > that much space. Could do something just like: > > mapsize 20 20 > space 0 0 > forest.111 > sign.111 > space 0 1 > cobblestone.111 > orc.111 > ... > > because after all, the only think the client knows is the face name/number. > It'd really need to store things by name since the face numbers can change > from > run to run (OTOH, it could be clever at create a bmaps file for each map that > contains the number to name map for the faces stored in the map, thus making > it > even easier to parse those cached maps). > > 5) Outdoor maps would need improved handling - right now, the client isn't > even > aware when the player moves across the tiles. It does have logic to recenter > and clear out the old data as needed, but to handle outdoor maps, it would > sort > of need some idea of where it is (which goes back up to telling the > coordinates). > > 6) It would be neat to have 'map' objects within the game that show a map. I > think tchize is working on adding image support to objects. But what I > envision > beyond that would be if you have one of these maps, and is actually where the > map displays its stuff, if you applied it, it would 'fill in' the area around > you on your map (fog of war) area. That brings in the question, of if there should be a cartography skill, and if map makers should be able to restrict it's use on some maps. I think the results of mapping the maze mikeeusa has been working on recently would prove to be interesting. (it would need to be mapped in more than 2 dimensions, since it uses tricks with tiling) In addition, I think the idea of having "bad" or inaccurate maps, for the purpose of misleading players, could prove interesting. -- Andrew Fuchs _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
