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'.
_______________________________________________
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
