CryptidProductions
Member
So, for the life of me I can't figure out how to actually select instances and get information about them to show up in the debugger windows
Attachments
-
296.6 KB Views: 13
That explains a lot, the tutorial I watched wasn't clear on "you have to pause the game first" partPause the game by clicking the pause button.
Switch to the Instances tab. The Instance (sans s) tab inside of that shows info about whatever is currently in scope. The All Instances tab shows info about all instances.
Okay, I get the debugger to open and show the code for a random object in the room it's choosen when I pause but I can't figure out to switch instances in the debug code window because the instance list is only showing that one random object as in scope despite the player an and enemy being on screenPause the game by clicking the pause button.
Switch to the Instances tab. The Instance (sans s) tab inside of that shows info about whatever is currently in scope. The All Instances tab shows info about all instances.
// Some examples
// If you want the debugger to pause after 30 frames do something like
if (frameCount >= 30) {
var breakHere = 1; // Set a breakpoint on this line
}
frameCount++;
// If you wanted to stop the debugger on a specific instances draw event then add a line
// at the start of the objects draw event
if (id == 1000120) { // some id for the specific instance
var breakHere = 1; // Set a breakpoint on this line
}
// If you want the debugger to pause when something collides with the player
var collision = instance_place(...);
if (collision.object_index == obj_player) {
var breakHere = 1; // Set a breakpoint on this line
}
1)If documentation and tutorials at all helped me I wouldn't be asking how to work it here, now would I?Please read the manual:
Debugger
Watches
breakpoints
In the screen shot you showed you can see the 'Instances' tab. It list all instances currently in the game. You can open each and inspect there current values and variables.
To get to specific places in code use breakpoints to stop the debugger when and where you want. Unfortunately the GMS debugger does not support conditional breakpoints so you will have to do it the old school way:
Usually though you don't have to be so conditional. Just put breakpoints in your existing code where you want to pause. e.g. want to pause on the players step event, then put a breakpoint at the beginning of the players step event.GML:// Some examples // If you want the debugger to pause after 30 frames do something like if (frameCount >= 30) { var breakHere = 1; // Set a breakpoint on this line } frameCount++; // If you wanted to stop the debugger on a specific instances draw event then add a line // at the start of the objects draw event if (id == 1000120) { // some id for the specific instance var breakHere = 1; // Set a breakpoint on this line } // If you want the debugger to pause when something collides with the player var collision = instance_place(...); if (collision.object_index == obj_player) { var breakHere = 1; // Set a breakpoint on this line }
2)Reading variables or breakpointing an entire object doesn't help figure out why complex code as a whole is not working right on a specific instance of it in the room hitting specific conditions. Especially if it's re-using gravity code that several objects are using as a script function.
To repeat myself:
You seem to be having problems and are frustrated. So I will give you the benefit of the doubt and assume you are saying silly things due to your frustration.To repeat myself:
If the object has several instances in the room just breakpointing that object so the first instance to run it pauses the code isn't going to help me. Especially when I can't figure out to view code in the debugger in a way that tells me which instance of the object it applies to
Especially if that code is a script function that's being used by two different enemy types AND the player because it's a basic gravity routine.
When the debugger breaks the 'Instance' tab shows you the current scope. In your screen shot I have highlighted it. Opening the 'Built-in variables' listing will show you the id of the current instance.Especially when I can't figure out to view code in the debugger in a way that tells me which instance of the object it applies to
Okay, I'm almost there and this seems to be the Skully I need to check judging by his ID and the room creation order but how do I do I actually see inside the script function and break within it?You seem to be having problems and are frustrated. So I will give you the benefit of the doubt and assume you are saying silly things due to your frustration.
Calm down and read.
When the debugger breaks the 'Instance' tab shows you the current scope. In your screen shot I have highlighted it. Opening the 'Built-in variables' listing will show you the id of the current instance.
View attachment 39370
Every instance has an id. The second tab 'All Instances' shows you every instance currently in the game. Expanding those lets you inspect them: (This is highlighted in green below).
View attachment 39372
When the debugger breaks use the tools to step in, over, and out of code. Pay attention to the call stack it is highlighted below. Everytime you step, code is executed and values change. Step slowly, inspect what is relevant and get a solid idea of what has just happened, what is about to happen, what you expect the results will be, and how those results match your expectations.
View attachment 39373
The first step in trying to isolate bugs is to create a reproduceable case. 100% reproduceable is the goal, but you can't always get there. Just narrow down the conditions to get the issue to occur as often and reliably as possible; idealy in the exact same way every time or close to it. This allows you to not only reliably examine the issue but will also act as a test that you fix the issue once you fix it. The process of creating a reproduceable case will typically increase you understanding of the problem.
Once you have a reproduceable case then try and narrow down the exact conditions. This can be done by setting breakpoints at various places in the code and inspecting variables BEFORE and AFTER the issue. As well show_debug_messages can help in this regard to help isolate the exact timing and positioning.
The more conditions you can identify that cause the problem the more you will understand it and the more easily you can set conditional breakpoints to eventually break exactly before the problem occurs and STEP through and see it occur. Look at my previous post for an idea of what I mean by conditional breakpoints.
As a note of caution, be very aware of any code you have that is based on delta time. Pausing the runtime will typically have unwanted effects on code based on delta time. For debugging purposes consider refactoring so any reference to a delta time instead uses a fixed time.
These are the tools available. They are only tools and you will need to find ways to use them. You can't open the debugger and have it just show you the problem. Debugging is just as much a skill and an involved task as any other part of development. Use anything and everything you have access to (mainly your imagination) and try to figure out what is going on in your code.
The debugger along with the show_debug_message are invaluable tools but the main tool will remain your intelligence and imagination. Relax, take deep breathes and engage your brain.
I strongly recommend reading the manual. Read the manual, use the debugger to verify your understanding, when you run into problems then come back here and ask SPECIFIC questions.
Good luck.
Im not 100% sure what you are asking.Okay, I'm almost there but how do I do I actually see inside the script function and break within it?
You can actually see the values in instances without pausing if (1) real time debugging is turned on, and (2) you are looking at the all instance tab and not the instance tab. However, code is obviously updating really fast (probably 60 times per second) and so only updates that are stable for seconds at a time are really going to be visible without pausing. Still, inspecting instances in the all instance tab while the game is running can be incredibly useful.That explains a lot, the tutorial I watched wasn't clear on "you have to pause the game first" part
Choose the step into button function call button (F11) - this has to be a custom function you can't step into built in ones. (beaten to it)Okay, I'm almost there but how do I do I actually see inside the script function and break within it?
Yeah, what I'm wanting to do is actually see the code that's being run inside my custom function so I can step through it and find where it's glitching out in regards to that instance running itIm not 100% sure what you are asking.
If in the screenshot above you have successfully paused in the Step event on the line gravity_step() and you want to know how to go into the gravity_step function?
At the top of the script debugger script window are some buttons:
View attachment 39375
Step in, Step Over, Step Out
These also have keyboard shortcuts F10, F11, Shift+F10
These are described in the manual: Debugger
If that is not what you mean then ask again with clarification.
In the future post your code using the code tool of the forum instead of a screenshot.So I found an interesting bug in my code, I think?
For some reason when running this code it seems to be skipping over the while loops in some weird way that make him float in the air?
Yeah, 100% what's happening. Despite floating above the floor the check is returning false and I can't seem to find the cause.
var T_Y = y + vspd; // Here T_Y includes y
// Now again you add y to T_Y so effectively you have 2*y+vspd
if collision_line(x+2, y+T_Y, x+R_X, y+T_Y, ...) {
...
}
DELETED
I just posted the code that way to show the variable values down the status window for reference.In the future post your code using the code tool of the forum:
View attachment 39378
Without know exactly what you are doing I think you have several errors:
As well even though your comment says "find ceiling" which would imply a vertical line, the collision_line is casting a horizontal line (start y and end y are the same).GML:var T_Y = y + vspd; // Here T_Y includes y // Now again you add y to T_Y so effectively you have 2*y+vspd if collision_line(x+2, y+T_Y, x+R_X, y+T_Y, ...) { ... }
There are several magic numbers here in your code. Review your code and double check it makes sense. Give you magic numbers names along with explanations of why they are what they are.
Ok, that could work.1)It is a horizontal line being drawn above the players head that checks all the way across to check to see if there's a ceiling above them
Yeah, I think I'm picking up on the debugger and wondering if maybe I should make another thread with the indentified problem that's stumping me.Ok, that could work.
Also double check the math for the y when checking floor and ceiling. Remember y increases downwards. I understand vspd may be negative or positive but make sure everywhere you are adding to y and meaning to look up or down that it will in fact be correctly positive or negative.
Hopefully you have the hang of the debugger now, which I believe was the point of the thread.
//find ceiling and hit it
if collision_line(x+2, y+vspd, x+R_X, y+vspd, Solid_Floor_Obj, false, true){
while !collision_line(x+2, y, x+R_X, y, Solid_Floor_Obj, false, true){
y += sign(vspd);
}
vspd = 0;
}