Keys Sorting Suggestion
in General
Hello NIA,
Is it possible to create a new feature for Key sorting for the "amount" of keys, it would be make it easier to delete the unessesary keys.
There are now sort possibility for distance and Name. The third would be Amount of Keys.
What do you think about that idea?
Tagged:
6
Comments
there are lots of possibilities for sorting, in addition to what you suggest.
by level
by faction
by energy
by direction (AKA "by bearing", akin to "by distance", think the other component in polar coordinates, helpful for fanfielding)
by ownership (mine first, others after)
i'm sure other folks will add to this list...
Sorting by key amount should be easily doable.
It doesn't require any trips to the server to do so, unlike the options @GorillaSapiens suggested.
Don't confuse your expectation of implementation with what the devs may actually come up with.
It is possible to implement these with "one trip to the server".
One very expensive trip
well,. then, lets start keeping some images on the device, and then the server will only need to update the text part of the information. the server load would drop phenomenally!
s
Except that doing it in "one trip" would be laggy and expensive. Everything is "possible" but at scale some things become 'unwise'. The key differences is that dynamic data needs to be constantly retrieved, instead of pulling it once, caching it, and never talking to the server again. Sorting by static data only causes no additional transmission, so @KiNgSiZe2019's original idea is totally viable from a data point of view, unlike your suggestions, because the only person capable of changing the inventory count is the user, and we're already maintaining a running differential on inventory.
Sorting by city name could be useful, to delete or capsule the keys from a particular location.
City Name is difficult when it comes to grouping. Suburb or postcode/zipcode, sure, as that's part of the address, but if you want to group "cities" it becomes harder to determine where one city ends and another starts.
Not all.
"Bearing" is just as static as "distance"; it can be computed client side from current location and portal location. That said, portal location needed for distance isn't really "static", they can and do occasionally move. Ditto for Portal Name, those change occasionally too. Do you think the servers are sending distance each and every time the player moves? Or do you think it's smarter and they simply send location and let distance get computed client side? Bearing can be computed client side from location information.
Let's take sort by faction. The client already fetches this information when it displays the list, to know what color to make the bars. there is no reason it couldn't be used to sort client side.
What about energy? do you think the server side is sending "%full" for each resonator? that takes extra maths. why not send the Level and current energy for each reso, let the client do the maths.
The truth is you have no actual idea what gets transmitted, how the underlying databases are arranged, or how they could be arranged to make these things just as fast as what already exists.
In general, people with no understanding of the underlying implementation should NOT **** down ideas because they think it is "too expensive" computationally / resource wise. you have no understanding what it would actually take, or what optimizations could be brought into play if it does turn out to be expensive.
The thing is, when the key list is returned, data that is considered dynamic (like faction, resonators etc.) is loaded using something called "lazy loading". Only when the key gets into the view in the list does the client sent out the request for the actual dynamic data. This is why you can open the key lost, have it open for, say, 5 minutes, and then scroll down just to see it loading, because the scanner never made the request for that data in those 5 minutes. Location and Portal name is not 100% static, true, but with the new Lightship database, it is only changing once every 24 hours.
For the scanner to sort by faction/resonators etc., it would need to load all that data at once, which it just isn't doing at the moment to save costs. If you open the key menu just to look at one key, it would make no sense at all to load the status of 500 portals (with the addition to that: When the portal details are loaded in the key list, Ingress actually places the portal on the map. With 500 portals loaded in at once, it'll start lagging like crazy).
A compromise for the additional server load could be that sorting by dynamic data is only available for C.O.R.E. subscribers to offset the cost.
"city" is printed when you look at the portal view. If it's there, it can be had and sorted by.
Bearing is meh. I wouldn't worry if they implemented it, but it wouldn't be worth it, and would suffer from the same mix-ins as distance.
Let's take sort by faction. The client already fetches this information when it displays the list, to know what color to make the bars. there is no reason it couldn't be used to sort client side.
Except that it doesn't do it in bulk. It fetches a small number at a time, as you scroll the view. If you have 1000 keys in your inventory and open the first few, it might only request 6. Then you scroll and it gets another 6, and so on.
What about energy? do you think the server side is sending "%full" for each resonator? that takes extra maths. why not send the Level and current energy for each reso, let the client do the maths.
I know that it's sending the precise energy value for each reso, but again only for a small set, and only on request as you view them.
The truth is you have no actual idea what gets transmitted, how the underlying databases are arranged, or how they could be arranged to make these things just as fast as what already exists.
Most people who've been dealing with this for a long time do understand how they do this. Because they've told us parts of it over time, when bugs have come up.
As @InvestigateXM said, it's using "lazy loading". It's a concept where you only gather the parts that are needed, instead of long database queries that lock large amounts of a database at once. For the nosql style format that Niantic uses, this becomes even more significant, because the paging affects the performance of the game for everyone. If everyone is requesting the status of every key they have, every time they open their inventory, because otherwise their data would be stale, then there is a massive number of unnecessary requests by every user, just to sort the data. We've seen what happens when a lot of people in a given area all ask for the same data, when there's anomalies and the game grinds to a halt. Sorting by dynamic data, which requires regular refreshes to keep the data up to date, would make that far more common and worse.
"city" is printed when you look at the portal view. If it's there, it can be had and sorted by.
That's actually the suburb, in large cities. Which, as I said, is fine to sort by.
A compromise for the additional server load could be that sorting by dynamic data is only available for C.O.R.E. subscribers to offset the cost.
I honestly don't think the massive performance hit would be worth it and probably turn away more subscribers because of lag.
The location address on portals usually was a hardcoded Google Maps address. From my understanding, it's not a simple look at a city name because it's stored in the database as encrypted data.
Even with redacted, the sorting by portal key with energy was draining on the server. There's a reason why if you want to field, you put all of the c.rap keys in their own capsule. (and also why it guesses beyond 200 km)
(and also why it guesses beyond 200 km)
It's based on a timeout rather than a distance. It's just that by the time it gets past a few hundred kms in most cases, it's timed out. I've gotten solid locks on keys 1000kms away before.
So... what is your understanding of underlying implementation and 'costs' and how do you know so much more than everyone else here???
My little question escalated very quickly. .
The simple idea was only:
"Make it possible to sort my keys by amount.. nothing more. Like sorting by name and distance.."
It's essential for keymanagment.
If you have 600 different keys its dramatic to search the one with the highest amount you didnt need.
Thanks for all answers, but if you aren't working for Niantic it doesnt help a lot 🤷♂️
We can only suggest whether it's possible. Niantic won't tell you they're doing it until it's done.
i don't. but i'm not the one discrediting ideas by making unfounded claims on what is and is not "expensive".
The thing is, they arnt unfounded, most are quotes from this very forum... do you know how many queries are needed to get all your key numbers and how long that would take???
@Perringaiden you have probably bothered to check, can any of the iitc plugqins, sort the inventory list by number of items???
I’ve proposed this idea in the past, but I’d be okay with sorting by energy once every 12-24 hours or something. Another perk of being a CORE member perhaps.
Though, speaking of charging keys, I think I’d much rather have the ability to charge while in a key locker.
I wrote my own, which can sort keys by number, but that's not fit for general consumption. Too many "I'll get around to fixing that" bugs.
@KiNgSiZe2019 With a C.O.R.E. subscription, the Intel map has an option (upper left) labeled "Inventory". It even groups identical keys that are in different media. For example, if you have one XYZ key loose, and one in a key locker, and another in a capsule - it will say XYZ - 3.
Copy the Portal Keys section of your Inventory into your clipboard. I'm sure you can figure out how to get it into a spreadsheet. Then, sort by number.
Fix the latency first. One time it took almost 60 seconds before loading a key in a key locker. Mind you, this happened even with 5G Internet speed.
No, i don't know, and neither do you.
What i DO know is that nobody outside Niantic has the information you're asking for. Do you work for Niantic? I didn't think so.
I would love this feature too!!!!