Why does Tractor still zone us?

[Tagrineth]

Which is why I said I wanted technical details. You are basically correct in that, if it is not zoning us during a teleporter (conflux or otherwise) then it shouldn't need to zone us when using tractor.

I am thinking that since location is updated client side (which is why you can still run around while d/cing) they don't have a way to tell the client that you should be at X,Y,Z coordinate without also telling the client to change areas. That is the only acceptable answer they could give as to why it can't currently be done, but I don't believe it is the case... hence why I ask whether NPC teleporters are, in fact, also using a zone change.

Actually this makes perfect sense.

With NPC teleporters and Confluxes, the player is initiating the teleportation effect themselves. Quick go-ahead from the server, the client updates the position, the server receives the confirmation that you're at the new position, verifies that you initiated the motion via NPC (without verification, you'd be hacking!) and presto! new position.

In other words, we're still working all client-side with client-server confirmation - there's no server "putting" your character at a new location.

Draw-in is similar in that it's a mob effect and thus the server itself knows the position of the mob at a given instant so the server can verify the draw-in command and send it to the player, thus sending the player to a specific point that is clear and functionally known to the server.

I think the problem lies in the way the server cross-verifies whether "boosted" transportation methods (aka anything that isn't running, especially anything that breaks Flee speed) are legit or not. They'd probably have to add a whole new layer of client-server communication and back-and-forth verification to ensure that your corpse's warping to another player's location was legit, since lag can affect so many variables. It wouldn't be totally out of the question for an intrepid hacker to abuse the newfound ability to perform an arbitrary corpse-port with clever use of falsified client-server verification ("oh, don't worry, I was just Tractored!") - and before you say "oh well the server can just verify Tractor was used"... well in the case of lag or even a d/c of the person casting Tractor, it would cause a serious conundrum because the client-server verification that Tractor was cast would no longer exist, which would set off a red flag the size of China and possibly cause a legit player to get banned for pos hacking. All because of a stupid asinine mishap of a failed client-server verification.

Simply put, for this to work and be in any way reliable, the server would be forced to trust the client too much - which could easily lead to abuse.

I'd rather see SE add a server-side special case to certain effects that allow the zoning to 'fudge' maintained status - in other words, add a special flag to Visitant status that can verify if you zone with the same entry and exit zones, your Visitant status is auto-restored by the server and position retained instead of being cleared as normal.

Given SE's penchant for poor programming practices, I'd hazard that the above would be significantly easier and safer to add to the code than changing the fundamentals of Tractor itself.

[Invader]

Actually this makes perfect sense.

With NPC teleporters and Confluxes, the player is initiating the teleportation effect themselves. Quick go-ahead from the server, the client updates the position, the server receives the confirmation that you're at the new position, verifies that you initiated the motion via NPC (without verification, you'd be hacking!) and presto! new position.

In other words, we're still working all client-side with client-server confirmation - there's no server "putting" your character at a new location.

Draw-in is similar in that it's a mob effect and thus the server itself knows the position of the mob at a given instant so the server can verify the draw-in command and send it to the player, thus sending the player to a specific point that is clear and functionally known to the server.

I think the problem lies in the way the server cross-verifies whether "boosted" transportation methods (aka anything that isn't running, especially anything that breaks Flee speed) are legit or not. They'd probably have to add a whole new layer of client-server communication and back-and-forth verification to ensure that your corpse's warping to another player's location was legit, since lag can affect so many variables. It wouldn't be totally out of the question for an intrepid hacker to abuse the newfound ability to perform an arbitrary corpse-port with clever use of falsified client-server verification ("oh, don't worry, I was just Tractored!") - and before you say "oh well the server can just verify Tractor was used"... well in the case of lag or even a d/c of the person casting Tractor, it would cause a serious conundrum because the client-server verification that Tractor was cast would no longer exist, which would set off a red flag the size of China and possibly cause a legit player to get banned for pos hacking. All because of a stupid asinine mishap of a failed client-server verification.

Simply put, for this to work and be in any way reliable, the server would be forced to trust the client too much - which could easily lead to abuse.

I'd rather see SE add a server-side special case to certain effects that allow the zoning to 'fudge' maintained status - in other words, add a special flag to Visitant status that can verify if you zone with the same entry and exit zones, your Visitant status is auto-restored by the server and position retained instead of being cleared as normal.

Given SE's penchant for poor programming practices, I'd hazard that the above would be significantly easier and safer to add to the code than changing the fundamentals of Tractor itself.

This makes zero sense, I'm sorry.

Here is how the mechanic should work:

1) Player A casts Tractor on Player B.
This would involve sending the information that "Hey, I just cast tractor on Player B!" to the server.

2)The server records the current position of the player casting tractor as well as the target (Player B) on whom it was cast.

3)The server tells Player B that Player A cast tractor on them, prompting the confirm/deny prompt for accepting Tractor on Player B's client.

4)Player B accepts tractor, at which point the server does whatever it would do for teleporters/draw in/confluxes/whatever to move Player B to the recorded coordinates.

In this scenario, which is the only way it would ever be done, Player B cannot "hack" a tractor, because the server will have no knowledge of the associated position to which they should be moved. In other words, regardless of however it is done now, Player B's client should have no prior knowledge, nor any control over the location to which they move. This would prevent hacking the Tractor system.