UberGuy

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.

There's no drop suppression. Not for invention stuff. There's drop suppression for a few things: Threads, Shards, Catalysts and one other thing - maybe converters? - have suppression mechanics. (All of the suppression mechanics for each of the things that have them are different.) Stuff like recipes, IO salvage, and SOs are all fixed probabilities checked on every defeat of a standard rank critter. The specific odds vary by critter rank and only by rank. However, your personal odds of receiving a given drop, once one is determined to happen, vary with team size, and, in multi-team contexts, whether another team did more damage to the thing that was defeated (which means the random choice of who gets the drop is given to someone on their team).

Just a status update, I'm working on building the code to perform dedicated data exports that will facilitate a set bonus search/lookup interface. However, I'm pretty tied up with work for the next few weeks, and then I go on vacation, so I probably won't get a lot of new feature work done for the next month or maybe two. Obviously, updates will appear here when I have them. 🙂

Personally, it wouldn't really bother me - I certainly don't consider it trash. But I also don't tend to rely heavily on snipes as an opener. If one's primary goal is to use your snipe as a high DPA booster to your regular attack chain, it's not especially valuable that it have long range, since you can't use your other powers at the snipe's regular range. Remember - snipes exist on ATs other than Blasters, and not all of those ATs have the damage scales (or an Aim/BU to use with it) to reliably one-shot snipe even just minions (at least at high notoriety). So having it as a hard-hitting opener, while still useful, is less transformative. It really comes down to your character and what your playstyle priorities are. Personally, I don't slot this set because I prefer the bonuses from others. If the bonuses were right for my build, I'd probably give it a good think, especially on non-blasters.

Fast mode turns any snipe into a high DPA attack that you can consistently use in your attack chain (assuming you can absorb the cost of doing so), which for a lot of sets can significantly improve their DPS. I don't think it would fail to improve DPS on any set, but some sets get more mileage out of it than others. The original behavior for fast snipe was dependent on your toHit bonus. If you could get to a consistent +22% or more toHit (from Tactics, Kismet, etc.), you simply always had fast snipe all the time. While the new, combat-dependent version of fast snipe is lower damage than the original, you can get it back to its old fast snipe damage if you can still get to +22% toHit. So you can basically get the old fast snipe behavior back - except you always have to open with some other attack (or get attacked) before you can start using it in "fast" mode. Some people prefer having the fast version all the time, because its simpler and can never be interrupted. This is who this IO is meant for - people who liked the old behavior and basically want it back.

Yep. That's the point of that enhancement. It keeps you in "in-combat mode" so the behavior of the snipe is consistently the fast version.

Yep, was just looking at this due to another report of the same. It grants temp powers, and those temp powers are flagged with "disable_temp" as a disable mode. I think they should probably have that removed. Admittedly, that means you could rez and then zone into a context where temps are disallowed, but I really don't think that would be an issue, since most of the effects last 60s and the mez protection lasts 90. An alternative might be to change the base power to use ExecPower instead of GrantPower. I think if it did that it could point to the regular inspiration powers - if so the temporary versions could be dispensed with entirely. (I was thinking an Emerge lasted longer than the equivalent granted by RtB, but they're the same.)

Are you on teams or at large raids? If so, low drop rates are typical. If you are soloing, especially at high notoriety, then I'd personally want to see some evidence, like a video, and confirmation you don't have any drops disabled. Because the claim flies in the face of other evidence.

@altenate, in the video, what is the "deaths head" icon I see in your status tray? Is that the countdown to the vigilante alignment power? Just trying to make sure that EB isn't affecting you with something that could cancel the placate. I made an ElM/SD Stalker on Cryptic and couldn't seem to replicate this, but I didn't slot everything you mention above.

I think if that was it, it would break Placate on every Electric Melee Stalker. I know a lot of us skip Placate these days, but surely someone would have noticed / reported that before now. I hope.

There doesn't seem to be anything amiss with the actual definition of the Placate power for Electric Melee. It's not missing anything that it should have set up in order to function properly. So whatever is going on, it's not that the power itself is misconfigured.

I don't spot any obvious issue with the power itself.

Punchvoke and the auras can miss their taunts against AVs. Also, punchvoke has a target cap of 5. If they were over-level, there's also a chance that any misses or critters out of range causing any taunts more distant AVs did get to wear off. Edit: But yeah, them just wandering away does seem odd.

Actually, I was misremembering that Taunt proper only had a chance to miss against players. So I guess we'd need to know what Bill was up to in terms of taunting to know if the punchvoke behavior could explain it.

Taunts can miss AVs and GMs. Even though they're auto-hit, they have a condition expression on them that still checks the toHit roll outcome, and if it was not sufficient to hit, the taunt doesn't happen. My guess is that this was what was up, especially if you were counting on any taunt auras you wouldn't normally slot for accuracy.

In no way to diminish the efforts made to protect our characters and other server-side data, it makes sense that there was zero data loss with this issue. By all reports, this is a networking issue only, along with an unplanned reboot of the auth server. Basically everyone who was connected timed out or was booted, much like for the regular server restarts. It stands to reason that everyone would reappear in the same places (at least in the open world zones) that we were when things went south. Backups (off-site ones in particular) would really only come into relevance if our servers were physically damaged or wiped clean. And I'm certain there would be data loss in such a case. Even the most aggressive backups are a snapshot in time, so there would be "lost" time between the event an the date/time of the last backup. But we would not lose everything, and most importantly, we would not lose things that had been around a long time.

Teensy tweak - the far end of the search input boxes now show how many entries are matched by your current input. Usually what you type in the box is way shorter than the input box itself gives room for, since its width is set to display your final selection, so I don't expect this number display to get in the way visually. (Plus, the number should get smaller the more you type.) Let me know if you run into places where it does interfere. There were some more small fixes. Mainly, using a link to a search selection on the main page (or navigating back / refreshing the page) wasn't populating the powercat/powerset/power links. Also, I shortened the text for each of those links to only display the name of the thing in question, rather than the fully qualified name. This was done because the full name of some powers is huge, so the power link in particular would sometimes overflow and mess with the page layout.

I pushed a few small changes over the last few days. Most were tweaks to search to improve performance and reliability of some of its behavior. I also went through and made sure all the pages that work off of URL query parameters show useful messages if you give them bad (or no) parameters instead of just giving you a mostly-blank page and a spam of errors in the browser console. This also cleaned out a legacy input box on the power page that would appear if the requested data couldn't be found - that's super redundant and inferior to the search interface that's now on the power pages. I've been peering at my copy of the game's code to make sure I really understand rules for things like when a set piece's bonuses stop working, so I can add more of that info to the boostset / boostset groups pages. Fun fact - the game uses the rules for SO/DO/TO degradation with level difference to determine if a crafted IO will give you bonuses or not. This is where the "IO level -3" cutoff comes from. An SO more than 3 levels lower than your combat level gives you 0 boost. The code says (paraphrasing) "include this boost in the power's set piece count if that logic would give you more than 0 boost." (This made it hard to find the logic in question - it's not at all clear from a casual perusal that this is what that bit of code is doing.)