UberGuy

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.

Oh, no, now let's be clear. While I do maintain it, I built what CoD's powers data extracs on top of @RubyRed's parser work. It's grown significantly since then, but I likely would never had undertaken it without that codebase. Also, the updates I am able to make when the Homecoming team releases updates is because they help me to know what changed at a data level. CoH's game files are extremely opaque in nature. They are almost literally a memory dump of the C data structures. If you don't have either source code or someone to tell you what has changed about them ... well, I won't say figuring it out would be impossible, but I'll just say there's totally no way I could do it as a side hobby project without the help of others. Even Ruby based their original work on original source code leaks. The one thing I can mostly take credit / blame for is the website presentation. Even there, while the codebase is wholly my own creation, I used the original City of Data as a UI inspiration and I regularly get feedback from folks like @Captain Powerhouse, @Booper and @Number Six (and many folks in this thread) when I display things poorly (or not at all) and/or things need better labels / descriptions.

This one should be easy to track down. I'm glad at least the logic for "tell us when you don't know what to show" works, rather than the old behavior of just not showing anything!

🤔 Yeah, that's not right. It clearly gets that the effect is based on an damage table, but it's not adjusting it. That probably means not just this power is affected. I'll dig into that ASAP.

Since the "Alpha" environment is apparently deprecated, the already out of date info for it on CoD will, most likely, never be updated again. As such, I plan to remove it from the site this weekend. The "Beta" and "Live" links will remain accessible in the header's revision text popup.

This is probably some oddity of browser-side and/or server-side caching. I haven't deployed any site updates since about 20 minutes after I posted about the I27 changes. (I had missed some data fields in powers and redeployed to add them, but they were just new JSON fields on powers - not powersets or their names - and that's the only place they appear.) That was like 18 hours ago, and the cache settings on CoD stuff are supposed to be 10 minutes. And I supposedly invalidated the server side cache as part of the deploy. So... 🤷‍♂️?

I do see the new Epic sets on the AT pages. I don't see the updated names. That seems to be legitimate - the old names are in the data. I am not sure what's up/missing/wrong there. Edit: Actually we can see the right names in those screenshots. I may have been confusing my browser (and myself) using the back and forward buttons across server boundaries, silently switching between views of Homecoming and Alpha.

🤨That is surprising. Those have always had well-defined means of relationship to the ATs that can use them. If these were created with some new way of building that relationship, the code that stitches them together probably doesn't account for it. I'll have to go data diving to figure that out.