LS Management

[Asiaine]

I spent enough hours debugging my own code, so I DO know how fragile a system can be.

BUT. If this:

if (person.distance <= 20)
{
   kick(person);
};

cannot be changed into this:

//if (person.distance <= 20)
//{
   kick(person);
//};

Then the person who wrote that engine needs to be fired immediately. I am not saying it's how the code looks like, any equivalent of the above code can work. If it's a function, make it return true no matter the distance. If it's a function that is used to calculate distance elsewhere, remove the check and just set the result for kicking the player to true.

I am talking about cases where removing an if-check makes sense, not about ones that make the whole thing collapse. It doesn't make sense to talk about those cases.

Name me one example of how kicking a player could be implemented that makes removing the distance check impossible. Until then, my opinion won't change. The excuse of being unable to remove distance/online check is BS.

There is more to it than that:
A check has to be done to see if the user is available and can be 'modified'.
The user who is removed has to have the linkshell removed from their list of linkshell.
The user who is removed has to have their linkshells re-listed so that they appear in a new & correct order.
If the user who is removed is on the linkshell when being removed something different happens than if they are not on when they are removed.. This has to be handled as well.
The server has to be notified to no longer relay messages to that user since they have been kicked.

All of these require communication. Unfortunately it appears that any sort of communication outside of a very small range is severely restricted. So it may not be possible to send requests to do all these actions if both parties are not in the same location at the same time (and therefore being processed by the same server/whatever).

So it is not quite that simple

[Soukyuu]

There is more to it than that:
A check has to be done to see if the user is available and can be 'modified'.

The user data should be available since the data is stored on the server(s), most likely just an entry in a database.

The user who is removed has to have the linkshell removed from their list of linkshell.

This is possible the moment the user data is available (see above)

The user who is removed has to have their linkshells re-listed so that they appear in a new & correct order.

There is no "correct" order from what I can see, every time I get a new LS/throw away a pearl, the list gets randomly thrown around. In any case, it is a modification of character data - not based on online status.

If the user who is removed is on the linkshell when being removed something different happens than if they are not on when they are removed.. This has to be handled as well.

that one is independent on being online - it's just a flag in the character data which tells you which linkshell you have set.

The server has to be notified to no longer relay messages to that user since they have been kicked.

This happens when a LS member sends a message, it is relayed only to those who are members of the shell and are online at the moment - this is not part of the kicking procedure.

All in all, you list things that make sense, but nothing is tied to the user being online at the moment of removal. I did say my "example" was heavily simplified.

Communication/synchronization between zone servers also works as long as both players are online, so even if each server really has it's own database, it still doesn't explain the inability to do the same queries when one of the players is offline. It's as if to kick a player you send a request to the player's client to execute the "retire" command. If it's the case then may the Twelve help SE.

[REDace0]

...It's as if to kick a player you send a request to the player's client to execute the "retire" command. If it's the case then may the Twelve help SE.

Ding ding ding! I think we have a winner!

As a software dev myself it's been really fun following this thread and analyzing the potential causes of this bizarre limitation. Thanks for continuing to contribute.

[Asiaine]

The user data should be available since the data is stored on the server(s), most likely just an entry in a database.

Yes, the emphasis on 'should' is valid. It may not be the case that this is happening. Which could then help explain why all the other things do not happen properly.

I have sneaky feeling all data is held in a very localized area (not whole server wide, but sub-zone wide) which is why every time you move 100 feet in ul'dah everything takes so long to re-load. Either way.. we are speculating, and my statement above was not to say fact but to suggest that there may be some reason why it is not so simple.

I think it can be taken for granted that there are many areas for improvement in the present server base (by SE's own admission) and one of those may be the root cause here.

This happens when a LS member sends a message, it is relayed only to those who are members of the shell and are online at the moment - this is not part of the kicking procedure.

The 'list' of the members who should receive the message must be maintained. The user getting kicked must be removed from this list. In a way I am glad it is not so that the entire LS must be online and in the same room in order to kick someone.

The code to remove the user from this list may not work properly when the user is not online.