Request Make Handlers toggle-able via Client Preferences

Discussion in 'Client & Site Suggestions' started by Party, Aug 10, 2016.

  1. The various handlers (login, unexpecteditem, bankpin, NPCdismisser) should all be toggle-able via the client preferences. They should be over-ridden by whatever is within the bot code.

    This has been pretty much standard practice on the RS botting scene for as long as I can remember, with various handlers toggle-able from buttons on the client without even having to go via a preference menu.

    This makes so much more sense from a design point of view than the current implementation, which would require every bot to have the toggle-switch for each handler. It would also open a range of options for the end-user.

    @Arbiter I know you're the UI dude.
    Seathe and SuperBotter like this.
  2. No. Users are dumb. They will disable things they shouldn't and then blame the resulting issues on the client. There is no use case that has been presented to me that is better handled by the user than the Bot Author. I encourage you to make that statement wrong. :)
  3. - Creates more randomisation; one will not dismiss NPC, others will.
    - Certain items in the unexpected item handler are to some people collectables (think of the golden statue pieces in Prif), why would you automatically destroy them?
    - Login handler being disabled might be a lot safer for people, imagine a bot getting stuck, and then it comes in to a login/logout loop.
    - If you automatically set the values to what they are now, and don't make them easily clickable (don't put them on the front screen of Spectre) users shouldn't be able to missclick and automatically toggle a button they didn't want to toggle.

    Just adding on to @Party 's statement, I think it would be quite useful as well.
    Seathe likes this.
  4. Unexpected Item Handler. Some items (the sliske pieces for example) are too frequent and bankable, destroying them wastes time and xp and they don't interfere with most bots.

    Bertrand beat me to it, but he makes additional valid points too.
    Seathe and Bertrand like this.
  5. That sort of randomization adds a single bit of entropy. It is not enough to be significant, considering how much entropy we already introduce into the automation.

    Regardless of how "collectible" an item is, if it results in a bot bugging out and potentially getting banned then we should always destroy it.

    Staying logged out after a forced logout is a very easy heuristic for Jagex to use to ban bots. Bots that get stuck should not exist. If they do they should be fixed immediately or promptly deleted.

    I'm not worried about misclicks. I'm worried about users not knowing what's best for them.
    --- Double Post Merged, Aug 12, 2016, Original Post Date: Aug 12, 2016 ---
    If a bot is not affected by unexpected items then it is the Bot Author's responsibility to disable the handler. It is a condition that is on a per-bot basis, not a per-user basis.
  6. - What qualifies as an item that bugs out a bot? Basically all items are bankable, just not dropable (They use the "Destroy" interaction).
    - It's not a forced logout, but a timeout logout. So logging out because of AFK seems like a legit action, opposed to directly logging in (which DOES indicate bot behavior. Why would you AFK x minutes, log out and then immediately log in?)
    - Fair point, end users aren't the brightest. Nonetheless I think the pro's outweigh the cons.
  7. Unexpected items can fill up an inventory and mess up the logic of bots that don't consider that condition. If that condition either does not apply to your bot or would not cause an issue, we highly recommend you disable the handler.

    I added some notes regarding LoginHandler above after you posted. Additionally, forced logouts can happen for a number of reasons, including networking issues.

    I disagree. I see no pros that can't already be implemented responsibly by Bot Authors, who are expected to be more intelligent than the general masses.
  8. what about the addition of a breakhandler on the client
    --- Double Post Merged, Aug 12, 2016, Original Post Date: Aug 12, 2016 ---
    for example i want a bot to only run an x amount of hours
  9. Break-handler is a big one for breaking a lot of bots. That said, a simple bot.getBreakHandler().setDisable(true) would be naise.

Share This Page