Jump to content
daxmagex

Posting a Proper Script Bug Report

Recommended Posts

Posting a proper bug report for a script isn't very self-explanatory and is quite ambiguous for many users, thus resulting in many bug reports to look something like this:

  • “script not working. please fix”
  • “so many bugs”
  • “getting stuck”
  • "script very slow! plx fix"

 

Although it’s quite understandable to not know what information would be useful in a bug report (You would generally need to be quite fluent with computers or know a bit of programming), reports like these generally do not help the script writer debug the problem in most cases. (By most, I would say over 90% of the time)

 

Script writers usually run through a series of tests before releasing their scripts. If the script is released without the tag BETA or Development, it would generally mean that they have fixed all problems and are not experiencing any problems with the script. It would be hard helping you without any information since the script was fine the last time they have ran it and would not know where to start.

 

This tutorial will help you provide the script writer as much information as possible to fix an issue with the script.

 

Why follow this as a guideline? 

 

If you post a bug report without sufficient information, this is how it would go:

  • You post report and wait for me to reply
  • I receive report, look over it and find out I have insufficient information. I tell you to post more information and wait for you to reply
  • You post more information and I will need to look over it again

This can go on for days.

 

 

 

Proper Bug Report Format

 

Step 1: Copy and Pasting Client and Bot Debug

 

This can be found near the bottom edge of the Tribotclient. Press shift and click to selectively choose which lines to copy from. It would be preferred to copy both debugs completely and indicate to the script writer the time the problem have occurred (e.g 2:25:32). This is almost ALWAYS necessary. Even if the client or bot debug is spamming the same line over and over, the interval at which the line is being spammed may help the script writer know indicate where the problem may have occurred.

 

a8c6ef0799.png

 

Step 2: Screen Shot/GIF/Video

 

Depending on the issue, you can decide for yourself which is the most appropriate. Many script writers such as myself put the bot status on the paint which will tell us at which state is the problem occurring at.

 

Script writers know very well how their script works. What you see may not be what they see. I once had a user who refused a screenshot because he deemed it was useless because nothing was going on but proved to be a major part of what allowed me to debug the issue when he finally gave me a screenshot.

 

Step 3: Stack Trace

 

This is generally needed when a script is stuck. This will indicate exactly where the script is being stuck as and is very useful information.

 

It can be found here (Print Script Stack Trace): 

 

1c0b9f7e9e.png

 

It will look something like this once pressed (It will be visible in the Client Debug):

[02:51:28] Script Stack Trace:[02:51:28]  java.lang.Thread.sleep(Native Method)[02:51:28]  org.tribot.api.General.sleep(yh:170)[02:51:28]  scripts.daxHunter.utils.trap.Action$2.active(Action.java:44)[02:51:28]  org.tribot.api.Timing.waitCondition(ko:50)[02:51:28]  scripts.daxHunter.utils.trap.Retrieve.twoTickLaying(Retrieve.java:138)[02:51:28]  scripts.daxHunter.utils.trap.Retrieve.actionOnTrap(Retrieve.java:65)[02:51:28]  scripts.daxHunter.managers.BotManager.bot(BotManager.java:189)[02:51:28]  scripts.daxHunter.Main.run(Main.java:110)[02:51:28]  java.lang.Thread.run(Thread.java:745)

Step 4: Description of Problem

 

Giving detailed information on the issue is also a crucial part in allowing the script writer to debug your issue. You should indicate what causes the problem and how often the problem occurs.

 

Step 5: Your Settings

 

Provide the settings and modes which you have ran the bot in. In most cases, it would be screenshot of your settings in the GUI.

Edited by daxmagex
  • Like 16

Share this post


Link to post
Share on other sites

Where do i psot my bug reports? I think it's needed to help for you as a script writer(s) fix issues faster and easyer. Sinc i ask stuff on skype, and get repaly best case after 12-24 hours after asking i feel like i should post them on forums in correct section, so scripters will have to fix them and will feel more responsible for fixing it...

Share this post


Link to post
Share on other sites

Where do i psot my bug reports? I think it's needed to help for you as a script writer(s) fix issues faster and easyer. Sinc i ask stuff on skype, and get repaly best case after 12-24 hours after asking i feel like i should post them on forums in correct section, so scripters will have to fix them and will feel more responsible for fixing it...

 

Post them on the thread of the script

Share this post


Link to post
Share on other sites

The bug im encountering:

 

- it missclicks the tiles so it places the traps on the wrong spot, not a huge deal but this should work flawlessly imo.

 

- the escape from pkers doesnt work for me, it just keeps eating food standing on the same spot till it dies.

 

here is a picture of the debug:

 

 

 

GUI settings:

 

 

-snip-

Post it on his thread. :P

Edited by Flax
  • Like 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Our picks

    • This release will:

      Fix key event handling issue


      Fix other event handling issue


      Fix RSServer hook


      Update world hopper to have it use OCR, thanks to Todd


      Use proper disposal of old Graphics objects


      Reformat code


      Rearrange code


      Organize code imports


      Apply around 8000 automated code refactorings


      Make preparations for Java 9


      Fix 11 various bugs


      Add more reliable debugging support


      Fix mouseEntered/Exited event dispatching bug


      Fix minimap walking bug where it opens the map


      Fix broken hooks for today's game update
        • Thanks
        • Like
      • 55 replies
    • This update will:

      Fix GE inventory item positioning bug


      Fix broken object hooks
        • Like
      • 27 replies
    • This release will:

      Fix some ClosedChannelException bug


      Fix bug in RSObject#getAllTiles


      Add game tab support for "Kourend Favour"
        • Like
      • 15 replies
    • This release will:

      Fix Settings UI placement bug


      Fix game object location bug


      Fix small layout bug making the client shift up and down


      Fix client crashing bug where loading the client with a small display area will cause the client to crash


      Fix annoying Linux bug relating to painting events and peers


      Fix settings saving bug where settings are saved to disk more often than they should


      Fix RSInterface#isBeingDrawn bug affecting a limited amount of people


      Drop Java 1.7 bytecode version for 1.8


      Important: Since the downloadable RS client uses Java 7, it will no longer be compatible with Looking Glass. To make up for this, we will add support for using other clients such as RuneLite (at a later date).


      This change was necessary to allow us to use Java 8 syntax. It also paves the way for Java 9/10/11 support.
        • Like
      • 40 replies
    • This update will:

      Fix the RSMenuNode bug which also fixes the bug with bank opening


      Fix the incorrect object positions bug


      Fix and re-enable the LG Objects API Accelerator


      Fix the RSObject#getAllTiles bug
        • Like
      • 22 replies
  • Recently Browsing   0 members

    No registered users viewing this page.

×