Hello!
There is a slight problem with stepping through code (debugging) that has been confusing my students (this I think is not just a VR issue but affects the ‘real’ version as well). When Students go through the code one step at a time they sometimes spot a mistake before the next step is executed. For example they step through the code and realise that on the next step the robot should turn right instead of left. The code editor allows them to make an edit to the blocks to retify this. But the problem is that when the next step is now executed, the change they have just made is not taken into account and the old instructions are executed. It needs a stopping and restarting of the program to see the change happening which is confusing to them.
Ideally (just like in debugging ‘real’ code) it would be great if any changes could be applied immediately while the debugging is in process. If somehow that is technically difficult it would be better if no cahnges to the code can be made when stepping through the code to avoid any confusion.
Thanks,
Mike
Hi @Michael_Poelzl first off, I love hearing that your students are paying close attention to their code while stepping through it! That’s great 
Something that may help is some kind of sign or signal to help students remember to stop their project when they spot a bug. For instance, you could use a mnemonic like : STAR (Stop the project – Talk about the bug – Adjust the project – Restart).
Or I sometimes had students hold up a Stop sign image (or hit a paper Stop sign that was on the desk) as they announce when they spot a bug - so they can be reminded to stop the project first, THEN make a change.
I used this kind of things often with my students as a way to sort of slow their action just enough to remember what a correct procedure for something was.
1 Like
There’s some technical reasons behind this functionality as it works today. Basically, when the “Start” or “Step” button is pressed, a copy of the currently Block interface is sent to the Interpreter’s Virtual Machine (VM) - the actual system that is “running” the code and communicating with the VEXcode VR Playground. Any edits to the Block interface are not sent to the VM until the project is stopped/restarted, but the editor does not lock-out the user from editing the code at that time.
This is good feedback and we’ll take a look at how to lock-out the interface while running to prevent the user from editing… as Just-In-Time (JIT) debugging would be awesome but is quite a large amount of development vs. the relatively low use case at the moment. Not to say that it’s not possible, we’d just have to do a lot more investigation into improving the VM to support this.
Hope this helps clarify how the system works. Thanks!
1 Like
