Number Six

It doesn't work like that. You may be thinking of the thing Paragon did (once) when F2P went live, but that wasn't a name release. That was a mass "offlining" of characters which completely removes them from the database and relocates the character data to text files on the shard's dbserver (not the central database). If somebody tried to play that character it has to go through a complex "onlining" process to get moved back into the database. They likely did that to reduce the database size because they had 9+ years worth of abandoned characters in it. Freeing up the name was just a side effect. We didn't want to use that for a variety of reasons, likely related to why Paragon never did it again - that system is kind of flaky and might have caused more headaches than it's worth. I'm not confident it still even works because we've made some character database changes and updating that dormant system was not a priority. The new name release system doesn't have any kind of persistent flag. The name determinations are made in real time when serving up the character list (for the warning labels) and at the last second when attempting to create a character. It only works when turned on. That also means if we change the policy tiers at some point, it would take effect immediately.

There's a fair bit of space between "Vet levels are overtuned" and "TEAM OR ELSE", but you do you. There have been a ton of other options besides iTrials that have been buffed significantly since retail. The implication of my statement was also that despite my opinion, there aren't any plans to make significant changes to incarnate progression. I'd hope that would be obvious from the way that the vet level change never made it out of beta and became a change to merit conversion instead.

There's not a rule against it and I'm not convinced there should be a rule against it, but the game's rewards structure should not be set up in a way that encourages it.

Not to mention an effectively unlimited number of free accounts.

Postponed, since that would have been about removal of veteran XP from AE, which isn't happening. There's about 5 different problems intersecting here, and if/when we decide to address the underlying problems with AE rewards relative to the rest of the game, there will be more detail about the reasoning. Removing the conversion is to address a different though tangential issue - a set of circumstances that encourages a very particular type of abuse involving a cycle of deleting and re-creating characters to take advantage of the frontloaded and limited supply of Empyreans. Removing the conversion (mostly) isolates the benefits to things that are account-bound and limits its impact on the economy, making it not worthwhile in most cases. That's likely preferable to most people than removing or significantly reducing Incarnate progression through vet levels, even though they were tuned for a much smaller population and probably shouldn't have ever gone live in the state they're in today.

I wouldn't say complete rewrite, but a very large amount of work to retrofit something like that in. I did some exploratory work early on to see how feasible it would be and there are an annoyingly large number of commands (including internal ones you don't see) that take a character name and use it as a unique identifier. Also would require a bit of redesign to integrate globals more thoroughly; currently they are second class citizens and the game doesn't even know what your global is until a few ticks after you log into a map (each map, separately), once the chatserver connection is up and running. And if chatserver happens to be down, it doesn't even know or have a way to find out.

That's a good question and one that is not covered by the current notes since we're testing the system in warn-only mode. If I were to flip the switch tomorrow and turn on enforcement, the current implementation renames inactive characters only when a new character is created with the same name. It does not kick in for renames. That's intentional as this is a feature that's designed both to make things more inviting for new players, as well as opening up options during the creative process. It's not intended as a way to snipe that one name you really want, and while it can be used that way by determined players, it takes a little more effort than just hitting the rename button.

Updated the patch notes to include the pre-warning state:

Which devs are using alt accounts? DM me details and I'll personally smack them because I have no tolerance for dev sockpuppeting in feedback threads. Note that's not the same thing as GMs posting on alt accounts. GMs' role is that of community support and moderation and they are not involved in development direction. We specifically encourage GMs to post their gameplay feedback on civilian accounts rather than their GM account to avoid it having the appearance of an official statement.

If it makes you feel any better, the Kheld/Granine toggle suspension and the 8s suppression when mezzed of offensive toggles are two completely separate things with different goals, different underlying tech, and are not at all connected by anything other than the reason they ended up sharing a feedback thread -- they both have "Toggle" in the name.

Level 21+ is 365 days which is comparable, and per internal discussions we're considering extending that to some of the lower levels as well. Of course I didn't really want to mention that yet since everything is in flux until release and may change from one build to the next, but it's definitely not set in stone. There have been some other good ideas too that seem feasible to implement, like looking at time played to avoid affecting slow levelers or roleplayers too harshly, but again it's early in the process. Even once page 4 goes live, remember that we are not activating enforcement just yet, because we want to make sure people have plenty of time to adjust.

I said the opposite, that work-around won't work anymore. TBH I thought that particular issue was fixed ages ago -- it was on the radar because people complain about the last active time being wrong -- but apparently it wasn't. It is now, in all its incarnations. That includes offline promote/demote, altinvite, failed renames, etc. Even the little-known glitch that checking a name during character creation resets the 'last active' of the first character on your roster (serverside, not what's in playerslot.txt) to 0, because we're dealing with 18 years of piled-on hacks and workarounds and the name check for some insane reason is a mapserver relay command that has to load one of your characters onto a map briefly in order to run it.

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.

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.

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.

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.

It's probably a font issue because I believe the game has full UTF-8 support. Even experimented with emoji but most look terrible. I'll have to check which font the in-game chat is using by default.

I didn't believe it either at first. The developer who worked on the multipliers for the post-50 XP in AE ran into an issue with the calculation and fixed it, and only later realized the implications with regard to the boosters, so we went and checked and discovered that sure enough they've been awarding triple XP in AE this whole time. You can verify easily by running an AE mission on live without, then with a booster and comparing the XP awarded per defeat. Then do the same on Brainstorm. Strangely, despite having been that way since the boosters were rolled out, nobody reported the issue. 🤔

It's not a fixed cap, it's dynamic. If a particular sound is already in the queue to be played -- i.e. if something else already has it set to start in the same tick, the volume is multiplied by 1/(nqueued+1). So the first instance of the sound plays at full volume, the second copy plays at half volume, the next at 1/3rd, etc. The system also adds a small random delay (<100ms) to the duplicate sounds to prevent the waveform from lining up exactly stacking the amplitude.

Besides, everyone knows that the electric guitar asset is an axe customization, not a mace...

We are planning to do some dev diaries to explore the reasoning behind some of the more controversial items. However, we wanted to give players a chance to give their initial reactions before being influenced by those. Keep an eye out.

Try copying them over to brainstorm to see what happens -- it SHOULD finally be fixed.

Even if you are at aggro cap, you'll be able to grab them now. Since they're sorted in reverse order by threat, a freshly taunted target (remaining duration of taunt effects gets a large multiplier) will be at the top of the list and will be the first one re-evaluated. So what will happen is the one you taunted will move into your 17 'uncapped' attackers and run towards you, while the one with the lowest threat gets pushed 'out' and will go find a more interesting target.

Also, account activity is not something that's possible for the system to access due to the game's distributed architecture. Account data lives on a separate system from the individual shards. It would take a much more substantial rewrite of the character list code to for it to be able to query that efficiently.

I'm a little confused because this is already the case. The yellow triangle warning indicates a name that will be up for grabs "soon", with the length of the warning being proportional to the tier that it's in. 7 day, 14 day, and 30 day warning periods for the 3 tiers. The orange triangle indicates a name that would be at risk, but isn't actually because the system isn't in enforcement mode yet. At some point in the future, when enforcement is turned on, the orange icons will become the red icons with the white exclamation mark you see in the screenshot above. That's the "do something now!" indicator. Or ignore it if it's not a name you really care about.