Why does Tractor still zone us?

[Invader]

Teleporters (including Confluxes) have a specific entrance/exit area. It is known where the player is going to end up. Tractor has no specific entrance/exit point.

I already said that "if all it is is a hard-coded location, couldn't it be made to be variable with regards to the location of the player casting Tractor". Please read the entire post before replying.

Your example doesn't affect Abyssea or the time system placed on such said system.

How does Visitant Status (which is what I assume you mean by "time system") have anything to do with reprogramming how Tractor works?

[Korpg]

I already said that "if all it is is a hard-coded location, couldn't it be made to be variable with regards to the location of the player casting Tractor". Please read the entire post before replying.

I'm not a programmer, but I don't think your way works because Tractor does not have a specific set of coordinates to kick you out of. You have to actually "zone" to get from one point to another while dead. Teleports have a specific set of coordinates to pop you at. When you hit a teleport, it takes you to X, Y, Z at this specific map.

How does Visitant Status (which is what I assume you mean by "time system") have anything to do with reprogramming how Tractor works?

I said your example. If you said Conflux, your example would make more sense in the matter.

[Rhianu]

I'm not a programmer, but I don't think your way works because Tractor does not have a specific set of coordinates to kick you out of.

I've taken a few college classes on programming, and I'm only a beginner, but even I can tell you that it shouldn't matter whether the calculation is preformed using a pre-designated number or a variable. Computers are perfectly comfortable working with either type of data.

If the game can teleport players around an area without zoning by using set numbers, then it can also do so using variables. In theory, it could work by reading in the coordinate values of the BLM casting Tractor, and then reassigning the coordinate values of the player he or she is casting Tractor on to match those values. The mere presence of a variable in an equation should not necessitate a loading screen. The real reason, whatever it is, has to be something else.

More detailed information on exactly why it supposedly can't be done is needed here.

[Invader]

I've taken a few college classes on programming, and I'm only a beginner, but even I can tell you that it shouldn't matter whether there is a pre-designated number or a variable. Computers are perfectly comfortable working with either type of data.

If the game can teleport players around an area without zoning by using set numbers, then it can also do so using variables. In theory, it could work by reading in the coordinate values of the BLM casting Tractor, and then reassigning the coordinate values of the player he or she is casting Tractor on to match those values. The mere presence of a variable in an equation should not necessitate a loading screen. The real reason, whatever it is, has to be something else.

More detailed information on exactly why it supposedly can't be done is needed here.

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.

[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.

[Aliron]

Wouldn't it be possible to make the visitant status work similar to signet/sigil/sanction which does NOT wear off when you change areas or get tractored. The duration of those is based on various factors, for instance Sigil duration is based on a key item, just like how long to make Visitant last is based on the Stone key items spent. Even the new hourglass key item in Dynamis works in a similar fashion to what we're looking for. It could be as simple as copy and pasting some of the coding for the Hourglass to Visitant status in some parts.