[Unexpected] [2.70.1] Active Drone cooldown increases after event is over

InvestigateXMInvestigateXM ✭✭✭✭✭

I noticed it the last few events, but I remembered to record it today. A few minutes ago, the Dronenet Weekend finished and the Drone cooldown returned from 10 minutes to 60 minutes. However, if you have moved the drone prior to the end, the cooldown increases once the event ended. In my example, I had 6 minutes left until the next move. Once the event ended, it was increased to 56 minutes. This feels very unexpected and seems inconsistent with portal cooldown as well. It would make more sense for the drone to keep the 6 minute cooldown and apply the normal one only after the next move.

Tagged:
8
8 votes

New Report · Last Updated

Comments

  • GargishGargish ✭✭✭

    Yeah, noticed this, too. Also, if you have the drone view running, the counter just continues to tick down to 0 instead of updating to the correct (higher) countdown value.

  • edited May 2021

    This is actually a valid implementation.

    If (Now.Add(-DroneCooldownMinutes) > LastHack) {
       AllowHack();
    };
    

    The fact that DroneCooldownMinutes changed doesn't invalidate the implementation.

  • If the distance for kinetic capsule does not shrink with the start of event (you'll get low-dist kinetic program only when started it during event), I think the same should be true for the drone


    Or, if we speak about some anomaly that reduced the cooldown time - then after the end of event the cooling time should not increase by adding 50 minutes, but increase by reverse multiplying to the same factor that reduced time during event (for example, 6 min remained cooldown should became 36 min (6*6), and 2 min -> 12 min)

  • If the distance for kinetic capsule does not shrink with the start of event (you'll get low-dist kinetic program only when started it during event), I think the same should be true for the drone

    That is a completely different mechanic. You're assuming that Niantic records when a drone "can be" used again. This would be a non-standard way of implementing a timer, because they have to record the time of the hack anyway so there's no good reason to record another future time instead of using that previous hack time.

    Kinetic Capsule settings are "locked in" when the program starts, and persist for the length of the walking, which is not time based at all. This is a valid implementation in the same way that people complaining that their 8km capsule doesn't suddenly jump to 2kms when an event starts.

    You can't have it both ways. When the event started, all the people who had hacked 10+ minutes before the start of the event, could hack with their drone immediately again because of this implementation. This is the better choice for the event, because it allows most people to start immediately.

  • ToxoplasmollyToxoplasmolly ✭✭✭✭✭

    You're doing that thing again where you argue for something based on what's convenient or laziest for the developers at Niantic, not what makes for the best player experience.

    • When you move the drone, record the current time and the calculated time for when it can move next, based on current conditions. Call that calculated time "X".
    • The next time there's reason to inquire as to how much time remains until the drone can be moved, take the time recorded for its previous move, and calculate the time for when it can move next, based on current conditions. Call this calculated time "Y".
    • Offer the player the earliest of "X" and "Y".
  • kittysukittysu ✭✭✭

    I think it is fine as is. It is also consistent with hack behaviour as heatsinks are added/removed from a portal.

    If you hack a portal, then another player adds a heatsink, the time between hacks is based on presence of a heatsink. If a portal with a heatsink is attacked and loses the heatsink after your hack, you have to wait the full 4 minutes.

    To me - the important thing is that you are not "penalised" by having to wait full hour at start of event and end of event - as long as you gain at least once, it doesn't matter which.

  • edited May 2021

    not what makes for the best player experience.

    When two options are equally valid, easy development works.

    You're arguing against the current implementation, but I guarantee you'd also be arguing against the opposite implementation because if someone used their drone then had to wait 59 minutes into the event before they could drone again, you'd be up in arms.

    You don't get to have your cake and eat it too.

    You're doing that thing again where you argue for magic with zero consistency except for "whatever I don't like change it".

  • ToxoplasmollyToxoplasmolly ✭✭✭✭✭

    You don't get to have your cake and eat it too.

    And why not? As if one drone move in slightly less time is much of a cake to begin with.

    You're arguing against the current implementation, but I guarantee you'd also be arguing against the opposite implementation

    Which is why I described a third implementation that addresses the "issues" with both of the ones that you seem so fixated on.

    Drones are magic, and internally inconsistent magic at that. There's not much of a backstory to Ingress right now, and it's not as if the one it had ever impacted the game in a way that people really cared about. Any ol' mumbo jumbo will do to justify the behavior I described.

  • Drones are magic

    As a software developer, when someone says "Magic" what they mean is "Do things like I want, while also adapting to how my mind changes at any given moment, and if it doesn't change to my mind regardless of the missing ESP module... it's broken".

Sign In or Register to comment.