I think I'll store the return teleport in the t.txt file.
Let us keep thinking this out ... perhaps we need a new file, e.txt for exits.
What is coming to my mind is the "ant hills", the ant hills if you recall actually scrolled ... so did the newer death mountain.
This was done with hardcode in the scroll routine of the client so instead of scrolling the command was intercepted and converted into a teleport.
So perhaps we could have a system where you can set both scrolls and exits and the data gets saved in e.txt??
Yeah, that's what I was thinking. Scrolling wouldn't need a z-location, so a z-location of -1, for instance, could mean to scroll. I also had in mind a value (blank?) to mean don't exit in that direction, in case that was needed. A new map could either default to no exits, or teleporting to the map with the same first letter and the number linked with the lowercase letter, such as Aa -> A0, like we were thinking, before.
I actually don't really have a strong opinion where it is stored. I set up t.txt so it could take more parameters for cities, if needed, but it doesn't have to. A separate file would mean the server doesn't need to read the map data to do an exit, at the cost of another block of disk space per map. I also thought of 4 empty files, (which shouldn't take any blocks, right?) Each file could start with a direction, then the map and z-location. That would mean searching the directory, though.
-QuaCzar : SysOp | P2P Guide | Anarchy Leader | #1 Magic