Number Six

Rereading your post, the only thing that looks like possibly a bug is Critical Mass and Fallen from Grace sometimes spawning as EBs. The villaindefs for those only exist as bosses and don't define an EB rank, it's weird that they're somehow getting their rank upgraded.

Not a bug. Bank missions have always spawned a named boss, much like a lot of storyarc missions do. This is normally a boss rank enemy. Different bank missions have a different pool of bosses to choose from. The high level missions (looks like Founders and PI) also include a chance for a signature villain to spawn, if and only if there are 4-8 players on the team. Only if one of the signature villains is chosen does it spawn as an EB or AV, depending on notoriety settings, and only then because that's the only rank that exists for those villains. The spawndef doesn't specify a rank so it would normally try Minion, Lt, Boss in a random order. Couldn't tell you exactly what the chance is supposed to be at a glance. Safeguards are a bit of a house of cards when it comes to the way the mission is built, and there's multiple layers of randomized variables that are chained together. I do remember it's always been a fairly low chance as far as I can remember, since they were added way back in issue 8. It may be worth checking the page 7 beta to see if the rate is any better there. It wasn't explicitly looked at, but one of the underlying changes in page 7 was cleaning up some legacy code, and that included switching out the old rule-30 RNG that was still used a few places for a higher quality random number generator.

There's a teeny tiny little X in the bar on the top (or the bottom, depending on where it is, which can make things confusing) of the window. That will close it without undoing the changes.

The red dots have nothing to do with the cap. The red dots are hardcoded to appear once there are more than 1,100 players concurrent on the shard. That applies regardless of what the cap or queue threshold is set to. As far as I can tell that's always been the case and has never changed. Yellow dots appear above 250.

Slight update, I checked to verify and we are actually at just over 64,000 active accounts over the last 30 days. 36,000 active in the last week, which is also not an atypical ratio for us. Highest concurrent users across all shards since the announcements has peaked at about 4,950 a weekend ago, highest concurrency on weeknights running around 4,100 to 4,200. Just for funsies, let's assume player habits haven't changed in the last 20 years, which is probably a bad assumption. Let's also assume that of 125,000 paying subscribers, every single one of them logs in at least once a month. Also a bad assumption, I know plenty of people who left their sub active even when not playing for a while, especially if they prepaid for the discount, but anyway this is for entertainment value only. That means I would expect a peak concurrency of... 9,660. Spread across 13 shards. That's fairly in line with both the recommended settings for player cap in the config files as well as the behavior that starts to exhibit once you go past 1,500 concurrent, and become debilitating once you're past 2,000.

Also in 2008 it's quite likely that the difference in hardware capabilities was compensated by having much smaller character records at the time (less database load, much less complex queries hitting it), as well as a significant difference in playstyle -- more people street sweeping open zones, less rapid fire task forces, no league content, etc.

125,000 subscribers does not equate to 125,000 concurrent by any stretch. People play at different times of the day and do not necessarily log in every day even. For example, right now we're hitting about 4,200 CCUs on weeknights, but our MAU is in the 40,000-50,000 range. That's not an atypical ratio in the MMORPG industry.

Uh, what? Not sure where that came from but it's incorrect. Best guess based on supporting evidence is that the cap was set to 2,200 for most servers on live... though in the 2011-2012 time frame they never got close to that, except for the last month of course. With the limitations due to the way the code works I'm not sure how stable they would have actually been in practice with 2,200 concurrent. Those limitations were not unknown to them as there are even comments pointing out areas likely to become a performance problem, but they didn't have a clear solution to fix them. Their hardware was probably less consolidated than ours is, so it's possible they could have sustained that. Based on our experience I can't see it ever being stable for long with more than 2,000 or so on a single shard. We lowered the cap on Excelsior to 1,500 prior to the license announcement as a precautionary measure, as the shard had already been having hiccups almost nightly whenever the big raids disbanded.

@Cipher had to clean up the calendars, as someone, or possibly multiple someones, had created quite the number of perpetually repeating events and it was causing significant performance problems for the forums. I'm not sure what the current plan is for those, if there is one.

I mean... I think it works, tbh.

It's not something we've changed, it's still AL0. It's used internally by the buff UI when you cancel via right-click so removing it would be fairly involved. It does require you to know your entity ID however, which is not visible anywhere and changes every time you zone... I don't see how it could possibly have ever been useful for players to call it directly.

Hotfix for an issue that a few players are having with the game crashing immediately upon launch due to incompatibility with some third party software.

Check the "Windows" tab if you're already in-game.

It really is a great crew, there are times I wish I had people with that level of capability and professionalism working with my at my real job. Not that the people I work with are bad by any stretch, but it's unusual to have so many folks who are truly next level working together. And so many people who are very very good at what they do but have no problem working as a team, no issues with egos or butting heads, it's just been amazing. Going to shout out @Telephone for now for all of the awesome work they've done building and documenting our infrastructure (internal documentation is something a lot of people overlook but is critically important!). From the servers to the automated deployment systems, the auto-triage system for the crash reporter, for taking the time to teach me what the heck kubernetes is... and so much more. There are several others as well who haven't had much of a public persona but have contributed hugely, and I hope in the coming days may be able to be a little more visible now.

Yeah, it has nothing to do with "under-performing" servers or anything like that. Like Jimmy said, it's 100% a measure to keep Excelsior stable, and to keep Everlasting from going down the same path. We'll continue to work on technical solutions as well, but ultimately are fighting against some design choices by the original team that cause scalability issues and non-linear resource consumption once you get above around 1,000 concurrent players on a single shard. Excelsior is consistently bigger and busier than Freedom was on the retail servers, if that tells you anything -- but players had more shards to spread out on then.

TBH half the reason the launcher exists* is because I was annoyed that all of the existing launchers like Tequila used .NET or Qt or some other heavyweight framework that's almost as big as the game itself. Especially .NET since it's a pain to get it working in Wine for mac/linux folks. Running a launcher and waiting 15 seconds for a ton of .NET assemblies to load just to get the list and start verifying files is not great. So I decided the new launcher needed to be written in straight C** and not require anything that the game itself doesn't, that way if your system can run the game either natively or through something like Wine, it can run the launcher. And it should prioritize fast startup and optimization to get the game to a playable state in as little time as possible. Thank you so much for the kind words. It makes me very happy that it seems to be meeting the design goals of being fast, just working, and getting out of the way so you can play the game! * The other half is of course outlined in the license announcement. ** Sort of, the core and updater is C, and the UI is implemented in Lua with C bindings as an experiment and proof of concept of some things we want to do with the game client's UI.

Because you like high pop servers and play on Excel, so you never interact with anyone who prefers a quieter experience. Typically they don't phrase it like that no, but just today I heard from someone with a friend who no longer plays on HC because of the, and I quote "toxic behaviors from the PLing and LFG crowd". We have free server transfers, people can play on Excel if they want. There's no financial benefit as I've explained before, since the shards share a hardware pool. So again I ask, why should we force people to move who don't want to, just to satisfy your desire for "more bodies to fill out task forces at all hours"?

But why? What possible benefit could that have? Force people who like low-pop servers onto the high-pop server instead so you see a couple extra people wandering around during prime time? (until they quit because they hate all the noise)

If their health gets below 10%, their AI makes them become invincible and untargetable - so no enemies can fire powers at them and they aren't affected by AoE. They'll then run back to their spawn point and wait 2 minutes to regenerate health before being able to enter combat again. Even if there was something that could one-shot them to bypass that, they're also flagged CannotDie and they literally... can't die. Their health has a minimum value of 1. And if something somehow bypassed THAT, like a GM (game master not giant monster) outright deleting them from existence, since they're persistent NPC's they'd respawn a few seconds later.

Geo is also a custom format unique to the COH engine. You're not going to find anything about it on the Internet. If you want to create tools to work with them, the only place to go for information is the source code of the game itself, which is findable in the same places I mentioned earlier. Ask around on Discord if unsure. Experience coding in C is advised.

There are 3dsmax files for some of the models and animations out there. I can't link to them because of the dubious legality issues, but if you check the usual spots for COH-related development they shouldn't be too hard to find. Something about dolphins if I remember correctly. Those are the same ones we have. Nobody (including us) has a complete set that covers everything.

It lets you have different sets of graphics and game settings. When you launch homecoming it uses -profile live, when you launch the Beta server, it uses -profile beta. The default location for loading bind files and options.txt is settings\[profile]. So if you're bypassing the launcher you'd want to use "-profile live" unless you want to keep any in-game settings you change separate for some reason. Probably you'd want to just use "live" so your graphics settings carry over and you can load any saved keybinds, etc. It's not for the launcher, it's the way the launcher communicates to the game which set of files to use. It's also a required parameter to start the game so you need to have something there.

The anim format is extremely simple, it's just a list of bones and positions / quat rotations for each bone on each frame. Note that means you cannot IMPORT an existing anim file and get anything useful. You won't have any keyframes or animation curves. You need the max files to use for reference. Anim is strictly an end target. Geo is a lot more complicated. Both anim and geo can be exported from 3dsmax through a somewhat roundabout workflow involving a 3dsmax plugin to write a nonstandard VRML variant that gets run through a converter tool. There is a python-based geo exporter for blender floating around out there, but it's not complete, has some bugs, and doesn't fully/correctly implement all the sections of the geo format which would cause problems later, so most serious asset work is done in 3dsmax. Animations have to be done in max. A bigger problem than file formats is that the source files we have are all in max format and the concepts used don't map 1:1 to other software. For animation work you really need that source data so you have an existing skeleton to work off of. None of that is connected to what Cobalt and Namoi were talking about. Most of the time involved in creating animations isn't modeling and animating, it's testing with the thousands of combinations of body types, costume parts, and sliders to make sure that things meet our quality standards. Those are that there shouldn't be obvious clipping with the "default" settings, and a little clipping is okay if it's limited to certain slider settings or when combined with certain other parts, but it should be a small amount. Stuff like too high/low poly count or holes that let you see into the hollow interior of the player model are huge no-nos. There's a certain amount of subjectivity involved but things have to pass muster and not have too high a "jank factor". What we really need more than tools are artists who have the time to work with Naomi and learn the workflow and the ins and outs of the art style. Support for other tools may eventually help with that some by expending the pool of artists available since there aren't many with 3dsmax experience, but it means translating all that knowledge into other software which is not an easy task. There's no quick fix for that.