Number Six

That's... still a thing, we didn't touch it. My main UI setup has 2 or 3 different chat windows on different parts of the screen. Just click 1, 2, 3, and/or 4 next to where it says "Tab", then click the little filled circle in the corner to undock it and move it elsewhere.

Thanks for sorting them out, I was going to pop in and ask why you're trying to use PgUp AND right-mouse-button at the same time, since those do polar opposite things. There was a subtle change in the behavior in the very specific situation where you try to use camera look and mouse look (the one that rotates your character) at the same time. Mouse look was made to take priority to ensure that running with Left+Right mouse buttons pressed works correctly and you're able to steer while running regardless of which order you pressed the buttons in. It's a small enough thing that it didn't warrant a patch note on its own, as it shouldn't affect anybody, since there's no reason to use both functions at once. But yes, the correct answer is to not press the right mouse button at all and just hold PgUp and move the mouse to rotate the camera -- not a new thing, you could always do that. 😀

Can you try on a new character using the Modern scheme? If you're getting no camera move at all that means you're probably on one who got switched to Classic and doesn't have the left click camera stuff at all, so it's not really testing if the issue with window sizing is fixed.

Yep, that all sounds right! A big part of the problem was that it turns out the profile system with the drop down didn't ever really work right to begin with. Seemed to be unfinished. I guess nobody noticed because almost no one used it. So that had to be fixed to actually work...

If you don't mind, could you re-test on RC3.5? Copied characters from live should now default to "Classic", while newly created characters get "Modern" unless you've overriden it by saving default key bindings.

These changes only apply to new characters, and overridden by customized bindings that were previously saved. The keybinds.txt file created by clicking the button to save bindings has always taken precedence over the defaults for new characters.

Click Classic. Click Save to default file. That takes 5 seconds and you never have to think about it again.

Just fixed that one internally a few minutes ago. The map slider looks like a scrollbar, but is not and is actually a completely separate control that is only used by the map. Because of course it is.

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.

That's surprising since binds are saved serverside with the character. Will look into it as that's not how it's intended to work.

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.

Not sure I understand what you mean, that's not something that was changed AFAIK. I just checked on live to make sure and that shows up when clicking through the options, right after "Show when selected"

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?

It's not going to be the default because it can make the screen quite cluttered in places, but coming Soon™ to a page 7 beta near you:

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.

You should keep an eye on RC3...

Also I'm not going to clutter the options menu with it since there's already too many esoteric things in there, but if you really want shrinking icons combined with power timers, I just added a hidden /tray_always_shrink command. It persists in your account settings so you only have to use it once.

It also disables the shrinking icons altogether, even when NOT using the recharge timer, as well as the exploding "0" animation that coincides with the sparkle if you are using the timer in Centered mode.

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%.

About 23%

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.

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.