Debug idea/request

Discussion and feedback on Construct 2

Post » Sun Oct 02, 2016 10:44 pm

Just had a thought that it would be fantastic to be able to see which events run or not in the debugger.

Even if it was just a list of numbers corresponding to the event numbers that get highlighted if they run each tick, that would allow quick confirmation of any conditions mistakes by seeing if an event runs or doesn't run when it is supposed to.

I have no idea regarding the feasibility or difficulty of implementing such a feature though.
Mistakes were made.
B
49
S
24
G
107
Posts: 1,581
Reputation: 60,303

Post » Sun Oct 02, 2016 11:08 pm

I doubt there's a good way to implement that. One problem with the method you describe is that it would require constant switching between C2 and the debugger to check which event is which. A much simpler solution is for you to just code something into the event you want to watch with that never happens anywhere else in the event sheet. I generally rotate a part of the UI.

This method is also better because then you can tailor the visual feedback to what works best for you. For example, I sometimes create debugSprites (a basic yellow square) at the locations of specific instances which reveals which objects the event was using.
Moderator
B
94
S
33
G
33
Posts: 3,006
Reputation: 27,744

Post » Mon Oct 03, 2016 1:38 am

I use the browser object to log a message in the console for events I want to fire. It's a really quick way to do this and you can just pull up the console in chrome to see it.
B
103
S
38
G
19
Posts: 962
Reputation: 17,986

Post » Mon Oct 03, 2016 10:56 am

Events run at 60 FPS, so trying to make sense of a list which changes every 16ms, or trying to watch for the briefest of flickers as something highlights for 16ms only, seems to be a pretty difficult way to review what is running. Also it's probably more complicated to define "which events ran this tick" than you think - triggers can fire outside of the normal tick cycle, functions can run the same events multiple times, etc.
Scirra Founder
B
387
S
230
G
88
Posts: 24,251
Reputation: 192,464

Post » Mon Oct 03, 2016 5:08 pm

If the debugger could let you step one event or condition/action at a time and be able to inspect what is being picked then that would probably satisfy the op. Also would it be possible to set break points in triggered events and let you step through that?

Currently debugging events is something new users have trouble with. More advanced users resort to logging text or visualizing what's picked somehow manually. Debugging more complex events usually requires disabling most of the events and building it up a little at a time while visualizing what's picked. In some cases advanced users can mentally run through the events as they read it to find what's amiss but in most cases it's easier to scrap it and start from scratch.

Anyways being able to debug events at a finer level would be useful in helping new users with the nuances of the event system and advanced users to identify where their events are failing.
B
91
S
31
G
103
Posts: 5,241
Reputation: 67,768

Post » Mon Oct 03, 2016 9:25 pm

The breakpoints feature should already support running events step-by-step. The problem with triggers is it's really hard to support them in browsers. It would be easy if we could "hang" the browser (just suspend execution) while you've hit a breakpoint, but browsers are specifically designed to make it difficult for pages to do that for obvious usability reasons. So the problem amounts to saving and restoring the entire JS execution stack. That's a really tough problem! We've simply skipped the future, but I would like to support it if we can figure out a way to do that.

Showing the currently picked objects would be interesting, but I'm not sure what the UI would look like for that... how would you keep that clear & intuitive when there are potentially hundreds of instances being filtered from multiple object types?
Scirra Founder
B
387
S
230
G
88
Posts: 24,251
Reputation: 192,464

Post » Mon Oct 03, 2016 10:00 pm

I'm sorry to hear it is not a simple implementation. I always feel guilty about "feature suggestions" as they basically amount to asking someone to do extra work, but I really appreciate that you read and respond!

I did notice the debugger doesn't update every tick as I assumed it did after I went and looked more closely.

Regarding the perception of a single tick, I'd like to disagree. The eye is quite good at noticing differences and changes of state. Quick example - https://www.dropbox.com/s/49cxynn9onjhs ... .capx?dl=0

In this case it would be a simple yes or no, if the event ran or not. It would show if an event is running when it wasn't supposed to, or vice versa. In a chain of events/conditions, you would be able to see how far down they get activated until. This would let you pinpoint where to start looking for mistakes in conditions.

I understand I can (and do) manually add in debugging stystems, but it is clunky and a bit specific - sometimes you want to check a large if/then subevent chain or function, and it can be useful to see multiple events at once. Also as r0j0 mentioned, such techniques are generally beyond beginners.

I brought this up because I saw something similar in the UI of another scripting program (energy management software), and thought that it was great. The use case is a bit different of course, in that software it is running as you edit the script and you only need to look at the script to begin with. But it shows quickly at a glance what is and isn't running, and I thought something like that applied to C2 could be very useful.

Image

Being able to see and confirm picked objects would be also have amazing utility, but I wouldn't even know where to begin regarding how to represent that in a scalable manner. And you definitely wouldn't be able to process that information in the instant that the event is called.

Anyways if it isn't feasible, that's too bad. Thanks for the discussion though!
Mistakes were made.
B
49
S
24
G
107
Posts: 1,581
Reputation: 60,303

Post » Tue Oct 04, 2016 5:17 pm

@ashley
That makes sense. It would be a nice to have though. I guess I was imagining the ui highlighting the picked instances in a similar way to what happens when you select an instance from the list.
B
91
S
31
G
103
Posts: 5,241
Reputation: 67,768


Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 3 guests