Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
IceKontroI

[SUGGESTION] Script rating feature (pros & cons)

Recommended Posts

This suggestion thread is to entertain the idea of adding a user rating system to associated TRiBot scripts. Here's the implementation of such a system. Once a script is stopped, if it's a public repository script, a dialog box appears asking the user to rate their script experience with either a thumb up or down. Ratings are timestamped and repository search results can now be filtered by average user rating, with an option to only use ratings from the past {day, week, month, year}. Below are any pros and cons worth mentioning that I (or anyone in the comments) can think of. I will also propose solutions to any cons since I know that's what people will tend to focus on.

@TRiLeZ @Todd @Usa

Pros

  • Provides a single unified way to score repository scripts which we currently do not have.
    • Current ways of rating a script are:
      1. Scripter's reputation: not super accurate, only works for popular scripters.
      2. Posts on the script's thread: tedious to read through many recent posts.
      3. User testimonials: anecdotal and typically not representative of the overall experience.
  • It will now be significantly easier for new and experienced users to choose scripts from the Repository.
  • Script writers now have a way to gauge customer satisfaction. This will lead to:
    • More appropriate pricing for scripts.
    • Better script update/patch focus from the scripter.
  • Another reason to choose TRiBot over other clients that do not have a system like this.

Cons

  • Users can repeatedly start then stop the script in order to gain access to another rating.
    • Solved by only allowing a TRiBot user to rate the same script once every 12 hours of real time.
  • Users new to a script that can't figure out how to use it in the first 5 minutes of use will rate it poorly.
    • Solved by preventing users from rating a script until they've run it for at least 6 hours of script runtime (excluding pauses and breaks).
  • User bans will influence user ratings. Keep in mind that bans are a part of the user experience, which is what the rating system aims to measure.
    • High banrate scripts will get lower ratings because of:
      • User error: poor botting practices leads to users blaming the script.
        • This is a universal constant and applies equally to all scripts, so it doesn't affect the comparison process.
      • Overall OSRS botting banrate: another universal constant.
      • Method-specific banrate: some botting methods are more closely monitored than others leading to an unfair rating due to bans.
        • When users compare scripts of the same method, this will be a constant across all those scripts, so it makes no difference.
        • When users compare scripts with diverse methods, the rating they see will not reflect the true rating of the script.
          • This means users will gravitate to lower banrate scripts, which isn't objectively fair, but will improve overall TRiBot user experience.
      • Script-specific banrate: scripts with poor antiban or botlike patterns will be rated worse than others.
        • Good, that's actually the way it should be.
  • Scripters that choose to write scripts for high banrate skills will be seen as worse scripters than they really are. There are two options here:
    1. Simply avoid the methods that are known to have higher banrates.
      • Unfortunately doesn't apply to existing scripts.
    2. Work hard to develop a stringer antiban implementation for the scripts that need it. If you do this properly:
      • Your script will stand out as the only good one in a category of otherwise poorly rated scripts.
      • You will gain nearly all the market share for that category.
      • You can now charge more for the script since the only other options are poorly rated ones.
      • You'll drive innovation in the field of antiban if you are successful here.
  • The implementation of a system like this will take lots of time and resources.
    • It is what it is. A rating system like this will improve TRiBot significantly, but it doesn't come without costs.

Overall, it's not a perfect system, but there are workarounds to many of the issues that do come up. If you can think of any more pros and cons, or better solutions to existing cons, please post them and I'll update the OP. Overall, to me, it seems like the benefits outweigh the disadvantages, most of which are either minimal when you analyze them, or have simple solutions. In the end, the Repository does need some revitalization, and this would significantly improve it and the TRiBot user experience.

Edited by IceKontroI
  • Like 2

Share this post


Link to post
Share on other sites

I used to think a system like this would be great, but bans would play too great a role in rating scripts. The rating should be solely on the script quality. A high quality script can still receive a large amount of bans due to other factors, yet it would still receive a low rating in this system. Unfortunately I don't think there is a way to make a script rating system where bans don't play a part in the rating (implicitly or explicitly).

Share this post


Link to post
Share on other sites
16 minutes ago, HeyImJamie said:

I still vote no to this. I can see it being useful, but other clients have similar and all it's used for is a way for botters to spite the scripter when their account inevitably gets banned.

2 minutes ago, Naton said:

I used to think a system like this would be great, but bans would play too great a role in rating scripts. The rating should be solely on the script quality. A high quality script can still receive a large amount of bans due to other factors, yet it would still receive a low rating in this system. Unfortunately I don't think there is a way to make a script rating system where bans don't play a part in the rating (implicitly or explicitly).

A system like this needs to consider bans in order to objectively capture the user experience sentiment. Is it in the scripter's best interests from a financial gain perspective? Not at all. You two are both premium scripters, so your posts quoted above present a conflict of interest for the new system.

Share this post


Link to post
Share on other sites
27 minutes ago, IceKontroI said:

A system like this needs to consider bans in order to objectively capture the user experience sentiment. Is it in the scripter's best interests from a financial gain perspective? Not at all. You two are both premium scripters, so your posts quoted above present a conflict of interest for the new system.

I don't agree with that view. It could hurt a scripter's income just as much as it could increase it.

Share this post


Link to post
Share on other sites
13 minutes ago, Naton said:

I don't agree with that view. It could hurt a scripter's income just as much as it could increase it.

I agree with you. Overall it will reward scripts that offer a positive user experience, while punishing those that do the opposite.

You said the rating should be solely based on script quality, which would be perfectly fair if scripts all had the same banrate across the board. This isn't the case, and the element of banrate shouldn't be ignored; it's arguably a more important factor to the users than how much GP/EXP the script earns per hour. Rating a script by a combination of its writing quality and banrate encourages not only high quality scripts, but also scripts that use safer methods. That's a good thing for users, which means a bigger user-base, which in turn means more customers for scripters.

Share this post


Link to post
Share on other sites

Throughout the years I've probably gotten 5 times as many users leave feedback about being banned than those who leave positive feedback about their results and I'd like to think that I am one of the better scripters here. So even though my scripts are well respected, I would have an overall negative or low score assuming the verbal feedback I already have gotten were to be translated to a rating system.

Also the fact that you were able to go more in depth about the cons vs the pros just shows this is not a good idea.

Maybe instead of a rating system, just an overall feedback system with predefined responses.

Edited by Encoded

Share this post


Link to post
Share on other sites
7 minutes ago, Encoded said:

Throughout the years I've probably gotten 5 times as many users leave feedback about being banned than those who leave positive feedback about their results.

It's a lot simpler to click a thumbs up/down icon on a dialog box that pops up automatically than it is to open browser -> go to tribot.org/forums -> find the thread -> type and submit a post. This means you need to be motivated to actually go through the current lengthy feedback process, and nothing motivates a tribot botter more than getting banned. Rating systems are shifting towards a simpler format (youtube going from 5 star system to like/distlike system) because simpler formats produce more unbiased feedback.

I'm not saying people will never leave unwarranted bad feedback, but that it's going to be nowhere near as bad as people seem to think it'll be.

Edited by IceKontroI

Share this post


Link to post
Share on other sites

I might implement this into my scripts as a trial run just to see what the results would be.

However my implementation will be different from what you described.
I will only open the dialogue after the user has logged 100 hours (subject to change) with the script and the user will only be able to have 1 rating.

Share this post


Link to post
Share on other sites
2 hours ago, Encoded said:

I might implement this into my scripts as a trial run just to see what the results would be.

However my implementation will be different from what you described.
I will only open the dialogue after the user has logged 100 hours (subject to change) with the script and the user will only be able to have 1 rating.

I would be interested in the results. Please make a thread about it if you do end up going through with that idea.

Share this post


Link to post
Share on other sites
3 hours ago, Encoded said:

I might implement this into my scripts as a trial run just to see what the results would be.

However my implementation will be different from what you described.
I will only open the dialogue after the user has logged 100 hours (subject to change) with the script and the user will only be able to have 1 rating.

100 hours logged weeds out the clueless botters so you don't have to worry about their inability to use/understand the script's setup properly affecting the rating score. This is a pretty smart way to get a more accurate rating. 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Our picks

    • This update features:

      Fixed broken hooks from today's update


      Fix wilderness level with RuneLite (Thanks @Todd)


      Add support for Kotlin .class files in scripts (Thanks @wastedbro)


      Overhaul Inventory API (Thanks @wastedbro)


      Add List support for common methods


      Change method grouping to make more sense (by functionality)


      Refactor methods to utilize Java 8 streams instead of cumbersome loops




      Recognize chatbox minimization (Thanks @JoeDezzy1)


      Fix Screen#isInViewport when NPC chat is open (Thanks @JoeDezzy1)


      Fix login bot bugs (Thanks @erickho123)


      Fix hint arrow return values (Thanks @Encoded)


      Fix depositAllExcept functionality (Thanks @wastedbro)


      Change containing box interface bound and adjust for Y values (Thanks @erickho123)
        • Like
      • 150 replies
    • This release will:

      Fix prayers and world hopper API (Thanks @JoeDezzy1 and @erickho123)


      Improve banking API (Thanks @Encoded)


      Adds methods for returning and using Java Lists, rather than arrays


      Slightly randomizes some hardcoded behaviour


      Removes sleeps from waitConditions; the efficiency saving potential is negligible in these use-cases, therefore cleaner code is preferable


      Other back-end improvements





      Note: If you are using LG, please restart both the RS client and TRiBot.
        • Sad
        • Haha
        • Thanks
        • Like
      • 90 replies
    • This release will:

      Add new internal framework for capturing exceptions


      Fix issue with not selecting the last column in world hopper (Thanks @Todd)


      Add a message about pin usage in Banking#openBank (Thanks @Todd)


      Disable the firewall by default (Thanks @Todd)


      Fix handling of the welcome screen after login (Thanks @Encoded)


      Fix wrong amount bank withdrawal (Thanks @Encoded)


      Fix Screen#isInViewport


      Fix Game#isInViewport (Thanks @Encoded)


      Call onBreakEnd for ListenerManager Breaking Listeners (Thanks @Encoded)


      Fix Prayer#getPrayerPoints NumberFormatException (Thanks @JoeDezzy1)



      Note: If you are using LG, please restart both the RS client and TRiBot.
        • Thanks
        • Like
      • 28 replies
    • This release will:

      Fix LG for both OSBuddy and RuneLite


      Fix issue where the resizable client isn't able to be made smaller (Thanks @JoeDezzy1)


      Fix detection of the logout game tab when resizable mode and side panels are enabled (Thanks @JoeDezzy1)


      Add initial support for Sentry to allow us to identify and easily debug exceptions happening with all TRiBot users


      Add methods to determine if the bank is actually loaded, and not just the overarching interface (Thanks @wastedbro)



      Upcoming updates:

      Improved CLI support


      Full Sentry support


      Much more
        • Like
      • 64 replies
    • This release will:

      Fix NPE in Camera API (Thanks @wastedbro)


      Update deposit box interface ids (Thanks @Encoded)


      Add various bank methods (Thanks @wastedbro)


      Banking#getWithdrawXQuantity


      Banking#getDefaultWithdrawQuantity


      Banking#arePlaceholdersOn




      Fix resizeable minimap bug (Thanks @wastedbro)


      Remove Java 8 requirement


      Please note: TRiBot is not yet fully compatible with Java 10+




      Fix the break handler issues by ensuring the break handler thread never gets paused


      Fix broken settings hooks



      Upcoming updates:

      Improved CLI support


      Much more



      Note: If you are using LG, please restart both the RS client and TRiBot
        • Like
      • 68 replies
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...