UberGuy

There are now help pages for these pages: Boostset Groups Boostset Entity The help new reflects that pages that show duplicate display names will show a popup instead of a parenthetical internal name entry. Number labels on all page images have been made larger so they're easier to read without zooming in on the image. The main outstanding things I know of offhand for help pages are: Update the settings page help for new theme features Add an icon "legend" to the power page help Update the power page help to reflect that it now includes a search box

I have to wonder - do we really need the AE to have a fleet of PPD / Arachnos drones around them, at least outside of Atlas and Mercy? Players don't congregate outside the AE, and I don't think NPCs loiter around them either.

A minor fix to an issue I'm not even sure anyone noticed: the power category page offers a breadcrumb popup that links you to the AT page for ATs that can use powersets in that powercat. This works great for player ATs. For NPC classes, not so much - those would send you to a blank page due to errors, since NPC ATs lack the powerset references the AT page uses to build its display. The powercat page popup still lists the NPC classes, but they are no longer links, and it sorts them below the PC classes. Also, if the powercat has no associated ATs, the entire breadcrumb text + icon is hidden. (Technically, it's not rendered at all.)

New shinies! Per page search box on powers pages. This was pretty easy to do. You can search for powers directly from an existing search page. Unlike the search box found on the main page, once you pick a power from the picker you're sent to that power immediately. (On the main page, picking a power updates the three links to the right so you have a way to get to powercats and powersets, not just powers.) I changed how duplicate display names are handled for... Powersets on the power category page Powers on the powerset page Inherent powers on archetype pages Previously, duplicate display names would be displayed with the internal name next to it in parenthesis. Unfortunately, this approach had problems. Some internal names are terribly long, so needed to be truncated. Making the table column a lot wider to allow for this was a huge waste of space on pages where powers had no duplicate display names. Long internal names that were truncated were no better at disambiguating the power than the display name. So I've replaced the parenthetical names with a lightweight popup that only appears for non-unique display names. Before After To try and deal with the occasional really long name, I display the names by replacing underscores with spaces so they can word wrap.

PS: The whole recipe thing is probably going to be something of a slow burn. It's kind of a rabbit hole, because recipes refer to a whole bunch of other things that the bin parser doesn't know about, like salvage, workbenches and so on, that the recipe either crafts or requires to do the crafting. To get recipe parsing to work, I have to teach it how to read the data on those things too, or it won't know what it's doing as it pulls out the recipe data. I will probably be able to get away with skipping some of what the recipes refer to (like info on what workbenches let you craft it), but I still have to go through and figure out what I need and don't. I'm basically doing that in layers. Get it to read salvage, then recipes, for example. Really weird baby steps.

That's useful info. It's still maybe manageable, as long as it doesn't jump around too much. I might be able to do something a like I did with Entities (critters) where I show their name by level range. That was an exercise in just this sort of collapse of data into ranges when the data "natively" exists as something defined at each and every level. In other words, the game data doesn't say "it's called a Wild Rikti Monkey for levels 34-37". The game data gives you a distinct entry for every level for which Rikti Monkeys exist, and I look at that and suss out the ranges for the names. If, say, only certain things like salvage and level of doodad created vary, I could pick that out the same way and display one page for a recipe with tables showing the salvage and whatnot by level range. But if too much varies, or some things vary too much to build useful ranges out of ... maybe not. I'm optimistic, but CoH implementation details sometimes have a way of crushing optimism. 😆 But recipes really should be pretty consistent over kinda broad ranges. If they're not, at least we can build a list and maybe get them cleaned up.

The main thing I'm thinking of doing with the data is use it to audit recipe descriptions and levels against actual enhancements. But I figure if I get the data, maybe I can show it too. But as you say, it may not be worth the effort. It sort of depends on how uniform they are. If they're well-behaved, I'm thinking maybe I can "collapse" ones that vary only by, say, level to a single thing myself. And if they are inconsistent, maybe we can get that fixed, and then I can collapse them.

Nope, it's not new. And it's also known. There's apparently no way around it. The power that grants you the procs is disconnected from the actual attack, and it can't tell that you no longer have access to the attack and can't "inherit" its particulars such that it disappears at the same time. At least with current tech.

I finally uploaded the updated Power Page help. It's still not done because I want to add keys for the copious number of icons you can find on this page. But I updated the page for other new stuff that's not icon-based. Main help pages todo list: Add help pages for the new Boostset and Entity Search pages (That's two help pages.) Go back and make the numbers on most of these pages' images bigger. Fortunately that won't be too time consuming since they're text layers in Photoshop images. Document the icons. I'll probably do this in phases, with AttribMod icons last, because there are a ridiculous number of them. The only site features I'm looking at adding right now are: An on power-page search box. I really like being able to search directly from the Boostset and Entity pages, and miss it on the Power pages. I need to play around with it and see how much space it needs. Power names can be really long, which is why the search box on the landing page is so wide. Case in point: "Boosts.Attuned Mark of Supremacy F.End/Pet +Resist(All) and +Regen Aura (Mastermind)" Maybe something for recipes. I am poking at teaching the Rust code to read them, and if I get it working, I might as well display the info. I'm not sure yet what display approach would make sense though. I want to see the data first. Unlike boosts, for which the enhancement's level is effectively a attribute, there's a unique recipe for crafting boosts at every level you can craft them for. So the recipe for a level 25 Mako's acc/damage enhancement is totally distinct from the recipe for a level 50, even though they basically craft the same thing with a different number set on it.

It actually always used to proc on inspirations. I am not sure it is still supposed to, as new events have been added that give more granularity about what is activated. It used to be it couldn't tell what was being activated so could proc on anything. Actually, since I updated CoD last night, I can tell it explicitly does check if the activation was an inspiration, so definitely intended. if ((target.EventCount>EndActivateClick > 0) + (target.EventCount>EndActivateInsp > 0)) && !Source.Mode?(kArcaneBolt) What's excluded here is toggles - which makes sense, as people could spam zero-recharge toggles on and off to build up Arcane Power.

Yeah, the hotfix zone rotation and the fact that Arcane Power and post-teleport hover activation started working again are surely related.

It's intentional. That's what the IO does - it makes it so you always act as if you're already in combat when activating your snipe. The primary target user for this are folks who had perma-fast snipe through the old toHit-based mechanics and disliked that the new "in-combat" version causes them to switch between activation modes. If you want the benefits of slow snipe as an opener, don't slot this IO.

Some minor tweaks: A fairly large number of powers, mostly for critters, reference power icons which simply don't exist. Sometimes they just have the name wrong, but sometimes they reference files that clearly no longer exist, or perhaps never existed. Historically the process that builds the powers data had no concept of whether the power referred to an icon I could actually extract, and would blindly point to it no matter what. Now the process checks if the icon was extracted, and if not, the power is flagged so the site will display a question mark icon instead of a broken image. This will also reduce a known source of "file not found" errors in the site's access logs, reducing noise and helping me find other, potentially more serious missing file errors. I discovered some PvP/PvE parsing was busted, and has been for a while. I rewrote the parser that handles expressions like this a while back, and there were some lingering bugs I happened to stumble across. They are now fixed, I hope. I said that last time. 🤞 Some more help pages were updated. That process continues, slowly. I'm probably 2/3rds done. The power page is a beast to document. A few small visual tweaks mostly meant to make the site look a bit better on narrow devices like tablets or (heaven help you) phones.

It should be fixed now. I got my hands on a mac and debugged it from there. What I posted in Discord: Edit: Access to the mac I used also let me spot a couple of other errors that didn't show up (or at least weren't obvious) in Chrome, and those are also now fixed. I pushed out incomplete help page updates to get the fixes out, so a couple of the help pages are more correct now too.

Any chance this has improved? I don't thnk what I was looking at was likely to actually be blocking at all, but I did change something, so there's a chance I fixed it. Absent that I'd need some console logs from the Safari browser, probably from the macOS version.

I may see the issue - Safari likes to send OPTIONS preflight requests, and I think those may be being rejected. There was a similar problem when I first stood up the site, but this has a different cause. Will update here if I can get those requests flowing and we'll see if that fixes Safari.

That's effectively true on iOS, but not macOS, at least so far. Chrome on macOS is its own, independent thing, with a different rendering engine and everything. Does Chrome work correctly there? I am trying to narrow this down to Safari/Webkit specifically.

From what I can tell, Safari should be handling this. To understand why it's not, I would need to see the errors from its developer console. I may be able to do that myself later today, at least on a mac, but I have no access to an iPad. Chrome is available on iPads. Does it suffer this issue? Edit: Were caches cleared?

I wonder if those platforms aren't sending requests expecting/allowing compressed files back. I would not expect that of any modern browser. I may have to turn on some logging. Also doing some Googling about those browsers.

My bad. Another deploy script bug. Trying to tune the site a bit and some of the small files ended up flagged as compressed when they weren't due to a variable not being cleared in a loop. Unsurprisingly, browsers don't like being told to uncompress something that was never compressed. One of those small files that said it was compressed and wasn't? The new code for handling light/dark switching, which is loaded on every page. The site should mostly be working now. Some edge places may not if they rely on data files that had the above issue. The simplest way to make sure all the data files are correct is to re-upload them all, so I'm running that now. It will take about 20 mins from the time of this post. Edit: Done some time ago.

Back when it worked previously I found Spectral's immobilize completely useless, even on characters who can stack it with other effects, so I would love to see it increased.

Very small update - the help pages are still out of date, but at least they obey the theme setting now. Updating the help is slow just because (a) it's prose and (b) I have a lot of screenshots to update. The annotations on the screenshots are particularly slow to redo. I'm using this update to change the annotations to layers on top of the base screenshot image so I don't have to recreate the annotations on each image from scratch each time the screenshot changes.

Yep. The confuse and the immobilize were missing tags that set their chance to happen above zero.

Weird, it works for me off of the above link. Are you getting a browser "file not found" page, or a CoD "power not found" page? I wonder if you're seeing the default info on the page due to a Javascript error. It will say something about the power not being found until the data is loaded, and if the data load blows up, you'll be left with that message. (Something I should probably address.) If you're getting the "power not found" message, can you try a force refresh of the page? It's usually Control-F5 (or Command-F5 on a Mac).

Two main reasons. The finished product is massaged in ways that make it consumer friendly, but may obfuscate its relationship to the bin data. If you look at my raw data on the site, it's going to be confusing to map some of it back to the internal names. Why? Because the internal names are sometimes complete butt in the sense that they would confuse a regular player. Hell, they often confused me. But I had the benefit of source code and some help from our devs to translate. Also, some of the structures just were more efficient to flatten or otherwise remap in order to make sane JSON that performed well to be re-parsed by a website. I don't dump everything to the site, though I do dump most of it. Since the focus is on powers, some things just aren't relevant to how CoD works and get trimmed. IMO the raw data is more valuable to someone writing new tooling, because they can pick and choose what data they need how it's displayed or massaged, instead of having to (re)parse what I transformed it into for CoD. Ultimately, this is why I took Ruby's code bolted Python onto it. I don't actually operate on the output of Ruby's original code, which does similar transformations to what I describe above. I modified it to emit its internal, "raw" representation of the bin data, which is much more "pure", and feed that directly into Python. Basically I replaced Ruby's approach to making the data "human readable" with one that made it "CoD" readable for my interpretation of what CoD should do. I could have operated on Ruby's output, but it would have made some of what I did a lot harder. Not because Ruby's choices were bad, but because they were optimized for slightly different goals.' Edit: It's worth noting that Ruby did add a feature to export "raw" data as well, just to files instead of cranking it into Python data. (I could read the "raw" output and read it into Python, but that would be even slower than what I do now.) There's no reason I can't bundle up the finished data too, but I think that would be more useful to regular players than to a tool writer. And regular players probably get a way nicer view of that data on the real site rather than peering at raw JSON. The JSON is provided on the pages so people can find things I don't handle (yet), or spot things I handle badly.