Feature Request - sort keys by rechargeability

This could be as simple as, "Keys for portals your team owns that aren't fully charged go at the top." Something that simple would save me a lot of scrolling.

Tagged:

Comments

  • Sounds simple, but is actually very expensive to implement.

    All data from all portals you have a key from needs to be loaded before they could sort them.

  • TrerroTrerro ✭✭✭

    I'm pretty sure most people end up scrolling through their entire key list when recharging anyway, which means the data's getting processed and sent regardless. If the concern is that it might have to update in realtime to be sorted correctly (which would indeed hammer the DB server if a lot of people were doing it), I'd say have it run the sort -once- when you first click that sort, then have a refresh button, but give it a 5-10 minute cooldown.

  • IF someone scrolls through their key list entirely, that is a worst case scenario for the servers.

    If you want to sort by health or any of the other dynamic data, loading all data is the ONLY scenario, even if you don't update it afterwards.

  • TrerroTrerro ✭✭✭


    Speaking as a programmer, displaying a key list isn't programmatically much harder than displaying this forum thread, and in fact, the code is very similar - inner join 2 SQL tables, feed the results into a foreach loop (or a while loop if you prefer that style), each iteration of the loop displays one entry (a post block in this case, a portal status block in that case) - the sort is built into the SQL query, just give it an "order by" clause. In other words, tell the database server to dump all of the matching data to you, pre-sorted, then take each row of the results and apply them to the display code. Doing this -once- takes very little time, and even if it has to happen 2 million times/day (one per every player that remote-recharges things that day), you'd never notice the load, even though the key list involves one extra calculation (lat long from you to the portal, since it shows distance to portal on the readout). There are 86,400 minutes in a day, needing to run that code an average of 25x per minute is not a major load - your desktop could handle that effortlessly, to say nothing of an actual rack server that's specced for this sort of thing, and again that 25x/minute assumes 2 million people remotely recharge things every day, which is probably waaaaaay overestimating.

    Note: I'm assuming they've de-normalized resonator health into the primary portal table for the purpose of making this specific query faster, since it's a very common one that spits out a large amount of data. If it instead has to actually load the resonators, then they have to inner join 3 tables rather than 2, and the query will take longer... but it's still not going to stress a server rack.

    The danger isn't that everyone loads their whole key list daily, the danger is that if it has to rapidly refresh for 100k people all trying to recharge things at once, then it starts having to do that, not 2 million times per -day-, but 2 million times per -minute-. THAT's a concern. Doing it once per day per player is, unless the backend architecture of this game looks very, very different than I'm expecting it to, just not a big deal.

  • XQlusioNXQlusioN ✭✭✭✭✭
    edited June 2021

    No one is arguing with you that it is hard, it isn't... It's expensive.

    Each cloud provider charges for reads. Having to read 200 things instead of 20 is a major increase in costs.

  • ToxoplasmollyToxoplasmolly ✭✭✭✭✭

    Doing this -once- takes very little time

    As they might say on Wikipedia, "[citation needed]". Database engines are not magic. They're even less magical on industrial scale data sets. Indices are not a magic wand that suddenly make everything fast.

    The ever-present bugbear is IO latency with persistent storage, and a priori, you can't just wave your hand and go, "it'll all be cached in RAM, so who cares."

  • SSSputnikSSSputnik ✭✭✭✭✭
    edited June 2021

    So dribble dowload key data moment client opens. If its still downloading, grey the sort button.

    Combat in a portal dense area puts far more load on.

  • edited June 2021

    "As a programmer", you haven't noticed the lazy loading?

    They haven't de-normalized the resonator health into the primary portal table because the primary portal data used by keys is static data not current state. State data is loaded on demand as keys are viewed.

    Everything that is displayed that is static was loaded many cycles ago when the inventory was downloaded/updated.

  • TrerroTrerro ✭✭✭

    I think you're overestimating the actual size of the data set. A portal has a name, lat/long coords, 4 mods (which have a "which mod is it" number" and an id number of who deployed it (to observe the 2/agent limit). A resonator is portal id, slot, playerid, level of resonator, current health. This is a few hundred bytes per portal. Even if there's 10 million portals, that's a few GB. Each portal also has to save every agent ID that has ever hacked or capped it (for badge purposes)... but most agents have interacted with less than 1000 portals, so that's something like a single GB... for the entire portal network. With comm logs, recent battle data for damage report emails and such, anti-spoofing logs, etc, you can probably throw an x10 on there... but ignoring the images, it's probably less than a single terrabyte, and even with the images, you could probably cram all of the game's data into a desktop. Since the images are also more filesize than everything else combined by far and almost never change, you can also just slap those on a different machine.

    This isn't GMail, where a billion or so users each have thousands of emails that average a few K each WITHOUT even looking at attachments, and you need several warehouses just to store your DB, and hyper-optimized code for the whole thing to not grind to a halt. On THAT scale, I/O latency and efficency of all sorts of actions that you never normally care about becomes very important... but Ingress just isn't throwing that kind of data volume around.

  • You're still thinking of that all as one table and one call.

    It might blow your mind, but when you open your inventory, there are NO calls to the server for information. The GUID, name, location, image URL, and count of every key in your inventory has been retrieved long ago and is regularly updated.

    They don't even ask the server for a specific portal's status, until the key is shown on screen. Your whole argument is based around static and rapid dynamic data being stored in the same table. Something they've never done, and should not do if they have a clue.

  • ToxoplasmollyToxoplasmolly ✭✭✭✭✭

    At the end of the day, here's the thing: As I scroll through my portal keys, the addresses and photos might all be there, but I still must suffer the little "loading" spinner for seconds at a time as the resonator health for each new screenful of keys is loaded. That behavior by itself is enough to put doubts to your claim and understanding that loading all of the portals' health can be done in "very little time."

    Indeed, my interest in this feature is precisely because loading of portal health is so slow. If I could scroll through all my keys without having to wait for anything to load, I wouldn't need the ability to sort by health — I'd just quickly flip through them all be and done with it.

  • grendelwulfgrendelwulf ✭✭✭✭✭

    If loading and sorting keys by portal health was a things, could you imagine trying to do it during anomaly while you are on a recharge room?

  • It can't be any worse then linking, I just want something i can run every 3 days to maintain my anchors, NOT a feature to replace live defence.


    You could even mark keys to decay that would be ignored from the recharge queue.


    Basically what this feature would look like:


    Hit keys, recharge queue.


    The keys in your inventory are slowly polled 100 at a time, like what happened on redacted when you'd scroll through your inventory, except it's live filtering. The order at this point is locked and cached (with a cool down), so it doesn't need to poll constantly.

    You could choose to sort by either 'most recently modified' i.e. attacked, charged, decayed, or upgraded. Or by portal health.

    Only portals of your team colour would be returned.

    The obvious complaint is going to be recharge rooms / defensive recharging, but that's a balance issue already. Better to only let agents who are deployed, or organised have that luxury, IMO, and exclude it from this Recharge Queue for maintenance.

    Doing this should relieve most of the pressure and issues people have.

    If they really don't want to sort by something as dynamic as health or last modified, at least let us sort by team / level. That data should at least be more stable allowing better UX.

    If anything, the explicit cooldown and cache will *save* performance compared to the current situation, which causes agents to spend time, and refreshing portal status several times.

    If NIA are smart, they will be already caching recently modified portals, so I disagree that it'd be more expensive then linking or current recharging tactics.

  • starwortstarwort ✭✭✭✭✭

    It's a frequently asked feature.

    And what I always say when this comes up: before we add anything to the key sort menu, let's have alphabetical sorting by portal name. If that doesn't work, what makes you think they can sort it by any other criterion?

  • ZeroHecksGivenZeroHecksGiven ✭✭✭✭✭

    Would be nice to know how feasible this even is. Is this a, “never gonna happen,” type of request or a, “it could happen someday,” type of request?

Sign In or Register to comment.