UberGuy

Getting closer... I think all of the things we wouldn't consider "set bonuses" are being filtered out. This code builds the list of bonuses you can search for based on inspection of actual set bonus powers. Because of that, some stuff we find in "global" bonuses like the damage proc for the Spider's Bite global damage proc or the Scrapper's Strike crit bonuses are just too complicated to sanely display this way, Thus, I carefully restrict the kinds of attribmods it treats as "set bonuses". Anything that deals damage, grants extra powers, applies chance mods, or targets something other than the caster are all filtered out. This can be tuned as needed in the future. Only scales that apply to the currently-selected bonus types appear in the "Bonus Size" list Everything updates on the fly as you click on things. The column headings let you sort by the columns' values. Bonuses you can get with one slot name display the piece from the set as CoD itself understands the set piece order (so the LotG De/+7.5% Rech is the 6th piece in the set). Single-piece bonuses like that sort as "1 slot" in the order. The main thing missing right now is that everything resets if you refresh the page or navigate away and back. This is kind of annoying, at least to me, so I plan to do something about it. I expect my solution will let you hardlink to the page with a particular configuration, which I think might be nice for sharing pages here or in game. PS: The "Include Greater" filter means "currently selected scale or greater".

I'm just going to leave this here for now. This is still very rough and not fully tested, so it may be a few days before I shove it live. In particular, I have more info to display about the matches.

As it turns out, none of the effect group icons use the red strike-through "no" visual, so I'm definitely playing with that. The main problem now is that just overlaying the "no" over the target makes it so you can't really tell its a target any more, since the red ring makes it hard to notice the the concentric rings and the slash hides the bullseye. I'm playing with less bland combinations for something that looks good though. But no rush on that, since no power even uses this icon yet. I'm focusing on new site features instead.

I understand. What I'm saying is that any icon with that superimposed on top end up just looking like the "No" icon. The details underneath are too small to make out. So having two icons that both look like that ends up just looking like two of the same icon. When they can appear together in the same list of icons, I try to keep the icons looking distinct. At least from other completely different flags/mods.

That's kind of taken, I think. I already have an icon that looks like that, and it would be really hard to tell which one it is - the red "no" overlay kind of "wins" at that size. However I'll check and see if I am using that as an effect icon or an attribmod icon. If I'm not using it as an effect icon, I think it's fair game to use this.

Power effects groups now display the "HitRollSuccess" and "HitRollFailed" flags, which require that a power have either hit or missed its target, even if the power over-all is autohit. The example below is taken from Earth Manipulation / Salt Crystals. The "hit required" icon above, while hard to see because it is small, is a target with an arrow in the bulls-eye. The "miss required" looks very similar, but the arrow is off to the side. However, no powers yet use the "HitRollFailed" flag, so only the "hit" icon above actually appears anywhere. PS: It's hard to make visually distinct icons that also convey something just with their picture, given how small they need to be to support the visual information density we need for CoH powers info.

This is fixed. I just didn't have support for the "AdjustTimer" flag, and the logic was falling through to the default (no flags) behavior for the "RechargePower" attribmod (which is to immediately recharge the named power). Looking into this also caused me to notice that some attribmod types were displaying any delay info twice ("blah for X sec after Y sec (only self) after Y sec"). This is now also fixed.

Entity pages now support displaying conditional data. For critters that have conditional blocks defined, a dropdown for displaying the available conditions appears. (This won't appear if there are no conditions for the critter.) When you change the dropdown, the entity's data will update in place to reflect the changes that mode results in. It also updates the URL so that you can hard-link directly to an entity with a condition selected. Note that the UI for picking the condition is subject to change. The expressions here can be basically arbitrarily large, and really long expressions will look awful as drop-down entries. On a related note, you may notice that the URLs generated for the conditions is just a string of letters and numbers. That's because I converted it to something that would not be horrible to use in a URL. (For the curious, it's an MD5 hash of the requires expression, in hexadecimal.) Support for this was not trivial to add, and it makes me really appreciate what must have been needed to do to add this into the game engine. The conditional overrides can't just blindly overlay the default critter data - a lot of the condition block can be "null" (or other special values that mean "nothing here") so that you have to merge the condition block with the default settings. And since the defaults come from level range definitions on the critter, displaying some of that on CoD the way I do (as a list of level ranges) was probably messier than what you would do in the game engine, where you should know a critter's level. I had to merge the condition's level range with the default level range data, since technically a condition block might overlay only part of a critter's level ranges, and could span them in arbitrary ways. I also noticed that the description for some new critters contains markup like that used for powers data, so I ported over the powers pages layout for data containing markup. Critter descriptions now show in dark mode by default, controlled by the "Colorful / Monocrome" display setting on the settings page. I had a dev request to add per-level costume data, so that's visible now also. (It actually has been for a couple of days.) Like the critter name, this can be overridden in the conditional block. As always, let me know if you run across broken things. More, smaller updates are coming, but this was the big one.

Wasn't aware of that issue. There are no new mod flags that are relevant, so this has probably been busted since I added support for it. I'll have to dig into what's up there. What should happen is that the amount of recharge should appear in the hover popup for the little clock icon over on the right side of the attribmod's row. But it's making it look like it's full immediate recharge. That's probably going to be easy to fix.

This should be fixed now.

That is correct. The hardmode powers are part of the conditional data for the critters, which CoD is ignoring for now. It only shows you the base stats (and powers) for the critters with none of the conditional stuff. That will change, just not today. As a tangent to that topic I am going to have to go over a fair bit of the way the CoD back-end links powers to critters for purposes of "critter AT" attribution, because none of it will be checking the conditional data.

We would see powers that directly grant +def, but not powers that boost the strength of +def powers. But if you don't have any such powers in play (pretty easy to tell that in general just by looking in your status/buff tray), then that's not it.

The set bonuses are going to all be the same, given identical sets and slot counts. The difference has to be coming from your actual +def powers. So all your enhancements are level 50, or are attuned and you are level 50? No Alpha or power-boost-like effects boosting +def powers?

And it's live early. Let me know if you see any broken things. At this stage, it's probably likely that powers or critters using new features may be broken. At the very least, it's certain that some new things won't be shown until I add direct support.

It only took about 10 minutes on my lunch break to get the basic critter data display mostly working. I still need to deal with the fact that the way valid critter levels were defined changed (it got a lot simpler). Right now this level range display for new critters is the only thing that's just plain broken. I do expect to have it working later tonight. I think there's a nice way I can handle displaying the conditional info, and it shouldn't be very hard to implement, so expect to see that this weekend.

OK, I got all the new data making it out of the bins and into (updated) Python classes. The CoD data export logic then blew up on some of the new boostsets, since it tries to sanity check the scales and had no idea what to do with the new combined Threat Duration boosts. (It was all like "yo, why are these dual enhancements boosting both aspects so much!" - logic I added to help audit sets back in the spring.) It was easy to educate it about these boost types and once I got past that, all the data exported fine . Tomorrow I will work on updating the website code. I need to update the "entity" pages as described above. Having it read the default "condition" structure instead of reading those fields out of the base villaindef will be easy. I probably also have to update a bit of code/config around boosts to make sure the renaming of "Taunt" to "Threat Duration" doesn't break anything. It's almost certain to break the default (non-set) boost icons unless I handle it, since those come from a manually-managed lookup table. Right now, I expect to be able to easily finish the core functionality updates tomorrow evening. I'll start on the fancier updates around displaying conditional villain info and knock vectors this weekend. There are also a couple of small fixes that have been languishing for months that I will get out in the next few days.

Got the critter parsing working, now working through some new powers stuff. Should be faster ... I think!

I'm still plugging along. This critter change stuff is taking a little longer than I thought it would. It's not hard, just a bit time consuming. Eventually, I need to rework the "entity" pages. The reason is that there are now a bunch of the data entries for critters that can be swapped out based on condition tests. This is surely what's made a lot of the new cool tricks we see in the ASF possible. Because of this new data layout, I am having to rework not only how the data is parsed, but then how it's handled from there (Remember, I usually massage all this data at least a bit because CoD doesn't need all of it in its raw glory.) That then also means I have to update the web pages that display that data. To save time, I'm working on just updating the pages to display the critter's default attributes (which is all most critters have). I'll add the ability to display conditional configs (where they exist) later. I considered just punting on the critter data changes to get the updated powers data out, but that would have been more work, I think, than just updating the critter data handling. The reason is that my data extract / deploy automation assumes I'll always perform a full data rebuild, not a merge of new and old data. Changing that was going to be enough work (and risk of screwing something up) that just cranking this critter stuff out looks to make the most sense. Yep, CoD's back-end does already handle the knock data, so I just have to figure out a way to display it on the web pages. A brute force approach of displaying the vector components and its anchor type is probably the simplest start. There's some vector stuff in the ASF, so I'll add that in ASAP once I get the core extract and display updates wrapped.

Looks like the biggest structural changes were around critter data. I think I've got a handle on it, but I definitely won't finish it tonight. Fingers crossed 🤞 that I can crank it out by tomorrow evening!

Whoops. 😲 I thought the target date was more like this week. Anyway, everything else applies.

Just a heads up - I am alive and am working on updating the site. Real life has just been very busy. Testers will have noted that I haven't been able to update the site for a while now. Things are calming down a bit, and somewhat oddly the holiday season should mean I have more time again, especially leading up to year end. I may not have the site ready to pick up the release of Page 3 the day it goes live, but it should not be more than a day or two late, I am hoping. There are some data structure changes I am working through to make the parser compatible with the latest test server builds, and then I can generate data for them (and for Live).

If only the code could update itself every time the data structures and enums changed, that would be awesome too.

The issue seems to be that Synapse's Shock and probably all the new sets have their attuned versions flagged as below. This is only supposed to be used for things like PvPOs and Superior enhancements. It means they work all the way down to level 1. ignore_exemplar_for_bonuses = true

Most likely. Am I correct in inferring that these were attuned pieces? Unfortunately, the level something can be slotted at is controlled by different settings than the lowest level at which set bonuses (no longer) function. Having a given piece of a set contribute to the bonuses you get is supposed to be based on the Boostset's level range definition compared to your own level, where the level an individual enhancement can be slotted at is specified on each individual boost (enhancement) itself. I can't see why Reactive defenses should work all the way down to 15, since it's Boostset spec says its lowest level is 20. That should make it stop working at 17.

While I've kept parts of Ruby's tool up to date, I don't use it like most people would - my build is invoked via an internal API wrapper that I call from within Python code, and emits data directly to Python. I haven't been updating the export code that is how most people would use the command-line tool. Basically my build is a fork that's diverged from Ruby's version, and Ruby's version now has more "raw" data export features from when I first forked off of it, which was a big reason I forked it to start with. That's a long winded way of saying my updates really aren't such that you could use them directly. I have two intended ways of addressing this. I've long intended to contribute updates back to Ruby's mainline code. This shouldn't be too hard, but I've let our codebases diverge enough that it's going to be a bit time consuming for me. I also intend to provide a download from CoD of an archive of the "raw" version of the game data that my Python code produces. This is (very) similar to Ruby's version, but lightly optimized for how I build the "final" version that back's CoD's displays. My focus for a long time was just getting CoD itself working, displaying power, AT and critter data fully and correctly. Then I left it alone to focus on my job and then take a vacation. I'll be back soon (days) and should be able to work on both.