Number Six

You won't be able to, it's a combination of the character's specific dbid and an old oversight somewhere with the way chat bubbles are handled and conflation of the dbid / entity id. I fixed it once before for a different situation but it appears there's another case somewhere. It's on the radar because GMs get asked about it sometimes, but super lower priority since it's purely a display glitch. It's just a case of a game mistakenly showing a chat bubble when it shouldn't (i.e. it can only happen if you're able to "hear" Max's chat in the first place, by being in the same channel for example).

It's not the name...

This is because Microsoft did something kind of dumb. The MSVC 2015/2017/2019 runtime has long been a single consolidated download that provided the needed DLLs for anything made with those compilers, and was fully compatible across all versions. At some point, they made a breaking change to the runtime. But instead of doing a new release, they quietly added it as a separate DLL, at the same time as they expanded the download to be for MSVC 2015/2017/2019/2022. They did not push out the new runtime in a Windows Update or anything, it's just a newer version of the "same" runtime that includes an extra DLL. That means that a lot of people think they have the runtime installed, but attempting to run any application compiled with Visual Studio 2022 or newer releases of Visual Studio 2019 will result in a cryptic error message about a missing VCRUNTIME140_1.dll file. It's a hard dependency, too, so the application can't even check and display a friendlier message, it just fails to run. Currently we use VS2022 for development, while the build server compiles using a specific VS2017 toolchain. We're planning on moving the 64-bit* builds to VS2019 and eventually 2022 in order to take advantage of some better code generation for improved performance. However, this makes the executables depend on that DLL. and until now the launcher had only been checking for the base level of the runtime, not the newer version that includes it. * The 32-bit build will continue to be built using 2017's v141_xp toolchain for maximum compatibility with old systems.

A Giant Monster causes the exact same amount of "lag" (whether it's server resources, client rendering resources, or whatever) as a Hellion. It's just another critter, nothing special about it except that it has more hit points and is rendered larger on the screen.

300 feet

The character "Temp Fairy" on Excelsior has PraetorianProgress=7... that's a temporal warrior.

Since they are instant 50s as soon as they're created and never change, the only reasonable option was to treat them like level 1 characters. So they always have a 30 day limit. Correct, we're not using any of that system. Getting kicked out of supergroups -- or worse the supergroup disbanding and the base getting deleted if they're the last member, losing email/ah, etc. is just far too punishing on someone coming back after a long absence. That's probably why Paragon abandoned it. They get a number appended to the end. 1 if it's available, otherwise 2, etc. If they're already at the length limit then the last letter is replaced with a digit. Basically the same rules as when you do a server transfer if the name already exists on the destination. They'll see CharacterName1, also with the red exclamation mark because the character is still inactive and subject to name release. If nobody took the name while they were away, they'll just see CharacterName with the alert icon.

True, because the system is not in enforcement mode, it uses a different icon for "would be eligible for release, but not really because we're not doing it yet" which is harder to tell the difference. Once it goes live and the red and white icon starts showing up it'll be a lot more obvious.

Not disputing that's what they called it; I suppose it's just semantics. Though FWIW it's not just the code that calls it that, the in-game messages when you try to access an offlined character also aren't consistent with the description in that announcement: "The character has been moved off the database because the account has not been logged in for 90 days or more. Choosing to enter the game will reload the character.<br><br>If you were a member of a supergroup you will need to be re-invited.<br><br>There is a chance your player name was used by another player while your character was inactive. If this happened, you will be allowed to rename your character once." "We are currently restoring your character from our long-term storage. Please wait, this may take a few minutes." "An internal error has occurred with the servers. You tried to login a character from long-term storage before restoring that character."

Hover over the icon. The yellow one is the pre-warning letting you know that it's not eligible for release yet, but it will be soon, so you can preemptively log into it before it gets there. For the 1-5 bracket, that starts showing up 7 days prior to the actual date it would be released. The "at risk" icon for being over 30 days is either red or orange depending on if the system is in enforcement mode or not. IIRC the red icon for when the name is actually eligible to be claimed also has an inverted (white) exclamation point on it, to make them easily distinguishable for people who are color blind or have difficulty discerning the yellow/red part of the spectrum.

That wiki page is incorrect. There was no such thing as "unreserved" status in the code until we added something similar (though it's calculated in realtime rather than being a flag in the database or something) as part of the Homecoming name release system. From the description it sounds like the offlined characters that were removed from the database were misinterpreted as some kind of unreserved flag, but that's not what was actually happening. AFAICT offlining was a somewhat newer feature though so I don't know how the 2005 sweep could have worked. Perhaps they had an earlier version of it that was replaced for Going Rogue.

It is a completely different system. The one on live wasn't a name release at all, it was a one-shot script they presumably* ran during downtime that looked for characters on inactive non-paying accounts (this was shortly after the F2P transition) and physically removed them from the database to cheaper storage. These "offline" characters could still be seen in the character list and attempting to log one in required the character to go through a process of being re-imported first, which is very similar to a server transfer. Freeing up the names while they were offlined was just a side effect. Our system doesn't work like that at all and is a fully automatic realtime system that renames inactive characters "just-in-time" when a new character is being created with the same name. * I say presumably because we don't actually have that script. The architecture for handling offlined players still exists in the code, but there's nothing that actually triggers moving characters to offline storage, so it must have been somehow handled outside the game server.

@Molubdos Beacons have been deployed and the fix should actually be in place now.

Whoops, that's because I derped and deployed the data patch, but forgot to deploy the new beacons. Will restart Brainstorm overnight when there's less activity and post here when it can be tested.

It should be clarified that the referenced change isn't a prohibition of the practice as a whole -- if that were the case we simply would have made those modes subject to the normal AFK timer. They're a notice that GMs reserve the right to kick someone who is AFK if it's being used it in a disruptive way.