Number Six

And in the current implementation it's not even a separate flag that can be set. There's a function that calculates the status based on character level and last active timestamp by checking them against the server's configured name policy. That function is called every time the server tries to create a character whose name already exists, and also when you retrieve the character list to send to the client along with the other information. It's not possible to "flag" a character for name release or not since it's all calculated on demand based on the policy.

After some local testing I'm about 99% sure that the future timestamp hypothesis is correct and it's ending up like 1 second ahead of the dbserver clock. Haven't managed to reproduce those circumstances occurring spontaneously but have been able to reproduce a phantom name warning with "0 days offline" showing by artificially manipulating the timestamp. Not a cause for concern as the name is actually no longer available 1-2 seconds later, but you don't see it until you exit the character select screen and come back to refresh the status. Easy enough to fix the display issue though.

If anyone reproduces this, can you try exiting back to the shard list and then immediately coming back to the character select screen? Don't log into any other characters, just hit "Back" and pick the shard again, and see if the icon is still there. I think this is a display glitch. I've triple checked the code but it doesn't make a lot of sense how this could happen, since the name release status is calculated in real-time based on the last active timestamp, which is clearly sometime today because the (also calculated) time offline is displayed as '0' on the same screen. The only thing that comes to mind is maybe a timestamp very slightly in the future by a few seconds is getting stored in the database, perhaps as the result of clock drift on one of the mapservers. That could possibly result in the math underflowing and looking like a very large number, but would resolve itself after a second or two. If that's the case, leaving and coming back should show the status correctly. I'm going to go ahead and add a check for that particular edge case. I may suspect that it's a display glitch, but haven't spent a lot of time looking into it yet and want to make absolutely sure that there isn't some other issue.

The shards themselves have no idea when the last time you logged into your account was. Excelsior only know when the last time User3897 logged into Excelsior was. If User3897 logged in to some other shard, the Excel dbserver would have no idea and would think the account is still inactive. The authentication server of course knows, and the second part of your question seems to be, well why can't the shards just ask the auth server "when did User3897 log in last?". The answer is that sure, we could build something to do that, but no channel of communication currently exists to do that so it's a net new system that would require programmer time to design, build, and test. Programmer time that is currently being spent on other projects. If we were doing it as an offline script, the shards wouldn't need to know that information. The one time Paragon did something like that, they did an offline script that just shoveled a bunch of old characters out of the database to offline storage, so they couldn't even be logged in without a process to rehydrate the record (this also makes backups a lot more complicated). If we wanted to be really obnoxious and do that, or rename everybody's old characters to GenericHero12345, that would be a way to go, but we decided early on that we wanted a lighter touch that would be less intrusive. So the game servers instead will leave everything alone and only rename inactive characters "just in time", or at the moment somebody tries to create a new character with the same name. Doing that requires that each shard know at all times which names are eligible to be reclaimed. Since it's based on character activity that's easy - it implicitly knows the last login timestamp for the character anyway. If it were based on account activity, then it would mean they'd need to know the activity status of the account tied to any arbitrary name that's being checked. Since the design goals for the name release system included dealing with active accounts that have 10 active and 900 inactive names that haven't been touched in years, there wasn't any sense building an extra system to look at account activity that doesn't meet those requirements.

Of course we have that ability, that's not a question. It's not about accounts not being tied to characters or whatever, it's about the way shard isolation works. Once you're logged in, you get handed off to a different server depending on which shard you pick, and those shards just get handed an account name (which is how they know which characters to retrieve). The shards themselves do not have access to the account database - that would be a violation of shard isolation and bad design from a security perspective. Sure, we could pass along last activity date when you log in, but that's not the problem. Doing inactivity based on account means that Everlasting would have to know the last account activity for all accounts, even ones that have only been logging into Excelsior lately. And it would need that information to be readily available whenever somebody is creating a new character in order to know if the name should be reserved or not. It's not impossible, for sure. It could be done with an on-demand lookup back to the authserver, or a local cache that gets updated whenever someone logs in on every other shard, or several different ways. But it would mean implementing a new system that doesn't currently exist, and it just isn't worth the developer time when what's already been done is perfectly adequate to address the issues. Especially true when you consider that one of the concerns is someone with an otherwise active account deliberately holding onto many names with no intent to use them -- much more of a risk when accounts are free than when there was a subscription fee. Also to clarify some confusion from upthread, when the system goes live, the timer does NOT reset. Red names immediately become eligible for release. Though I'll reiterate that they don't lose the name right away, only if somebody else creates a new character with that same name.

When did this happen? Occasionally an account shows up and spams phishing or spam links, but they typically get banned and all the messages deleted within minutes, sometimes seconds if a moderator or admin happens to be reading when it happens.

You can also use browser based discord in incognito mode with an account made on a throwaway email. The software install is absolutely not necessary -- I don't run it because I don't like it tracking what processes are running.

Technically I think it was done during the gap between live and HC, when a lot of stuff got re-tuned for a small pop private server environment. We just never un-did those changes. But if you go onto a stock I24 server you'll see them in all their glory. Not pictured on the wiki article is enhancement converters going for 10 merits each.

Not quite. More along the lines of since the costs were already reduced by a HUGE amount, as much as 400% lower in some cases, we would be very careful about adjusting them any further. As merits were designed to be a release valve to keep the market under control (i.e. you should never be paying merit prices for uncommon recipes unless something has gone very wrong) I wouldn't expect that to happen unless there were signs of significant supply problems.

There's four threads of any significance: main thread that runs the game, render thread that actually renders the 3d graphics, physics thread, and audio thread. Typically only the main thread and render thread see significant CPU time, though the physics thread can under some circumstances. There are a few others like the threads responsible for loading textures, saving options and map fog of war to disk, etc, but those never use a lot and are only background threads so that they don't impact the main loop. Unfortunately for those of us with AMD graphics cards, their OpenGL drivers often end up CPU-bound in the render thread processing the very large amount of draw calls the game makes. Nvidia drivers tend to handle it a bit better, but the current AMD GL drivers assume that games use more modern techniques to reduce draw call count since that was a big focus of game optimization in the late 2010s. COH does a little bit of that and at least tries to group up things with similar textures or shader modes, but not go to the lengths that the drivers are built to expect.

In case anyone asking for the merit costs of recipes to be lowered forgot, I'll just leave this right here. https://archive.paragonwiki.com/wiki/Merit_Rewards#Rewards_Purchases

Thanks, Satan.

🤔

One (but not the only) metric we looked at was the total influence being generated gamewide, which doesn't need to take into account the number of players because it's a global picture of all influence. When that graph showed 80% of all influence being created in a single map (Shiva Fragment), something is out of balance.

Expanding on this a little, the thing about making money from the AH is that it's a finite resource. Wealth acquired from the market is not generated out of thin air -- it's taken from other players who value convenience and getting things right now more than influence. But there's only so many "lazy players" to make money off of, so the more people who engage in marketeering, the less there is to go around. If everyone were to switch to using the AH to acquire wealth at once, suddenly nobody would be making any at all. So maybe at a particular moment in time it's the best way to make money, but that can change at any time and completely independently of anything we do since it's based entirely on player behavior.

Because the irony of making Castle be the trainer for PVP-only characters in Recluse's Victory was just too good to pass up.

Greetings! It's my pleasure today to introduce not one but TWO Community Representatives to help coordinate the base building community. Please give a big hand to @Dacy and @Easter Bunny, who will be sharing the responsibilities of the role -- only fitting since it's well known just how labor intensive base building can be, but the results are nothing short of astounding. So just what are those responsibilities? Community Reps are something we've been slowly rolling out to be a bridge between players and the Homecoming Team and facilitate community involvement. The idea is for players who are known within the community and specialized in specific areas to: Act as a liaison between players and the development team and help organize and prioritize requests for features and changes that benefit the community. Organize base related events -- possible examples include contests or tutorials. Be a resource that people can go to for information in a specific area. They'll be manning the "Base Building" global channel as a hub for questions and advice. Simple enough, right? With that out of the way, I'll let them (re-)introduce themselves and add anything they want to say.

The main difference there is that ASF and ITF HMs were designed knowing that barrier exists and could be stacked -- "cheesing" certain parts by stacking is an expected strategy, but you have to choose between stacking for temporary immunity during harder parts or keeping it rolling for better overall protection, and bringing a lot of Barrier means giving up some other Destiny abilities.

It creates a new patch every 5 seconds. That wasn't changed. Only the interaction with procs was changed so that it can only proc once every 10 seconds, and not every time a patch is dropped.

Whoever designed the trial? We didn't change the damage values -- I checked the commit log just to verify. Foot Stomp and Prism Blast always did a stupid amount of damage -- Scale 1.32 Smashing damage and Scale 3 (!) Unique1 damage. From an archvillain class enemy that's... a lot. Especially for an enemy with a +100% tohit bonus, so defense isn't going to help you much. Ambrosia gives you 75% Res to Unique1 (or 65% if you're in Master Mode). Assuming that bit is working correctly -- it looks like it should be but might be worth double checking if it seems to be doing more damage than it should. Even with 75% that's going to be something like 480-ish special damage, and another 857 smashing on top of it. That's level 40 values, I don't remember if the experimental levelless version changed that but I think it got reverted because it never quite worked right. Oh, looks like it just got the range extended and goes up to 50 now. So it would be more damage (655 special after ambrosia, 1154 smashing) but you also get to be level 50 and have more HP. The smashing part is not autohit, but it does have that built-in massive tohit buff, and god help you if one of the DE gets close enough to drop a Quartz. Admittedly it was a long long time ago but I remember even on retail that crystal titan being no pushover on the squishier ATs. The strategy was always to burn it down as fast as possible with overwhelming damage.

You sure you didn't copy the beta notes or something? The wiki page has it as well and you can check the version history to see that it always has: https://homecoming.wiki/wiki/Issue_27_Page_2 My memory is a little fuzzy because that was over a year and a half ago at this point, but I remember the first version in development applied to all pets, but there was a tech issue of some sort that caused problems (I kind of think it had something to do with pets that can't be affected like Phantom Army and some lores), and it had to be changed before release to specifically target mastermind pets instead.

The plan was to only have them appear when in large groups, but it turned out that the Halloween code spawns things weirdly and can't actually do that. There wasn't enough time to fix it for this year and we had to settle for the level 25 workaround, but it's planned for that to be changed so that in the future they won't spawn when solo trick or treating.

We've literally said multiple times that's not the case, and bent over backwards to make the Prismatic Aether system and hard-mode rewards purely cosmetic items to show off with and not affect gameplay at all. Even after the 'nerfs' to get things a bit more even-keel, AE powerleveling is still faster than it was on retail and drops sellable items instead of tickets, merit costs are an order of magnitude lower, there's perma double XP available, market prices are way, way lower than they ever were and you can purple out characters for a fraction of what it would have taken. You get Incarnates for basically free -- tier 4s even! -- for doing other content, rendering iTrials mostly obsolete. Sure, I've said before I think it should have been tier 3s at most through that system, but we have no plans to change it. Other servers joke and say that HC is "easy mode" and comprised of nothing but people who farm all the time, and while I disagree with their perception and think it's not as extreme as some seem to think, it's definitely quite a bit less grindy than when people were paying monthly subs or being pushed into the cash shop. I mean if that was really our intent and all we've managed to do in that direction is add some costume change powers, then we're really bad at it. If you still don't believe it and think we're out to destroy everything out of spite or whatever, I don't think there's anything any of us can say that will make a difference.

I have some old numbers from back in August. As of 21 days after Page 4 dropped and added them to the game, a total of 71,566 aether had been generated. 21,270 had been spent and there was 31,477 spread across a number of characters and on the market. I assume the other 18,819 was in SG base storage or email or otherwise squirreled away somewhere. At that time, 7 characters across 6 different accounts had >1200 aether on them (1200 was going to be the price point for baby mode before it was lowered to 250 and the tier 4s added). I don't have current numbers readily available, but after another 2 months and with the Halloween badges now rewarding up to 10 per character, I can only suppose there's a lot more in circulation.

I checked the I24 data and that +100% ToHit is present there as well, so don't blame us for that one! You can blame us for the autohit special damage, which IIRC was changed to be autohit so that you had to actually get Ambrosia and couldn't cheese it with stacked Barrier. Though with that +100% ToHit buff unless you've got a team with you anyway it might as well have been autohit...