-
Posts
716 -
Joined
-
Last visited
-
Days Won
15
Content Type
Profiles
Forums
Events
Store
Articles
Patch Notes
Everything posted by Number Six
-
Known issues that will be corrected and don't need to be reported: Existing characters using the new key bindings if they haven't previously loaded binds or customized the keys in question. This is intended to only affect new characters. We are planning to do a database-side migration of existing characters to the Classic key profile during go-live to avoid this issue. Resizing UI windows causing the camera to move and interrupt the resize.
-
Confirmed this is an oversight. The game only saves the bindings for individual keys when they're changed, otherwise it falls through to the profile. Which means if you haven't customized the movement keys at all, the changes to the default profile would affect existing characters as well. To avoid any nasty surprises, the current plan is when Page 7 goes live, we'll run a database query to change the profile of all existing characters who are using "Default" to "Classic" instead. That way new characters will be created with the new defaults while leaving existing characters unchanged, as was intended.
-
Ahhh, personal player name. I was pretty sure we hadn't changed anything there so I checked the code all the way back to when HC started and it's always been just an on/off settings. Only thing I can think of is that you set it using a slash command or manually editing the saved settings file. It would be /option_set ShowOwnerName 6 Not sure about changing the options to allow that normally, it's a super niche use case and I can't imagine it being as generally useful as the ability to show enemy names. May be a moot point anyway as I'm considering the suggestions for a target-of-target window but that would be an I28 thing at the earliest.
-
That sounds complicated, because then you'd need to check if the target's HP is 0, track who defeated that target and check the alignment to see if it was a Hero or a Villain, handle exceptions and special cases like the target being a robot, etc etc. And what to do about Vigilantes, maybe a null the gull option for whether they kill or just incapacitate?
-
Also if you DO see someone whose behavior is over the line, please open a support ticket, preferably with screenshots or chat logs that include timestamps. The GM team can't monitor chat 24/7 and relies on player reports to know when they need to step in and calm things down. Even if that particular instance ends up being determined that it's not egregious enough for immediate action, it does build a record of repeat offenders and affects future decisions.
-
One of the frequent complaints about the volume in this game is that it's somehow louder than everything else on the system. Yet last time I threatened to reduce the top end volume because nobody sets it above 20%, a couple people complained and said that for whatever bizarre reason, they have to set it to 100% on their weird old laptop and it would be literally unplayable if the top end volume changed. So yes, it does go to 11. But if you play with the slider you'll notice that if you push it to 100% it wants to snap there and it takes extra effort to go beyond that. And at 150% it is indeed louder than all those wimpy other games you have set to a measly 100%.
-
We considered that but it would mean a second restart for everything else, which is maybe marginally better but also annoying for everyone.
-
Don't worry, we have a couple people on the infra/admin team who do enterprise SQL server tuning for their day job. We're very well aware that it will try to consume all available system memory for page cache. 😉 But the reason it's so critically important to run SQL on a dedicated host separate from dbserver and/or other game components is exactly so that it can make use of all that RAM without having to artificially limit it to a much lower cache size to accommodate a variable amount of memory demand from other processes. That and dbserver is extremely sensitive to latency. It can't handle a stall if SQL is monopolizing resources and something gets paged out or has to wait on a kernel mutex.
-
Bigger server go faster.
- 83 replies
-
- 11
-
No, on SQL it's simply having more buffer cache. It's about getting as much of the character database in-memory as possible to minimize I/O wait, which gets amplified in high load scenarios when the game's dbserver has a large amount of database transactions pending. AE missions are on a completely different VM and don't even go into SQL.
-
Global services like the auction house, chat server, etc. work by the service itself connecting to each shard, and if one of the shards are down it tries to reconnect every few seconds. But it does this synchronously, freezing the entire process, and causes lag on the other shards if they are waiting for a reply from the service. Also accountserver is not the most well written piece of software and instead tends to get really crashy if shards are down.
-
Counterpoint is that with 8 badges you can get them all in Atlas and then you have a new shiny teleporter than only goes to... Atlas. Where you already are. You still have to get at least one more badge to unlock any other destinations, which isn't a great feeling for a new player. 10 badges ensures that it actually has some use when you unlock it. Either way, feedback on that particular feature should go here:
-
Where's this 25% coming from anyway? I see no indication that it was ever supposed to be 25%.