Patch 7.2's Account ID protection measures have already been circumvented

[Kazuke_Miso]

And we're watching the problems with that in real time. FF14 makes plenty of money, getting more power for their servers should not break the bank.

I mean I seriously cannot imagine doing server-side blacklist calculations cost that much extra money. At some point FF14 players have to realize that CBU3 is the epitome of a penny pinching studio. Yoshi P is a glorified accountant. He takes pleasure in cutting costs on his precious spreadsheet.

[PotatoePet]

I mean I seriously cannot imagine doing server-side blacklist calculations cost that much extra money. At some point FF14 players have to realize that CBU3 is the epitome of a penny pinching studio. Yoshi P is a glorified accountant. He takes pleasure in cutting costs on his precious spreadsheet.

Programmer (and former game dev) here with nearly 20 years of experience (also server-side development):

I assume that yes, it will cost more power. I assume this because they implemented this feature in that way obviously to save that power.

If I had to guess how they handle player synchronization in open field is that they have a mesh of cells. Every cell can be subscribed to by players and are a basically shouting out all information required to synchronize data with all subscribed clients. (Everyone receives the same data) You can see those cells in-game btw when there are a lot of people around and the game is actively lowering the amount of cells you can subscribe to.

This all is pretty performant as it's basically a simple pubsub system. Creating custom packages for every user would mean extra computing power needed.

As I never have worked on a MMO before I can't estimate the exact extra cost. It might also be a problem of old code not being able to support this change requiring at least a refactoring of that old code.

Just wanted to add my 2c because people in the forums are always like "This is a beginner problem and totally easy to solve." when they most likely never worked on server-side code before.

In regards to that "cryptography" attempt of them... That's actually a beginner error. But any cryptographic approach is destined to fail anyway, be it a hashsum or actual encryption as the client itself still has to be able to differentiate between players so hashes need to be unique or the encryption has to be decrypted by the client (and therefore must have a key to do so which can be extracted)

[Gurgeh]

Programmer (and former game dev) here with nearly 20 years of experience (also server-side development):

I assume that yes, it will cost more power. I assume this because they implemented this feature in that way obviously to save that power.

If I had to guess how they handle player synchronization in open field is that they have a mesh of cells. Every cell can be subscribed to by players and are a basically shouting out all information required to synchronize data with all subscribed clients. (Everyone receives the same data) You can see those cells in-game btw when there are a lot of people around and the game is actively lowering the amount of cells you can subscribe to.

This all is pretty performant as it's basically a simple pubsub system. Creating custom packages for every user would mean extra computing power needed.

As I never have worked on a MMO before I can't estimate the exact extra cost. It might also be a problem of old code not being able to support this change requiring at least a refactoring of that old code.

Just wanted to add my 2c because people in the forums are always like "This is a beginner problem and totally easy to solve." when they most likely never worked on server-side code before.

In regards to that "cryptography" attempt of them... That's actually a beginner error. But any cryptographic approach is destined to fail anyway, be it a hashsum or actual encryption as the client itself still has to be able to differentiate between players so hashes need to be unique or the encryption has to be decrypted by the client (and therefore must have a key to do so which can be extracted)

Absolutely! 100%!

But I don't think many people have suggested if a "begginer" issue to "solve".
I think what they (and I) have suggested is that is a "beginner" issue to "not make in the the first place". And in that they are 100% correct, and another 1000% on top of that.

- They should never have started exposing the account ids to the client 'in plain text'.
- They should 'never' have started exposing the account ids to the client.
- They should never have started exposing the account ids to the client in a game that is 'rife' with addons, and has a game culture where cat/bun-girls and romantic (oft confused) relationships are hallmark of your game.

It was a beginner F up not to make.

What is also 'very' feasible if you can be arsed is to roll it back.
Not saying its easy.
Yes rebasing the code will be gargantuan.
But it is doable.
It frankly 'has' to be done. Its the only option on the table.

AsI've said elsewhere I could easily believe tha moving this server side is well within 'infeasible' (effectively impossible) territory. (Unless you want to be changing so much you'll be irining out the kinks and game breaking bugs for the next 3 years)

I'll be blunt what I think they should be doing is saying:
- We realise we have messed up. We hope you understand we did this with the best of intentions. But we realise we have really messed this up.
- Many of you are not going to like the following, but we have a responsibility as dev to show leader ship. (the same way we do on other ocassions we don't listen to you and do our own thing anyway)
- ALL game dev is now on hold until further notice.
- We are continuing suspension of housing until dev resumes. We anticipate many of you will want to pause your sub. (hell even offer free sub, or heavily discounted to cost of keeping the lights on in the server rooms.)
- All dev resources are now working on rolling back this change and the testing that entails. This will be a herculean task for us as obviously we can't just delete DT with that. (yes I know, no jokes abut you wish they would please)
- There will not be any field operations. There will not be any more dungeons, nor msq, nor raids, nor unreals, not fesitval-events until this work is complete, except were a this does not in anyway delay or remove resources from rolling back the blocklist change.
- We are very sorry for this but the welfare of the community is the most important thing to 'us'. (we are showing leadership and following our own mind on this)
- It is a certainty that all content will be severely delayed I am afraid. We are very sorry.

(hey, we can't offer you our AAA titles, but maybe you'd like to claim a couple of old titles. We are 2 old final fantasy titles on your registered XIV platform. Perhaps you'd like to try something you've seen appear in XIV? Something you probably never would have bought.)

"We are your friends. We've got your back"

And really those that want to get indignant that their raiding schedule is a serious busineness and must not be impeded. F'em.

[PotatoePet]

...

Yea, one would wish they would take any responsibility in the situation.

AsI've said elsewhere I could easily believe tha moving this server side is well within 'infeasible' (effectively impossible) territory. (Unless you want to be changing so much you'll be irining out the kinks and game breaking bugs for the next 3 years)

Which brings me to

People here keep missing the fact that the privacy issue is fundamental to the feature, not the implementation. So long as the feature is "block all characters in a given user account", there is no possible implementation that will address the privacy concerns.

Yea, that's true. The feature will always make it possible to link one character to another. Only thing they can do is making it harder. Question is, if this is actually worth it for the little effect this feature actually has and if just increasing the block list to 1000 slots would be a better alternative.

[Rin_Sato]

.
...
Question is, if this is actually worth it for the little effect this feature actually has and if just increasing the block list to 1000 slots would be a better alternative.

Making the blocklist 1000 slots does sound like the best option, especially with how simple and easy it would be to do, they can't possibly mess that up too...