Search the Community
Showing results for tags 'Debugging'.
Found 2 results
This tutorial will teach you how to use an IDEs debugging to utilize break points to debug your TRiBot scripts. This tutorial will only show how to do it with Intellij, but that same thing should apply to other IDEs. Setting up Intellij to run TRiBot 1. We must set up the project dependencies. You can get here by using Ctrl+Alt+Shift+S or going to File -> Project Structure Once you are here, click on Modules and select the dependencies tab. Debugging Tribot requires you add the following files to your dependencies. To add a dependency, click on the green + next to Scope and click JARs or directories. tools.jar You can find this in your jdk directory. Example: C:\Program Files (x86)\Java\jdk1.8.0_101\lib substance.jar You can find this in your %AppData% Tribot location. Example: C:\Users\Your User\AppData\Romaing\.tribot\dependancies trident.jar You can find this in your %AppData% Tribot location. Example: C:\Users\Your User\AppData\Romaing\.tribot\dependancies bin You can find this in your %AppData% Tribot location. Example: C:\Users\Your User\AppData\Romaing\.tribot\bin 2. We must setup a new Run/Debug Configuration. You can get here by going to Run -> Edit configurations Once you are here, create a new Application configuration by clicking on the green + and clicking Application. The new configuration will be created and we must edit the settings now. I named my configuration Tribot. Main class: org.tribot.TRiBot VM options: -Xmx386m -Xss2m -Dsun.java2d.noddraw=true -XX:CompileThreshold=1500 -Xincgc -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -Xbootclasspath/p:"C:\Users\Spencer\AppData\Roaming\.tribot\dependancies\xboot860.jar" -classpath "C:\Program Files (x86)\Java\jdk1.8.0_101\lib\tools.jar";"C:\Users\Spencer\AppData\Roaming\.tribot\bin";"C:\Users\Spencer\AppData\Roaming\.tribot\dependancies\substance.jar";"C:\Users\Spencer\AppData\Roaming\.tribot\dependancies\trident.jar";"C:\Users\Spencer\AppData\Roaming\.tribot\dependancies\TRiBot.jar"; Make sure to switch out the directories to what they are on your computer. Program arguments: TRIBOTSESSIONID MEM384 OLDSCHOOL Replace TRIBOTSESSIONID with your session id. You can find this in %AppData%\.tribot\settings\startup.ini PLEASE NOTE: if your session id does not start with SID, add it to it. Example: ccaa-das9fg87ad9fg7a98df7ga98df7g2aead32kjhhj13k You should place: SIDccaa-das9fg87ad9fg7a98df7ga98df7g2aead32kjhhj13k Hit apply and you are ready to go. Using breakpoints to debug your script. Breakpoints are extremely useful for debugging your program. They allow you to stop the program during runtime and see what is happening. Lets use this simple script as an example. I'm having an issue. Even though I'm near the Oak Trees my script is not clicking the Cut option. We can debug this by adding a break point and stepping through the script. To add a breakpoint, you click on the empty area next to the line numbers which will place a red circle. This red circle is a break point. While debugging, any time your script hits said circle, the script will stop and you will be able to interact with it. Now that I have a break point setup, its time to debug it. We can launch the TRiBot client by going to the Run menu and clicking Run -> Debug 'Tribot'. If this option is not available, you can click Run -> Debug... and select the correct configuration. Once your client has loaded, you can run the script you are debugging. When a breakpoint is triggered, your script will pause and options will be available within the IDE. A blue line represents the current line you are debugging. You will notice that your client has frozen while you are interacting with a break point. To prevent this, right click on your break point and change Suspend All to Suspend Thread. Now when you encounter a break point, your client will no longer freeze but you can debug the script. Now about the real problem. Why isn't my script clicking Cut on the oak tree?!?! Well we have a few options here. We can use some nice features down at the bottom in the debugger. will rerun the program. This will close your current client and open a new one. will continue the program until it encounters the next break point. will stop the program, ending your tribot client. will "step over". This will run the line of code and go to the next one. It will not go into any method calls. will "step into". This will run run the line of code, stepping into any method calls that are made. The reason debugging is extremely useful is you can see in real time what each line of code is doing. In this program, we can "step over" all of our lines, and see the line 17 will gathers all Oak trees in our area. If there is more than 0 Oak trees in the array, it will attempt to click the Cut option on the first one. By repeatedly clicking step over, we can see what happens. Now why can't it cut the tree?? Lets "step over" so we are on the trees.click line. If we right click we can see an option that is Evaluate Expression. Click it, or press Alt-F8. This will bring up a new window that looks like this. This allows us to run code that doesn't even exist in the script!!! Lets try running trees and pressing Evaluate. We will see some stuff that doesn't really make sense, but at least we know that there is a tree that we can click on. By typing a . on that line, intellisense will prompt us with valid things we can type. Lets look into the objects definition. We can do this by typing trees.getDefinition() Well, that brings up some more values that don't really make sense for us. By looking at the Tribot API or even typing another . to see what are valid things we can type we can see that trees.getDefinition().getActions() is valid. Lets try that. Hmm, it tells us that Chop down and hidden are valid options for interacting with this tree. I think I found my issue. Cut is not valid and Chop down is. By evaluating this, the result is true, and in the TRiBot client, the bot successfully clicked on the tree!! This is just a small introduction on what you can do with debugging. For more information on what you can do while debugging, consider consulting google.com.
So here are some useful debugging tools that I use from time to time which should help you guys understand more about a process's memory, process's threads and give you a general idea of how does a process work. IDA: Debugging files on the three platforms IDA natively runs on (i.e., Windows, Linux, Mac OS X) is straightforward, and thanks to the power of remote debugging servers, it is possible to enable debugging of any executable, from any platform! https://www.hex-rays.com/products/ida/debugger/ Ollydbg x32/x64: OllyDbg is a 32-bit/ 64-bit assembler level analysing debugger for Microsoft® Windows®. Emphasis on binary code analysis makes it particularly useful in cases where source is unavailable. http://www.ollydbg.de/ ProcessHacker 2: A free, powerful, multi-purpose tool that helps you monitor system resources, debug software and detect malware. http://processhacker.sourceforge.net/ Cheat Engine: Cheat Engine is an open source tool designed to help you with modifying single player games running under window so you can make them harder or easier depending on your preference(e.g: Find that 100hp is too easy, try playing a game with a max of 1 HP), but also contains other usefull tools to help debugging games and even normal applications. It comes with a memory scanner to quickly scan for variables used within a game and allow you to change them, but it also comes with a debugger, disassembler, assembler, speedhack, trainer maker, direct 3D manipulation tools, system inspection tools and more. http://www.cheatengine.org/index.php