interserver teleporters? Combined client/server?

[general_failure]

Hi there.
I've been playing around with the crossfire Client and Server, exploring its capabilities.
Given the way it works, it looks to me like an interserver teleporter is possible, probably with a bit of extra work on the server code. Am I wrong in this assumption?

I believe that it's already possible to get mapdata from a server and also copy player data to another server, more or less.

This opens up the possibility of mini-servers built into a special client build, allowing players to hop between servers and host their own mini-worlds (or big ones if they felt like it). I know there's a lot of obstacles to overcome for it to work properly, but Crossfire is almost capable of all this now.

I'm only bringing this up because I wrote up a game design brief on a sort of peer to peer game a few months back. Then I started to play with Crossfire and realised that it was very close to my idea. So close that I instantly abandoned it.

I think I'm asking a few things here:

* Is what I'm asking possible?
- If so, will any of the features be added (ie server hops)
- If they won't be, would anyone mind if I had a crack at it myself? not as a part of the crossfire project of course.

* If the code already supports any of the features somewhere, where do I find it so I can learn how its implementation functions?

Hope I'm not wasting everyone's time with this. Thanks.

[cavesomething]

I'll prefix this post with a brief outline of how the server works currently.

The unit of time is a 'tick' which is (in theory) 1/8 of a second.

The servers world is made up of objects, which are in one big linked list, with various offshoot lists. (eg, player objects point to the objects that make up their inventory, items in containers point to their container, etc). These objects all reside in maps, which contain squares that also point to the objects in them.

players are also represented by a more abstract struct, which holds the object that represents them, but also data specific to players (like the socket they are connected on).

when a player logs in, the player and all his objects are inserted into that list, with the correct connections between them, when a player logs out, they are removed from these lists (but saved to a file)

in order to transfer a player between servers then, you would want to logout the player, tell the client to connect to the new server, and send the new server the player file.

I've been playing around with the crossfire Client and Server, exploring its capabilities.
Given the way it works, it looks to me like an interserver teleporter is possible, probably with a bit of extra work on the server code. Am I wrong in this assumption?

this has been discussed before; have a look at http://forum.metalforge.net/viewtopic.p ... ht=connect

However, no one has yet done this, in principle it would be relatively straightforward to have a technically functioning solution, but the game integrity issues are more interesting (hard).

The server-server communication layer doesn't exist, so this would need to be written or adapted from somewhere, that isn't an insurmountable problem however. (see below on that point)

Probably the way you would have to write it would be to have an exit with a slaying field which would have something like $REMOTE-hostname:/path/to/map/ then you would save the character, send the character file across to the remote server, and tell the client to establish a new connection to the remote server (probably purging the client's stateful data and having the new server resend, at least initially).

server side, you need a simple mechanism to transfer files from trusted hosts mechanism, a one-liner to rewrite the player's savebed in the transfered file to the destination on the remote server, as well as a way to tell the clients to connect to a new server,

client side you need to parse that command, esthablish a new connection, purge the items and spell lists, resend the setup commands, and relogin

I believe that it's already possible to get mapdata from a server and also copy player data to another server, more or less.

not really, currently transfer of player data between servers is done manually, for game balance reasons as much as technical ones. (if I create a character on my own server, I could level them up to level 100+, give them silly amounts of platinum, and a specially modified uber-weapon, obviously most 'real' servers wouldn't want me using that character on them).

A quick hack with libcurl, and properly setup ftpservers would allow transfer of player files but no one has yet done this, because automated processes for this are not useful in game terms.

This opens up the possibility of mini-servers built into a special client build, allowing players to hop between servers and host their own mini-worlds (or big ones if they felt like it). I know there's a lot of obstacles to overcome for it to work properly, but Crossfire is almost capable of all this now.

technically it wouldn't be hard to hack, and I admit it sounds like quite a cool idea (bittorrent for MMORPGs), however there are a number of major game issues that remain;
1) what happens if a host goes down? (maybe have the sending server ping the remote one first, then announce the exit is closed if they don't respond?)

2)when you quit, which server do you reconnect to (maybe a 'dispatch server', that all other servers would recognise, and declare player locations to?)

3) I am playing on a fairly fast european server, I go through a door, I then get connected to some other server on a dial-up connection somewhere in africa, my ping time has suddenly increased to above 1s, and the game is now unplayable?

4) what stops me creating stupid cheat items on my own server, and bringing them into the larger world?

5) how do I know that the remote server isn't hostile, and won't try to exploit a security exploit in the client (there are no known security holes at this time, but I'd bet there are a few unknown ones)

more minor points:
6) making chat/shout, work across all servers would be harder, - in the earlier thread I pointed to above, hacking in jabber libraries was mentioned for that.

7) bank/postal system etc, wouldn't share balances/delivery queues across servers - maybe that isn't such an issue (you described them as universes, so maybe they shouldn't share the same postal system anyway)?

making parties work in such situations would be interesting, preserving them across server switches would need some special hacks (maybe using a dispatch server like I mentioned above) - Ryo is currently writing a script to do automatic party rejoining, so maybe that would work for this.

9) how do you sync hiscore/exp tables, archetypes, etc, across all of these servers? (maybe some sort of hash)?

10) making 'who' work across servers would be hard.

11) the server measures times in ticks, if one server doesn't make a tick (due to having too much to process) it will get out of sync with the other servers.

I think I'm asking a few things here:

* Is what I'm asking possible?

technically, yes, from an organisational point of view, it is much harder.

- If so, will any of the features be added (ie server hops)

It's doubtful, I think there is more desire to make the server run in threads locally (to better utilise SMP and dual/quad core systems) than to make it run single-threaded on multiple systems.

- If they won't be, would anyone mind if I had a crack at it myself? not as a part of the crossfire project of course.

sure, feel free to hack away, and ask if you have any questions (#crossfire on freenode is probably the best place for a quick response most of the time, although many of the cf developers are either in western europe or north america, so there are a few quiet times of day).

If you get something interesting, post about it on the crossfire mailing list (crossfire@metalforge.org)

* If the code already supports any of the features somewhere, where do I find it so I can learn how its implementation functions?

I'd look at the metaserver communication code for the server, and the metaserver script itself, try and hack that to connect to arbitrary servers, and send more data, then write an implementation of the metaserver into the server code (it is in perl, you'd need to port it to C) - with the hacks you need to send the data you require.

the metaserver is in crossfire/utils, or you can download direct from webcvs: http://cvs.sourceforge.net/viewcvs.py/* ... in?rev=1.3

the metaserver handling code in the server is in socket/metaserver.c
you may want to use a more advanced protocol for the player-file sending, since they can get quite large, and doing packet formation manually may not be the best approach there

[general_failure]

I'll give a proper reply later, after I've had a good night's sleep, but I thought I'd say a couple of things now.

I actually did come up with some possible solutions for the inter-server communication in the design brief.

Part of the solution was a lookup table of online IP addresses gained from whatever other instance it connects to. Those lists are updated with the new IP address etc. The lists are periodically checked. It holds immediately connected peers on a higher priority. The server aspect of the peers are sort of connected in a matrix, and only really worry about their close neighbours.
I mean 'close' as in degrees of separation, or jumps from the current instance of the peer.

Security (character integrity):
Well, I Think I've been actively avoiding this. I've had a few ideas but they all have their own problems.

The next morning:
Insomnia has hit hard, haven't slept at all. I'll attempt to answer these bits the best I can still.

1) what happens if a host goes down? (maybe have the sending server ping the remote one first, then announce the exit is closed if they don't respond?)

I'll have to recover the doc I made from one of the old hard drives.
I came up with a plan to have adopted maps.

It works something like this:

Each character has an 'original' copy of their player data maintained and sync'd on their own machine.

Each player on a particular map has the map automagically downloaded and cached on their machine, partially for performance reasons.
Each player also has an IP list of the other players on the map.

If the server of the map should suddenly dissappear, the following will happen:
A flag set in the map, specifying whether the map should be adoptable is checked. If so the orphaned clients do a poll, asking if their connection is broken too. If so, one of the clients is elected an adoptive parent of the map.
Depending on the server settings the adoptive parent has specified, the map may stay resident and active on their machine, or only persist until it is empty.

The orphaned clients are redirected to the new IP address, and as much data as possible is restored to the map.

If the map is not set to adoptable, the players are relocated to a special home map on their own server, with a teleporter to their own public level and other levels on their IP list (kind of like initial connection to a server).

2)when you quit, which server do you reconnect to (maybe a 'dispatch server', that all other servers would recognise, and declare player locations to?)

Something like that. Just a known server which has a list of other servers, which in turn have their own. etc etc.
Which reminds me. A problem may arise where links between maps are broken, from people going offline or whatever, and create 'island universes'. This is where the known servers come in handy. The islands can be rejoined.

3) I am playing on a fairly fast european server, I go through a door, I then get connected to some other server on a dial-up connection somewhere in africa, my ping time has suddenly increased to above 1s, and the game is now unplayable?

My ping time is lucky to be under 2s. It's still playable. You just need to think ahead.
However, remember how I mentioned a degree of spidering for IP addresses? I see no reason why there can't be a query of the server that you want to connect to, asking how fast the connection is. The honesty of this is up to the server owner though.
A filter could easily be made stating to only connect to servers above a certain bandwidth.

4) what stops me creating stupid cheat items on my own server, and bringing them into the larger world?

This is an issue I've been grappling with. Remember, when you voyage out into the big bad world, you are hopping across to other people's servers and therefore using other people's rulesets.
The default ruleset (with a little extension) could be set up so certain items are rendered unusable on a server, or their values clipped to a preset maximum.

5) how do I know that the remote server isn't hostile, and won't try to exploit a security exploit in the client (there are no known security holes at this time, but I'd bet there are a few unknown ones)

You don't. I guess the ban list could be made communicable on connection or something.
Hostile servers are a risk that is taken with many online activities though. It goes with the territory.

more minor points:
6) making chat/shout, work across all servers would be harder, - in the earlier thread I pointed to above, hacking in jabber libraries was mentioned for that.

Would you really want a universe of people shouting? If people want to communicate with party members there's the IP link I mentioned. Or I guess a more adventurous method would be to build in a tailored IRC client.

7) bank/postal system etc, wouldn't share balances/delivery queues across servers - maybe that isn't such an issue (you described them as universes, so maybe they shouldn't share the same postal system anyway)?

That is also a problem. About the only way I can think of is a few semi-permanent postoffices and banks, perhaps in communication.

making parties work in such situations would be interesting, preserving them across server switches would need some special hacks (maybe using a dispatch server like I mentioned above) - Ryo is currently writing a script to do automatic party rejoining, so maybe that would work for this.

Parties would be awkward. automatic part rejoining does seem the easiest method.

9) how do you sync hiscore/exp tables, archetypes, etc, across all of these servers? (maybe some sort of hash)?

Seems like a good idea. Perhaps for extra archetypes there could be an equivalent of the unique_items directory, except it's just a storage place for singular archetypes that are temporarily tacked on to a list.
Ie. if a player comes over from another server, their home server and the last server they visit are queried for an archetype which doesn't exist on the current server.
If it exists on the queried server, the temp file is made. If not it's ignored.

archetypes with dissimilar definitions would default to the settings of the current server. Law of the land and all.

10) making 'who' work across servers would be hard.

Things like 'who' can be divided into categories:
* Local Who - Lists who's on your instance of the peer.
* Server who :- This lists who is on a specified server. basically an extension of local who.
* Spider who - Goes n number of hops along the list from a specified server, local if not specified.

11) the server measures times in ticks, if one server doesn't make a tick (due to having too much to process) it will get out of sync with the other servers.

For each map there will be one active server, and clients connected to it.
I guess it could be possible to have servers sync'd, but differences in settings, architecture etc could cause inconsistencies. Probably best not done.

That'll do for now. Questions? Statements? Please tell me if I'm spouting garbage.

I've been looking through the server autodocs. pretty straightforward.
I would like to know how the map graphics are transferred to the client for caching and use though. I haven't figure that one out yet

[cavesomething]

Apologies for the delay in replying, I saw your original post before you edited it, and after you edited it it didn't show as a new post, so I didn't look again.

Security (character integrity):
Well, I Think I've been actively avoiding this. I've had a few ideas but they all have their own problems.

1) what happens if a host goes down? (maybe have the sending server ping the remote one first, then announce the exit is closed if they don't respond?)

I'll have to recover the doc I made from one of the old hard drives.
I came up with a plan to have adopted maps.

It works something like this:

Each character has an 'original' copy of their player data maintained and sync'd on their own machine.

Each player on a particular map has the map automagically downloaded and cached on their machine, partially for performance reasons.
Each player also has an IP list of the other players on the map.

Which would reveal all passwords/level connections etc, I know that all the maps mf uses are in CVS, but this isn't neccessarily the case for all servers, and in any event it currently takes effort to cheat in this way.

Likewise having the IP adress of all other players is potentially dangerous, if you accidentally annoy random script kiddie, suddenly you could find your system under attack.

You also make the assumption that everyone has a direct connection to the internet, and isn't firewalled/NATted to the point where they can't (or won't) run a server.

If the server of the map should suddenly dissappear, the following will happen:
A flag set in the map, specifying whether the map should be adoptable is checked. If so the orphaned clients do a poll, asking if their connection is broken too. If so, one of the clients is elected an adoptive parent of the map.
Depending on the server settings the adoptive parent has specified, the map may stay resident and active on their machine, or only persist until it is empty.

The orphaned clients are redirected to the new IP address, and as much data as possible is restored to the map.

This sets off alarm bells, if you have an item dropped on the floor, outside the range of view of the player you elect to host the map, that item will be lost.

likewise a client can't know which monsters have been killed, or where all the other players are on the map; given that the clients have complete copies of the map, if you rely on them reporting their location to the newly elected server, they could report themselves as being on the square with the most valuable pickup-able item.

Assuming you want to continue running the map, what happens when the original host comes back up again, how does the data sync?

If the map is not set to adoptable, the players are relocated to a special home map on their own server, with a teleporter to their own public level and other levels on their IP list (kind of like initial connection to a server).

Ok, that's not too bad, a slightly better outcome than what happens with a server crash, however, since the single-server model that exists right now assumes that the server will mostly stay up, it is less of an issue than it will be when everytime someone logs off part of the world disappears. (what happens if your apartment/guild happens to be in that segment? would you be unable to access it until the same person re-appears?)

4) what stops me creating stupid cheat items on my own server, and bringing them into the larger world?

This is an issue I've been grappling with. Remember, when you voyage out into the big bad world, you are hopping across to other people's servers and therefore using other people's rulesets.
The default ruleset (with a little extension) could be set up so certain items are rendered unusable on a server, or their values clipped to a preset maximum.

this doesn't mean I couldn't create a complete set of the most powerful legally-available items on my server and use them, your detection mechanism would not be able to identify them as cheat items (at least as long as the real_wiz setting is on)

5) how do I know that the remote server isn't hostile, and won't try to exploit a security exploit in the client (there are no known security holes at this time, but I'd bet there are a few unknown ones)

You don't. I guess the ban list could be made communicable on connection or something.
Hostile servers are a risk that is taken with many online activities though. It goes with the territory.

yes, but crossfire's client-side defense against that is rather limited at the moment, you would really need to audit all of the client code before such a system could be put into production.

9) how do you sync hiscore/exp tables, archetypes, etc, across all of these servers? (maybe some sort of hash)?

Seems like a good idea. Perhaps for extra archetypes there could be an equivalent of the unique_items directory, except it's just a storage place for singular archetypes that are temporarily tacked on to a list.
Ie. if a player comes over from another server, their home server and the last server they visit are queried for an archetype which doesn't exist on the current server.
If it exists on the queried server, the temp file is made. If not it's ignored.

archetypes with dissimilar definitions would default to the settings of the current server. Law of the land and all.

What about items that are modified from a base archetype (quite a few maps do this, it is the prefferred way to create 'unique' items that don't have their own image).

10) making 'who' work across servers would be hard.

Things like 'who' can be divided into categories:
* Local Who - Lists who's on your instance of the peer.
* Server who :- This lists who is on a specified server. basically an extension of local who.
* Spider who - Goes n number of hops along the list from a specified server, local if not specified

so you want a player search engine for 'who' to work?

I think probably a centralised approach would work better here, if you have a centralised server, have the players all report to it everytime they get a newmap command and then let the servers cache the responses from the main server. (or just have players ask for it directly)

That'll do for now. Questions? Statements? Please tell me if I'm spouting garbage.

I think it could be an interesting academic exercise, but the difficulties that seem to be involved in creating a balanced and coherent game world would seem to prevent it being usable for actually playing without serious modification.

Still, if you want to go ahead, crossfire is released under the GPL to guarentee your Freedom to do exactly this sort of thing, and if it does work, then let us know, I can't really see that the fully distributed model would be used, but spanning the game world across two or three servers could be very useful (limits impact of server crashes, and reduces the strain on bandwidth at a single point).

I've been looking through the server autodocs. pretty straightforward.
I would like to know how the map graphics are transferred to the client for caching and use though. I haven't figure that one out yet

From what I remember from when I was writing a client-side parser for this:

To transfer image data the image or image2 packets are used. These contain a numeric id, the data length, and then length bytes that form a valid (in theory) png file corresponding to that face, the map1 commands then send a list of faces that are visible on the square, and the client composites them ontop of each other.

If caching is being used, the faces aren't always sent, the server sends a 'face' command first.

the face commands send a face number, a name to associate with that number and a checksum, so that the client can check if they have it cached first.

if the client has it cached, then they use the cached version, if they don't (or the checksums don't match) they send askface <number>

[general_failure]

Sorry about taking so long to reply. I just haven't fely up to giving a semi-intelligent reply.
That and I've been struggling to get Debian Sarge to install on my 'development' PC. After 2 weeks I finally succeeded, with the aid of some horrible tweaks and tomsrtbt. It seems as though its hardware is categorically incompatible with sarge. I'm filling in some of the larger cracks right now. Crossfire should be installable again soon, so I can get back to it!

Apologies for the delay in replying, I saw your original post before you edited it, and after you edited it it didn't show as a new post, so I didn't look again.

Security (character integrity):
Well, I Think I've been actively avoiding this. I've had a few ideas but they all have their own problems.
I'll have to recover the doc I made from one of the old hard drives.
I came up with a plan to have adopted maps.

It works something like this:

Each character has an 'original' copy of their player data maintained and sync'd on their own machine.

Each player on a particular map has the map automagically downloaded and cached on their machine, partially for performance reasons.
Each player also has an IP list of the other players on the map.

Which would reveal all passwords/level connections etc, I know that all the maps mf uses are in CVS, but this isn't neccessarily the case for all servers, and in any event it currently takes effort to cheat in this way.

Likewise having the IP adress of all other players is potentially dangerous, if you accidentally annoy random script kiddie, suddenly you could find your system under attack.

You also make the assumption that everyone has a direct connection to the internet, and isn't firewalled/NATted to the point where they can't (or won't) run a server.

Firewalling first:
Given the way the higher level communication code works, I see little reason why it can't be piped through other protocols (at the possible expense fo performance). It means the server would need to support these communication methods too. Possibly even with a decent chunk of client code in place.

What I say here is based on the current functionality of crossfire.
e.g. commands could be sent back and forth via IRC to the server.

There could even be a telnet interface layer for the truly masochistic person. I mean a graphical frontend that gets commands via the telnet protocol from a modified client on the server end. I know that hurts. Sorry

IP addresses = dangerous. I agree. Is there a better way?

Player information integrity and synchronisation is a large problem.

I am curious as to how 'Dungeon Siege' protects it's player data. It's stored on the client side.

If the server of the map should suddenly dissappear, the following will happen:
A flag set in the map, specifying whether the map should be adoptable is checked. If so the orphaned clients do a poll, asking if their connection is broken too. If so, one of the clients is elected an adoptive parent of the map.
Depending on the server settings the adoptive parent has specified, the map may stay resident and active on their machine, or only persist until it is empty.

The orphaned clients are redirected to the new IP address, and as much data as possible is restored to the map.

This sets off alarm bells, if you have an item dropped on the floor, outside the range of view of the player you elect to host the map, that item will be lost.

likewise a client can't know which monsters have been killed, or where all the other players are on the map; given that the clients have complete copies of the map, if you rely on them reporting their location to the newly elected server, they could report themselves as being on the square with the most valuable pickup-able item.

Assuming you want to continue running the map, what happens when the original host comes back up again, how does the data sync?

the other clients connected to the map keep track of each other to avoid any discrepencies.

If the map is not set to adoptable, the players are relocated to a special home map on their own server, with a teleporter to their own public level and other levels on their IP list (kind of like initial connection to a server).

Ok, that's not too bad, a slightly better outcome than what happens with a server crash, however, since the single-server model that exists right now assumes that the server will mostly stay up, it is less of an issue than it will be when everytime someone logs off part of the world disappears. (what happens if your apartment/guild happens to be in that segment? would you be unable to access it until the same person re-appears?)

Mirror the save-state on local server. It's the only way I can see to get around it.
Ie, on trying to reconnect, your client does the following:
(sorry about the dodgy c pseudocode. It's just easier for me to explain it)

Code: Select all

if(saved_world_exists)
{
  if(saved_world_savestate_exists)
  {
     if(compare_data(remote_savestate, local_savestate)) //1 is equal
     {
        restore_savestate(remote);
     }
     else
     {
        restore_savestate(local); //restores local data to your local world
     }
  }
  else
  {
     restore_savestate(local);
  }
}
else
{
   restore_savestate(local);
}

I know a switch probably would have done the same, but it's pseudocode anyway.

4) what stops me creating stupid cheat items on my own server, and bringing them into the larger world?

This is an issue I've been grappling with. Remember, when you voyage out into the big bad world, you are hopping across to other people's servers and therefore using other people's rulesets.
The default ruleset (with a little extension) could be set up so certain items are rendered unusable on a server, or their values clipped to a preset maximum.

this doesn't mean I couldn't create a complete set of the most powerful legally-available items on my server and use them, your detection mechanism would not be able to identify them as cheat items (at least as long as the real_wiz setting is on)

True true.
But any networked game can be hacked by the server operator. This is most noticable in games like the Quake series, especially since the advent of the code being GPL'd.
They may just decide to tweak things so they have a weapon not easily obtainable in the map etc.
To my knowledge there is no real way of protecting against 'legal' objects being created by illegal means.

5) how do I know that the remote server isn't hostile, and won't try to exploit a security exploit in the client (there are no known security holes at this time, but I'd bet there are a few unknown ones)

You don't. I guess the ban list could be made communicable on connection or something.
Hostile servers are a risk that is taken with many online activities though. It goes with the territory.

yes, but crossfire's client-side defense against that is rather limited at the moment, you would really need to audit all of the client code before such a system could be put into production.

No argument. Networked programs are always a risk. Ones that transfer files moreso. It would require a thorough screening before it could be usable in the wild.

9) how do you sync hiscore/exp tables, archetypes, etc, across all of these servers? (maybe some sort of hash)?

Seems like a good idea. Perhaps for extra archetypes there could be an equivalent of the unique_items directory, except it's just a storage place for singular archetypes that are temporarily tacked on to a list.
Ie. if a player comes over from another server, their home server and the last server they visit are queried for an archetype which doesn't exist on the current server.
If it exists on the queried server, the temp file is made. If not it's ignored.

archetypes with dissimilar definitions would default to the settings of the current server. Law of the land and all.

What about items that are modified from a base archetype (quite a few maps do this, it is the prefferred way to create 'unique' items that don't have their own image).

Are you asking about if an object is created from a base archetype which doesn't exist on a server?
If the base archetype does exist on the server, then I don't see why the super-archetype can't be patched in. Parsing may be a little awkward though.

10) making 'who' work across servers would be hard.

Things like 'who' can be divided into categories:
* Local Who - Lists who's on your instance of the peer.
* Server who :- This lists who is on a specified server. basically an extension of local who.
* Spider who - Goes n number of hops along the list from a specified server, local if not specified

so you want a player search engine for 'who' to work?

I think probably a centralised approach would work better here, if you have a centralised server, have the players all report to it everytime they get a newmap command and then let the servers cache the responses from the main server. (or just have players ask for it directly)

I like your idea.
Still, a spidering search engine would be kind of cool.

That'll do for now. Questions? Statements? Please tell me if I'm spouting garbage.

I think it could be an interesting academic exercise, but the difficulties that seem to be involved in creating a balanced and coherent game world would seem to prevent it being usable for actually playing without serious modification.

Still, if you want to go ahead, crossfire is released under the GPL to guarentee your Freedom to do exactly this sort of thing, and if it does work, then let us know, I can't really see that the fully distributed model would be used, but spanning the game world across two or three servers could be very useful (limits impact of server crashes, and reduces the strain on bandwidth at a single point).

I've been looking through the server autodocs. pretty straightforward.
I would like to know how the map graphics are transferred to the client for caching and use though. I haven't figure that one out yet

From what I remember from when I was writing a client-side parser for this:

To transfer image data the image or image2 packets are used. These contain a numeric id, the data length, and then length bytes that form a valid (in theory) png file corresponding to that face, the map1 commands then send a list of faces that are visible on the square, and the client composites them ontop of each other.

If caching is being used, the faces aren't always sent, the server sends a 'face' command first.

the face commands send a face number, a name to associate with that number and a checksum, so that the client can check if they have it cached first.

if the client has it cached, then they use the cached version, if they don't (or the checksums don't match) they send askface <number>

I see. That is very interesting. That little bit of code could be modified to send other items. Like what I'm not entirely sure yet though.
I have been contemplating hacking together a '3-D' client which this could be used for at very least. Ie. for sending meshes instead of bitmaps.
I was thinking of just having a perma-cached tileset clientside until it seems workable.

The serverside code I *think* could have a little bit of client code hacked in to allow transfers of playerdata and possibly even bitmaps. Then a primitive teleporter could be achieved. Wouldn't try it with a good sharacter though. For some reason I keep thinking of 'The Fly'.


I guess for now the whole thing would just be an academic excercise, wouldn't it.
There's something I tend to say quite often. "It'd be great!... if only people could be trusted".