Why does Tractor still zone us?

[Arcon]

I think the problem is exactly that; they don't know which noodle in the spaghetti code because its so far back none of the current team would have worked on that sections, and so decided it would take to long.

I can understand that excuse in general, sometimes code is just really bad. I'm just having trouble to believe that it applies in this case. What does tractor actually do? It gives the dead player a "tractor effect'. It saves the location of the caster when the spell went off and makes a dialog pop up on the players screen. If the player accepts, it starts the zoning process.

They wouldn't even need to touch the spell. This zoning subroutine is completely unrelated to the spell itself, it's just one piece of code, that zones you and puts in a certain location after the zoning process. I could very well imagine, that any kind of zoning or moving could be done by one function that looks something like this:

setLocation(area, pos)

If area = current area, it's basically a draw in and puts a player on the appropriate position in the pos vector (may call a different subroutine for that). If area =/= current area, it iniates a zone. We do know that both mechanisms do already exist, SE wouldn't even need to know them or how they work. If the zone(area, pos) or drawIn(pos) functions are really extremely complicated and spaghettified, who cares? They don't have to change them or even understand how they work or even look at them. Just use them.

I just don't see how spaghetti code can be an excuse in this case. I'd love to get my hands on the source code. If it really was as bad as everyone says, I would at least be at peace with the way things are going, but hard to just take the same excuse time and again, when it doesn't seem to make any sense. As Daz put it:

POS bots have been doing this since 2004. If a bedroom programmer can do it in two hours, an SE programmer should be able to do it, and make it look pretty in the same amount of time.

[GlobalVariable]

I can understand that excuse in general, sometimes code is just really bad. I'm just having trouble to believe that it applies in this case.

Yeah well whatever the actually technical details are, they should darn well reconsider their decision here. The mechanic has been a problem in enough cases to make me think it can present future problems to. If it had been fixed back when besieges was new, or even when campaign was still going strong, we'd never have run into it as a problem in abyssea. I really don't want it to be there to screw people on whatever new thing they come up with next.

[Raxiaz]

Too true, GlobalVariable. Too true.

[Darkshade]

If the programming is bad or whatever, I just don't see why they couldn't keep the spell but write a new effect for it so it calls the new code when it is cast to do what other users are suggesting in this thread. I'm not a C++ computer science major but it doesn't sound that hard to do, really.

[Invader]

while I might agree with you under normal circumstances, the devs have said that the original spell was tied to spaghetti code and would be most difficult to fix, therefore adding a new spell rather than modifying the original would just be less complicated, when this game was originally coded they didn't do much documentation to allow for easier solutions and tractor was among that code

Could you point me to the Dev post by Camate or another SE official that said the problem is because of spaghetti code? I didn't see that post. I DID see other players speculating that that was the reason. Either way, it's not an excuse.