LS Management

Please for the love of the twelve could we possibly get LS management tools added already! I mean it can't be that difficult can it? Can we get a response on when this will be addressed already!

Agreed. We need at a minimum:

- Ability to remove players from LS from any location.

- Global Linkshell Message of the Day (so leader and officers can set daily info for members) this needs to be UI and text command.

- Linkshell Event Attendance tracker. An in game system that allows leaders and officers to schedule events in game based on current content and tracks or allows leader and officers to track which members participate in those individual events. There should also be a point system to simplify the viewing of each members attendance.

- Linkshell Bank: members can donate Gil, items, or gear to be stored in the bank which can be used to fund events or help other members whilst keeping tracking of each donation and withdrawal.

As much as I agree with you on this, I doubt it will happen as soon as we'd like.. :[

The sad truth is....The Devs seem to ignore this very real issue. I mean I realize that there are other things that need to be fixed, but seriously the ability to at least remove someone from the LS regardless of if the are online or nearby should be fairly easy to fix which will help out greatly. I mean for the love of everything that is holy we are now paying for the game is it too much to ask for this small favor?

They will probably just blame it on "server limitations" and we will have to "be patient until 2.0".

It really is beyond ridiculous at this point. The core of any MMO is its social aspects and Guild Management is a massive contributor to a MMOs various social aspects.

This should all have been fixed way before now. I'd even say 1.18 should have included more LS administration options and refinements.

Disbanding an entire LS because some lazy ppl stopped playing the game and are wasting potential active member space... Then creating a new shell... Then REinviting EVERY active member into the newly formed LS... Stupid.

Not being able to kick members from your LS unless they are standing right next to you... Yet again, Stupid.

Very common, simple, and important issues which have never even been touched... and sadly those are only the beginning of the much lacking Linkshell management options.

I seem to recall an actual dev quote that said they were unable to implement these features until the server is revamped in 2.0.

Sadly, I looked and I looked, but I was unable to find that quote, so take that with a grain of salt.

I recall the same thing Raldo. There seems to be something about the way the data on the server is structured that would make certain data operations infeasible. From what I've read, part of the problem is that segments of each game world and their corresponding data live on separate physical servers. So if a player is somewhere else in the game world on a different physical server maybe you can't update their Linkshell data?

If that was the case which it could be as I am not all that familiar with coding, would that not have made the party search feature that they put in impossible as well?

Who knows, but you'd think if you can invite anyone from anywhere, you could kick them from the linkshell from anywhere.

I'm sure it made it very difficult, but party status isn't linkshell status, and it may be that with the party search system in place they have established the framework needed to implement linkshell management. However, that means the server programmers, who are currently implementing a better-architected system from scratch, have to find time to code this new feature and then it has to pass QA. We may see it in the next patch or two.

I guess my real issue is that they kept LS from FFXI but failed to put in what made LS useful! It was not like they did not have a guideline on how to do it. In doing so we are still paying for a game that is horribly broken. The Devs answer seems to be "Let them eat cake."

Allanon, if you did not yet realize the previous devteam made some horrible, horrible choices, which are being fixed now.
I have... No idea HOW in the sake of forever they screwed up the server structure so badly, but they did, and fixing that is apparently work of nightmares (I wouldn't doubt).
So they can't fix this just yet, but are most probably going to fix this ASAP.

Quote:

---

Originally Posted by Raldo

I seem to recall an actual dev quote that said they were unable to implement these features until the server is revamped in 2.0.

---

I remember them saying that too, though I call bullshit on engine limitation excuse. Seriously, what engine breaks down if you remove an if-check from a piece of code?

Quote:

---

Originally Posted by Soukyuu

I remember them saying that too, though I call bullshit on engine limitation excuse. Seriously, what engine breaks down if you remove an if-check from a piece of code?

---

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.

Quote:

---

Originally Posted by Skies

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:

Code:

---

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

---

cannot be changed into this:

Code:

---

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

I doubt it's impossible for them to do, it's probably just too troublesome / they have bigger priorities and 2.0 is less than a year away. So they go with the "we can't do it due to the data structure" excuse as a PR move.

Quote:

---

Originally Posted by Fated

I doubt it's impossible for them to do, it's probably just too troublesome / they have bigger priorities and 2.0 is less than a year away. So they go with the "we can't do it due to the data structure" excuse as a PR move.

---

They said they could do it but they have to redo the system then redo the system again for 2.0 so they said they did not want to waste the time on it :(

Quote:

---

Originally Posted by Zenaku

They said they could do it but they have to redo the system then redo the system again for 2.0 so they said they did not want to waste the time on it :(

---

They should just give some intern that part of the code. We don't need a complete overhaul, but being able to kick inactive members is a must.

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

Quote:

---

Originally Posted by Soukyuu

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.

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)

Quote:

---

Originally Posted by syntaxlies

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

Quote:

---

Originally Posted by 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)

---

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.

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.

Quote:

---

Originally Posted by 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)
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.

Quote:

---

Originally Posted by REDace0

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:
http://i44.tinypic.com/2ebc13q.png

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.

LSMES
LSMES
LSMES
LSMES
LSMES
LSMES
LSMES
LSMES
LSMES
LSMES
LSMES
LSMES

I'm with Crim on this one.

Let's be skeptical, lets presume the engine has been coded so terribly in the first place, that for instance, for player A to interact with player B they need to be in the same zoned area.

So perhaps the command might look like this presently.

PlayerA has to send this message to PlayerB
[playerB breakPearlForLinkshell:linkshellNameID];

And, if playerA doesn't have access to a pointer for playerB then it can't send that message.

However, there is no reason why commands should be sent from player to player, surely all commands are sent to the servers, and thusly the servers back down to the players.

So, in reality, it should be more something like...

[server breakPearl:playerID ForLinkshell:linkshellID];

the player would then receive a message from the server

[self breakPearlForLinkshell:linkshellID];

Simples?

What if that player is logged off? :O, well, then the pearl should be set as a flag in the players userdata and then be broken when he logs in.

However. /pcmd add "player name" works across zones. You can practically invite people from anywhere.

Bad excuses for not remedying the linkshell kick/remove and atleast a MOTD litterally 8-10 months ago, are unacceptable.

i'm ok with the first 2 but the others that is just how u manage your ls don't need that in game u can do that on a web page

Quote:

---

Originally Posted by Myrhn

i'm ok with the first 2 but the others that is just how u manage your ls don't need that in game u can do that on a web page

---

i see a lot of people downplay what LS management shouldbbe like. heres what the competition has,


http://www.youtube.com/watch?v=8fVuohgoHX8

Quote:

---

Originally Posted by syntaxlies

i see a lot of people downplay what LS management shouldbbe like. heres what the competition has,


http://www.youtube.com/watch?v=8fVuohgoHX8

---

Thats very nice but it works there because they actually lvl the guild/ls, in here fo far we don't do that sort of stuf so is not really necessary and that can be leave outside

Quote:

---

Originally Posted by Myrhn

Thats very nice but it works there because they actually lvl the guild/ls, in here fo far we don't do that sort of stuf so is not really necessary and that can be leave outside

---

your not thinking of the future though. Why we have now is not even close to good enough.

Im not sure how free companies are gonna work but they may be something like that.

Quote:

---

Originally Posted by Soukyuu

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

BUT. If this:

Code:

---

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

---

cannot be changed into this:

Code:

---

//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 :)

Quote:

---

Originally Posted by Asiaine

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.

Quote:

---

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)

Quote:

---

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.

Quote:

---

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.

Quote:

---

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.

Quote:

---

Originally Posted by Soukyuu

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

Quote:

---

Originally Posted by Soukyuu

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.

Quote:

---

Originally Posted by Soukyuu

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.

It could be like this, I just don't see the connection to the user online status, since no character data is stored on player's PC (apart for the UI element postion, chat logs and macros).

That's why I half-seriously suggested it just calls the client's "retire" command without a prompt, that would explain the online requirement.

Quote:

---

Originally Posted by Soukyuu

It could be like this, I just don't see the connection to the user online status, since no character data is stored on player's PC (apart for the UI element postion, chat logs and macros).

That's why I half-seriously suggested it just calls the client's "retire" command without a prompt, that would explain the online requirement.

---

Maybe target user's data is not available unless target user is online.... that could be interesting.
When offline user data not stored on active server.
When online user data moved from inactive server to active server.
User data can now be manipulated a bit ^.^;;

Yes, I agree.. there are many areas for improvement here, and many things are questionable.
I also believe if it were simple fix they would do it. So it may be safe to believe it is not simple. Then just imagine how bad it could really be... then +1 it, and we may be there ^.^;;;;;

For me, I just want to be able to walk through Ul'dah and see people.... lately I can walk around all of Ul'Dah and not see a single person or NPC.. unless i stand and wait...