Number Six

I think you're misreading -- he's saying they stuck close before the patch, and now run away after. All the reports I've seen about it have been on Brutes, so may be an issue with the global taunt proc.

Looks like it's not just Avalanche, but quite a few different knockback procs. So enjoy the fun while it lasts. 😃

Going to verify with @Captain Powerhouse; it looks like the PvE Knockdown effect in the Avalanche and Superior Avalanche procs is missing the PPM entry, which makes it a guaranteed proc. The PvP version of the effect looks correct.

Which powerset? I've seen some unconfirmed reports of critters running away from Burn, which may indicate the global taunt proc isn't working right with Blazing Aura. Since it wasn't caught on the beta server it may be limited to specific powersets.

Are you sure that whatever you're using to download updates is working correctly? Both of those outputs show that it's missing the homecoming-specific patch files. They should be in a "homecoming" directory under ~/.local/share/wineprefixes/test1/drive_c/Program\ Files/CoX Crash on "Loading badges" (and the missing cgfx files) are both a dead giveaway that patch piggs are not being loaded. Edit: Just thought of it: Using a relative -patchdir like that is sensitive to the current directory. So try running it from one level up: ~/.local/share/wineprefixes/CoX64/drive_c/Program Files/CoX$ wine hc-bin64/cityofheroes.exe -patchversion 20200121_679 -auth 51.79.19.146 -patchdir homecoming

If you set it to run borderless on Monitor 2, and you later tried to start the game with only 1 monitor connected, it would see some insane display resolution for the nonexistent monitor like 1819284759 x -948138433 (yes that's a negative height). That would in turn cause the game to try to do silly things like scale up the login screen and render fonts with glyph sizes of 18000x18000 pixels per letter, causing a crash. The game now detects such a situation and will revert to windowed mode if the configured monitor doesn't exist, allowing you go into the options menu and set it to run borderless on one that does.

I can't say for certain because you never know when a showstopper bug will be found, but given that we're on Release Candidate #4... I'd say Soon™

@moxierocks, Can you try the beta client and report what happens? It includes several fixes for common problems that people have been having. As a bonus, if it doesn't work, it also allows you to directly upload the crash report into our issue tracking system. The release candidate currently being tested even has several fixes for problems that were recently reported through the new tool.

Better run a level 20 diagnostic.

An argument can be made about magnitude, but in general ATs with powersets dedicated to personal defense don't get force multiplier capability "out of the box" -- without having to dip into things like the leadership pool. IMO that's a good thing -- no one AT should get to do all of the things. Speaking mostly about 1-49 here since Incarnate powers seriously homogenize things. Sentinels are in the same boat with Opportunity, but IIRC PH wants to redesign their inherent anyway so I wouldn't count on it staying like it is.

When the AI for the crate you're supposed to be retrieving from the bad guys forgets that it's supposed to be an inanimate object and starts turning to face you whenever you're nearby.

😏

Actually not possible. The total concurrent numbers, even on weeknights, is higher than the maximum number of players allowed on a single shard, even for when the game was in retail. If everyone played on a single shard, there would be constant queues during prime time. Raising that maximum any higher than it currently is can be done, but when we experimented with it early on, found that the limit is there for a good reason. dbserver (the piece that manages a 'shard' like Excelsior) has a ceiling of about 2,200 - 2,500 players before it starts having issues. Beyond those numbers any kind of database latency at all can very quickly escalate into cascade failure and cause instability. Splitting up the player base solves the design issue, even if the shards share the same hardware resources, mapserver pool, and database backend.

I guess at 20% (same as Achilles Heel procs) it is higher than I remembered it being. I don't really have a dog in that fight and in general like the extra flavor, though I'm not sure I'd call something added in Issue 18 a "signature power". Mostly I'm making sure people aren't still under the misconception that it bypasses the purple patch. It used to be ridiculously good against +4 AVs because of implementation details, but not for many years.

Errr, if you're running +4, Bruising is barely doing anything. It gets hit hard by the purple patch.

Even that is unlikely, because as I've pointed out more than once when these conversations come up, our servers don't work that way. Shards are cheap. The map cluster that accounts for the majority of the cost serves all of them (except Reunion) and can be scaled up and down independently to fit the overall number of players across all shards. That's how the game was designed to be run and why Paragon never seriously entertained the idea, because it would not have been necessary to do that to reduce expenses.

They were never locked to 2 processors. There were only 2 threads that did any significant work (since physx and the main thread were so tightly bound), so they could only effectively use two. In practice, the render thread and physx thread could never do any work at the same time. Even now fully using all 3 only happens under certain circumstances. At some point in the future it would be nice to identify things that can be parallelized, but there's a lot of work still to get there and be able to to do it safely.

There are 3 threads that can use significant amount of CPU. 1. Main thread - all game logic, input, processing, etc. 2. Render thread - all draw calls and anything that touches the OpenGL driver, driven by thread #1 3. PhysX thread - simulation of visual effects that interact with the environment (sparks, etc), debris, etc 1 and 2 are relatively unchanged from retail. 3 used to be frame-locked to 1 -- it would do some background processing but ultimately if PhysX took too long to run a simulation timestep, the main thread would wait for it to finish, delaying the drawing of the frame (meaning thread #2 would also be idle). In the modern 32-bit and 64-bit clients (not the safe mode client), #3 is now fully decoupled and runs independently. If PhsyX starts to lag, it just won't be updated that frame and will make up the difference on the next one. If it gets too far behind, it will start removing PhysX objects in order to catch up. Under very effects-heavy situations with lots of particles flying around, that can lead to more efficient utilization of those first two cores. There are a few other minor threads, such as the background texture loading thread, geo loading thread, and some created by OS libraries for things like asynchronous networking, but those are relatively low-load and only serve to reduce latency.

Specifically on the topic of porting AE missions: Honestly even if it were easy I'm not sure I would want to. With lots of respect for some of the talented AE writers out there, the AE toolbox is just so... limited... compared with what you can do with the full range of what's possible in standard missions. Consider the high bar that was set by the arcs added later in the game. Almost every single arc added in the last 2 or 3 years of the game includes things like customized mission maps, scripted NPC interactions, caption text, challenge badges, customized enemy powers, cutscenes, etc. While not every mission needs all of those at once or they start to feel gimmicky, by comparison AE missions feel like glorified radio missions. AE is a decent enough place to cut your teeth writing, but a good mission is produced by a team involving not only the writer but also mission designers, map editors, powers developers, artists, etc. We prototyped that process with the new vigilante & rogue arcs, putting a team recruited from within the community together to produce it, and everyone learned a lot from the experience. Those lessons will be applied to the arcs currently in development, and as we continue to get more people familiar with the processes involved we hope to get the pipeline more streamlined, and also to be on the lookout for additional talent within the community to add to it.

Two things: Can @Garbleor anyone else who is having a similar problem try to locate islandrum.sh somewhere in the coh folder and post the contents? Once again the backtrace points at something wrong with the launch parameters, which seems to indicate an Island Rum issue rather than a game issue, but I haven't had any luck finding out what it's actually launching the game with. Also, an experiment: Launch Island Rum, let it validate/update, but do not run the game yet Go into applications/coh or wherever the game is installed Delete homecoming.exe Go into the hc-bin32 subfolder and rename cityofheroes.exe to homecoming.exe Move homecoming.exe out of hc-bin32 and into the top-level COH folder Try to launch "Homecoming (Safe Mode) the from Island Rum that's still open This doesn't actually launch safe mode, but launches the new 32-bit client with Island Rum thinking that it's safe mode. Surprisingly, this has actually worked for one person and would confirm that it's a problem with the way Island Rum is launching the new clients. It's not a permanent fix since Island Rum will redownload the original files the next time you run it, but if it works for more people it will help narrow down the problem and what needs to be fixed.

One possible reason is that increasing the aggro cap for tanks makes it less desirable to have more than one tank on the team, not more, since a single tanker can pick up everything.

Bit of a tangent, but the spawn behavior is correct, while the not-leveling-while-on-a-TF behavior is the bug. The reason for that is that you used to level up during a TF -- either natively or along with whoever you were sidekicked to. That broke when they introduced super sidekicking in Issue 16. Ever since then, upon starting a TF, the entire team gets locked to the level that the leader was when they started the TF. That means starting a TF at the minimum level, formerly a staple of static teams and SG runs, instead makes the entire TF a painful slog. It's a known bug that will be addressed at some point, just a matter of time and priority.

I'm working on a standalone diagnostic tool to help get the info we need from these oddball devices, so keep an eye on this thread for it. At the end of the day, both the old client and the new one ultimately use the same method of getting joystick/gamepad input, but the old one had an extra middleware layer that Microsoft has since deprecated -- the newer one just gets the raw HID events directly. In theory anything that works with the old client should work with the new one, but in practice there may be some not-quite-compliant hardware we need to do special workarounds for (that presumably DirectInput was doing before).

Cool, and again I don't want people in this thread to think I'm calling them out on this specific conversation, since there was some prior back and forth on the topic. It just reminded me that I've been meaning to say something about it as a more general matter.

Right, the amount of work to implement has to be taken into some consideration. Changing how the AI works does require a lot of care and caution to not break other things, but the team at least has tried to be cautious and conservative about all changes*, so it's not significantly worse than anything else. *(There are a lot of people who are very passionate about this game just the way it is, so we try to expand and enhance without pulling the rug out from under them) The actual difficulty is also something that is often unknowable until somebody takes the time to actually go and evaluate what it would take. That's why I don't think it should be wielded as the sole overriding factor to shut down discussion. Just as a purely hypothetical example, let's say the PVP community had a strong and overwhelming consensus that reverting to pre-I13 PVP was necessary and the only way to fix things. If that happened, despite it looking like an absolutely overwhelming amount of work, it might be worth examining if there was any way to automate parts of it and reduce the burden to something that would be manageable. Maybe possible, maybe not, but I wouldn't want to completely take that option off the table without even looking. If somebody wants to say, "This is how the game has always worked, we shouldn't change it just because we can," that's a valid argument to make and by all means build that case. I just ask for people to please be careful about invoking "can't be done" when what they really should be doing is discussing why they don't like it.