For ingress there are only 3 individual data streams. Your inventory, your stats and comm. All the other game data about the portal network is not personal. Even clicking a portal detail will give every agent the same result.
I think the difficulty is in that.
That being said, I would love love love visual uniques both on the intel map and in scanner. I think that feature is an absolute fan favorite.
Absolutely this. PoGo has little significance in uniques, but has a clear indicator of what’s an unspun PokéStop. Ingress has a number of stats, badges and events based on uniques yet no official way to track your uniques.
This is an idea I had for a tracker, just some free space on the portal, the badge greyed out if not visited / capped / scout controlled, and coloured in teal if that action has been done.
If it can’t be done live, perhaps a sync every once in a while that updates some kind of indicator. It’s needed and very long overdue.
Real question... does every portal have a unique id?
If so, couldn't a copy of the visit and capture list be stored client side? If so, couldn't the list be checked and visual indicator be generated client side?
I'm not sure of the impact of that on local processing, lag or battery... just trying to think outside the box.
I agree that the visual indicator on the map as exists in PoGo should be the true goal. Niantic shouldn't compromise because this "is just Ingress" when they've set a clear standard of excellence.
so you want every client to have a copy of the portal list,,,, when is it resynced etc, remembering that every piece of data costs to store and transmit
By now, rough guess of maybe 9 million or more. You wouldn't need entries for every portal though. Only entries for things that are non-zero.
Couple of points on this though:
Every portal does have a unique ID.
There's no such thing as 'permanent user data' on a client install, except for authentication credentials. The "cache" on a phone is usually things like portal images and map backgrounds, and AFAIK even those are redownloaded regularly. So this data would have to be downloaded on handshake and regularly synced during a session (because players can and do use different devices).
To store a GUID + two flags table in memory for every portal that a player has visited would take about 2 MB of memory for anyone with Onyx Explorer. (And including transmission of that data each time you log in and syncs)
Again, the issue is not that it can't be done, but that it will take intentional development, and a lot of careful design to ensure that it doesn't significantly impact performance.
I realize that, I would think once the portal has been tapped on, you have now made a “call” for that data and it should be easier to present than on the map itself...
I think it is practical. If one has unique counters and hack a new portal, how is it checked client side? Adapt code implemented in PoGo to mark unhacked portals and profit.
I remember that, at first, PoGo didn't have unvisited stop mark.
I don’t disagree, but from everything I’m reading, it’s all but impossible. I’d rather have something than what we have now. Would the portal view option get us by for another 6-12 months? I’d like to think so
So, when the game loads all portals in sight, it could bring that 2 flagbits together, reducing downloaded data. When resyncing, it will keep refreshing all visible data. No need to keep GUID for all captured/hacked portals.
Disregard anything of "How" PoGo does it. The code base is completely different for the server (including different language and different database). PoGo conversion is really only adaptable for the client until they actually move to the Real World Platform (the PoGo server platform).
If you read Ofer2's comment, the data is currently stored in a hash with a user's ID. Therefore the first step of any change would be to take every single portal in the database, and hash each one with every single player in the database, to determine which portals a given player has actually captured and visited (and probably Scanned and Controlled).
So 9 million portals, by at least 3 million player accounts. That's 27 trillion combinations. And since it's a hash, you can't decrypt it. You can only go forward.
And this is only the work to get the current state into a readable form. That doesn't start to discuss formatting the data to be geographically retrievable at performance speeds.
The two flags could be stored against the portal's other data when it's retrieved yes. Note that the two flags are distinct. One flag would be a tri-state of None, Visited, Captured (since Captured includes visited) and the other would be Controlled (for Scout Controller). They can't be merged without being silly combinations.
If NIA could rerun the surveys about the subscription model, I for one would be ticking the “strongly agree” box if they include a question about being willing to pay for my uniques data
I'm not a programmer, but surely it can't be difficult to have it that when you open a portal, since it's already now needing to load the info, it can look at you badge info and say "this user has not hacked, make hack yellow, this user has not deployed on this before, make deploy yellow". At least at first, might not work on the actual map, but should be enough and easy to do.
Quick explainer on what @ofer2 said regarding the data storage. (Let me know if anything is off, Ofer2)
Process when you hack/deploy/upgrade on a portal:
Take the GUID of the portal.
Take the ID of the user.
Generate a hash string. This hash is 'one way' and 'destructive' meaning that there's no way to reverse the hash into it's component values. Once the hash is generated, you can never know what the two parts that went into it were, without attempting lots of combinations to find out which set generates the same result.
Check if the hash already appears in the multi-million entry table. This is optimised by indexes and database process, but it's still "Does this random looking string appear in the database".
If it does not, add it to the table, and increment a counter against the user's account for unique Visits or Captures.
None of this allows you to say "Who has hacked this portal?" or "Tell me all the portals this user has hacked". Converting the data is possible but both would take development time to implement and take processing time that has to be paid for by the processing unit, to Google.
If you can tell me what user and portal the string 'X23JKKSELC23KSKEWCKK2SSQAWEDW' refers to, I have a quantum processing development team who'd like to look inside your head. Ofer's explanation makes it clear to anyone understanding it, why the data isn't available right now, and why there's a heavy processing load to convert the data, let alone develop a new recording and retrieval system to allow it to be used geographically.
If you were willing to allow them to wipe all existing Uniques and start over, it'd be quicker and cheaper development. I doubt that you could find player support for that idea though.
Should the conversion be done? Yes. Should it be a priority? Almost every player says yes.
Comments
For ingress there are only 3 individual data streams. Your inventory, your stats and comm. All the other game data about the portal network is not personal. Even clicking a portal detail will give every agent the same result.
I think the difficulty is in that.
That being said, I would love love love visual uniques both on the intel map and in scanner. I think that feature is an absolute fan favorite.
The markers arnt the issue,, the retrieving the status of said marker is...
Absolutely this. PoGo has little significance in uniques, but has a clear indicator of what’s an unspun PokéStop. Ingress has a number of stats, badges and events based on uniques yet no official way to track your uniques.
This is an idea I had for a tracker, just some free space on the portal, the badge greyed out if not visited / capped / scout controlled, and coloured in teal if that action has been done.
If it can’t be done live, perhaps a sync every once in a while that updates some kind of indicator. It’s needed and very long overdue.
Great idea, I iked it👏🏻👏🏻👏🏻👏🏻
Question, how often and how many portals would client query.......?
Impressed by the badge overlay idea,,,
Muito bom isso seria ideal no jogo!!!
Real question... does every portal have a unique id?
If so, couldn't a copy of the visit and capture list be stored client side? If so, couldn't the list be checked and visual indicator be generated client side?
I'm not sure of the impact of that on local processing, lag or battery... just trying to think outside the box.
I agree that the visual indicator on the map as exists in PoGo should be the true goal. Niantic shouldn't compromise because this "is just Ingress" when they've set a clear standard of excellence.
Hack everything. Cap everything. Problem solved.
I can't understand the difficulty of doing this, it seems to me how to turn on a key.
Tell me Niantic, for why not?
so you want every client to have a copy of the portal list,,,, when is it resynced etc, remembering that every piece of data costs to store and transmit
@Perringaiden how many portals are there?
By now, rough guess of maybe 9 million or more. You wouldn't need entries for every portal though. Only entries for things that are non-zero.
Couple of points on this though:
Again, the issue is not that it can't be done, but that it will take intentional development, and a lot of careful design to ensure that it doesn't significantly impact performance.
I realize that, I would think once the portal has been tapped on, you have now made a “call” for that data and it should be easier to present than on the map itself...
I think it is practical. If one has unique counters and hack a new portal, how is it checked client side? Adapt code implemented in PoGo to mark unhacked portals and profit.
I remember that, at first, PoGo didn't have unvisited stop mark.
I don’t disagree, but from everything I’m reading, it’s all but impossible. I’d rather have something than what we have now. Would the portal view option get us by for another 6-12 months? I’d like to think so
About #3:
So, when the game loads all portals in sight, it could bring that 2 flagbits together, reducing downloaded data. When resyncing, it will keep refreshing all visible data. No need to keep GUID for all captured/hacked portals.
Edit: well, this is like said in #2.
Again,, the data isn't visable in a way the client cant see it.....
Pogo relies and an entirely different backend with data that is easierly accessible without extraneous and costly data requests....
Disregard anything of "How" PoGo does it. The code base is completely different for the server (including different language and different database). PoGo conversion is really only adaptable for the client until they actually move to the Real World Platform (the PoGo server platform).
If you read Ofer2's comment, the data is currently stored in a hash with a user's ID. Therefore the first step of any change would be to take every single portal in the database, and hash each one with every single player in the database, to determine which portals a given player has actually captured and visited (and probably Scanned and Controlled).
So 9 million portals, by at least 3 million player accounts. That's 27 trillion combinations. And since it's a hash, you can't decrypt it. You can only go forward.
And this is only the work to get the current state into a readable form. That doesn't start to discuss formatting the data to be geographically retrievable at performance speeds.
it's really disheartening, everybody thinks it's cool, but everybody saying "this is impossible". waiting a response from the Niantic team.
Don't saying "this is impossible"
No-one is saying it's impossible.
But it's also not "turn on a key" by any stretch of the imagination. It requires them to commit development time to it.
The two flags could be stored against the portal's other data when it's retrieved yes. Note that the two flags are distinct. One flag would be a tri-state of None, Visited, Captured (since Captured includes visited) and the other would be Controlled (for Scout Controller). They can't be merged without being silly combinations.
If NIA could rerun the surveys about the subscription model, I for one would be ticking the “strongly agree” box if they include a question about being willing to pay for my uniques data
Lets say that:
So it is not impossible. It only depends if Niantic wants to implement. Or it is in development roadmap.
And just to justify: scout controller inexisted at first in Prime. And now there a lot data related to it. Just give development enough time.
Development is split between new features and bugs. And I don't think anyone wants to keep the bugs.
I'm not a programmer, but surely it can't be difficult to have it that when you open a portal, since it's already now needing to load the info, it can look at you badge info and say "this user has not hacked, make hack yellow, this user has not deployed on this before, make deploy yellow". At least at first, might not work on the actual map, but should be enough and easy to do.
I think the same thing
@gazel2
surely it can't be difficult
You'd be surprised. Especially when you're taking someone else's 10 year old code never designed for the purpose it's being asked of it.
since it's already now needing to load the info,
It is not doing this.
@gazzas89 @Bivoltz and you're both wrong. Please carefully follow what Perringaiden writes you and take a look on a comment he linked, from the person who knows how exactly this is implemented, instead of speculating. For your convenience I copy the link: https://community.ingress.com/en/discussion/comment/126507/#Comment_126507
Quick explainer on what @ofer2 said regarding the data storage. (Let me know if anything is off, Ofer2)
Process when you hack/deploy/upgrade on a portal:
None of this allows you to say "Who has hacked this portal?" or "Tell me all the portals this user has hacked". Converting the data is possible but both would take development time to implement and take processing time that has to be paid for by the processing unit, to Google.
If you can tell me what user and portal the string 'X23JKKSELC23KSKEWCKK2SSQAWEDW' refers to, I have a quantum processing development team who'd like to look inside your head. Ofer's explanation makes it clear to anyone understanding it, why the data isn't available right now, and why there's a heavy processing load to convert the data, let alone develop a new recording and retrieval system to allow it to be used geographically.
If you were willing to allow them to wipe all existing Uniques and start over, it'd be quicker and cheaper development. I doubt that you could find player support for that idea though.
Should the conversion be done? Yes. Should it be a priority? Almost every player says yes.
Is it easy? Not a chance.