LS Management

[Soukyuu]

Soukyuu... God, i'd love to see you go down to ANY badly-written program (I think XIV's client would work) and remove an if-check and then you watch the entire program collapse in a black hole of nonsensicality.
You have NO idea how fragile a system can be, specially when it's vastly complex, thrice so when it's badly built.

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.

[Skies]

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.

Aha, I see. No, the fact is probably not the distance, but interaction between zone servers, I think. I do not exactly believe that they have kick functions purposefully tied to distance but- You know how if you have a bad connection it takes forever for people to show up on your screen? And how there are no loading times when entering/exiting city and so on? That's because XIV has this odd 'seamless' transtions between zones, and you cannot actually, for some reason or another, do a variety of interactions between two different zones. (okay you probably knew that already, but it helps the peanut gallery)
I remember the first time I tried to make a party in XIV and it was literally impossible, my friend said "Take two steps forward" and I did- And it solved it magically. Turned out we were trying to make the party while each one was standing right on the border of two 'zones'.

It is possible that this range limitation is tied to that (which is in turn tied to the way the servers are structured, the alteration of which is probably at least 50% of what the work on 2.0 is about), which would be why it isn't possible to alter things right now.

Edit: Also- Suddenly I realize I might not fully understand what you were going on about in first place. I'm not a native english speaker and now and then my language parser just fails me, so sorry if that did occur.

[Soukyuu]

I'm going about being unable to kick a player if they are not online AND standing right beside you. So basically if you have someone in your LS you want to kick, you have to hunt them down. Or break your LS. Same applies to inactive members.

The way i imagine the LS is implemented is a list of names, containing your rank in the LS. So why does removing a name from a list require a, let's call it "zone" check? The player is on the list, so why can't we just remove it? Not only that, they are claiming that enabling us to remove players independent of their zone status would require a major rewrite of the LS system.

(Inviting to a party works independent of players being in separate zones btw)

this was suppose to get added in 1.21(there was a post from yoshi on it)

Could you please find the link? I can't remember them planning to do anything before 2.0

[Skies]

I'm going about being unable to kick a player if they are not online AND standing right beside you. So basically if you have someone in your LS you want to kick, you have to hunt them down. Or break your LS. Same applies to inactive members.

The way i imagine the LS is implemented is a list of names, containing your rank in the LS. So why does removing a name from a list require a, let's call it "zone" check? The player is on the list, so why can't we just remove it? Not only that, they are claiming that enabling us to remove players independent of their zone status would require a major rewrite of the LS system.

(Inviting to a party works independent of players being in separate zones btw)

I think that about this time it's a "Spaghetti Code" issue as a friend of mine put it. I can't actually disagree with you that it seems like it should be simple, but it isn't for some god-forsaken reason, and my wild guess is due to the zone structure, and not a forced check. Same way that buying something straight from the market ward Search feature seems to 'rezone' you. It's less that they have a 'zone check' or 'distance check' and more like the operation is somehow impossible if the other person is on another zone/distant.

WHY is it this obnoxiously stupid? I am very sure that whoever is in charge of looking over the LS code right now is asking himself this same question.

[REDace0]

Ah! That explains why it has to reload everything. It throws you into the zone of whichever ward you're buying from temporarily without telling the client to render anything from that zone. You still have to render the characters fresh when you return though.

This is starting to make sense to me now. Apparently all, or nearly all, player data is actually carried inside the current zone. This is a very poor design choice obviously, but I think this must be the case. It explains why seemingly simple tasks take so much time. They require the creation of entirely new tables and functions to link data from multiple zones.

[Soukyuu]

Apparently all, or nearly all, player data is actually carried inside the current zone. This is a very poor design choice obviously, but I think this must be the case. It explains why seemingly simple tasks take so much time. They require the creation of entirely new tables and functions to link data from multiple zones.

My only reaction, if this is true is:


It would also explain why they don't want to be to specific when telling us they can't do it, they are probably just too embarrassed to admit just how many design mistakes they did.

[syntaxlies]

I'm going about being unable to kick a player if they are not online AND standing right beside you. So basically if you have someone in your LS you want to kick, you have to hunt them down. Or break your LS. Same applies to inactive members.

The way i imagine the LS is implemented is a list of names, containing your rank in the LS. So why does removing a name from a list require a, let's call it "zone" check? The player is on the list, so why can't we just remove it? Not only that, they are claiming that enabling us to remove players independent of their zone status would require a major rewrite of the LS system.

(Inviting to a party works independent of players being in separate zones btw)
Could you please find the link? I can't remember them planning to do anything before 2.0

i looked for the quote but couldn't find it. you would have to check all the dev post. it said something along the lines of: after the item search is complete we plan to revamp LS system for 1.21, how ever this will be a difficult task.

Someone posted it it in another LS management thread back in DEC(i think dec), but i couldn't find the thread.

i had also re-posted it in another thread and posted it on my LS website but it doesn't save the shout box that far back.

I do know that it was created after the original post that said they couldn't do it because of server limitations.

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