[Suggestion] Allow us to see the last login of LS members

[FinagleABagel]

It would have been nice, but when an official rep tells you that it's a no go - why do argue with that? Do you have some sort secret insight as to how their DB queries work or if there's a security risk associated with your ideas?

That's pretty arrogant.

[Molly_Millions]

It would have been nice, but when an official rep tells you that it's a no go - why do argue with that? Do you have some sort secret insight as to how their DB queries work or if there's a security risk associated with your ideas?

That's pretty arrogant.

No, but database queries aren't some big industry secret.

[FinagleABagel]

No, but database queries aren't some big industry secret.

Please read. Obviously DB queries aren't secret, but I wasn't aware that you knew what SE's DB architecture was. Or how they query the database. Or how much bandwidth they have available. Or...well anything that would allow you to argue intelligently with a community rep.

Like I said, it would have been nice but ultimately its a fairly unnecessary luxury. If I had to choose between this and the laundry list of already planned additions, I'd pick all of those additions over this one.

[Molly_Millions]

Please read. Obviously DB queries aren't secret, but I wasn't aware that you knew what SE's DB architecture was. Or how they query the database. Or how much bandwidth they have available. Or...well anything that would allow you to argue intelligently with a community rep.

Like I said, it would have been nice but ultimately its a fairly unnecessary luxury. If I had to choose between this and the laundry list of already planned additions, I'd pick all of those additions over this one.

I do have experience working with databases that contain numbers of accounts about 10 orders of magnitude larger than the numbers on each world server. We can query that database joining about 20 to 30 tables and receive results in a matter of seconds. It's obvious from the reps response that the LS ui query uses a single table. Something doesn't sound right to me.

[MageBlack]

Its a petty thing to be this upset over. They gave their answer. Maybe pose it again later on down the road when they have fewer issues on their plate that are more important. and its not just 128, times that by 8 because you can have up to 8 LS's. Organize through a website, be creative. Gamers have been resourceful in this regard for ages, you cant tell me you are incapable of managing a simple LS without that tool. Would it be convenient? Yes. Is it the end of the game if its not there ASAP? No. Take their answer graciously and keep it in your back pocket for a later date.

I do have experience working with databases that contain numbers of accounts about 10 orders of magnitude larger than the numbers on each world server. We can query that database joining about 20 to 30 tables and receive results in a matter of seconds. It's obvious from the reps response that the LS ui query uses a single table. Something doesn't sound right to me.

Something doesn't sound right or maybe you just don't have all the information they do. This is what Irks me the most about some posters, they pretend to know exactly how SE is doing things and how "simple" it would be to fix/implement.

[Molly_Millions]

Its a petty thing to be this upset over. They gave their answer. Maybe pose it again later on down the road when they have fewer issues on their plate that are more important. and its not just 128, times that by 8 because you can have up to 8 LS's. Organize through a website, be creative. Gamers have been resourceful in this regard for ages, you cant tell me you are incapable of managing a simple LS without that tool. Would it be convenient? Yes. Is it the end of the game if its not there ASAP? No. Take their answer graciously and keep it in your back pocket for a later date.



Something doesn't sound right or maybe you just don't have all the information they do. This is what Irks me the most about some posters, they pretend to know exactly how SE is doing things and how "simple" it would be to fix/implement.

I'm not upset. It just seems crazy to me that the infrastructure can't support it.

Also, implying that I am not managing my LS via a website seems pretty ignorant. Of course I'm doing that. But it may come as a surprise to you that not everyone wants to sign up for an additional website outside of the game. Not everyone uses facebook, or the official forums either. As a matter of fact, a website is less efficient for managing membership than an in-game solution. What I'll probably end up doing is just using the 1.0 solution of creating a second LS and moving all of my active members to that one, then eventually breaking the old one thus shedding the dead weight that way. It's a pain in the ass but the only in-game solution that's viable without SE implementing my suggestion.

[Rivienne]

I do have experience working with databases that contain numbers of accounts about 10 orders of magnitude larger than the numbers on each world server. We can query that database joining about 20 to 30 tables and receive results in a matter of seconds. It's obvious from the reps response that the LS ui query uses a single table. Something doesn't sound right to me.

I agree with most of this (I have exp in large databases myself), but one thought occurs to me: what if they don't consistently store it in another accessible table either? It sounds like they are using a single table design for LS, and for FC.

I.E. they are storing the date in the FC table. Which means the only way to get this would be to join to the FC table, which not everyone has.

It could be literally as simple as, they can't do it reliably because the data is only stored in the FC table. So LS -> left join Players -> left join FC, it still might not show if the person isn't currently in a FC.

I know this should be easy, I agree. But it does sound like a potential schema change would be required and nobody wants to sign off on a schema change in a live environment. No matter how trivial. Not in my experience anyway.

[Molly_Millions]

I agree with most of this (I have exp in large databases myself), but one thought occurs to me: what if they don't consistently store it in another accessible table either? It sounds like they are using a single table design for LS, and for FC.

I.E. they are storing the date in the FC table. Which means the only way to get this would be to join to the FC table, which not everyone has.

It could be literally as simple as, they can't do it reliably because the data is only stored in the FC table. So LS -> left join Players -> left join FC, it still might not show if the person isn't currently in a FC.

I know this should be easy, I agree. But it does sound like a potential schema change would be required and nobody wants to sign off on a schema change in a live environment. No matter how trivial. Not in my experience anyway.

Or even add a new field for last login date to the table that character data is stored in.

[viion]

Only SE would find something as a "last logged in" time difficult........ They need to rehire :/

[Rowan_Moonkeeper]

I agree that this would be a nice addition. Also, linkshell messages would be appreciated, since I know several LS' that have members from multiple FC's that run events together (BC, Titan runs, etc). I'm aware FC's have a message to all members available when you log on, so having one for LS' would be nice.

In FF11 it was /lsmes. Oh but wait, that's 1. too easy & 2. referenced to 11 which is a huge no no. Pity really as 11 is apparent throughout 14, but just ignored.