Party Finder Notification

[Greed]

Actually I like it....
Than again some people don't even like to see "FC members log-in text in chat log..."

[Arcaloid]

I don't think they can send you notification whenever someone post a new PF that suits your search, because that will increase server load.
They can however, make client to remember the last search result, and compare it when it does the background search so it can tell you how many listing are new.
This may need to be an option that players can enable/disable though.

[Arkista]

It is pretty lame feature as is, But with some work it could be perfect. As the OP said, I was under the impression that it would allow us to set which dungeon or content we are looking for, And when someone starts a party it would notify us. Not just tell us how many parties are seeking.

[DSN]

I don't think they can send you notification whenever someone post a new PF that suits your search, because that will increase server load.

Actually a simple pub / sub model could fulfill this with little overhead server side.

[DSN]

It was mentioned already that doing what you suggest in the OP would cause much server stress, so they went with that simple implementation and will monitor servers to see if they can improve it at a later time.

Not true unless you dont know what you are doing

[joshsecret]

i honestly thought it would come with a window like the DF to where you could select a few options and it would keep track for you. i know nothing about servers or stress or anything technical so ill leave that to others to discuss.

off topic:
one thing that i find odd, is that when you tech ppl talk or i read dev responses about how they cannot implement certain options due to _______; then why do we have the floating text now when you scroll through your friend's list?
again i wouldn't even begin to know how much space that takes up, but it seems kind of redundant. yes i know they are offline, i can tell by it being grayed out and the symbol next to their name, so why use up space to have flying text?

[Wobble]

I was pretty disappointed myself.

[Yshnal]

Not true unless you dont know what you are doing

Explanation below:

Can you add some sort of feature where we can select what content we would like to do and then there is a notification when someone creates a party for it? For example, if I want to fight Ifrit, I can check a box on the list and when someone starts a party in Party Finder for Ifrit I would receive a notification.

The notification feature that is to be added in patch 2.16 is an extremely simple message that displays the number of recruiting parties every 15 minutes.

By only notifying the number of new parties and sending this to all players, the stress on the server would be minimal.
*On the client side, you can hide this notification, so that it won't appear in the chat log.

This feature alone should be sufficient enough to prompt you to check the party finder list, instead of having to open the party finder window to check if there are any new parties gathering.

However, from a player's perspective, the requested feature is useful and it would definitely be convenient to have this.

The problem with this, as usual, is server stress.

To implement the requested feature, the following is a rough idea of the data and processes that would have to be added.

1. Expand the party finder server so that players can register content they wish to participate in and be notified when it appears.
   
   Add server memory.
   
   Make it possible for each player on each World to register (roughly a max of 5,000 players).
   *With the implementation of the feature in 2.16, this memory is not needed.
   
   
2. Make the party finder feature server execute the notification process at either of the below timings:
   

   a. When the notification list is updated in #1 (possible for 5,000 people to update this whenever they like).
   b. When a new party recruitment is registered.

   To give a breakdown of the notification process, all of the newest notification list registrations and all of the newest parties that are recruiting would be compared, and then the system would determine to which character and for which recruitment a notification should be made, and this process would involve sending out notifications to each character on an individual basis.

Therefore, compared to the previously mentioned feature planned for patch 2.16, memory would be needed to perform this process on the server side, and due to the fact that the processing load would significantly increase, countermeasures would be necessary to disperse the load (which could potentially involve enhancing the actual servers). As a result, this would drive up the time needed for implementation as well as the work needed to ensure stable operation.

Due to the above reasons, we will be pushing out smaller-scale changes to features that can be accomplished with a small amount of server stress and bit-by-bit improve their convenience. As for features that run large risks of server stress, we will continue to look into everyone's requests and see if we can implement them in some way as operation of the game moves forward and the conditions change.

http://forum.square-enix.com/ffxiv/t...=1#post1829032

[DSN]

Over complicating something does not make a good solution, there is no I need to perform all this analysis.

The desire to make the server do and be the final end for everything is not good practice.
Read about collision detection in online gaming, there is a reason the majority of the market has scenarios where the client wins because it doesn't matter what the server sees if it is not accurately portrayed to the clients (I shot him why did it miss?, I dodged that why did I get hit)

Here is how pub / sub works. You subscribe to a queue, when an event occurs that affects members of that queue you fire a message to members of the queue.

Real world example:

I want to run Ifrit Extreme. I mark notify me of new groups for Ifrit EX.
On the backend I am put in the queue Ifrit Ex
Someone Creates a party for Ifrit Ex
This triggers an event to notify users in the queue Ifrit EX

What does this take to process?
Sending a message

What great analysis needs to be done to accomplish this?
None

How do you deal with 5000 people wanting to run the same content?
You create sub queues based on data centers, languages, or abitrary max limits for queues (If queue A has 200 members create queue A.2 and start putting new users in here using LRU and FIFO)

How much data is required to process this data?
This could be accomplish this with a small JSON message {queue: 'ifrit ex', count: 20} which could trigger the message client side "There are {count} groups in Party finder for {queue}" or "A new group for {queue} has been created in the party finder". You could even put the rate limiting on the client side as to not repeat messages to frequently by adding a timestamp to the messages.

But what about the servers?
Look websites do this all day everyday, if the servers powering this game cant do what a basic Ajax website can handle something is very wrong here. The queues should be per data center and should be a system that sits besides current infrastructure in an SOA architecture, it should also be resilient to the point where if this should fall down and crash it does not impact normal game play as it is again not a part of the main servers running instances, zones, etc.

None of this is not hard to accomplish.

[Yshnal]

I'm the first to be against doing everything server-side (specially with no EU datacenter), but I also realize that if they want to do it that way (and it's our reality, like it or not), then they're doing the right thing by not implementing fully something that would stress the servers until they can be sure that those can handle it. I prefer that to the alternative of them deploying it fully and having lag or crashing the servers.

Anyway, what you're explaining is the same that Mr. Minagawa explained. In order to do that, you must think in the worst case scenario (5000 users needing that message, each and every one of them subscribed to a different event). That would require the server to process what info has to send to which user, and that's what he was explaining. Right now the server only handles ONE message for the whole 5000 players, without having to reserve processing resources to process and send any extra message. In other words, right now the server just looks how many PF groups there are there without looking anything else and sends the number to all clients, but by doing what you suggest it would have to look the number of PF groups for A content, the number for B content, etc. and then send those different messages to all clients. It would require the same resources as what we have now, but multiplied by n, where n would be the max. number of possible events (n will increase in the future when more content is introduced, and they have to account for that too, at least on medium term).

Also, running a website is not the same as running an MMO. The processing power and memory resources required for everything that is running here is way more than what a webserver has to handle. I know this first hand, as I've worked with and monitored both (and in an MMO more reliant on the client, that gives the servers less load than what they get when almost everything is done there as is the case in FFXIV).

It's not something trivial to do, and one has to be careful when implementing things such as those or you break the whole system.