issue 27 Focused Feedback: Name Release Policy - Phase 1: Warning Mode

[UltraAlt]

On 7/15/2022 at 1:43 PM, lemming said:

I think this is something that's *cough* probably done now with alt accounts until the person wants to use them....   Not a real example or anything...

 

Oh, really. Sounds more like "Move along, Citizen! Nothing to see here!"

[Excraft]

55 minutes ago, Andreah said:

That doesn't solve name squatting, it just solves account abandonment.

 

How do you know that a name you might want isn't on an abandoned account?  Something doesn't smell right there.  Another player actively playing who has a name you want can be contacted and you can negotiate with them.  If they don't want to release it, tough luck on you.  Pick another name. 

 

55 minutes ago, Andreah said:

I could be in favor of more aggressive name release schedules, criteria, and features; such as:

 

I'd be in favor of me being able to take whatever character names you have whenever you aren't logged in and playing them.  You're not using them at the time so I should be able to use the name.  I find that entirely reasonable. 

 

55 minutes ago, Andreah said:

The folks who're most upset by the new system have been sitting on vastly larger shares of the namespace than typical players, don't actually care enough about their character names enough to spend a single minute, or less than a minute per month on them, or frankly, don't hardly play the game anyway.

 

So what exactly is a "typical player"?  And as far as not caring, this isn't what roleplayers posting here have said.  They have legit reasons for wanting to keep their characters at a specific level.  But I get it, it's ok to be inconvenienced so long as it isn't you. 

Edited July 18, 2022 by Excraft

[arcane]

I could do without this change but logging into all my NON-50 alts once in a blue moon for a second won’t kill me. I think there’s 2 of them.

 

I do not think it should be expanded to 50’s.

Edited July 18, 2022 by arcane

[ShardWarrior]

1 hour ago, Andreah said:

That doesn't solve name squatting, it just solves account abandonment.

 

Yes, it does provide a solution.  Your solution is to contact the player who has a name you are interested in and negotiate with them for releasing it.  If they do not want to release the name to you, they are absolutely under no obligation to do so.  If an account is abandoned, there is no recourse for another player to contact them, so those can and should be freed up. 

 

1 hour ago, Andreah said:

Again, I'm having a hard time feeling sympathy for the level of entitlement I perceive.

 

I am having a hard time feeling any sympathy toward the entitlement people have in thinking they have more right to something than someone else.  There are any number of valid reasons someone may have a low level character name reserved.  None of them make you more entitled. 

Edited July 18, 2022 by ShardWarrior

[Jacke]

As much as it would add work to the already overworked GMs, I think taking over a name should require a ticket submission.  This allows a more flexible policy.  It would also prevent someone doing a mass takeover of names.

[Doc_Scorpion]

1 hour ago, Andreah said:

The folks who're most upset by the new system have been sitting on vastly larger shares of the namespace than typical players, don't actually care enough about their character names enough to spend a single minute, or less than a minute per month on them, or frankly, don't hardly play the game anyway.

Oh?  Since you have access to the player database and can cross reference from forum handles - tell me how many level 1 characters I'm squatting on.  (I won't hold my breath because you don't and you can't.)

 

1 hour ago, Andreah said:

Again, I'm having a hard time feeling sympathy for the level of entitlement I perceive.

Interesting how the people against burdening active players are "entitled", but those who feel they have a dev-given right to the names they want...  aren't.

[Bionic_Flea]

15 minutes ago, Jacke said:

As much as it would add work to the already overworked GMs, I think taking over a name should require a ticket submission.  This allows a more flexible policy.  It would also prevent someone doing a mass takeover of names.

 

I have no problem with an automated system to free up names that have been and may remain unused for a long time.  However, I am concerned that a purely automated system with no governor or regulator may lead to offensive name claiming (see my post above) or a new name squatter that doesn't mind logging in periodically. 

 

I think there should be a limit to how many names an account can claim in a certain period of time.  What I don't know is what amount is reasonable.  One name claim per month per account, perhaps?

[Troo]

@Jacke and @Bionic_Flea may have a reasonable concern that hadn't occurred to myself.

[El D]

Returning to this thread, I still think the most user-friendly implementation of this policy - given Homecoming's deliberately massive allowance of character slots across multiple servers and allowance of multiple accounts - is for a check-in option at the Character Select screen.

 

It'd remove any semblance of 'time imposition' for active players while still immediately allowing for abandoned accounts to have their camped names released, and perhaps more importantly unambiguously lay the responsibility at players' feet to maintain the names they want to keep. If the name release timer is made minimally impactful to manage, any name lost at that point is solely the responsibility of the player - there's no 'The devs made it too obnoxious to deal with!' when it's made to function as easily as possible with Homecoming's 1,000 character slots per server. This would mean that some active accounts would end up keeping a higher number of names on low-level alts, but they're also still active accounts. If another player really wants one of those names, they can send a global tell and make a request.

 

I wouldn't object to audits of problematic accounts, either. This easier option could, theoretically, allow for accounts to simply fill up every possible server slot with Level 1 characters and, so long as they logged in regularly and went through the check-in, still camp all those names. Abusive name camping being made explicitly against HC's account policy - effectively treating this as a deliberate misuse of the account system - could be considered a bannable offense. Or at the very least, grounds for having those characters immediately generic'd.

Edited July 18, 2022 by El D

[Bionic_Flea]

POSSIBLE BUG?

 

I'm not sure what is going on here.  I have one character on Brainstorm with a ! for being offline for 236 days.  OK that makes sense, but I also have one with 208 days and two with over 400 days that do NOT give the notification icon.  What's up with that?

 

[Andreah]

If anyone thinks that more than half the names aren't being held by fewer than half the accounts, that's patently absurd.

 

Moreso, I expect and consider it almost without question that the vast majority of the names in the database are held by a small fraction of the total accounts, and worse, many of these accounts with many names are held by the same actual player. I'll cite the Pareto rule. And I would love to see the devs produce statistics of how many accounts hold how many names.

 

I recall at HC launch a number of people mentioning they were systematically going through names they could think of to deliberately squat on them. 

 

Again, no sympathy.  Log those characters in once a month or risk losing their names.

[ShardWarrior]

12 minutes ago, Bionic_Flea said:

POSSIBLE BUG?

 

I always get a chuckle when @Bionic_Fleaposts a bug report 🤣

Edited July 18, 2022 by ShardWarrior

[Number Six]

2 hours ago, ShardWarrior said:

If you can query the character database, regardless of size, for an account ID then there is a link between characters on a shard and account.  If you can do that, you can update all characters on all shards as active upon login.

 

Sort of, though there are a couple of issues with it.

 

1. dbserver is heavily multithreaded (it used to be hardcoded for 64 threads; I rewrote it to be configurable and we are currently running 96 threads on Excel in order to increase the maximum concurrent players it can handle) and has strict ordering requirements for updating character records to guarantee referential integrity while taking advantage of concurrency for performance. In order to solve the issue of long waits at the "Retrieving Character List" screen on login which were caused by waits on the SQL queue, the character list queries were moved to a separate queue with its own thread pool (I think 12 or 16 dedicated threads currently) so they get priority. However, use of that alternate queue comes with the requirement that the queries be *read-only* -- changing character records from the wrong pool would break that guarantee and throw referential integrity out the window. So if updates were done during login, the normal queue would have to be used; which means submitting a separate query for each character (since the threads are assigned with a hashed bucket system based on container ID to load balance requests and make sure the same thread handles updates for the same character in-order). tl;dr bulk updating characters at login could make the login process take significantly longer during peak times when the SQL queue is long.

It's also important to remember that dbserver does not issue raw SQL to the database. Everything has to run through the container system, which is kind of Cryptic's home-grown object-relational bridge, think like Hibernate or something but custom crafted for COH. The container system handles in-memory caching and locking -- bypassing it and changing data directly is a bad idea and would result in an inconsistent view. This is the precise reason that we have strict rules about touching the underlying databases while the shards are running. Even character transfers and beta copies get run through dbserver's container layer. That means no bulk UPDATEs that cross characters.

 

2. Updating them all on login would make all characters on your list always show as Last Played: 0 days ago. There is not a separate field for the name release; the last active time is used as-is. That doesn't seem desirable.

 

3. With enough work and redesign of the character database, those probably could be worked around. However so far we feel the system works well enough as-is to not want to invest that much more time in it. The most likely changes to happen at this point are tweaks to the various policy tiers.

[AboveTheChemist]

11 minutes ago, Bionic_Flea said:

What's up with that?

 

The one with the warning flag is level 1 and subject to the name change rules. The rest all appear to be level 50 and exempt from the rules.

[UltraAlt]

15 minutes ago, Jacke said:

As much as it would add work to the already overworked GMs, I think taking over a name should require a ticket submission.  This allows a more flexible policy.  It would also prevent someone doing a mass takeover of names.

 

This would allow "people in the know" to get names but keep those that might randomly get a name from getting it.

Seems like less flexibility to me.

 

With the system the way that it is, no one knows when a name might enter the state where someone could get it. It is unlikely that any group of names would become available all at the same time.

 

I'm seriously thinking it would be weird for people to take time every day to check even 10 names everyday to see if they can possibly "capture" one of them. 

I mean this isn't Pokemon, and no one is likely to capture all the names that they want.

 

[ .... going off on a tangent here that isn't related to the person that I'm replying to, but I think it's relevant to character names in general ....]

 

I understand that some people want "a certain name" or several names that they feel that they "own" or that are somehow inherently theirs. 

That is really what freeing up names really comes from.

 

I never really bothered with using my favorite name(s) on every server on live (in order to keep other players from using it).  It eventually did happen with one character name (the name of the first character I created when logged in that week before Issue 2 dropped) before the Sunset, but it was a unique enough name that no one had picked it.

 

I've run into someone using one of my names from live here. (Well, I didn't actually run into them, the name was simply taken when I tried to pick it) I think the first revision of the name that I tried was successful. How long has it been now? A couple of years at this point on Homecoming? I finally went to another server and tried that original name that someone else had picked on the other server and I got it on Everlasting just a month or so ago. 

 

I honestly don't even think that I've tried more than 5 variations of any character name before getting a successful character name.

Only one of the character names that I had before the Sunset that I have tried so far was taken and that was in the example above.

 

It isn't to be mean, but you aren't really being that creative if you are having that hard of a time getting a name for a character. 

I would say that you are either picking a name that already exists somewhere in fiction or something easily triggered in the collective unconscious.

 

I mean sometimes it just takes the addition of an adjective....

 

 

 

.... is so much a part of the comic book culture that gaining adjectives for your character's name as you level is built into THE CITY .... if you want to use them.

 

I just find it ironic that people having issues naming characters in this game that is based on and allows so much creativity.

 

Oh, I'm sorry, I forgot .... it isn't about being creative, it about some players wanting to have "their name" .... so much so that they want to be able to take it away from another player that decided to try to pick it before they did.

 

 I mean, isn't that what all this is really about?

[Bionic_Flea]

5 minutes ago, AboveTheChemist said:

 

The one with the warning flag is level 1 and subject to the name change rules. The rest all appear to be level 50 and exempt from the rules.

 

Ah! Thanks, that makes sense.  Meteoric was actually Auto-boosted to 50 with the freebies menu, but not trained.  And he sits at 50 on the live server.  So my brain just read right past that.

 

 

[Number Six]

1 minute ago, Bionic_Flea said:

Ah! Thanks, that makes sense.  Meteoric was actually Auto-boosted to 50 with the freebies menu, but not trained.  And he sits at 50 on the live server.  So my brain just read right past that.

 

I guess that's an implementation detail that might not be obvious but should be mentioned, the trained level of the character is what's important, since that's what is stored in the character record and what is easily accessible by the dbserver.

 

Determining earned-but-not-trained levels means comparing character XP to the level schedule, and dbserver doesn't load the game data or even require that it's present on the system, so it doesn't have a way to know that.

[Stoked]

Regarding the process to update accounts on login ...

You don't have to execute updates on login. Just leverage the stored last login time and simply run a job 1x per day or week or whatever to execute the updates at off-peak hours.

 

In all my years as a DBA and programmer, I've never seen such a ridiculous word salad used to describe why multi-threading is getting in the way of executing a SQL query. As if there's only one way and one time to perform those updates. Give me a break.

[Jacke]

5 minutes ago, Stoked said:

Regarding the process to update accounts on login ...

You don't have to execute updates on login. Just leverage the stored last login time and simply run a job 1x per day or week or whatever to execute the updates at off-peak hours.

 

In all my years as a DBA and programmer, I've never seen such a ridiculous word salad used to describe why multi-threading is getting in the way of executing a SQL query. As if there's only one way and one time to perform those updates. Give me a break.

 

In all my years as a Systems and Network Admin, I've never glibly assumed on taking on an existing system or network that I can just do any change I want.  I've got to know the whole thing cold and be certain my change will have the effects I want without blowback.  I'd take on that same stance with a MMO with many databases.  In fact, my experiences with databases shows that things are even more fateful there.  Be pure. Be vigilant. Behave.

[ShardWarrior]

22 minutes ago, Number Six said:

 

Sort of, though there are a couple of issues with it.

 

1. dbserver is heavily multithreaded (it used to be hardcoded for 64 threads; I rewrote it to be configurable and we are currently running 96 threads on Excel in order to increase the maximum concurrent players it can handle) and has strict ordering requirements for updating character records to guarantee referential integrity while taking advantage of concurrency for performance. In order to solve the issue of long waits at the "Retrieving Character List" screen on login which were caused by waits on the SQL queue, the character list queries were moved to a separate queue with its own thread pool (I think 12 or 16 dedicated threads currently) so they get priority. However, use of that alternate queue comes with the requirement that the queries be *read-only* -- changing character records from the wrong pool would break that guarantee and throw referential integrity out the window. So if updates were done during login, the normal queue would have to be used; which means submitting a separate query for each character (since the threads are assigned with a hashed bucket system based on container ID to load balance requests and make sure the same thread handles updates for the same character in-order). tl;dr bulk updating characters at login could make the login process take significantly longer during peak times when the SQL queue is long.

It's also important to remember that dbserver does not issue raw SQL to the database. Everything has to run through the container system, which is kind of Cryptic's home-grown object-relational bridge, think like Hibernate or something but custom crafted for COH. The container system handles in-memory caching and locking -- bypassing it and changing data directly is a bad idea and would result in an inconsistent view. This is the precise reason that we have strict rules about touching the underlying databases while the shards are running. Even character transfers and beta copies get run through dbserver's container layer. That means no bulk UPDATEs that cross characters.

 

2. Updating them all on login would make all characters on your list always show as Last Played: 0 days ago. There is not a separate field for the name release; the last active time is used as-is. That doesn't seem desirable.

 

3. With enough work and redesign of the character database, those probably could be worked around. However so far we feel the system works well enough as-is to not want to invest that much more time in it. The most likely changes to happen at this point are tweaks to the various policy tiers.

 

Thank you much for the technical response.  Some follow up questions -

1. Why not run an update routine as part of regular maintenance or even run on off peak hours?
2. Is having people repeatedly logging in and out for each character they want to keep less stressful on the system?  If this problem is as enormous as some are making it out to be and from your explanation here, that certainly seems likely.
3. Not sure I understand why having all of the characters showing the same last login is undesirable?  I am sure others find this useful, just saying I personally do not.
4. Seems odd to me that adding a single column for "active account" to the character database is a huge effort.  Is this more effort due to having to rework the character select code to access it versus database architecture issue?

 

[Bionic_Flea]

While I would like for there to be an easier way for active accounts to keep their names, I would NOT like a system that automatically set all my characters to zero days online whenever I logged in to any character or whenever the query was run.

 

I use the time logged off as an indicator of when certain characters deserve some game time.

[Troo]

35 minutes ago, Stoked said:

Regarding the process to update accounts on login ...

You don't have to execute updates on login. Just leverage the stored last login time and simply run a job 1x per day or week or whatever to execute the updates at off-peak hours.

 

In all my years as a DBA and programmer, I've never seen such a ridiculous word salad used to describe why multi-threading is getting in the way of executing a SQL query. As if there's only one way and one time to perform those updates. Give me a break.

 

I'm gonna cite dunning-kruger here... oh, never mind you're gonna get deleted anyway.

 

Thanks for the chuckle.

 

 

Edited July 18, 2022 by Troo

[Doc_Scorpion]

8 minutes ago, Bionic_Flea said:

While I would like for there to be an easier way for active accounts to keep their names, I would NOT like a system that automatically set all my characters to zero days online whenever I logged in to any character or whenever the query was run.

 

I use the time logged off as an indicator of when certain characters deserve some game time.

Agreed!  I also use "last logged in" to help me remember if a particular character has run the WST or not.

[Number Six]

16 minutes ago, ShardWarrior said:

 

1. Why not run an update routine as part of regular maintenance or even run on off peak hours?
2. Is having people repeatedly logging in and out for each character they want to keep less stressful on the system?  If this problem is as enormous as some are making it out to be and from your explanation here, that certainly seems likely.
3. Not sure I understand why having all of the characters showing the same last login is undesirable?  I am sure others find this useful, just saying I personally do not.
4. Seems odd to me that adding a single column for "active account" to the character database is a huge effort.  Is this more effort due to having to rework the character select code to access it versus database architecture issue?

 

 

1. It could be done during maintenance, though we currently don't have any manual SQL tasks to be run doing maintenance - I wouldn't want to schedule it because maintenance time is not always consistent due to availability. It would mean additional burden on server ops to run the scripts on each database. I'm not sure how viable I'd consider this, since that would mean that it only updates once a week and names could be vulnerable in the interim.

2. Probably. It's naturally rate limited since most of the time it takes to log onto a character is the client loading the zone. People already do this for anniversary badges, etc.

3. We get support tickets all the time from people freaking out because a single character has an unexpectedly recent "Last Active" time, usually from an offline supergroup promote/demote (this is fixed in page 4). People do use it and care about it. So we'd have to add a whole separate column for last-active-but-not-really-just-for-name-release purposes, which would start out unpopulated and require more manual steps on page release if we wanted it to be useful.

4. Adding it to each character would be the wrong approach anyway, it should live in shardaccount, though that would probably confuse people since it's not global across shards. dbserver would need to grow something analogous to the namecache for shard accounts to make that data available on-demand without having to keep every account loaded in memory at all times.

[Number Six]

39 minutes ago, Stoked said:

In all my years as a DBA and programmer, I've never seen such a ridiculous word salad used to describe why multi-threading is getting in the way of executing a SQL query. As if there's only one way and one time to perform those updates. Give me a break.

 

Feel free to code something up and submit it, be sure to stress test against the specific software stack and the load it generates with a thousand concurrent players.

 

I just spent two weeks adding a ton of instrumentation and profiling hooks to diagnose why Excelsior was coming to a screeching halt every other night while the SQL server was only showing moderate load and no obvious bottleneck, but some queries were taking multiple seconds to come back. So you'll have to forgive me if I have very little patience with people who think they can monkey around with the server process at the heart of everything, that experiences the most load and is the most critical to be responsive because it also handles all cross-map comms traffic, and have no impact.