Fundamental Game Play Issues

[Alhanelem]

You're trying to apply common sense to programming when you clearly just don't know what you're talking about.

Actually, I have a BA with a major in computer science, so I do have some idea what I'm talking about. I really find it questionable that they would specifically code the game to remove the target lock on blink out, and that it's simply the target lock's codes dependance on having the model present causing the target lock code to decide it shouldn't be there anymore, and the targeting cursor's location being based on the height and scale of the target's model.

In short, because that would most likely mean these two things were coded by two different people who never communicated with eachother at all and the end result wasn't disruptive enough to get the team lead to tell them they need to redo it.

Displaying a model on the screen is the last thing any program will do

I learned from computer graphics class (which is a programming course, not an art course) that this really isn't always the case. Certainly not the manner in which we were taught, to be sure.

[Greatguardian]

Actually, I have a BA with a major in computer science, so I do have some idea what I'm talking about. I really find it questionable that they would specifically code the game to remove the target lock on blink out, and that it's simply the target lock's codes dependance on having the model present causing the target lock code to decide it shouldn't be there anymore, and the targeting cursor's location being based on the height and scale of the target's model.

In short, because that would most likely mean these two things were coded by two different people who never communicated with eachother at all and the end result wasn't disruptive enough to get the team lead to tell them they need to redo it.

I learned from computer graphics class (which is a programming course, not an art course) that this really isn't always the case. Certainly not the manner in which we were taught, to be sure.

Good, then we should be on level ground then. Everything I've bolded in the first paragraph, I agree with. The thing is, the game does not need the model to be present on the screen in order to know the height or scale of the target model. Likewise, I find it unlikely that the game is targeting a model at all, but rather an object which is represented by the model and thus is not dependent on the visibility of the model itself.

I believe it is significantly more likely that this was an error avoidance method rather than a necessity by design. We lose targets on blink, not because the model disappears, but because it is safer and easier to say "Lose all targets when a model is set to invisible" than it is to say "Lose a monster/NPC type target when it despawns or dies, but not when the player blinks, and also do not lose target on players when they blink, etc etc etc". The latter can be done with some work, of course. The first is just easier. When the functionality that the players want requires the latter, however, I think it becomes something worth looking into at least.

[Arcon]

The x,y,z position of a character is always known. The arrow points at the top of the character model. While there is no model (while it's still loading), it's just drawn at the default offset, which is (0,0,0) from the target. However, targeting already works even without the model. So it definitely is possible to have something targeted without having the model data. So if they need to make the character disappear while loading new equipment graphics (which is understandable), they could still keep the target, as those two are different things.

[Economizer]

However, targeting already works even without the model. So it definitely is possible to have something targeted without having the model data. So if they need to make the character disappear while loading new equipment graphics (which is understandable), they could still keep the target, as those two are different things.

Even if for some arcane programing reason this is BS, this sounds very logical and reasonable for anyone who has played the game for an extended period of time. That said, I doubt it is BS, considering that people who use third party programs have ways to avoid losing targets over gear swap.

I really hope we aren't going to fight over this though. Considering the amount of attention that the OP has gotten with likes, the last thing we need to do is give the mods a reason to lock this thread. If we can get the OP to a large amount of likes and someone like Camate is able to show it to the dev team, we might actually get some form of in-game response to these problems.

[Kaisha]

The x,y,z position of a character is always known. The arrow points at the top of the character model. While there is no model (while it's still loading), it's just drawn at the default offset, which is (0,0,0) from the target. However, targeting already works even without the model. So it definitely is possible to have something targeted without having the model data. So if they need to make the character disappear while loading new equipment graphics (which is understandable), they could still keep the target, as those two are different things.

Hell, they can make the target cursor/name jump down to the no-model pivot point and then back above the model when it reloads in after gear-swap for all I care, as long as I keep the focus.



Also, another vote for Tractor being useless. I've had 50+ occasions in Voidwatch where it would have been immensely helpful (since the current T4 batch spams AoE like nothing else in the game), but it wipes your status since it zones you, rendering it unusable.




Also for a minority problem: Accidentally disconnecting your gamepad during play requires you to reload all of FFXI for it to redetect it.