UberGuy

I didn't even know that was a thing. That's specifc to Blasters, and none of my Blasters have blast sets with snipes. Corrs and Defenders don't get a range boost for using their snipes.

If one had a built that gave fast snipes before, there was no reduction in damage. Because the base damage scales with +toHit, at the +toHit required to have used a fast snipe at all under the previous design, the new fast snipe damage is boosted up to the same level it had previously. Characters which can now achieve fast snipe but which never could previously now have that access at presumably lower base damage levels, with the specifics varying based on on their access to +toHit. This was likely very intentional - it proliferated the fast snipe capability but reduced the overall power creep across the population inherent in doing so. Slotting Experienced Marksman is only "gimping" yourself if you rely on slow snipe's increased damage. While I can see slow snipes being tactically useful (sniping down Sappers, for example), depending on your character type and playstyle, this may not be considered important. Fast snipe DPAs, even at their new, lower base damage, are still extremely useful to insert in a lot of attack chains if you can afford the endurance cost. If that's the primary use case, slotting this enhancement can make sense. Personally, I prefer to keep the slow version handy, but some people really dislike inconsistency.

New update. The site can now display data about powers which share "recharge groups" and "exclusion groups". A "recharge group" is one in which all powers share a linked recharge trigger. When any one of the powers starts recharging, they all do. An "exclusion group" is one in which only one power can be running at a time. Usually all such powers are toggles. When any one of the powers turns on, any other one running turns off. The group names are links to pages that show all the powers in that group, and each power entry in the list is a link to its power page. This update seems to touch bits of the site that really resist page refreshes picking up the new code. I had to clear my browser file cache to see the updates, both in my local dev environment and on the live site. Next up: Power lifetime settings (usually present on things like temp powers or other granted powers) Dark / light theme switching

Yeah, something like that could work for folks that leave the launcher running. Of course if you leave the game sitting at the login screen, the launcher might measure that as time "playing". It might be able to be a bit smarter than that, if there's an easy-ish way to monitor the client for active connections to a mapserver. (I think that stuff is all UDP, so the notion of "connection" may be tenuous.)

There was no such thing as the market on a given server. The market was (and is here too) cross-server. The only separation was the old hero/villain divide.

There are no game stats of any kind that aren't per character. The only way to do that would be to scan every character and sum their respective times. Any addition of stats to the launcher would be a significant expansion of what it does. It doesn't connect to the game's back-end at all. It simply auths to the forums and patches and starts the game client.

OK, the icons are now their "real" size. Instead of often being smaller icons in the top left corner of a consistently 64x64 image, they're now cropped to their useful size based on header data I didn't realize I should be parsing until @Number Six pointed it out. As is often the case after a change like this, you might have to clear your browser data cache to see the corrected site. The worst case scenario if you don't is just that the icons on boostset pages will look funny, with the color background and the boost icon being the wrong sizes and/or offset incorrectly. Other icons throughout the site mostly should not change. Most power icons already had a real and internal size that matched, so the code correction did nothing to them. The boost / boostset icons displayed on powers pages were (accidentally) already pre-rendered in a way that handled the raw images correctly, given that none of them had the visual artifacts that sent me down this road. The only other result of the updates is that power icons on power pages for powers that are boosts will appear larger now, since they are no longer scaled down due to including extraneous blank space.

Yep, that means I'm doing it wrong / the hard way. I'll inspect that header instead of just skipping it.

Updates! The PvP bonus bug #1 mentioned by @AboveTheChemist, above, is now fixed. It was a little more involved than I'd hoped, partly because I discovered quite by accident while testing the fix that not all PvP bonuses have "(PVP)" in their display names. So I had to add logic to test whether the bonus had a PvP "requires" expression, which involved changes further down the data manipulation stack than I expected to have to go to fix just the fact that I was displaying only one set bonus per incremental slot. The enhancement icon bug #3 above, is also fixed - I think. It turns out the funky image artifacts are not something my image manipulation code/library was introducing. Any image editor I loaded the raw DDS image data into showed those strange "extensions", so they seem to really be in the image data. Apparently, they don't appear in the game proper because it crops or masks them out. The icon files are 64x64 pixels in size, but the icons only ever use the first 44x44 or so. It was only icons which had image data all the way out to 44 pixels "edges" that showed the artifacts, which appeared to be a duplication of those edge pixels out to the full 64 pixel edge. I fixed the issue by masking out the unused pixels in "e_icon_*" images. Powerset pages now have a larger table showing not just the list of power names (as links) in the powerset, but now also shows the short help for each power next to its name/link. See the image below. Because the table is wider, it now has the row hover highlighting similar to that seen on powers pages. Thanks to @zenblack for the suggestion to display additional info next to each power. The short help for powers is pretty much the minimum I could display here, but it was simple to add the short help strings for each power directly to the powerset data. (The powerset page does not load the full data for each power - some powersets, like Temporary Powers, would have to load hundreds of powers.) Note that while the short help is a decent functional description for most player powers, it often sucks for critter powers and some "internal" stuff like internal implementation for Incarnate powers.

Yes, basically Traps had a similar problem, but it was actually much stronger, because it was a much larger area and it was also pre-PPM. It would have a (probably significantly) lower chance to proc if it was using PPM. I remember people using it to clear out all the minions on the rooftops of the two forward towers on the last map of the ITF. At its best, today's Burn couldn't approach that simply because it's just not that big of an AoE. Plus the proc chance probably isn't as good because of how it works in most pseudopets - it's based on a flat 10s cycle time, reduced by area factor..

Burn's patch does anemic damage. Burn's PBAoE effect, emitted directly from the user, is anything but anemic. I use it without a damage proc in it other than Assault Radial's Doublehit, and even when Assault is down, I have no complaints about Burn's ability to burn down even massed L54 bosses. Completely separate from the proc thing, the fact that it spawns a bunch of patches will probably be fixed at some point, and if it is, I agree that the base patch probably should be tuned upwards in damage a bit. Not to the level it achieves with current target saturation, but more than just one patch currently. But the fact that it summons multiple pets and can proc off of every one of them is way, way not intended. Like, no one (publicly at least) knew it was like that for years after it changed to its current design.

Oh, it's much worse than that. It summons a pseudopet for every foe in range, and each can proc. So it's proc madness. Fixing Burn should be super easy - Burn has a PBAoE damage effect plus burn patch summons, so the pet can simply be flagged not to proc at all. That way just the PBAoE will proc, and will do so based on its own cycle time, instead of the 10s activation time base Auto powers use.

Definitely a bug. I'll look into that. It should be easy to fix. 🤞 That's intended. The table gives a list of high-level function for each piece, derived from the actual configuration of the boost, not its display name. For example, the boosts shown for each enhancement are figured out by really inspecting what the power does and aren't just from the boost's name - which can be wrong! I can tell that an enhancement has a proc in it programmatically, but naming the proc based on what it does is hard (damage is easy, debuffs not so much), so I didn't try. It's intended that you follow the link to figure out what it does. Check something like an LotG:+Rech and you'll see something similar for "Global". I've noticed that too. I'm guessing its corruption happening when I extract them and convert them to PNG. At some point I need to dig into what's up there, but since it only happens to some of them, it's not been a high priority - especially since I'm using a 3rd party library for the conversion, so debugging it could be a challenge.

I realized I never responded to this post. Both powers are Auto powers, so they both come on immediately when the secondary critter is summoned by the triggering of the trap. The "initial" effect will only ever activate once - it has a 1000s activation interval and the "triggered trap" critter only lasts 30s (as defined by its "Self Destruct" power, which goes off after a 30s delay). The debuff effects in the other power eacg last 10s but reactivates every 1s, with new debuffs replacing old ones - they don't add together. There's nothing in there about the vomit because that's likely part of the hit FX applied to entities hit by one of the effects - I'm guessing it's the holds. CoD doesn't really do anything with animation data, so that's why you don't see anything there.

Couple of small updates. Entities (critters) now show their group name. Previously, this was simply an integer value I wasn't sure how to use, but I figured out it was an index into a list of villain group definitions. I've added the ability for the Rust code to read these and use it to populate the critter's group name. As long as none of the groups are too huge, I plan to use this to build a page showing villain groups by name, with each name a link leading to pages for all the critters in the group. (Even if the groups are too big, I can still likely provide some pagination within each group.) Powersets containing powers that contain more than one power with the same display name now show the internal names of the powers in parenthesis next to to the power name - something that is already done with duplicate display names in a few other places on the site. This duplicate name situation never arises in normal player powersets, but it's sort of common in some critter powersets and it's basically standard in some of the Incarnate powersets.

Yeah. The phased areas aren't really "instanced" in the way that's used in other places in CoH. While phased areas' contents vary based on the status of a team's leader (including a team of one player), different teams whose leaders are in the same state all see the same things in the phased area and can effectively "share" it. Everyone doesn't get their own team copy.

This seems like a simple fix. The status interfaces are missing their tags. The main powers both grant you the proc and set the chance it goes off using a global chance mod - in this case affecting tag "InterfaceStatus". But the only power bearing that tag, is (weirdly) the Preemptive Interface end drain proc's effect. Fixing this should be as simple as adding the "InterfaceStatus" tag to these powers: incarnate.interface_silent.immobilize incarnate.interface_silent.confuse For consistency, Preemptive should really get its own tag (something like "InterfaceEndurance"), though to be honest I don't know why all the other debuff effects need distinct tags. Since you can only ever have one Interface active, they could all share a tag.

I haaate drift, but have been able to ignore it for years because fast switch to Hover completely stops it. I can basically stop on a dime from flight because I can zip up to something and flip Hover on at the right place. (Within the limits of game client/server position (dis)agreement lag, of course. 😛)

I don't think it's possible for a Null option to do this. It would require completely different powers, or a code change to allow exclusion groups for powers to be some kind of expression, rather than just a string that's checked at power activation time.

This would require a code and data storage (DB) change of some kind. Nothing currently is shared across accounts except Global Mail and the stuff in "Character Items", both of which are rather limited. Character Items seems largely restricted to "back end" reward grants, with the closest to us "storing" things there that I can think of being opening Super Packs. Personally, I would not want all my characters' items and wealth shared by default. But I would like a better interfaces for sharing than Global Mail's. And yes, shared Inf would massively overflow if it was not a larger integer than per-character Inf is.

This. To my knowledge, Containment has never had a float text associated with it - only the extra mag effect of Overpower did.

I have those toggles on the side of my mouse, where I can flip them with my mouse hand thumb. At this point, I can do them by sheer muscle memory. There's no performance cost, unless I block myself by queuing attacks while I try to change travel modes. Edit: It helps hugely that the true travel powers (so excluding EvMa) are zero cast/recharge time, so you can toggle them on/off freely.

I don't run all the toggles. I build binds that let me toggle them off so they're mostly exclusive. I don't need Fly (or EvMA) to run when I'm in combat, and doing so is a huge waste of endurance. And until Hover's animation doesn't override Fly's, I don't want Hover on while I'm flying in open spaces. (Otherwise I'd keep it on for the movement control.)

Clearly it's just foreshadowing. Level limit 120 update coming Soon™! (But seriously, that's kinda funny. Clearly those stats are just freeform text.)

That's just for use on this pineapple pizza.