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
24. Januar 2011
21. Januar 2011
Its been a while...
I've been doing some reverse engineering work since the beginning of the new year.
I noticed that the intra zone teleports do not work for most zones, so i manually added them for felwitheb and erudin. While testing out the zoning, i finally figured out how to set the initial camera position upon zoning, i.e. we can no specify that a player should look up or down after zoning - useful so that the player faces the right direction.
Upon till then, our zoning worked server side, that means when the player moved to a specific location the server noticed it and if the player hit a zone border of teleport pad, we moved him manually. This works fine but is alot of unneeded overhead.
Now back to the intra zone teleporting, it was weird that some teleports did work without any interaction, in erudin for example, the pad from the harbor up to the palace worked. That meant the client knew some coordinates already.
YL provided some interesting input, he noticed that when using eye of zoom near a zone line/pad - the eye would vanishe - the client would kill it. So the client somehow must already knew the locations from WHERE a player should be teleported too, what he didnt knew was the destination of the teleport.
Well after further reverse engineering, i found out that the client had some kind of teleport table with indexes. I found the opcode which needed to be sent to the client along with an array of teleport destination and each specific magic number of each teleport destination. The client already scans the area when a player enters a zone point, he has a hard coded ID for each of these - and we just have to tell him for each of these ID where to teleport the player.
So what that means is, in classic (and afaik still to date) - the client knows only the zone lines but the server will tell him where he should teleport too upon zoning in. After some research i found that eqemu developers could simply take a live packet dump and extract the zone points from there. This is of course 1000 times easier than manually adding each destination teleport point from your own memory (setting up only 8 intra zone points took me around 5h). Of course the destinations change of time so we cant simply take a live dump now, but some older data might be useful, i think i got that covered.
BTW: One interesting info i found during reverse engineering was a funny opcode - it enables us to play a specific sound file to the player. The are all indexed by ID - so any wave file the client knows, we can play it. And the funny part is - if you use an unknown ID you get "This is an error message, please report the bug" in a muffled developer voice =p
I noticed that the intra zone teleports do not work for most zones, so i manually added them for felwitheb and erudin. While testing out the zoning, i finally figured out how to set the initial camera position upon zoning, i.e. we can no specify that a player should look up or down after zoning - useful so that the player faces the right direction.
Upon till then, our zoning worked server side, that means when the player moved to a specific location the server noticed it and if the player hit a zone border of teleport pad, we moved him manually. This works fine but is alot of unneeded overhead.
Now back to the intra zone teleporting, it was weird that some teleports did work without any interaction, in erudin for example, the pad from the harbor up to the palace worked. That meant the client knew some coordinates already.
YL provided some interesting input, he noticed that when using eye of zoom near a zone line/pad - the eye would vanishe - the client would kill it. So the client somehow must already knew the locations from WHERE a player should be teleported too, what he didnt knew was the destination of the teleport.
Well after further reverse engineering, i found out that the client had some kind of teleport table with indexes. I found the opcode which needed to be sent to the client along with an array of teleport destination and each specific magic number of each teleport destination. The client already scans the area when a player enters a zone point, he has a hard coded ID for each of these - and we just have to tell him for each of these ID where to teleport the player.
So what that means is, in classic (and afaik still to date) - the client knows only the zone lines but the server will tell him where he should teleport too upon zoning in. After some research i found that eqemu developers could simply take a live packet dump and extract the zone points from there. This is of course 1000 times easier than manually adding each destination teleport point from your own memory (setting up only 8 intra zone points took me around 5h). Of course the destinations change of time so we cant simply take a live dump now, but some older data might be useful, i think i got that covered.
BTW: One interesting info i found during reverse engineering was a funny opcode - it enables us to play a specific sound file to the player. The are all indexed by ID - so any wave file the client knows, we can play it. And the funny part is - if you use an unknown ID you get "This is an error message, please report the bug" in a muffled developer voice =p
Abonnieren
Posts (Atom)