Fundamental Game Play Issues

[Zirael]

Funny how many people are against changes that make sense + playing experience easier. Sure, you can get anywhere in New York by walking (and some would argue it's good workout for your health), but me personally, not being masochistic if only possible, would use metro to get from 1 end to the other. Dear SE, cater for sane people, not masochists, please.

I think I wrote somewhere sometime on these forums my issues with game's GUI already (pretty much similar to Byrth's), but to reiterate and expand:

Losing lock on monster after gear swap JA/magic (try playing THF and running around monster in circles for SA/TA/WS for several minutes, it hurts THF's DPS alot)
Collision lock with other players/monsters - every time you bump on a player/monster you are stopped in your tracks for ~1s. What's the point if then you are allowed to pass through them anyway? To say your greetings to each others? Makes no sense. And it's a real hindrance when you're in Port Jeuno, it's Saturday JP time and you're trying to get in your Mog House, or when you're kiting something (let's say King Behemoth back in the days, I know that area is huge, but as an example, if you had 200 people against you, they could MPK you with collision lock) and people get in your way (on purpose or even not on purpose).
Losing Reraise status when DC and you are subsequently killed by whatever you were fighting - not a major issue, but still. My friend was soloing Dynamis yesterday (he missed our scheduled run, so had to solo) and his game crashed; he logged back and was dead without Reraise. Having all your friends unable to come and raise and having everyone in zone too busy with their timed event's tasks (or unwilling to help competition), your only option is Home Point.
Unable to /search when dead - why is it that when you are dead you are not even alowed to search around for people who could raise you? You are unable to /shout for your own raise either. But you are still able to send /tell Anyone sees inconsistency and bad game design in this logic?

Also, in before PS2 limitations / spaghetti code / we-are-too-busy-adding-new-job-emotes-to-fix-this-for-you-so-U-mad?

[Arcon]

Unable to /search when dead - why is it that when you are dead you are not even alowed to search around for people who could raise you? You are unable to /shout for your own raise either. But you are still able to send /tell Anyone sees inconsistency and bad game design in this logic?

Reminds me of something else.... enable UI controls when dead/charmed. Also... while I get that you can't /say or /shout while charmed/dead for logical reasons, it makes no sense gameplay wise and just frustrates people, especially since you can still /tell or /p or /l. Why does it make sense for some things, but not for others? And not being able to control even the game UI when charmed is completely senseless.

[Insaniac]

I know they said they were looking into it but it seems like they forgot so:

Losing cruor buffs when you DC: DCing in the middle of a fight and coming back with half the hp/mp/stats you had when you DCed is stupid. It results in lost cruor, time, and sometimes lost fights. I assume the reason they drop on DC is because they share buff IDs with all other forms of stat boosts like DRK absorb spells and fenrir buffs which is also an issue because it causes these types of spells and abilities to have no effect.

Tractor zoning: Why in the world? Wouldn't it be less trouble to have this simply work like a monsters draw in effect? This problem is compounded in abyssea by the fact that "tractor zoning" causes you to lose visitant status.

[Tamoa]

I'd "like" the OP here a thousand times over if I could.

[Urteil]

Never experienced any of these things.

Welcome to FFXI, enjoy your bought character.

[Alhanelem]

OP covered the most longstanding problems in the game pretty well.

Just one thing-

* Blinking after gear swaps - The person you're targeting and their position are independent of the clothes they're wearing, so why is it programmed to break focus when someone gear swaps? This is annoying.

I doubt that it is "specifically programmed" to break your target lock. How it is, is that your character model momentarily disappears while the game loads the new model. The game uses the height/size of the model to determine where to put the targeting cursor, so when the model disappears, it has no place to put the target.

It's still something stupid that shouldn't be there, but I'm pretty sure the losing target is just a side effect rather than a conscious decision.

Then again, the solution is the same regardless- program it so it doesn't do that. ;p What happens when you think out loud.

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