/SEACOMSHOUT (SUBJECT) Command: *All Server-Wide Shout Threads Compiled Here*

[Greatguardian]

Shout messages are broadcast everywhere, and then filters determine whether they are seen client-side or not.

Linkshells, on the other hand, are simply their own communication network. The server does not have to send global messages for them. However, at the same time, Linkshells have a definitive maximum number of people in them (64).

You can't use the linkshell system to create an instance for EXP or Missions because each linkshell network instance cannot exceed 64 people. If you tried to exceed that, then yes, the same sort of server load increase would occur.

[wish12oz]

Linkshells have a limit of 64 players in them at a time, the server load thing is probably why, and I doubt the message is sent to every zone, it's probably sent to only the players who have the LS equipped, not the zones and everyone in them, or every person with an LS. If every person with an LS got sent the messages, there would be no need to cap them at 64.

EDIT::: beaten by a minute =|

[kingfury]

Okay, with that understanding in hand, is there in fact a limit on how many linkshells that can be possessed per server? If not, what if the specific /seacomshouts were designed to reach a specific number of players per message sent. Similar to how the "search current zone" truncates the list after listing so many players.

Perhaps between a combination of displaying a message to limited amounts of players and alerting those tuned into those channels through the appropriate comment category to check the most recently added message(perhaps like a /lsmes) once that limit has been reached, a modified Linkshell network could then provide a vehicle for such a system as I'm suggesting.

[Greatguardian]

There probably is a limit to how many linkshells can be on each server. There is already a limit on the number of linkshells which can be created each day.

A system like that may as well just be people creating linkshells and calling them EXP1, EXP2, EXP3, etc. That's pretty much what it comes down to. And if that's what people want, they may as well do it right now with the current linkshell system.

[Byrth]

In the time of broadband, "server load would make it unpossible" seems like a pretty silly defense, but it's possible that it isn't.

At 256 Bytes per message (~200 potential characters + transfer information), sending that information to 4000 players would result in less than 1 MB of traffic for SE (~.25KB for players). Still, 1 MB * 3 shouts per minute = ~4 GB more bandwidth per day = ~120 GB more bandwidth per month

Realistically, this probably works out to about ~$100/month more in costs per server, so Profits -$1600/month. No one is going to unsubscribe if this feature isn't implemented or resubscribe if it is, so they have no reason to cut their profits.

[kingfury]

There probably is a limit to how many linkshells can be on each server. There is already a limit on the number of linkshells which can be created each day.

A system like that may as well just be people creating linkshells and calling them EXP1, EXP2, EXP3, etc. That's pretty much what it comes down to. And if that's what people want, they may as well do it right now with the current linkshell system.

-------------
Funny you should say it that way since I was going to break it down in a similar fashion. The system would be the one organizing it in such a fashion, not us. All neatly behind the scenes. I would hate to try and describe it all in text description /stagger. It's a bit much to try to explain in just words, so I'll have to put together some sort of diagram to sort my thoughts in a way to make it easy to visually communicate(for myself mostly lol).

[kingfury]

I'll start off by saying, as I've said in other threads, I'm in no way a programmer! lol My thoughts on the possible workings of this /seacomshout's systems are totally based on "theoretical possibilities", so if anything seems too far fetch, take it easy on me. ^^; Hopefully the Devs will consider this a springboard concept and then tailor it to fit actual programming laws. I'm just attempting to think around the problem in a creative way.
------------

The Master Linkshells:

Imagine if each /seacom subject category had a respective Master Linkshell that could only discuss messages and shouts that pertain to their subject category(ex: "EXP" M.Linkshell, "Quest" M.Linkshell, "Missions" M.Linkshell, etc.). For the sake of argument, lets assume that they had the same limits of 64 members per shell as our everyday Linkshells do. The main difference between these linkshells would be that they have the ability to clone themselves multiple times to accommodate the amount of players that are "tuned in" to their respective /seacomshout subject categories. The very moment that 65 players toggle their /seacomshout channels to "ON" for that specfic channel, these Master Linkshells would instantly create a cloned version of itself to house that extra player. Cloned Linkshells would function exactly like their master versions, and would share the same messages sent to their Master Linkshell with all players housed within them. The cloned linkshells would house the same number of players as their masters. The Master Linkshells would constantly monitor how many players are tuned in so to always be ready to create the needed amount of clones to house them. The player game-side would be none the wiser as to this process's happenings, and would only notice an increase in messages being displayed within that /seacomshout subject category.

•The Master Linkshells

Expansion and Sharing of Messages:

On the back end behind the scenes, based on the /seacom category, the Master Linkshells could consider themselves EXP1(Master Linkshell), EXP2(Clone), EXP3(Clone), and so forth up to perhaps a specific limit as the number of tuned in players increase. So ideally, a Master Linkshell could clone itself over 9 times to accommodate 640 players tuned into it's /seacomshout subject category. Depending on the server limits governing Linkshell creation, 1000+ players could all be tuned into the same /seacomshout subject category while being being distributed amongst 16 Linkshells. All able to communicate Server-wide on the corresponding /seacom subject matter of their choosing without disturbing any other players throughout Vana'diel's zones. So long as the player inputs the appropriate subject within the /seacomshout message while composing it(ex: /seacomshout [EXP]), the message will be sent to the appropriate Master Linkshell to be distributed to all cloned linkshells. All /seacomshout messages composed and sent by players would 1st be sent to the Master Linkshells before being shared with clones so the Master Linkshells could determine how many clones need to receive the message. This would ideally happen almost instantly, and no player would be able to notice any lag between composing/sending a /seacomshout message and seeing the message displayed within their chat log as to make it feel similar to how linkshell messages are processed.

•Making Clones

Clone Deletion:

This system would have the ability to expand as needed depending on player load instantly, as well as shrink instantly as players toggle their /seacomshout channels to OFF. Master Linkshells would reserve the ability to permanently delete any cloned linkshell as soon as the reduced player load constitutes they are no longer needed. Should that same load of 640 players tuned in to that /seacomshout channel be reduced to 140, the Master Linkshell would delete 7 clones and house that 140 within 3 linkshells(the Master + 2 Clones). This would constantly be happening throughout the day, all seamlessly behind the scenes as players simply toggle their channels ON/OFF in-game. The Master Linkshells would be diligently cloning and deleting clones to constantly accommodate the number of tuned in players.

•Deleting Clones

[Runespider]

Any kind of global chat channel needs a strict time limit on repeat usage, say 5 mins. That would cut out most spam chat and make it more of a worlwide bulletin system for PuG content. As hard as it may be to implement it's either that or everyone will be forced into port jeuno forever.

I think Square more than anything fears spammers being reported and having to be dealt with by the undermanned GM team, they almost always counter stuff that leads to that.

[Byrth]

Unless you're bored and just like to draw, you should read my post again. $1600 is probably the profits from about ~200 accounts. Not counting the resources (programmer time) that would be consumed to make such a system, do you think 200 accounts would be created or maintained by introducing a new shout system? SE is a business. If the improvement you're suggesting doesn't offset the costs, it won't be implemented.

If you want your suggestion to be implemented, couple it with a technological solution that will offset the cost of implementation somehow. For instance, say you look at the program and notice that messages sent are always coded as 256 bytes with a bunch of null characters instead of a more efficient variable-length solution. So you suggest that SE start encoding message length and shortening the message sent, saving them a large amount of bandwidth every month.

Say you realize that all characters are not used at the same frequency, so you propose a more efficient encoding scheme, where less common options require more data to transmit but higher frequency options are encoded more efficiently, thus reducing the effective bits/character.

Consider reading the "Efficient Encodings" part of this page: http://www.cs.cmu.edu/~dst/Tutorials/Info-Theory/

[kingfury]

Unless you're bored and just like to draw, you should read my post again. $1600 is probably the profits from about ~200 accounts. Not counting the resources (programmer time) that would be consumed to make such a system, do you think 200 accounts would be created or maintained by introducing a new shout system? SE is a business. If the improvement you're suggesting doesn't offset the costs, it won't be implemented.

If you want your suggestion to be implemented, couple it with a technological solution that will offset the cost of implementation somehow. For instance, say you look at the program and notice that messages sent are always coded as 256 bytes with a bunch of null characters instead of a more efficient variable-length solution. So you suggest that SE start encoding message length and shortening the message sent, saving them a large amount of bandwidth every month.

Say you realize that all characters are not used at the same frequency, so you propose a more efficient encoding scheme, where less common options require more data to transmit but higher frequency options are encoded more efficiently, thus reducing the effective bits/character.

Consider reading the "Efficient Encodings" part of this page: http://www.cs.cmu.edu/~dst/Tutorials/Info-Theory/

--------------
I read your post ^^ and I agree that SE is indeed a business and has to consider all development cost based on any and all suggestions to improve this game.

I can't say that I agree that offsetting those development cost is always the definitive for SE's choice to improve gameplay however. For instance, just look at the Atma menu improvements being planned here. This is an issue that obviously is taking development resources and time to design and implement, but based on the outcry from players, SE's is deciding to rectify undesirable gameplay issues simply for the sake of improving gameplay. The same can be said for a number of other in-game fixes that have been implemented over the last year based on player feedback.

I believe if the suggestion is realistically formatted by the player in terms of possible development needed to actually consider it worth investing development $$'s into, there's a good chane SE can realistically consider the suggestion and implement it over time. Enhancing the /seacom system using Linkshell functionality shouldn't really be considered "a new system" since both the linkshell system and the /seacom system exist already. It's more like tweaking it to work in a different way. The suggestions you've just posted are great in terms of making the solution more realistic for the Devs to implement. This issue is one that SE has already expressed interest into solving, so I'm not sure why you believe it's not already on the Devs plate in terms of development time(post from Camate on the OP). I'm simply suggesting another possible solution to the problem since the solution is still being considered by the Devs.

Not bored since I do enjoy suggestion new concepts, and yes, I do love to draw ^^

/pops some popcorn to prepare to read the "Basics of Information Theory". ^^