Number Six

Welllllllllllllll

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.

Not a typo 😉 https://homecoming.wiki/wiki/Going_Rouge_Badge

Should be fixed in the new build that just went to beta. Thanks for the report!

Usually that message shows up as the result of an improperly installed mod or because a "data" folder somehow got created in the wrong place. If you know your way around file systems, here are the things to check for: Find wherever the cityofheroes.exe you're running is. In the HC launcher it's either under bin\win64\live\ or bin\win32\live\. For the older launchers it's under hc-bin64\ or hc-bin32\ Double check that folder and make sure there aren't any subfolders at all, especially not one named "data". That confuses the install detection logic and makes it look for the data files in the wrong place. The only things that should be in there are .exe and .dll files. You could also try deleting the whole 'bin\*\live' or 'hc-bin64' + 'hc-bin32' directories and letting the launcher redownload it as there are no user-customizable files under those.

Make sure your game version says 28.1.6272.2 in the launcher and you should find things better in that version. It fixes an issue that had a chance to cause a crash on the fourth character swap and beyond. Big thanks to the people who sent in reports from the diagnostic client; the extra checks in it pinpointed the exact issue and made it easy to fix.

tl;dr: Don't use Tequila or similar. The game used to save settings in the Windows registry, which is less than ideal for several reasons. This was redone years ago as part of the new file layout project, and moved into JSON configuration files that live within the new settings\[profile] directory structure. But to not break everybody's install, the old manifest-based launchers pass the -uselegacylayout flag that causes the game to use the old layout, and continue to use the registry for settings. When the HC launcher was introduced, it provided an opportunity to migrate to the new layout; and its installer is capable of helping copy data into the new structure. Installs done by the HC launcher no longer used the legacy mode and all of their settings live entirely in the JSON files. Fast forward to today. Some newer features like the power tray changes in Page 7 don't bother to implement the extra layer that copies settings back to the registry in legacy mode. No real reason to since the vast majority of players have migrated and we officially no longer support the old launchers (though do still update the manifests to make it easier for people who haven't migrated yet). The end result is that if you're still using one of those, certain settings won't be saved because they have no code to write them to the registry, and in legacy mode there are no JSON files present to save to.

This happens ridiculously often. Sometimes I see suggestions posts for something that is finished and waiting to go to beta and I have to double check to make sure it isn't a dev being cheeky on their player account (it never is).

Short answer: yes. We have the ability to hotpatch fixes for certain types of issues by swapping in new code that new instances run on, draining (locking) the zones running on old code, and letting the old ones shut down naturally after all players leave. There are limits since it really only works for mapserver changes, and the client & server data need to stay in sync, but it's quite useful for things like critical stability & security patches to be able to roll them out without a full shutdown.

That's not a problem, that's WAI for a hotfix being rolled out. In this case one to solve an issue with a small number of players getting stuck while zoning in to specific maps. "Server maintenance" in the tram list is exactly what it says on the tin.

The default binding got changed to left mouse button in page 7 for new characters, to line up with industry standard controls. Existing characters or those switched to Classic would have kept the previous setting of MMB.