[crossfire] Re: Map Protocol Question

[Mark Wedel]

Alex Schultz wrote:

>
     
      Yes, based upon the issues you're talking about in the three above paragraphs, I
     
     >
     
      think I've thought of a system that should work well:
     
     >
     
      -Give exits and teleporters a new attribute which for the purpose of this
     
     >
     
      explaination will be rerfered to as 'secrettype'
     
     >
     
      -the 'secrettype' would be any value from 0 to 255, as well as -1
     
     >
     
      -a 'secrettype' of -1 means that the client receives no data about it's coord,
     
     >
     
      for what has been rerfered to as 'secret maps' in this conversation
     
     >
     
      -for values of 0 to 255, all coord data is send and the client.
     
     >
     
      -values of 0 to 255 are an id of sorts that is sent to the client, the client
     
     >
     
      then appends this to the mapname for storing purposes which fixes asthetics in
     
     >
     
      non-secret areas. To make it look nicer the client considers it a seperate map
     
     >
     
      for caching purposes even though it knows the coords on the real map.
     
     >
     
      -a exits and teleporters which do not have a 'secrettype' defined default to 0
     
     >
     
     
     >
     
      And maps that need secrettype set would need (either for plot, cheating, or
     
     >
     
      asthetics) to be set manually, possibly with the assistance of a script to
     
     >
     
      detect possible potential spots (i.e. maps with lots of teleporters to itself
     
     >
     
      would be good things for a script to look for).
     
     >
     
      This method would take significant effort to adjust old maps where applicable,
     
     >
     
      however I feel that it would provide the best end-user experience and would at
     
     >
     
      the same time be not too much harder to modify maps for than something like the
     
     >
     
      regions was.
     
     
  Why can't a global map flag (no_client_coords) or something be added?  That 
would seem to be a lot simper than having to update all those exits (other 
concern I have with that is if you mix an exit or you add a new one or whatever 
else, things are broken).

  While having a secret type lets the client be more clever, you also have the 
problem of conflicts (suppose a map maker accidentally uses the same secret type 
for 2 exits?)  that screws up the client.  There is also the case that many 
exits don't always exit to the same space (when using an exit, if the target 
space isn't free, it finds a nearby free space) - that is likely to screw up 
clients who think it should be on sapce X.

  The other gotcha here is that you now have to modify the exits that lead to 
the maps, and not the maps themselves - this also seems an extra level of 
complication.

I'm also not sure what that buys - imagine the case of a 3 level dungeon, with 
level 2 having secret coordinates.  The exit from 1 to 2 would have one secret 
value, and 3 to 2 a different one.  But the effect here is basically the same as 
having no secret type, because the client won't be able to easily resync when 
player goes from 3 to 2, because the secret types don't match, and thus the map 
names don't match, so client would have to use a completely new map (logically) 
for fog purposes.  However, see my notes about tiling on how that could perhaps 
apply here.

  I wonder if instead of sending -1 -1 as coordinates, some form of hash could 
instead be done based on the coordinates.  This also works better with the idea 
below of sending exit data


>
     
     
     >
     
      If the map name was sent with the newmap command, as well as tiling data (names
     
     >
     
      of the maps that it tiles to), then it could deal with tiled maps easily and
     
     >
     
      properly.
     
     
  Actually not, not as it is now.

  Imagine the case of maps A -> B -> C -> D

  player enters map A.  gets newmap info for map A.  Player then goes to map D, 
exits, and comes back on D.  In the case of the first exit, client would get 
connection from A -> B, but nothing more.  When player comes back on D, gets 
info from D -> C.  However, client has no idea of the B -> C connection.  Newmap 
protocol commands are not sent when moving across tiles maps, because tiled maps 
are suppose to be opaque to the user.

  This is a bigger consideration if you consider that the world maps are tiled, 
and often players are moving across 10's of transitions before changing exits.

  My thought to fix this is that when you exit a map, the newmap1 command 
includes the map name of what you just exited, as well as the coordinates you 
exited from.  This in a sense fixes the problem, because often you will come 
back on the map from the same place you exited.  So when you enter the store 
then exit, the client would more easily be able to reconnect to where you were.

  This doesn't fix the problem of players using word of recall or town portals 
for example.  Even dimension door may through things off.

  My initial thought about the client being able to figure it out is that the 
outside world tiles have a very clear naming scheme.  For example, if you are on 
world_110_110, I can tell you that it is 500 spaces to get to world_120_110 (50 
spaces/tile).

  the other thought is that perhaps that when players do make a tile transition, 
send some form of newmap1 command (perhaps include some flag in that command 
that includes something like 'is tile update - don't clear your old data'.