Fundamental Game Play Issues

[Greatguardian]

A model being visible or not has absolutely nothing to do with the game knowing where and how large an object is. The game will always have that information available, whether the target is drawn or not.

It's more likely that the game's lockon function simply terminates whenever the target or player is rendered invisible, as a way to avoid errors before they happen. It is a lot simpler from a programming standpoint to make overbearing, catch-all rules than to add complex, individual functionality (lockon loss during deaths but not during blinks, etc), and the latter is much more likely to break or glitch.

Assuming that the software engineers who wrote the initial code are still working on the FFXI team, it would be an hour long fix at best. Given the fact that they obviously don't, it may take anywhere from hours to weeks to sort through the spaghetti code, depending on how badly it was commented, formatted, and designed. It's still worth the time to ask, though.

[Alhanelem]

A model being visible or not has absolutely nothing to do with the game knowing where and how large an object is. The game will always have that information available, whether the target is drawn or not.

It clearly doesn't, because you can often see and target players just as they're loading in (generally when there's lots of people in an area and it's deciding who to load and who to unload)and the targeting cursor points to the ground at their feet, then jumps up to over their head when the model appears. If it knew the size and position of the model before loading it, the cursor would be in the same place the whole time.

it would be an hour long fix at best.

You can't really decide how long it would take something to be coded when you don't know exactly how it's written. It (like everything else in the game is probably written in a needlessly complicated manner, and it's likely the whole reason some of these things don't get changed, outside of ps2 limitations, is because most of the original staff (who would better understand what they've written and how to change it) is likely NOT working on the game now, as you've said.

After all, why isn't a change in stack sizes (outside of analzying the impact of the change) a 30 second fix? One would expect it's simply changing a single number in a database and in the client data.

[Greatguardian]

It clearly doesn't, because you can often see and target players just as they're loading in (generally when there's lots of people in an area and it's deciding who to load and who to unload)and the targeting cursor points to the ground at their feet, then jumps up to over their head when the model appears. If it knew the size and position of the model before loading it, the cursor would be in the same place the whole time.

You can't really decide how long it would take something to be coded when you don't know exactly how it's written. It (like everything else in the game is probably written in a needlessly complicated manner, and it's likely the whole reason some of these things don't get changed, outside of ps2 limitations, is because most of the original staff (who would better understand what they've written and how to change it) is likely NOT working on the game now, as you've said.

After all, why isn't a change in stack sizes (outside of analzying the impact of the change) a 30 second fix? One would expect it's simply changing a single number in a database and in the client data.

You're trying to apply common sense to programming when you clearly just don't know what you're talking about. I'm sorry, but it just does not work that way. Centering a cursor at a fixed position on the ground before loading a model is likely a preventative measure of some sort, similar to target loss itself.

Displaying a model on the screen is the last thing any program will do, and any functions associated with an in-game object are completely independent of the model's actual display. They affect the object itself, a sequence of 0s and 1s and all that fun jazz in memory. Whether or not an object is visible on the screen, the game itself will have height, width, x coordinates, y coordinates, z coordinates, and all other data pertinent to the monster available at all times.

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

[Byrth]

I think I agree with both sides of the argument in this case. The fact that we lose target is obviously an outgrowth of how they programmed the follow command, which probably is limited by some deeper structural problem with the program. If you notice, your own camera doesn't even follow you when you blink. Try gear swapping while riding a chocobo and you'll see what I mean. It's dumb and should be changed regardless of why it exists, though.

Good ideas guys! I'll try to update the OP with them shortly!

[Gallus]

Annoyance: When your movement speed is increased, it doesn't take affect until you turn off autorun. Yet, when your movement speed is decreased, it does.