I've integrated my latest findings into the code, the client will now receive upon zoning in a list of teleport destination points which are retrieved from a DB table. The client will then sent the destination zone when he hits a client side zone line to the server. The server will then try to find the correct destination x,y,z of the new zone.
This is an odd quirk actually - you would expect that the client (who already knows the destination x,y,z since i've sent him this info at zonein) would sent you the coordinates along with the zone name - or at least the zone teleport index # of the destination he wants to use, but that doesn't happened - i debugged that part of the client and im sure its not the intended way - maybe to prevent cheating with teleporting to specific X,Y,Z. We can at least make sure this way that the client really hit a zone line and can force a specific loc.
The db table i've found is pretty good actually, i've tested 20+ zone borders and intra zone teleports (even the ones i added manually previously like erudin and felwitheb) and it works just fine. I only found one issue from nro->freeport because these zones do not end/continue on the same X value as a zone like qeynos hills -> qeynos (when you paste these zones together, they end where the other starts /loc wise for either x or y) - this is useful for putting the player at the exact X or Y when he hits a large zone line - it would be odd when you zone from the right most corner from freeport to nro but zone in in the center of this zone line.
Oh, btw i actually had an issue with the server side "find the destination point where the client wants to zone to" logic, all zones worked fine till i tested freeport, where i zoned ALWAYS into the sewers when i went from freportw to freporte or other way around - well turns out that somebody switched X and Y for finding the correct zone entry point when calculating deltaX²*deltaY²... a few hours lost on this tiny bug