Jump to content

Breaking News: Last Names Are Coming Back!


LiveReport
 Share

You are about to reply to a thread that has been inactive for 4135 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Thanks for the great news update, LiveReport.  Rodvik seems to be doing a grand job.  We might have to steal him to be our Prime Minister in the UK :matte-motes-big-grin:  He really does seem to listen to what we want - things that will improve Second Life for the majority. 



Link to comment
Share on other sites


Ceera Murakami wrote:

As I understand it, the barrier to name changes is that they did some really STUPID coding initially, and used the exact "first name" concatenated with "surname" as the string that all ID checks are coded to examine. The concept of UUID codes came later, and the UUID is NOT what any of their databases are keyed on or coded to use. So a change in the name, even if the UUID remains the same, is an incredible problem.

To fix it, they would have to change every instance where identity is checked, and they would also have to re-index the entire avatar databses so UUID was a primary key. (The latter may already be the case, I don't know.)

Still not an insurmountable issue. Fixed something like that at my company earlier in the year. Where we had stored a vast number of customers by some bery sensitive private numbers... and a new system put in place displayed on our website a certain item that was linked to what we'd stored them by... and had to sit there with the IT folks and have pretty much this debate... "It can't be changed" versus "can you just move a column in SQL and then alter the old column for a new entry?"

- In the end, took about 5 minutes of code work to fix, after 5 hours of back and forth on how to do it. They just ran a command line search and replace script.

 

Link to comment
Share on other sites


Pussycat Catnap wrote:


Perrie Juran wrote:

 

I know we still see names like "PleaseF*ckMe I'mYourBimbo" (whatever get's their jolly's off I guess...it is their choice), but overall I think we will see a bit more intelligence used by folks in choosing their name.

A lot of times now, the people who want an intelligent choice can't make one. Its simply not there for them. With last names, the only people making the foolish choices will be the ones who -wanted- to make that choice.
:)

 

 

This is so very true.  I would have hated ending up with Perrie35765899378300-3083830838 for my name.

And I did have a specific reason for choosing my name.

 


Kylie Jaxxon wrote:

That is an understatement, to be sure.  I have to wonder WTH the past management was thinking in regards to this and other policies.  I have absolutely no corporate experience at all, but could see the fail of this
:(

P.S.  I also think I can run my country (USA) better :matte-motes-silly:

I am accepting write in votes for President.

And I promise not to hide my Birth Certificate!

Link to comment
Share on other sites

"I would postulate that last names caused folks to ponder a little more their choice of first name."

File me under those for whom the choice of last names had nothing to do with my first name as - at that time - you had to enter in your first name before you could select a last name. Also at that time, they did not filter out the last names which had been used up. 

Link to comment
Share on other sites


Pussycat Catnap wrote:


Ceera Murakami wrote:

As I understand it, the barrier to name changes is that they did some really STUPID coding initially, and used the exact "first name" concatenated with "surname" as the string that all ID checks are coded to examine. The concept of UUID codes came later, and the UUID is NOT what any of their databases are keyed on or coded to use. So a change in the name, even if the UUID remains the same, is an incredible problem.

To fix it, they would have to change every instance where identity is checked, and they would also have to re-index the entire avatar databses so UUID was a primary key. (The latter may already be the case, I don't know.)

Still not an insurmountable issue. Fixed something like that at my company earlier in the year. Where we had stored a vast number of customers by some bery sensitive private numbers... and a new system put in place displayed on our website a certain item that was linked to what we'd stored them by... and had to sit there with the IT folks and have pretty much this debate... "It can't be changed" versus "can you just move a column in SQL and then alter the old column for a new entry?"

- In the end, took about 5 minutes of code work to fix, after 5 hours of back and forth on how to do it. They just ran a command line search and replace script.

 

Depends a lot on how well, or how poorly, the code itself is written.

I'd place it on a par with the "Year 2K bug" coding issues. For some programs, adapting them to cope with the Y2K bug was trivial. A simple search and replace to swap in a batch of code was all that was needed. But larger, more complex and less well-written code became a real rat's nest to untangle.

LL has a history of making some really bad coding choices, so I would be willing to bet that in their case, the code that would need to be changed exists in hundreds of different places, and in dozens of variations, across several inter-related modules of code. Fixing it would most likely take an eyes-on look at every line of code, by individuals familiar with exactly what does what.

The decision to base indexing off a concatenation of two very visible fields makes this one suck in terms of implementing a simple solution by updating database columns. You either have a 'pseudo-field' consisting of the concatenated value, or else on account creation a third column value is created that is the concatenation of first and last names. If they had the foresight to do the third field idea, they most likely also would have realized that a completely unique key would be a better index in the first place. So I'll bet they took the lazy way out, and calculate a pseudo-field as the key. If that is the case, they can't just repopulate the key field with the UUID. Placing the UUID in either the first or last name fields will break everything. 

That leaves them stuck with locating every place that checks for ID, and re-writing the part that says "compare against the concatenation of firstname and lastname" to change it to "compare against the UUID". And that could exist in many, many places in the code, with a wide renge of variations in how they coded it.

Link to comment
Share on other sites


Solar Legion signature:

 

If you'd like to IM me in world concerning something I have posted, do so in a polite and respectful manner.

 

I do not tolerate rude, crass or immature individuals, thus you will be muted for sending a disrespectful, rude or crass IM.

 

Your signature is one I respect.  

**Apologies for my off-topic post.  

Link to comment
Share on other sites


Ceera Murakami wrote:


Pussycat Catnap wrote:


Ceera Murakami wrote:

As I understand it, the barrier to name changes is that they did some really STUPID coding initially, and used the exact "first name" concatenated with "surname" as the string that all ID checks are coded to examine. The concept of UUID codes came later, and the UUID is NOT what any of their databases are keyed on or coded to use. So a change in the name, even if the UUID remains the same, is an incredible problem.

To fix it, they would have to change every instance where identity is checked, and they would also have to re-index the entire avatar databses so UUID was a primary key. (The latter may already be the case, I don't know.)

Still not an insurmountable issue. Fixed something like that at my company earlier in the year. Where we had stored a vast number of customers by some bery sensitive private numbers... and a new system put in place displayed on our website a certain item that was linked to what we'd stored them by... and had to sit there with the IT folks and have pretty much this debate... "It can't be changed" versus "can you just move a column in SQL and then alter the old column for a new entry?"

- In the end, took about 5 minutes of code work to fix, after 5 hours of back and forth on how to do it. They just ran a command line search and replace script.

 

Depends a lot on how well, or how poorly, the code itself is written.

I'd place it on a par with the "Year 2K bug" coding issues. For some programs, adapting them to cope with the Y2K bug was trivial. A simple search and replace to swap in a batch of code was all that was needed. But larger, more complex and less well-written code became a real rat's nest to untangle.

LL has a history of making some really bad coding choices, so I would be willing to bet that in their case, the code that would need to be changed exists in hundreds of different places, and in dozens of variations, across several inter-related modules of code. Fixing it would most likely take an eyes-on look at every line of code, by individuals familiar with exactly what does what.

The decision to base indexing off a concatenation of two very visible fields makes this one suck in terms of implementing a simple solution by updating database columns. You either have a 'pseudo-field' consisting of the concatenated value, or else on account creation a third column value is created that is the concatenation of first and last names. If they had the foresight to do the third field idea, they most likely also would have realized that a completely unique key would be a better index in the first place. So I'll bet they took the lazy way out, and calculate a pseudo-field as the key. If that is the case, they can't just repopulate the key field with the UUID. Placing the UUID in either the first or last name fields will break everything. 

That leaves them stuck with locating every place that checks for ID, and re-writing the part that says "compare against the concatenation of firstname and lastname" to change it to "compare against the UUID". And that could exist in many, many places in the code, with a wide renge of variations in how they coded it.

Admittedly, I am a complete novice when it comes to such things, but wouldn't they already know where all this is, since it had to be changed previously when they instigated one-word names, etc?

ETA: LOL, nm...I am really confused and possibly further explanation will confuse me more :smileysurprised:

 

Link to comment
Share on other sites


Kylie Jaxxon wrote:


Admittedly, I am a complete novice when it comes to such things, but wouldn't they already know where all this is, since it had to be changed previously when they instigated one-word names, etc?

ETA: LOL, nm...I am really confused and possibly further explanation will confuse me more :smileysurprised:

 

No, because their implementation of single names was merely by changing the sign-up process so any new account created stuffed "Resident" into the surname field. They changed the viewer only enough to deal with displaying the names and display names, and accepting input for login in a single field, by parsing a dot or space as a break between firstname and surname, and if no dot or space was there, they only check against the firstname and assume "Resident" as the surname. But the majority of the code relating to dealing with inventory ownership and assets could have been left untouched. 

Link to comment
Share on other sites


Pussycat Catnap wrote:


Mayalily wrote:

Are they going to create a new viewer for this as logically, I'd suspect so.  A viewer with two spaces on the bottom to add in a last name?  I ask because I am on a early version of V3 that has the IM's at the bottom.  If this add a last name viewer has IM's on the top right (which I cannot see without craning and hurting my neck), I won't be able to get a last name then.  And also, FS said it was DONE, so is FS going to add a space to add a last name or wha?

There's no reason IMs need to be in one corner or another. V3 lets you drag em all around - because again, nothing really requires something like to be in a certain spot other than what would be bad design.

 _________________________________________________________________________________________________

Oh, thank you for letting me know that!  That is vital information I didn't know about.  I was thinking that they may have stuck the IM's at the top now because internet TV is here.  I may have internet TV some time next year.  I also know of one sim now that I often go to that just announced last week they are on internet TV.  See, I was thinking with internet TV, we get to stand up sometimes and watch and move, and having IM's at the top of the screen would be easier to read.  I'm so glad to know we can move the IM's around, and that is probably for people who will be going from internet TV, to laptop, to pc, etc.  Good suitability factor to be able to move IM's around with internet TV soon to become all the rage. 

 

Link to comment
Share on other sites


Ian Undercroft wrote:

That presupposes that it will be possible to change an existing username and, in particular, to add a second name to a single name account.

Its all just variables in databases and objects in code.

I've seen some amazingly messed up bad code before, and seen it get fixed when somebody over-rode the complaints in IT and forced them to actually spec out and analyze the problem in detail, find the bug or defect, and wack it.

Code can always be re-written, and databases are just rows and colums of content - that can be moved around and resorted or even moved from one kind of database to another.

If you get a real professional programmer who actually believes its not possible, that's someone to replace. Not saying every IT job is easy by any stretch - but the nature of this one would be hard to imagine to be too hard.

 

It reminds of a recent move by the city governments here in the San Francisco area - they came out with a 5-year plan to develop an IT solution allowing GPS locating of buses in real time. A group of coders responded by making an app over the weekend and putting it up for sale that met the needs of the 5-year plan, without even having access to the buses to put in any hardware.

- Sometimes folks will way overcomplicate...

Telling a getter / setter for a variable to return one thing instead of another - that's something you learn on day one of any programming class... and the logic for it is nearly universal across languages.

 

Link to comment
Share on other sites

i think thats a great idea. I used to have a "real" last name on my old account, which i cancelled before i made this one. And i miss the last names.

May i make a suggestion:

People with the last name "Resident" should be able to pick a real last name. Because i already know a few people with names like "JohnDoeSmith Resident" (Display name is "JohnDoe Smith") which would give them a chance to turn it into "JohnDoe Smith" without the Resident thing.

And when people join SL they should still have the option between picking a Last name or "no last name". With the option to pick a last name at a later time...

Does that sound good?

 

Link to comment
Share on other sites

This is great news indeed, if they have an open last name field and not block any previous last name from being used i can finally create an alt with the last name Palmer. besides, the names i have been seeing lately have been getting ridiculous.

I also hope that they allow a name change card like they offer in some of the mmorpgs, so that it cant be abused, it should require payment info on file, a small payment of at least 9.95$ and can only be done once per year.

and while Display Names was an alternative, most people turned all display names off and the rest of us displayed both user name and display name and only a few in the RP community had only Display Names displayed for the sake of RP immersion.

the good thing is. implementing this shouldn't take long seeing as the coding is still there in the system so i guess there wont be a need for restarts or system upgrades.

this could be a scene out of Futurama.

Hubert J. Farnsworth: Great NEWS Everyone!.......... due to a computer error, you all can have last names once again 

Dr. Zoidberg: HORRAY!!!!!

Leela: finally!.. frankly, i was getting tired of everybody calling me by my user name OneEyedLeela Resident.

Amy: Right, do you know there were so many amy's registered that i had to add a bunch of letters and numbers too my name and i forgot how i spelled it so i could not get any of my money from the bank and stuff and i could not log into my FacePage or SecondRealLife.

Fry: i'm just glad i will have my name back because i was getting tired of my username DumbFryIsAnIdiot Resident, what about you Bender

Bender: thats not my name dumbfry, i prefer my username, BiteMyShinyMetalButt.

Link to comment
Share on other sites

  • 4 weeks later...


Pussycat Catnap wrote:

Liisa Runo wrote:

Here is one example of stuff what will be broken when someone changes name:
changed(integer change){ if (change & CHANGED_OWNER){   ownername = llKey2Name(llGetOwner()); }}

Personally im not too worried about my stuff, i love to do everything my self, so i can adapt to what ever change. And i dont really mind if i need to re-buy some stuff that maybe go broken.

Not trying to argue here, but i have heard that our database have UUID, first name as a string, and integer for the last name. Servers, viewers and databases can be changed to do almost anything. But user created content is something that LL cannot change.

Just have the function return a pointer to an object, the owner, referenced in the database by UUID - and pull out the name / display name variable of that object.

 We have no need to know what goes on inside the function, merely what variables to put in and what string it returns. They can use any means desired to alter what the string is composed of.

Fixing the above would be so trivial that I could probably do it, without knowing the coding language in question - its just a logic issue (I've fixed issues like this many times at various jobs in languages I didn't know... when you work in web production, you often find yourself doing half of IT's job and half of Marketing's job in addition to whatever's on your own job description). I'd look at the code, and paste in something with a similar structure but based on a different internal to the object variable.

 

Changing what the function returns will not affect to this type of scipt. The name got stored to the ownername variable 3 years ago when the customer bought the product from the creator and CHANGED_OWNER got triggered. This script will be broken if LL make us able to change our names.

Link to comment
Share on other sites

  • 2 weeks later...
  • 3 weeks later...
You are about to reply to a thread that has been inactive for 4135 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...