Jump to content

UberGuy

Members
  • Posts

    648
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by UberGuy

  1. So, on further research, it seems the update lag when scrolling on mobile is not a (missing/bad) browser feature thing. The articles I was seeing suggesting that are out of date. Browser tech has changed fast during the last 5 years, so there's a lot of old info out there. It seems it is honestly just a performance thing. Each time you update the search box, a new list of matched entries is built. When you scroll around, the code has to calculate where in that list you're currently at in order to know what list entries to display. This is an optimization to avoid rendering several thousand entries (10s of thousands for powers) on page load. This calculation of what to display is non-trivial because not all the entries are the same display height - duplicate display names and matches against internal names both cause the internal name to be shown underneath the display name, making some entries taller in a way that varies based on the current search box input. If every row is the same height, you can just figure out where you are in the list by dividing the current scroll position by the height of the rows, but with variable height, you have to get fancy. The brute force approach would be to walk the list of display items until their heights add up to the current scroll offset. The performance on this would be abysmal for large lists. Instead, I used a tried-and-true approach called a "binary search", where you start in the middle and say "am I above or below where I want to be", and then keep dividing the remaining list in half until you end up in the right place. Worst case performance on the brute force approach is proportional to the number of things in the list - a hefty 21,800 (not 28k like I said above) in the worst case of the powers list. But for a binary search, it's proportional to the log() function of this number. For the ~22,000 items in the full power list, it cuts down finding your place to 14 tries tries or less, with an average of probably around 7-8. But it still has to do this on every scroll update. But wait, the Entity search list has about 7,700 entries, which still seems to result in 12 tries or less, and the entity scrolls noticeably more smoothly on mobile. That tells me its probably not the time spent finding one's location that's the dominant factor. Power names, with their need to display the category, powerset and power names together, can be really long. So the search box (and the dropdown list) for powers is much wider than the Entity or Boostset search boxes. And a wider list box is more area the browser has to repaint on each scroll refresh. And that seems to make the dynamic scrolling updates to the list box slow enough that they fall behind when you scroll fast. Which... there isn't a lot I can do about, since displaying less than the full names would make the power search considerably less useful. I'm going to keep poking around, but so far it doesn't seem like I can do a lot about this. The best advice seems to be: Don't slap the search list with a massive swipe action that will make it rip through the list super fast. Unless you don't care if you can't see what's scrolling by, in which case, go nuts. AND put something sane in the search box so the code has less to search through a smaller list
  2. OK, folks. It took several days of learning, coding, breaking things wildly and then figuring out how to fix them, but I've implemented a fast scroll box that has a real scroll bar. Most of the original scroll interactions from my first go at this have been preserved. The main thing that's changed is the scroll indicators at the top and bottom of the list are gone, replaced by the legit scroll bar. The cursor up/down keys move the currently selection up and down, and scroll once you reach the ends of the visible list. The page up/down keys scroll roughly a whole screen at a time. Sometimes they go more or less than a whole page because it snaps to the nearest top/bottom row. If the mouse is off the scroll list, the page keys move the current selection to the top (page up) or bottom (page down). If the mouse is over the list, it's position determines the selected item. The mouse wheel will scroll up and down, without momentum. The list will initially put the last searched item in the search box at the top, unless that's not possible because the remaining part of list is too short. The last searched item is initially selected, whether it's at the top of the list or not. New behaviors are: The dropdown remembers its last position if you leave it without picking something. This is not really a feature, it's just default unless I do something different. Personally, I kind of like it. You have scrollbars. They scroll very fast even if you have all 28k powers matched by your current search. You can (finally) scroll on mobile using traditional swipe up and down motions on the list. Sadly, the behavior of the swipe scroll on mobile is not nearly as nice as it looks on a regular PC. This seems to be a limitation of the platforms - an actual difference in how all the mainstream mobile browsers handle scroll events. On desktop, many events fire as you scroll, creating a smooth visualization. On mobile, the scroll events fire near the end of the scrolling, meaning a fast scroll creates a long period of nothing visible in the list. I will continue looking for ways to address this - the one I found was out of date and discontinued, and most articles talk about just sucking it up. But hey, at least you can scroll on mobile now.
  3. There is no upper limit, only a lower one. That lower limit is normally equal to the lowest level the set exists at -3. So a level 20-50 set will work at levels 17-50.
  4. If the power now includes an "Activation Effects" group (AEGs) when viewed on CoD (and Reaction Time does), there's a good chance the proc will no longer work in it. I think this was not specifically intended. It's a side effect of changes to have various "self + foe" powers to use AEGs, which were done to clean up various powers. For example, Reaction Time was meant to hit as many as 10 enemies, but to also affect the caster. Previously, to support this, it had a target a cap of 11 and (even) more convoluted per effect-group requirements. With AEGs, it can have a target cap of 10, all those targets will always be enemies, and the self buffs come from the AEGs, which don't care about targeting (they always affect the caster.) However, a lot of self-affecting procs weren't configured with this new behavior in mind, and now they simply no longer work on the caster in powers like this because the power's standard effects no longer affect the caster. (Procs don't fire off of AEGs and the only standard effect group in RT that works on the caster now is the one with the buffs that trigger on detoggle.) This wasn't noticed in testing. Edit: And the change to procs in RT had nothing to do with the Stealth-related changes discussed above. I'm pretty sure something will be done here to address this, but I don't think we have a commitment to that effect from the devs, or any timeline.
  5. Sort of. All NPC fliers got their AI cleaned up so they fly with less zig-zagging and pausing. This was a fix meant to un-futz Mastermind pets, who were just plain dumb about following their summoner at long range made possible by improvements to Group Fly. Those AI improvements were made to core logic shared by all NPCs, so all fliers are now more ... purposeful in moving to their chosen target location. Their actual travel speed attributes were not increased, just how directly they move to get where they're going..
  6. I think you have to have hit it on the head. The full name of that power is "Redirects.Tanker Melee.Shinobi Skills". So the powerset name is, for some reason, "Tanker Melee". This is almost certainly a copy/paste mistake - the internal name is "Redirects.Blaster_Ninja_Training.Shinobi_Proc". As an aside, this is what happens if the game thinks you have powers from any powerset not marked as primary or secondary - a heading for the powerset name appears in the third, right-most column, where all your pools and temp powers and such go. If you have a "fruit salad" character with powersets that are normally impossible, they appear over there too. Which is sort of what's happening here.
  7. This. I have one of each. Solo, they kill about the same, though Scourge is obviously very nice for helping finish off foes already near-ish defeat. On a team, the Corr tends to shine more in combat since their damage doesn't trail off with team size. The Defender is noticeably more survivable, however.
  8. There doesn't seem to be a pet/NPC setting for this, so my guess is that it's hardcoded somewhere in the generic pet handling code as a way to ensure that ambulatory pets follow their summoners through elevators and similar doors, but has no distinction for static pets.
  9. No, it's plugged into the tohit formula. Basically, it counters 100 percentage points of defense.
  10. Quartz give DE +100% tohit bonus, so yeah, they basically cancel SR on their own. Suppression should not last for the duration of the effect - only for the period where you are actually mezzed. Can you test that in a more controlled environment, where there is nothing like Quartz around?
  11. Short version: yes, it was only intended to benefit actual stealth powers. Longer version: Stealth powers do things the IOs don't that powers like Reaction time can check for. As things stand now, such powers have no way to know you have a Stealth IO active.
  12. More search tweaks. I'm hoping this one is a big deal for heavy users of the site. The search box scrolls. You can use the cursor keys, the page up/down keys, a mouse wheel, or click on the scroll indicators at the top and bottom of the list. When the current search has no more data either up, down or both, the respective scroll indicators at the top or bottom darken and turn solid, to indicate you can't scroll further in that direction. I want to do some cleanup so that they disappear if the current search matches fit fully on screen, but that's a little complicated currently, so narrow search results will have rather glaring "you can't scroll this" indicators for now. Unfortunately, adding a scroll bar was beyond the scope of what I could easily achieve. I do believe it is possible (and have what I believe are relevant examples), and once/if I get that working, scrolling (via any input method) should be much more visually smooth. Plus, moving around the lists with the scroll bar will be much faster, though the page keys do currently work nicely. The search box now remembers two things it used to immediately forget if you touched its inputs It remembers the most recent selected search result. Previously, if you interacted with the search box, it would forget this, at least visually. This has an important meaning with the new scroll behavior - the most recently picked item is now used to anchor the drop down when you go to search. This is meant to facilitate poking around in the list near the most recent thing you looked at. The search box also remembers the most recent search input if you let the search box lose focus without picking anything. This way you don't have to re-type a long/complex search if you accidentally clicked off the search box or hit escape. These two combine - if you have something picked, then type a search but don't pick anything, when it loses focus the box will show the last thing you picked, but if you give it focus again, it will remember what you typed. Only when you actually pick something will what you typed will be cleared out. The search boxes at the top of various pages also now default to the object of that page. So if you navigate to Scrapper Siphon Life, as shown above, that power is already picked in the search box and the dropdown will be located at that power. Some caveats This works reasonably well on a desktop computer. Without a scroll bar, you can't do a lot with it on a mobile device. Arrow keys and page up/down keys, if you happen to have them on your soft keyboard*, do work, but otherwise you can't scroll, as far as I can tell. The up/down "bars" at the top of the bottom of the lists don't seem to honor mouse-like presses on a tablet the way they do an actual mouse on a PC. Because the search rows are not all the same height (because of the display of internal names on some rows), occasionally you get a row that's half visible. Scrolling one row will usually fix this, depending on what's visible, but because it only advances in "whole item" increments, certain combinations of visible entries just refuse to re-align until you get back to a place where everything is one row tall. Also, while I tried hard to squash these bugs, you may find that the highlighted item wanders out of the viewport. If you lose track of it, just click off the search area and back. Or just click / select something with the mouse / your finger. All the highlight selection bugs should be addressed fairly naturally once/if I get a scrollbar working. Edit: Just fixed a bug where scrolling with mouse wheel in the match list would also scroll the page itself if it had enough info visible to have a scroll bar. That's what I get for testing without the "raw data" icon checked. * For Android, "Hacker's Keyboard" offers arrow keys and, on the "Fn" page of keys, page up/down keys.
  13. Awesome. With that seeming to work well, I've updated the site to remember the new "search internal names" setting across pages and between visits. (As always, this setting is browser/browser-profile specific.)
  14. @Apparition, if you could give the above a whirl on iOS when you have a chance, I would much appreciate it.
  15. Some decent updates from the above list. Power and entity name searches now support explicit searches against "internal names" of powers and entities. The default is to search against display names. For example, the internal name of "Blaster Support.Devices" is "blaster_support.gadgets" Matches against the internal name are displayed with the internal name showing and the matched part highlighted. If a search string matches a mix of both display names and internal names, the display name matches are listed first, then the internal names. Matches are otherwise sorted by display name, even for matches against the internal name The internal matching checkbox is not yet persisted - you have to turn it on each time. I will add persistence, but wanted to get this out for wider testing. There is no meaningful benefit to searching internal names for boostsets, so the internal name search is not enabled there. The search box code got cleaned up and more "regular expression" features added. You can use "^" to indicate that something must be at the beginning of the string. "^Coun" will only match things like "Council...." and not "AnimusArcana.Counter Spell...." You can use "$" to indicate that something must be at the end of the string. "Blaster$" will only match things like "Epic.Mace Mastery.Summon Blaster" and not "Blaster Ranged..." You can use "|" to indicate "or" Including "^", "$", "|" or "*" signifies that your search string should be treated as regular expression-like. This changes parenthesis to be a match grouping operator, as in the example above. Without the parenthesis, the "or" would take precedence over the wildcard, and it would search for "(Council) or (5th*Kick)", which would give very different results. If your search doesn't contain the characters above, parenthesis are not special and just match in the name There aren't many display names with parenthesis in them, but there are some. If you need both regular expressions and to search for parenthesis in a name, you can use the backslash to "escape" your parenthesis to say they should be treated as literal strings and not grouping operators. All searches show highlighted match text. Previously only ones using a wildcard (*) would do so. All of this needs to go into the help. The search boxes are going to get their own help page.
  16. While working on the help, I either discovered new things I want to do with the site, or were reminded of issues / suggestions I still need to work on. So I actually have a decent little to-do list. In no particular order, this is what's on it now. Search result scrolling. This is a nice-to-have I may not be able to provide without a significant rewrite of the search box. I've never been satisfied with how results are limited and you can't scroll through matches. DONE! Allow regex-style anchors in search boxes. So things like "^" for "start of string" and "$" for "end of string". This would be particularly useful if I can't get the feature above working with reasonable performance. I need to make sure this has reasonable performance, as what I do now to support "*" in searches is already pretty expensive, but ensuring it only updates the search results every so often (instead of every time you type something) seems to work pretty well. DONE! Support internal power names on power searches. Entity search already works this way. DONE! Sort display name matches in search results before internal names. Most folks are going to be searching by display name, and right now the internal names sort first if they "win" alphabetically. DONE! Create pages listing all critters that share a power tag, like "Electronic" or "Undead" . Link to these pages from both entity and power pages. DONE! Create a "conversion simulator" that shows all the other sets you can convert a piece of a given set into, based on either its level or whether it's attuned. Break out data for set bonuses by attribmod and scale, to empower search/display for sets based on what bonuses they provide. Display more more boostset info in a table when viewing lists of boostsets from the Boostset Groups page. Max level the set exists at Lowest level the set's bonuses work at Lowest level at which you can slot the set (which is not always linked to the lowest level for bonuses) Check why there are no AT assignments for some power categories. At least some NPC power categories have no NPC ATs mapped to them, which is surprising to me. See why this is (not) happening in the Rust code. Clean up raw data files for compressed bundling and add download links
  17. 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
  18. 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.
  19. 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.)
  20. 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.
  21. 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.
  22. 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.
  23. 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.
  24. 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.
  25. 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.
×
×
  • Create New...