Number Six

Let's be honest for a second, if we took a poll, did not release the results of that poll, and then made changes based on the supposed results of that poll that no one can verify, would it change anything at all?

Truth. Just look at how absolutely insane people got over Aim not being added to Assault Rifle, and that's something that was never even live for a second, just considered.

It has nothing to do with credentials and everything to do with attitude, passion for the project, and ability to work as a team. One of the things we look for when recruiting are driven people who either already have skills that they've developed from looking at the various resources that are out there, or who have the ability to learn from example and figure out how things work without needing a lot of handholding. All of what we know has been reverse engineered from the leaked code & data, and while we do have experienced people who can help newcomers, they have projects of their own and don't have unlimited time.

You don't need to give people an excuse. Sure there are other issues that would make testing more difficult (though not impossible, once we were in open beta we have others who can absolutely run the merging and build process if you got hit by a truck, even if they normally prefer not to). But even if there weren't, setting deadlines and sticking to them is a Very Good Thing. If there's one thing we've learned about the development team that has been assembled from the community and is continuing to grow, it's that scope creep can be a real problem, and if we want to get more than 2 major releases out a year, we need to set goals and deadlines and reasonable standards, and not get caught up in trying to make everything perfect before release.

And as for storm blast, I agree with the team's consensus that while it's early days, we're pretty happy with the performance of the set in practice so far. It's not top DPS in every situation, and in no universe should it be. It does decent damage and is fun to play. A set that's fun to play despite not being the best at absolutely everything and not slavishly used automatically by min/maxers is every build is in absolutely no way a failure in our book.

3 with public personas and thick enough skin to put up with the abuse that gets heaped on them. 6 total who specifically work on powers. That's a separate group from the 6 who work on writing, missions, and content development. The art team is another separate group, it mostly borrows talent from the other teams at the moment. It could use a few more people dedicated to it and is something we're working on. I'm not in any of those groups since I focus mostly on coding engine features and technical upgrades to the backend, with some part-time help from a couple of others. Then there's @Faultline who mostly focuses on project management and integration work since even with guidance, developers are constantly stepping on each others toes and making conflicting changes that have to be sorted out. So a lot of the thread is already based on a faulty premise.

It wouldn't simplify the code at all to remove it, it would make things more complex. You can't just copy all enhancements willy nilly to pet powers that may not be compatible. The reason for doing it that way is so that things like damage and resistance enhancements don't get their wires crossed and end up in the wrong power with unexpected results.

And always have, since the day that IOs were added to the game. Pet enhancement inheritance doesn't care one bit about IO sets and only looks at the underlying standard type (for IOs this is visible as the base color underneath the icon).

When a power hits multiple targets and also has a per-target hit fx that played a sound, N copies of the sound get queued to play at exactly the same time. Normally if you play the same sound twice, the waveforms line up exactly and it causes the amplitude of the wave to double, increasing the loudness by about 6dB. For 3 targets it triples the amplitude, so about 9.5dB louder than the original. That also very quickly leads to clipping when the waveform gets pushed beyond the sample range - that crackling noise that could sometimes be heard on a really big howling twilight cast. It was changed because it's inconsistent and surprising that while most powers produce sounds in a specific loudness range, a small number could be radically louder by multiple orders of magnitude. Not a good new player experience and there have been quite a few complaints about game volume. Now when the sound system is told to play a sound that is already queued to play at the same instant, two things happen: A small random delay (0-0.1s) is added to prevent the waveforms from stacking. Instead of a single sound getting louder it sounds more like a chorus of multiple sounds. This also helps prevent ugly sample clipping. The additional copies of the sound have their volume reduced by multiplying it by 1/(Q+1) where Q is the number of copies of the sound already queued. The second copy is 50% volume, the third copy at 33%, 25%, etc. This means that the loudness range of the power is still technically unconstrained but in practice for most powers is within the 1.5x to 3x range, depending on how many targets are hit. That keeps things from getting out of control and being way outside the normal range. This can be seen most easily with long sounds like Howling Twilight. This would also apply to the foot stomp example, but be a lot harder to tell the difference because PunchHit2 is a short sound. If you really want to destroy your eardrums when hitting 16 targets... I just added a slash command to the upcoming page 6 code to disable the new queue handling. /loudstacking 1 Should do the trick. It's a persistent setting that goes in the json file so it'll remember it across play sessions, but not one that I'm putting time into adding to the UI.

That's... exactly how it works now.

That would be a bug. An issue causing the stance timeout to erroneously cause redraw even if you're in a different animation has been fixed internally and should be in the next brainstorm patch.

You replied before I finished my edit to answer it more thoroughly, so I'll just post here: If it's working correctly, you should draw your weapon(s) once at the start of a mission, or if you are idle long enough to go into a non-combat ready state. The reason for having the reset trigger on the ready animation is simultaneously for convenience, so an active player won't have a lot of redraw to deal with, and also for immersion purposes and trying to make the behavior seem intuitive. So long as the character is in the combat stance, and have prepared their weapon once, they're considered ready to go and can switch back to it at a moment's notice, whatever the hammerspace justification is for juggling a gun and a sword and whatever else somehow. But if they visibly relax and let their guard down, then a redraw is needed to get back into combat readiness.

The intent is to have a middle ground and to not redraw once in combat:

That said, maybe I should explain a little what the goal is here. There are two opposing design principles: Performance, and Aesthetics. Both are important to COH. NOTE: For the purposes of this discussion, I'm discounting the effects of the redraw timing bug, since it's something that may be fixed at some point in the future. From a performance perspective, no-redraw is the clear winner. There's a reason so many people default to selecting the No Redraw themes, to the point where a longstanding bug such as the above went unnoticed for over a year simply because virtually no one uses the original themes. However, from an Aesthetics perspective, it's not desirable to completely eliminate weapon draw from the game. Cool factor is a very important part of COH and we don't want to see the game devolve into nothing but characters standing there and numbers appearing over their heads -- it's not a text MUD. Weapon draw is a nice looking animation, especially when combined with the new back/hip weapon options. Weapons suddenly appearing in your hand breaks immersion. The ultimate goal is to find something in the middle that while players on both extremes may not be happy with, is a compromise that the majority can live with and be reasonably satisfied. The first attempt at reconciling these two principles was the No Redraw power themes. However, there are a lot of problems with these: As @Captain Powerhouse mentioned, they are a bit of a hack and cause all sorts of sequencer (animation) bugs that are difficult to track down. They're a huge headache to maintain because of the complexity of the animation sequencers. They break the cardinal rule of power customization themes -- aesthetics should never affect performance. Players shouldn't feel pressured to sacrifice the looks and cool factor of their character for the sake of getting better numbers. Along with the above, it becomes a noob trap. If you don't go change your powers to No Redraw, you're hurting your performance, perhaps without even realizing it. That's bad game design. The existence of No Redraw themes makes it harder to add alternate animations or effects for weapon sets, since every additional option added has to be doubled to make a No Redraw version of it. In practice, it's much more than double the work due to the complexity of the sequencers. With the status quo it's unlikely that new weapon sets or alternate animations ever get added. So make no mistake, whatever we decide, No Redraw themes need to go away. They simply are more trouble than they're worth. The next shot at addressing this was some extremely clever sequencer magic that @Captain Powerhouse came up with for the Katana revamp. At first we thought this was the best of both worlds -- we wanted weapon draw to happen outside of combat, but to not interrupt the flow once you were in an attack chain. Weapons magically appearing is a lot less noticeable when you're in the middle of a bunch of attacks. However, once we started trying to apply this to other sets some clear issues arose with Redraw 2.0: It went a little too far; in practice you would almost never see a draw animation unless you stood still and tried to activate a power without a target. It solved some of the complexity issue, but not all of it, so work on weapon sets would probably still get deprioritized a bit. It involved making draw animations instantly interruptible and because the sequencers are shared, it also affected NPCs. Due to how the AI works, this meant they would never draw their weapons and would always instantly summon them. This not only affected the timing of mob alpha strikes (even with the redraw bug; it ends up shortening the timing of the second attack in a chain), but combined with the first item it effectively removed weapon draw from the game entirely. This was considered a showstopper. The implementation being tested now instead adds logic into the engine to remember recent stances -- internally weapons are stances just like energy melee fists or even the generic combat stance -- and instantly switch back to them if needed again. It has the distinct advantage that it doesn't need manual adjustment of all the weapon powers or complex changes to the fairly brittle sequencers. Even things like Arachnos claws or patron mace mastery that often get missed just work with it automatically since it's a system-wide change. It's not perfect - if you have multiple weapons you do have to draw each one separately before they are remembered (though I have some ideas that may be able to address this) - but the goal is a compromise that works without being an undue burden, even if the timing bug is eventually fixed. Note that I think it got missed in the patch notes, but if you want to brandish a weapon for RP purposes you can press Escape twice to put away all weapons and reset the state. This is planned to be added to a separate command so it can be bound separately from the hardcoded untargeting/unqueuing logic built into Escape.

It's not every attack adding 0.2 seconds. It's something that happened occasionally but not often when I tested it, and may very well be the result of network latency or some other factor interfering with the tests. It definitely won't add 20 seconds to a 100-power attack chain, even if redraw happened for every attack. From a code perspective there's no difference between the redraw case and no-redraw case as far as when the next power activation can happen.

It used to. But it's been broken on Homecoming for at least a year now (whenever the rooting changes went in). It wasn't until recently that this was measured and confirmed. That change did not take redraw into account and always allows the next power in a chain to be activated based on the non-redraw timings. There are a few technical details that can sometimes still cause a minor delay (on the order of 0.1-0.2 seconds), but in general the performance gap between redraw and no-redraw cases is effectively nil.

Rikti Cellular Regeneration and Entertainment Chamber? 🤔

The people you're arguing with don't have any ability to change the rule, so it's just wasting yours and everybody else's time. Case closed.

That's correct; "fixed internally" means that it's fixed on our development branch, but it may take some time to make it into a release build. At the very latest it'll be part of page 6. It MAY be backported as part of a bugfix update to page 5, but can't commit to any particular timeframe for that.

It's related to Build Up. Was working on some stance related stuff for page 6 and bumped into this during a debugging session. Did a deeper dive and fixed an issue internally that I'm pretty sure is responsible.

Was working on some stance related stuff for page 6 and bumped into this during a debugging session. Did a deeper dive and fixed an issue internally that I'm pretty sure is responsible.

Developers are not running the show. The HC Admin team sets the direction, and while developers in general have pretty free reign to work on what they want to, we sometimes need to steer things one way or the other and have ultimate veto power. Some things that go to alpha testing may not ever see the light of day if they don't work out or don't mesh well with the overall design. Developers do, however, use Discord internally to coordinate within the team in real time. Since they're using it anyway, it's extremely easy for them to pop over to the testers discord and ask for feedback in specific areas, or even chat about design goals. It's simultaneously both less and more moderated than the forums. Less in that it's a somewhat more private setting with only those who want to be involved in development being present. As a result there's less day-to-day moderation needed there. The developers can talk more freely there as they don't have to worry as much about their words being misinterpreted or taken out of context - and I'll out-cynic you here by saying there are definitely a number of people who will try to find a way to twist any public statement from an admin, developer, or GM into something to harm Homecoming. It's sad but it is what it is. By the same token, it's more moderated because people who come only to troll and do not provide any useful feedback (positive or negative is fine if it's constructive) are not welcome there and will be removed. I make no apologies that we provide a healthy working environment for the developers. Developers are free to post on the forums if they wish, but many feel they have to be more careful about what they say in public and don't do it as often. Take from that what you will.

The officially released stuff is posted on the official forums. If you want sneak previews of what's being worked on, well, you've gotta go looking for it. It's not something we're going to commit to spending time on maintaining a PR presence for, especially since it's often in flux and changing from day to day.

It's this. We're not thrilled about having to have the minimum age requirement, but in order to comply with US law and not incur potentially large legal expenses to deal with the intricacies of handling what might be considered personal information of children under 13 (and disastrous fines if we get it wrong), it's necessary to write that into the terms of service and enforce it as best as we're able. If we become aware of an account owned by a minor under 13, we'll have no choice but to take action on it.

Same behavior as before. The auto-renaming of inactive characters only applies when new characters are being interactively created through the character creator. Renames and transfers will not trigger it, by design. Yes, someone could work around that by creating a new character to push a name out of the way, deleting it, then renaming or transferring a different character. While that behavior isn't encouraged, if somebody really wants it badly enough to go through all that, we're not going to stop them. Wolverclone5