UberGuy

Yeah, that's actually the table those critters look up, it really doesn't exist for critters. I have no idea what happens if the game tries to access a table that doesn't exist like that. I would hope for some sanity check to prevent a mapserver crash, and consider 0 damage a likely "fail safe", but am totally guessing without some code diving.

This morning I fixed a little fubar that's been lurking since the Page 3 update to CoD went live. Powers that accept Threat Duration set enhancements were missing their accepted enhancement display entirely, because that widget was hitting an error trying to look up the right icon for Threat Duration sets. Thanks to @Replacement for pinging me on Discord to report the missing enhancements display on a power, which led me to fix the root issue. I'm going to add some fail-safe logic to this so a missing icon results in an "unknown" icon instead of borking the display entirely. This sort of mishap is common when boost or set names change (which has happened a few times now), because I have to manually update the boost and set icon lookup tables that turn names into icons. (Which I half did for Page 3. I changed the generic / SO name-to-icon mapping, but not the set version. )

Another tiny update. Powerset pages now list powers in this sort order. Level the power is available to characters / critters Display name Internal name Historically, CoD has simply listed the powers in a powerset using the raw, native order in which they were listed in the game files. For regular AT powersets, this has usually been perfectly sensible, as those were fairly short lists of powers mostly pre-sorted by level. However, other "powersets", which are sometimes very large and often just big bags of loosely affiliated powers (like the "Set Bonus" powerset above), are often a wildly disordered mess. The new sorting should make finding powers in such grab-bag powersets a tiny bit easier without having to add column sorting to this page.

Uploaded a tiny tweak this morning. Most powersets of interest actually have long descriptions and (relatively) short names, so the display table on the "powersets" page is laid out to support that. Some powersets, though, have really long names and almost no description. Case in point, the "Set Bonus" powerset, where all the set bonus powers (including "globals") live. For a long time, such long names were simply truncated by the name column. I finally figured out a reasonably effective way to give them hover behavior that shows the full name in-line. The bold line with the background highlight is the one under the mouse in the two screenshots below. You can see that the line is allowed to extend into the next column and the background "glow" masks the text underneath. The CSS I used is a bit ugly, but seems to work fine on Chrome, Firefox and Safari. (Oh yeah, I can test on Safari now because my new job only issues Macs to employees. )

It's a click attack and not a toggle, so, like most such powers, it has a regular toHit check for all effects.

I just pushed a semi-major update to the site's header layout and functionality. The hamburger icon that used to only be for navigating to the settings page is now on the left and, when clicked, brings up a navigation menu for the entire site. The gold color on "Power Search" is the hover color, added to make it more clear which link you're hovering over. The nav entry for the current page will be in white text and won't be a link. This icon currently requires you to click on it to get the menu to appear. I'd appreciate feedback on whether this is pleasant or annoying. I can make it appear simply on hover, like most of this site's popups. The new "hamburger nav" has the advantage of being available on all pages, so you don't have to go back to the landing page to, say, get from a power page to an entity search. I moved the button from the right side of the page to the left because some of the site's pages are quite wide, and the right-side elements are easily carried off-screen unless you use the horizontal scrollbar. I left the rest of them over there, since the things remaining there probably aren't accessed often from those pages. On that note of things on the right side, it is now possible to make a source-specific data link to the AT attribute and modifier pages using the revision link shown on the right side of pages. I have also added an info popup to the nav menu on the right side of the landing page hopefully making it clear that this new menu exists. This popup appears when you hover the mouse over any of the links over there, and is not interactive, so it won't interfere with using those links. After a while though I will probably remove these links. (I also added hover highlighting to these links, but I need to tune it a bit, as the color I am using is hard to see in light theme mode. Oops.) [Edit: Link hover colors tweaked.]

OK, all the above fixes are in, including the SZE script expressions being displayed in infix notation and "Script Nofity" being updated. Protection mag is now a positive number and +maxHP is scaled correctly. I also added a row hover highlight to the bonus list table.

Ah, good catch. I looked right at those during testing and it didn't even register. And yes, the issue is that the numbers I am displaying are the raw scales for the powers' effects, usually but not always multiplied by 100% when displayed. That works for most set bonuses because they use the "Melee_Ones" scale table. But the MaxHP ones, as you note, use the "Melee_HealSelf" table, and the values in there are such that the raw scale needs to be 10x bigger than the resulting percentage increase over base. This'll be fixed when I next upload fixed data files, which should be early evening and fix all of the issues discussed so far.

I am sure that's what happened. (Edit: Well, sort of. I updated the enum name in the Rust code, but forgot to change how it serializes to text.) I'll dig around tonight and update it. That'll require (extremely minor) changes to the Rust back-end and the easiest way to fix it everywhere will be to just rebuild the data. My upload tooling only uploads changed files, and there probably aren't that many powers using that attribmod. This is fixed, as is the sign on the protection attribs. For now I flip the signs in the web code, but longer term I will flip them in the data extract so I don't have to loop through nested data structures in the web code to modify the values on load.

Yeah, I might flip the sign on those. Any mez protection would have this going on, but KB prot is all we get in that realm.

😲 Not sure how I broke that.

I made a small update so that clicking the "Show Greater?" radio adds a column to the end of the table with the bonus values displayed, since otherwise what you're being shown can be a bit mysterious. This scale column can be used to sort the entries. If you have it set as the sort column and turn the "Show Greater?" filter off, the sort reverts to the set names.

And it's live. You can get to it from the navigation on the main page. Which reminds me, that list is getting long-ish and I want to make it accessible from every page, probably via a popup from an element on the header row. Maybe I'll just add "Settings" in there and replace the "hamburger" settings menu icon with a nav icon of some kind.

Scripts are pure server-side. We don't have access to it in the client files to display it. The fact that you see it on that page tells me a new attribmod is missing or out of placesomewhere in the data extract code. That's not what that power is supposed to be doing - its displaying the attribmod with the wrong name. I checked older files and that was there before, so it's not an error. Maybe once upon a time I didn't handle or display it. But in any case, we can't display that stuff on CoD using client files. That info is server-side only. I could display the script info in the files, but then it has to go somewhere on the page, and since the vast majority of critters don't have it, I decided not to bother. It's there in the raw data, which is visible. The one thing I can easily do is to translate the RPN/postfix notation into infix notation the way I do for other expressions.

It just needs a little layout tuning and the ability to remember what you have selected.

I'll look into that. I have that data already for other sets-related pages, and I was already thinking of just pulling that data into this page for other display purposes.

That should be do-able. I think there's plenty of room in the table / on the page.

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.