UberGuy

The child effect which applies the cold damage has conditional statements attached to it and they're being displayed at least for me when I look at the live site. This seems like the constraints you mention. Is this not visible for you?

Looks like a display bug. The raw data sent to the site has them in the correct order. I'll have to check the code, but my guess based on spot checking them is that the web page code is sorting them by level then name. If so, I can just remove that and the current data will show the right thing.

Can you give me an example of this? I believe powers are ordered in CoD the way they are in the game data. If there are powersets where the first power in the data is not the T1, then that's probably what's up. The in-power info should still say correctly what level it becomes available at, though, and I could probably sort based on that if I'm not already.

Given what's on CoD comes straight from the game files, I'm inclined to agree with @Uun. Both powers are single-target, target self and have self as the only affected entity. While some effect lines say things like "all affected targets", what that actually boils down to is controlled by the Target and Entities Affected lines.

CoD updated with today's Homecoming patch.

CoD doesn't have this sort of capability today. It'd be possible to add, but you should understand that the lists involved would be pretty huge. There are many hundreds of player powers, and some set types have very pervasive application. (Think the various damage type sets and how many powers they would slot in.) It's extremely rare for folks to look at IO sets in this direction. Usually they want to know what sets their powers can take, not what powers can take a set. On the off chance that you actually could work within a small set of powers, like "what powers my character has that could take defense sets", you can see that on each power page's top right side. The icons up there show what enhancement types and set categories a power accepts - the icons with the IO-like hexagonal borders are for set categories. If you hover over the icons, the float text will show you the name of the thing that icon represents, and if you click on a set category icon, it will take you to the list of the sets in that category. I've attached a file containing the current list of player powerset powers that accept IOs in the "Defense Sets" category. Defense_Set_Powers.txt

Hey, gang, CoD has been updated, both live and beta! Very sorry for the late updates here. I have tooling that monitors the manifests looking for patches so I know to get on the update train, but there were two problems with them. I never switched that tooling from checking for updates to the old closed beta server to the new HC beta server. The tooling follows the login flow for the patcher, but as you all know the HC patcher relies on a valid login on these forums. My login had expired and the tool stopped checking anything. I've fixed both issues, plus made it so that if the tool's login is failing I get a notification and can go fix it. By the time I realized I needed to be working on updates, I had a bunch of stuff going on at home that needed to come first., Hopefully the improvements above will keep me on the ball better.

Hey, Tic. I remember you.

From what I can tell by looking at the git history, this never worked right. I guess no one ever noticed because either (a) they didn't move the slider, (b) they were looking at powers where child effects don't scale with level, or (c) they just plain didn't notice numbers that should change did not do so. I think I have to fit in option (c). The bug was incredibly simple. The hierarchy of child effects is literally a parent/child tree structure, where each effect group web display element is a child component of the parent effect group's element. The effect group widget has inputs that control how it displays its contents - things like AT tables, level, etc. Parent elements have to forward relevant inputs to their child elements. The web code has never passed the display level to the child components, so they always displayed at a default level of 50. This has been fixed. 😝

That doesn't seem to be any sort of display error. That's how it's actually set up. Even if those numbers were backwards (every 4.5s for 10s), it would only tick twice. Edit: I got confirmation from @Booper that this is WAI. It's got an interval so the attribute will stick around. The desired duration for that is 4.5s, If you check the flags, it's kept around to prevent a 2nd knock effect for that period. The 10s interval is arbitrary - it just has to be longer than the effect duration to ensure there's only that one tick. Edit2: I'll see about making the display more intelligent when the interval is longer than the duration, since this seems like an implementation trick we'll see in other places.

I just pushed a fix for the "Unknown Stacking Type" situation. I reused an existing icon for now - I need to noodle a bit on what makes sense given how small the icons are. I improved the "Unknown X" logic so it actually tells us the unknown thing's name in the popup. It always had the flag name, but just didn't know what icon or description to display. I also added the "Unknown X" behavior to several other attribmod icons that had a possibility to fall through without picking something to display, which could happen if a new value is added that the logic is not updated to handle.

I just posted a data update that contains fixes for things like "Δ K'ong". The issue was was in original Rust bin parser code, in parts of it that I have never actually touched before. There was logic that stripped out non-ASCII text from display strings of all kinds. I removed this logic entirely, so now everything in the clientmessages-en.bin is parsed as it's stored. There's a chance this will introduce control characters that were not previously present, though I mostly would not expect the website to care about such things. If you see something that looks off, let me know, as always. I also updated Brainstorm's data.

I just made a quick edit to the site meant to save people from being stuck on blank pages if they last had things configured to look at Cryptic/Alpha data. Since that's gone now, the site was busted for those folks, and it busted badly enough that they could not reasonably get to the settings page to fix it. I just pushed code that redirects folks trying to hit Cryptic data to Brainstorm instead. This should also handle folks using direct links to a specific dataset that targeted data=cryptic. The new code lets me add future data redirects like this in case they're needed again. I'll also look for ways to remove this lookup from the critical path for page load. Since there is code referencing the dataset in the header of every page, targeting a bad path breaks every page on the site early, which is, ah, not ideal.

The Live site should be updated for this week's patch. I'll work on the UI bugs mentioned above (and some older ones too) this weekend. References to data from the "Alpha" / Cryptic environment have been removed / updated to refer to "Beta" / Brainstorm.

While I can't say with certainty, I do not believe so. Edit: My understanding was that RedTomax had the info they did because they were close to one of the Paragon Studios powers devs. The original site was based on text info for the powers, rather than squeezing it out of client files. In fact, originally, most of this info did not exist in the client. I was only after "Real Numbers"™ was added to the client UI that powers data started being shipped with the client bins.