UberGuy

The base chain listed there is what I use. I keep an Achilles Heel -res proc in AS and a Fury of the Gladiator in SS, with the Critical Strikes proc in BF. In normal play, I wing the Moonbeam insertion based on situation. (Did I just get a CS proc? Am I at/above the +toHit needed to max out the base damage from the snipe? Is something annoying out of melee range that I can pick off now?) I haven't run an analysis on optimal snipe insertion since fast snipes were updated to their current mechanics, or done a pylon test.

My guess: -regen is good for hard targets. Personally, I prefer -res, because its benefit scales with your own (and your allies') DPS, but for folks with middling to low DPS, the massive -regen from the Cataphract is useful. It's own DPS is actually quite poor, but the -regen can count for a lot of "effective" DPS. Edit: And it does look pretty cool.

Nope. Why do you ask?

I don't have a claws, so no, I haven't tested that. However, I never saw it reported in any of the timing threads post sunset as winning vs things like DB or TW. It's possible that's changed, though I don't think anything about the powersets has changed recently. If anything changed, it's more likely something has changed in people's build "aha's". PS: Gaussian's benefit is extremely sensitive to your next-in-chain power, since it only lasts for 5s, meaning you will only reliably get 1, sometimes two attacks off after it activates. While I wanted it in my DB's build, I didn't have room for both it and the Critical Strikes proc, and that one is far more beneficial, especially when you have other sources of +dam (like FU/BF themselves).

There's a situational aspect to Build Up as well, namely the time you take casting it. As far as the rotation-wide view of the +dam powers in Claws and DB, I think there's zero question that they're worth it. (They also provide a good place, IMO to put things like Gaussian's BU proc or, as I tend not to be a fan of the set bonuses for the Critical Strikes set, the proc from that set as a singleton.) Claws is, IMO, the better of the two you are interested in mowing down multiple foes, while DB, while not terrible at AoE, is better if you want single-target DPS. Not mentioned before, optimal DPS use of Dual Blades means largely ignoring its combos. The only combo particularly worth executing is Attack Vitals, which I fall back to when my recharge is too low for the top DPS chain or when I want to keep my target flopping with the knock from Vengeful Slice. Vengeful Slice has a long animation you usually want to avoid, both due to animation lock and because the DPA is not good, but the bonus damage from the Attack Vitals combo ends up meaning BF->VS->Repeat is the set's second best chain (not including snipes) and is achievable with way less recharge.

Possibly already covered, as I skimmed the thread, but generally your optimized choice between sets that offer high defense vs high resist is to put high defense on Scrappers or Stalkers and high resist on Brutes. Not to remotely suggest that mixing it up is "wrong" or won't perform well in the vast majority of circumstances, but Brutes get the higher resist cap (90%) while everyone gets the same 90% average mitigation at the "soft cap" for defense. Nothing wrong with softcapped defense on a Brute, of course. The offense sets that go best on a Scrapper are the ones that offer the most +dam, which contributes more to total damage on a Scrapper vs a Brute because Scrappers have high base damage and low (no) inherent +dam, where Brutes have comparatively low base damage and match Scrappers by adding large +dam via Fury. So if total damage is (1 + damBoost) * base, on a Scrapper you're adding a bit of damBoost off of a low or even zero base, where on a Brute you're adding a bit of damBoost to an existing large number. Claws, Dual Blades and Dark Melee are examples of things that give good, sustained +dam. (T4 Assault Core Hybrid is also a good source of this for any build.) As a side benefit, these sets all also provide +toHit which makes epic snipes more damaging. I don't agree with Katana having better ST DPS to DB. DB is a monster, largely because of of the +dam from stacking Blinding Feint, which Katana has no answer to. It also helps a great deal to use Sweeping Strike, which has outstanding DPA, as part of your single-target attack chain. This requires a lot of +Rech and also a lot of endurance/recovery management. It has the side benefit that, if you can face the right way while cutting down bosses or higher, you'll also cut down the stuff next to and behind the main target fairly well.

There's not a big variation in the activation times of the fast snipes. Most have either a 1.33s or 1.67s activation time. Archery, Beam Rifle and Fire Blast have that 1.67s cast time. AR's is slightly better at 1.50s. Everyone else (who has a snipe) seems to get the 1.33s time.

For me, the 100% base is "noise". It doesn't provide information about what my build choices are adding. By which I mean, that 100% can be assumed, and to understand what my build / powers add to the effect / attribute, I need to mentally subtract that 100% if it's displayed. That's why I prefer to see the "base" as +0% and effects the modify the base as their "delta" value.

My guess is this will make versions that depend on raw DPS, mostly meaning Cimerorans, more competitive relative to the BP. BP do nice damage, but their biggest benefit, IMO (this bug notwithstanding) is the -res the Ravager can apply. That's still going to be very useful against hard targets. There's a good reason that -res is one of the most popular things to bring along on a team/league that needs to burn down hard targets. It's just not going to be as useful against over-level hard targets as it was. Ignoring combat mods was already a non-linear boost relative to something that did not ignore them, but they got to accelerate that boon even more with unmodified -res.

On the other hand, it doesn't seem very useful to have it, as it doesn't seem able to run on a modern Windows environment. I should try firing it up in an XP VM, just for giggles. Hero Planner 1.51. Last modified date 4/24/2004. 😵 I also have a copy of SherkSilver's Hero Builder, circa 2/24/2006. This actually still works. And yes, the day of the month on those really does match. Edit: Oh snap, I was wrong. It does work. They both do.

I got a big ole green light on critter data, so look forward to UI support for that in a future update. I'm thinking weeks, not days, just because I have to work on this in my spare time, but I don't expect it to be at all technically hard to add.

Regarding source code: TBD. Bear in mind that CoD is not something I was able to keep up-to-date with recent changes to CoH in a vacuum. Whether its source code can be made public may be complicated by the same constraints that affect Homecoming's own source code. I am feeling out what constraints may exist, if any. Unrelated to any legal constraints, CoD's current back-end tooling is not set up in a way that makes it consumable by the vast majority of normal humans. Probably the biggest reason for that is that I do my development on Linux, not Windows. Both Python and Rust work fine on Windows, so it can unquestionably run there, but I almost certainly need to rework some of the tools I use (for things like building new data bundles and pushing code update the site) for them to work on Windows. A number of things are currently bash scripts, for example. Making a tool like this easy for non-dev/non-admin types to use is actually a lot of work and creates its own support burden, so even if I end up free to do so, it will not happen for a while. As far as exporting critter data, that's another area where I'm asking for Dev feedback. It's one thing to let people know how their own characters' powers work, which is the primary focus of the site. Because old CoD also exposed NPC powers in its drop downs, I felt free to do so as well. And I obviously expose information about critters which players can summon, since that is a subset of "how their own powers work". However, I am sensitive to the devs opinions about how easy it should be to know everything about totally arbitrary critters. I very much share the feels when it comes to things like understanding critter resistances or mez abiltiies, and see great value in the community being able to research such things independently. However, I also understand that this is rather spoilery, and our current devs are adding new critters with new capabilities. Because of this, I have asked for the devs' opinions on this before I enable whole-hog everyone-can-see-behind-the-curtain features in CoD. Re: using the site as an API - my default position is "please don't". While hosting it is not expensive, I do pay for its use based on traffic. Well-behaved access to the data is not a problem, but I know from experience how easy it is to accidentally be a very bad actor when "scraping" another site. I actually still have a copy of it laying around - both the installer and an installed version in an imaged copy of my game machine at the time. I was using it in the first few weeks after the initial game release.

I made a variety of bugfixes / feature updates today. The main ones that affect live Homecoming powers relate to CoD not previously displaying information specific to powers with "Chain" areas of effect. There are a few attributes unique to these powers which weren't displayed. This included expressions for dynamic chain behavior, like targeting priority and "chain effectiveness" (which modifies the strength of an effect based on the number of targets it has jumped to.) The simpler chain-related values are shown at the bottom of the power's "Activation Details" in a new section for "Chain Attributes". Also missing was display of max target expressions, which dynamically affect how many max targets a power can effect. This does come into play for a number of chain powers, but is not chain specific. You can see an example of these on this power. A number of Electrical Affinity powers are chains, so this update probably really makes powers in that powerset make more sense. All of the new expressions are "whole power" attributes and can be quite long, so I display them above the tables, in the same place power "Requirements" go.

You commented it pretty well IMO, so places you were being "non-Rust idiomatic" seemed obvious to my untrained eyes. Plus, you'd probably be moderately horrified at how I did some of the serialization I added. 😂 Edit: I actually watched some on-line courses on Rust, so your code wasn't my only learning source. I'm not so masochistic that I try to learn a programming language Thirteenth Warrior style!

It was. But the good news was it was something I wanted to do, for a variety of reasons. Foremost among them was the fact that I personally missed having a working CoD a great deal. I used it a lot, even after it fell behind. But in the last year or two it became so far behind that even if the old site still worked, it would be wrong a lot of the time. Combine that with the fact that it was written in an unsupported version of PHP not compatible with any forums currently associated with CoH, and it was well and truly dead in its old form. Next was the fact that I saw doing this an an excuse to learn (a) Rust and (b) modern JavaScript. Rust is what RubyRed's bin file parser tooling is written in, and JavaScript is, of course, largely unavoidable when writing a non-trivial web page. I'm an IT person by profession (specifically, a Site Reliability Engineer - no, not at Google, they just "invented" the discipline as its widely recognized). Most of my programming skills are in languages used by Linux system admins, like Python and Bash, with some languages from my past and current jobs, like Java and C/C++. Rust is an up-and-coming language I was interested in. JavaScript is a consistent top-rank language mostly due to its ubiquity in web-based applications, which have, of course, taken over the world. It's been years since any of my work projects required me to understand JavaScript, and it's evolved a ton since then. Actually designing a web site from the ground up would certainly require me to catch up with it. There were a lot of iterations of learning to do. I had to not just learn what the Rust code was doing, you know, because I didn't know Rust. I had to figure out what the program was doing, because I knew very little about how to read the powers bin files. Progress between those goals would ping pong back and forth - learning how Rust works would help me understand what sections of code were doing, and figuring out what code was doing would help me understand what certain constructs in Rust meant. Once I had a decent grasp of how the Rust code worked, I started tinkering with it. I wanted certain outputs it produced in different formats, for various reasons that depended on the thing. I did make a variety of changes, initially small but more complex over time. But I quickly learned that adding all the changes I was envisioning was going to take me longer than I wanted. Mostly, that comes down to me not being a strong Rust coder. I knew I could do what I wanted easily in Python, even though it would not be as performant as Rust code. So I had a choice - spend the time learning to code faster in Rust, or invest in one burst of Rust learning to create a bridge between Rust and Python (for which there was existing support). I never considered ditching the Rust code - it did too much too well. I opted for the Python bridge, allowing me to treat the Rust library as a Python module that would expose iterators I could use to parse all the things. It took me a good week to build this, but then I could write Python code like this: # This thing is Rust code but can be loaded into Python as a library from coh_bin_parser import parse_bins # The bin files are read here coh_data = parse_bins.parse() for powercat in coh_data.all_powercats(): for powerset in powercat: for power in powerset: # do useful stuff I'm glossing over a lot of detail, but hopefully that makes some sense - one of Python's claims to fame is it is relatively human-readable. Make no mistake - the processing time for doing a lot of the power handling in Python instead of Rust is at least an order of magnitude longer (as in slower). But my speed in writing the code in Python was probably weeks faster. There's another benefit of having the data in Python. It's very easy (and pretty fast) to dump Python objects and reload them later. After I parse a release of the game just once, I can load all the data into an interactive Python session and search it. @Boppercan attest to how often this comes in handy for things like "find all / any examples of powers that X". On the front-end side I needed to learn not just JavaScript, but brush up on HTML and CSS, and learn about a few new browser features. I also ended up learning a JS web UI framework (Vue.js) - you don't want to reinvent the wheel when people have built sports cars for you. But "car" is a good analogy - there are a ton of moving parts and learning to use such a framework is a whole adventure of its own. (Props to @Leandrofor pointing me at Vue.js as the strong option with the lower learning curve than the main alternatives.) Basically, I probably increased my job marketability and salary potential significantly by engaging in something I enjoyed doing anyway, will use extensively while CoH-ing, and helps other people too.

But as mentioned up thread, for a raw list of all the categories...

PCs and NPCs aren't assigned their powers in the same ways. Each NPC entity gets its own list of powers, powers and powercats it can use. You can't build a directory like that for NPCs in a consistent way like you can for players. Those categories you can see are "bags" of powers that a given group's powers will probably be found in, but they can have powers from other powercats all together.

I don't understand what you mean. Power Categories don't map directly to enemy groups in any consistent / obvious way. I mean, some do, by virtue of obvious names, but not all. The only way to really know is to look at an entity. Edit: but look upthread for a way to get a list of everything.

The set-related nulls you're remembering are effects like LotG and Preventive Medicine. The 6th enhancement actually has no direct effect, so its only effect is a Null. That's because the special effect of slotting those is a set bonus, which is applied by external logic. Which reminds me - that's an expansion of the site I have planned - one that lists the details of boost sets (which is the internal name for enhancements that give bonuses based on how many you have slotted).

Actually, I found a bunch of other powers with this going on, and some are fairly new. This is just the player-specific ones. There are NPC ones as well. Corruptor_Ranged.Dual_Pistols.Bullet_Rain Incarnate.Interface_Silent.Confuse Incarnate.Interface_Silent.Immobilize Mastermind_Summon.Mercenaries.Equip_Mercenary Mastermind_Summon.Mercenaries.Tactical_Upgrade Mastermind_Summon.Ninjas.Kuji_In_Zen Mastermind_Summon.Ninjas.Train_Ninjas Mastermind_Summon.Robotics.Equip_Robot Mastermind_Summon.Robotics.Upgrade_Robot Mastermind_Summon.Thugs.Equip_Thugs Mastermind_Summon.Thugs.Upgrade_Equipment Pool.Utility_Belt.Flying_Kick Pool.Utility_Belt.Poisoned_Dagger Scrapper_Melee.Claws.Swipe Sentinel_Ranged.Dual_Pistols.Bullet_Rain Stalker_Melee.Claws.Eviscerate Stalker_Melee.Claws.Swipe Stalker_Melee.Ninja_Sword.Head_Splitter Temporary_Powers.Temporary_Powers.Opportunity_Lock

Null effects are usually, as you mentioned, for FX purposes (and I try to detect that and display it in CoD v2) or, in some cases, simply to put an icon in your status tray (as in the case of the Scrapper critical hit "inherent"). I've seen some I couldn't figure out, though. But there's no useful equivalent to that, as far as I know, for a fully-fleshed out effect with no chance of actually activating (and no visible means to change that chance). It's a bit like an effect with a condition that says if false

While that's true, that feels like a strange choice. This chance will be evaluated every time the power is used. While not even remotely wasted cycles worth being concerned about, it doesn't feel like something anyone working on the game would do intentionally for the sake of convenience in later adding a new effect in this spot, which would be a trivial bit of editing to do even with the old DEF file format. My guess is that someone did this while testing variations in the power, probably back in the Cryptic Studios days, got in in a satisfactory state, and forgot to clean this up later. It may be worth a pass to see if there are any other effects (in any powers) with a 0% chance but no tag on the effect or its parents.

If you can work with just a list (which you could use to input into the search box or, with a wee bit of figuring out, the address bar), use this. This would be easy to do, but I want to see what the powers that be think of it. That's a bit spoilery, and beyond what old CoD offered. If Leo and crew don't object, I'll make it a thing.

There are 36,000 of them. I don't think you want that... 😲 Edit: That was a pre-coffee answer. That's the number of powers. But still, it's almost 200. Is that really useful? And yes, totally cool to link to it from the wiki!

I'm happy to publicly announce that there is an up-to-date rebirth of the old City of Data site. The site is accessible at https://cod.uberguy.net/ This is meant as a successor to Red Tomax's original City of Data, and borrows heavily from that site's organization and visual display of information. Quite a few things have changed, , though, both in the game and our understanding of its data, so it's not identical to the old site. It shows more information in a lot of cases, and lets you see more "raw" data. This site would not have been possible without the extremely impressive work done by @RubyRedto create the Powers project and the coh.tips site. Ruby's Code Archeology blog post made me realize this project was achievable using Ruby's work as a starting point. I also want to thank @Bopperfor help trying out the early versions of the site, finding bugs and making suggestions. @Captain Powerhouse also gave valuable feedback, and some of his suggestions are still in the pipeline as tweaks and improvements. The site's data is extracted from Homecoming's game files using a modified version of Ruby's tool. This version exposes the raw data in a Python environment, where I perform additional transformations before exporting it as JSON. This version of the data acts as the backing for the website. The site is entirely dynamic on the client side - there is no server-side page rendering. This does mean the site requires Javascript to be enabled and a relatively modern browser. If you've updated your browser in the last couple of years, you should be fine. (If you haven't, I hope you have either an excellent antivirus or exceptional opsec skills.) There are some ways of displaying things the old CoD did which aren't the most practical for this version. They're possible, but more work (or cause more traffic) due to design decisions I made about how the power and other data is structured. Old CoD built display pages on the server, where the new CoD is entirely client-side logic. This means how the site displays things is more tightly coupled with decisions around the structure of the files it pulls in to show you data. For example, every power is sent as a distinct data file, so displaying a whole powerset on one page would currently require pulling down every power in the powerset. Do-able, but not great. (A more compact whole-powerset display is possible, but ideally calls for a better slice-and-dice export of the powerset as one file.) I've made some effort to check that the site works on mobile devices, but it is not really visually optimized for that. I have no way to test the site on Safari or iOS devices. I can test it on browsers that run on Linux, Windows and Android. Most of my testing was done in Chrome and Chromium-based browsers, plus Firefox. Questions and feedback are welcome. Be sure to check out the "Help" pages on the site, which are accessed via the question mark link on the top right of every page.