UberGuy

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.

This isn't a bug. Not that it can't be changed (technically), but that's a suggestion, not a bug report.

A couple more small updates and fixes. Not all attribmod types showed when they activated with delays or "over-time"/DoT-like behavior. This has been fixed. In particular, this hid the fact that the prestige rezzes have a small delay before the untouchable effect kicks in, which is how the site's lack of showing it was found. A string-to-integer (lack of) conversion bug, affecting the AT modifiers page, was discovered and fixed. (I am guessing almost no one hit this, because it would totally break the page.) The "Class Name" field on entity pages is now a link to the AT modifiers page for that AT.

This has something to do with the way the mission sets your level. There seems to be an "arc or mission-wide" way that properly strips you of powers like this, and an "in-mission only" way that fails to do this. It will fail to remove any power you have via grant by another power. For example, the new travel power bonus effects will stick around, even if you lose the travel power. It was testing for the travel power changes that actually brought this to the attention of the current devs. They do know about it, but I don't know what the priority is to fix it, if any.

The above issue with Super Stunners is fixed.

Thanks for that. That name entity's internal name is a bane on existence in multiple ways. I am forced to sanitize it because using it as a filename is invalid in nearly every operating system, and CoD uses a separate file for each entity. Clearly I missed lining up the generated link with the (sanitized) file name.

Small update! Based on reports of issues with the checkboxes in the header (PvP/E and Raw Data) not always applying on page load (which I have sometimes seen myself), I made some relatively small tweaks to how these are loaded. Hopefully, they will now consistently apply the checkbox setting to the page, rather than occasionally requiring you to re-toggle them to get them working. For the curious about how the sausage gets made... Visual elements on CoD pages are "components", each with their own code, and so loosely coupled. The main component on the powers page (itself made of other components) knows nothing about the checkboxes in the page header, per-se. That architecture is useful in a lot of ways, but it makes the way things communicate shared state (like the whether checkboxes are checked) relatively complex - more so than you'd probably think for something as conceptually simple as a checkbox. To solve for this, checkboxes "announce" their state when it changes (like when you click on them), and things that care "listen" for these announcements. On initial page load, the checkboxes "announce" their remembered state after they load it from your browser storage. But this means there's a so-called race condition - what if the checkboxes "announce" their initial status before the other components on the page that care about it are ready to listen for it? To deal with this, I have the components that need to know about checkbox state "announce" a request for all checkboxes to broadcast their state only after they're ready to receive such an announcement. Some of my decisions about how to build that were, in retrospect, probably not so well-informed about how the web framework I'm using actually works. In other words, I n00bed. I have moved when these things happen to an earlier stage in the page render process and also added some retry logic to them. Now if a components that cares about checkbox state don't see a status response for all the checkboxes it cares about, it asks for a new status broadcast again, and will do this multiple times until it knows everything it needs to. At least, that's the plan.

That makes sense to me, but as someone who plays a lot of characters who don't get that benefit from their snipes anyway, and also who has blasters without snipes, that seems like a-nice-to-have rather than something I would unequivocally refuse to lose. But I admit it does sound useful, and slotting this enhancement on a Blaster does make it much harder to leverage effectively.

I don't remember the exact details, but I know for sure that threads use a relatively complicated modification of your chance to get one based on how recently you got one before. I think I recall that shards have something similar, but it's different and not as aggressive. This is something shared on forums that are no longer around, so I don't know if I have access to the specific details anymore without a code (data) dive.