| 44 | |
| 45 | === Actions (3) === |
| 46 | |
| 47 | The actions are basically the same as with other debuggers. |
| 48 | You don't change anything at the code or what happens when it's executed. |
| 49 | These actions are just commands to stop and continue the execution in a certain way. |
| 50 | |
| 51 | Be aware that the debugger is only capable of stepping through JS code and has no control over native (c++) code. |
| 52 | |
| 53 | ==== Step ==== |
| 54 | Step (or step over) continues the execution until the next line of code is reached. |
| 55 | If there is a function call on the current line, it does not stop the execution after it entered the function (it steps over it). |
| 56 | |
| 57 | |
| 58 | ==== Step into ==== |
| 59 | If there is a function call on the current line, it steps into that function and stops the execution at the first line of that function. |
| 60 | Otherwise it just stops the execution at the next line of code. |
| 61 | |
| 62 | ==== Step out ==== |
| 63 | Continues until the current function is completed and then stops the execution in the parent function. |
| 64 | |
| 65 | ==== Continue ==== |
| 66 | Continue the execution of all threads. |
| 67 | |
| 68 | ==== Continue thread ==== |
| 69 | Continue the execution of the currently selected thread. |
| 70 | |
| 71 | ==== Break ==== |
| 72 | Stop the execution of each thread as soon as possible (basically as soon as the next JS code is executed). |
| 73 | |
| 74 | |
| 75 | === Threads (4) === |
| 76 | Actually the term "thread" is not quite accurate. |
| 77 | All ScriptInterface instances are listed there. A ScriptInterface represents a JS runtime and a JS context. |
| 78 | Multiple ScriptInterface instances can be used in one or more threads. |
| 79 | Important to know is that stopping one thread will sometimes make it impossible to stop another one without continuing the first again. |
| 80 | However, if two threads are really running in parallel and independent from each other, the debugger will try to stop the second thread too if you stopped the fist one. |
| 81 | |
| 82 | If one thread is in break state, you can double-click on it to switch to that thread. The debugger will try to open the file the thread is currently executing and it will display the associated callstack and variables. |
| 83 | |
| 84 | === Call stack (5) === |
| 85 | If you look at this example, keywordTestOR is the innermost function which got called by an anonymous function, which got called by "testFilter" etc... |
| 86 | Often the debugger will only show anonymous functions because we are working with prototypes a lot and don't use named functions often. |
| 87 | |
| 88 | You can double-click on one function name to display the variables of that scope. |
| 89 | |
| 90 | === Variables === |
| 91 | There are three main types of values that can be displayed. |
| 92 | |
| 93 | 1. Locals |
| 94 | Locals are locals variables in the current scope. |
| 95 | 2. This |
| 96 | This is Javascript's "this" object. If you are a Javascript developer you should know what it is, it's quite difficult to explain. |
| 97 | Note that we are using the "strict" mode which means that sometimes the "this" object will be empty. |
| 98 | 3. Global |
| 99 | This is the current global object. |
| 100 | |
| 101 | Sometimes retrieving these values from the game via JSON can take quite a while (in rare cases up to 15 seconds). |
| 102 | If you want to quickly step through code you should collapse all root nodes (or at least the ones with a lot of values) because their content is only loaded when they are expanded. This will make stepping a lot faster. |
| 103 | |
| 104 | The web GUI remembers expanded nodes and they will stay expanded the next time values are loaded from the service. |
| 105 | Sub nodes will not be collapsed if you collapse their parent node (they will become invisible but they will be in expanded state if you expand the parent again). |
| 106 | |
| 107 | |