NIA tried to reinstate a spoofed down portal… But they set it to the wrong faction.

Not only this, they put the Enlightened agents name who owned it as the owner of the portal… But they set it to Resistance. What even happened and how do we get it fixed?


Comments

  • GrogyanGrogyan ✭✭✭✭✭

    Report it to support, so they can fix it

  • GoblinGranateGoblinGranate ✭✭✭✭✭

    If they automated the restoring process none of this would happen.

    But no, they insist in doing this manually.

  • AzhreiaAzhreia ✭✭✭✭✭
    edited June 4

    Hi there, this was my mistake in logging the reset. The correction has already been logged and should hopefully run today.

    Post edited by Azhreia on
  • 1valdis1valdis ✭✭✭✭✭

    You know it's possible to implement. I'd even go as far as saying that portal/link/field state history implementation would take LESS time than you have all combined spent on doing it manually.

  • That sounds like an extremely-enormous-gigantic amount of data to store for every change in the playfield around the globe.

  • HosetteHosette ✭✭✭✭✭

    @MatiasM20 It would be, yes. However, it's not necessary. My experience is that the vast majority of portals that get spoofed down are long-standing ones, measured in weeks or months. I'm willing to bet that keeping a once-per-day snapshot of portal and link state going back two weeks would suffice for 90% or more of the restorations.

  • AzhreiaAzhreia ✭✭✭✭✭

    This has now been corrected and the portal restored to the agent under the right faction. He's no longer partial-RES ;P

  • AzhreiaAzhreia ✭✭✭✭✭

    That might not work either... considering that most of these portals get spoofed once they have a BAF attached, and the bi-weekly update may not have captured that.

    So portal stands for months... no links. Last snapshot was a week ago. Today, the community BAFs, using that portal as an anchor. It gets spoofed just before checkpoint, and all the links are lost. Spoofer reported, banned, portal restored to the point it was at a week ago. No links.

  • HosetteHosette ✭✭✭✭✭

    @Azhreia Ah, my apologies. I was unclear. I was suggesting a once-daily snapshot and keeping two weeks of one-day history. It might not catch links but it would in some cases. You're closer to it than I am but I suspect that it would provide the portal restoration info for any portals that weren't built specifically for the field. It wouldn't be perfect but it's better than having players say, "It was a P7 and I think there were two R8s owned by Alice, Bob, and Charlie and I think there were two rare shields and a VRMH..."

    Niantic has two weeks of comm history so they could in theory use that to restore the links.

    Developing tooling to keep and retrieve this information seems like a summer intern project to me.

  • AzhreiaAzhreia ✭✭✭✭✭

    I don't think the comm log is stored in any usable format for them to easily query. We've asked before if we could just get comm logs for a specific event instead of having to search for it ourselves.

  • LuoboTiXLuoboTiX ✭✭✭
    edited June 6

    Even if they do not have historical data, this still could be done automatically.

    When do you/we restore a portal? That's when a spoofing was detected and confirmed by NIA OPS.

    How do you/we restore a portal? By referring to what's suggested by the players who reported the spoofing in terms of "what was state of the portal before it's spoofed down".

    Then why not making it automatically? How about offering a form for reporters to fill in the state in advance. As long as NIA OPS confirmed the spoofing then a process would be triggered to the the restoration. No need for you to intervene unless reporters see something wrong and ask for a fix.

    Well, it saves your Vanguard's efforts but not other players. If you and other Vanguards feel OK with current process then definitely no need to make it automatic.

  • AzhreiaAzhreia ✭✭✭✭✭

    Quite frankly, without having some sort of verification on the state of the portal before spoof, that will be quite quickly abused. And also, not every portal qualifies for reset. Urban portals change hands too fast, and the gameboard is in constant flux. A reset has a very good chance of overwriting legit actions.

    Logging resets is not easy. Mistakes happen. I have been doing resets since the VG program started and I still make the occasional mistake. To leave that in the hands of the average agent to supply the correct information is asking for more mistakes, compounded frustrations and endless corrective runs.

    Until Niantic can effectively store portal states with all the necessary information, it cannot be automated.

  • edited June 11

    If it’s too much data, why not only store the data of portals likely to be targeted, maybe with some rules about cell service, long links or huge fields, inaccessibility, etc. I can only think of around 50 portals in our cell or affecting our cell that would qualify.

  • SSSputnikSSSputnik ✭✭✭✭✭
    edited June 11

    You could store diff history.. like file system snapshots

  • HosetteHosette ✭✭✭✭✭
    edited June 11

    @Ryaninator81st My principles for identifying "high-value" portals:

    • Proximity to other clusters of portals
    • Average length of links to/from the portal
    • Average size of fields anchored on a portal
    • Frequency of portal access

    Something frequently accessed should never qualify for a reset. Beyond that, those four variables can be used to calculate a portal value score that can be used to prioritize anti-spoofing activities. Note that this relies only on information that is easily available to Niantic (the location of portals and the amount of player activity) and doesn't need any external information about accessibility or signals.

    (This is from something I wrote five years ago, BTW.)

Sign In or Register to comment.