Debug should support normal click and onEnter, onLeave and onPileCreation #439

Closed
opened 2026-02-20 10:17:34 -05:00 by deekerman · 13 comments
Owner

Originally created by @RaphaelAlvez on GitHub (Dec 7, 2021).

even though these are not properly routines, they are part of the general automation tools we have.

here is a list of things that should be included:

  • basicWidget:

    • activeFace
    • properties set by faces: do not trigger change routines and are only updated after the change routines. should return a message informing that
  • spinner:

    • angle
    • value
  • seat:

    • player
    • color
  • timer:

    • paused
    • milliseconds
  • onEnter

  • onLeave

  • onPileCreation

Originally created by @RaphaelAlvez on GitHub (Dec 7, 2021). even though these are not properly routines, they are part of the general automation tools we have. here is a list of things that should be included: - basicWidget: - activeFace - properties set by faces: do not trigger change routines and are only updated after the change routines. should return a message informing that - spinner: - angle - value - seat: - player - color - timer: - paused - milliseconds - onEnter - onLeave - onPileCreation
Author
Owner

@rogerl50 commented on GitHub (Dec 7, 2021):

What do you mean by the first four? I haven't checked all of them, but I know that for timer, you do get debug information when you use the TIMER command from a button, or when you click either of the buttons in the composed timer widget?

@rogerl50 commented on GitHub (Dec 7, 2021): What do you mean by the first four? I haven't checked all of them, but I know that for timer, you do get debug information when you use the TIMER command from a button, or when you click either of the buttons in the composed timer widget?
Author
Owner

@96LawDawg commented on GitHub (Jul 12, 2022):

I don't know that I personally need or want all of the above, but something I think we must have are all the "routines." For example, let's say you have a button that moves a card from one holder to the other. If you click the button and review the debug report, you see the clickRoutine. But if the holders have enterRoutine, leaveRoutine, parentChangeRoutine, and/or parentGlobalUpdateRoutine, none of that shows up in the debugger. If you manually drag a card, the most recent event (such as a leaveRoutine will display in the debugger. But we need it so show every routine that happens during exeuction. I have repeatedly missed things when troubleshooting because it was in an enterRoutine that didn't show up on the debugger.

@96LawDawg commented on GitHub (Jul 12, 2022): I don't know that I personally need or want all of the above, but something I think we must have are all the "routines." For example, let's say you have a button that moves a card from one holder to the other. If you click the button and review the debug report, you see the clickRoutine. But if the holders have `enterRoutine`, `leaveRoutine`, `parentChangeRoutine`, and/or `parentGlobalUpdateRoutine`, none of that shows up in the debugger. If you manually drag a card, the most recent event (such as a `leaveRoutine` will display in the debugger. But we need it so show every routine that happens during exeuction. I have repeatedly missed things when troubleshooting because it was in an enterRoutine that didn't show up on the debugger.
Author
Owner

@96LawDawg commented on GitHub (Jul 13, 2022):

But if the holders have enterRoutine, leaveRoutine, parentChangeRoutine, and/or parentGlobalUpdateRoutine, none of that shows up in the debugger.

I was wrong. I know I've had some issues, but don't have any specifics right now and know that enterRoutine, etc. do normally show up. If I find a specific glitch, I'll post in this issue. Otherwise, forget my previous post.

@96LawDawg commented on GitHub (Jul 13, 2022): > But if the holders have `enterRoutine`, `leaveRoutine`, `parentChangeRoutine`, and/or `parentGlobalUpdateRoutine`, none of that shows up in the debugger. I was wrong. I know I've had some issues, but don't have any specifics right now and know that `enterRoutine`, etc. do normally show up. If I find a specific glitch, I'll post in this issue. Otherwise, forget my previous post.
Author
Owner

@RaphaelAlvez commented on GitHub (Jul 14, 2022):

I know one example from a long time ago +1 year I believe.

Setting owner in a holder on enter. No this should not be a normally hand it that specific case.

I couldn't find the problem and I had to add a global update routine that did nothing just to pick the properties changes. It was horrible.

Turns out it was a pile problem but it took me way longer to find the problem

@RaphaelAlvez commented on GitHub (Jul 14, 2022): I know one example from a long time ago +1 year I believe. Setting owner in a holder on enter. No this should not be a normally hand it that specific case. I couldn't find the problem and I had to add a global update routine that did nothing just to pick the properties changes. It was horrible. Turns out it was a pile problem but it took me way longer to find the problem
Author
Owner

@rogerl50 commented on GitHub (Jul 14, 2022):

I know one example from a long time ago +1 year I believe.

Setting owner in a holder on enter. No this should not be a normally hand it that specific case.

I couldn't find the problem and I had to add a global update routine that did nothing just to pick the properties changes. It was horrible.

Turns out it was a pile problem but it took me way longer to find the problem

Can you reproduce this?

@rogerl50 commented on GitHub (Jul 14, 2022): > I know one example from a long time ago +1 year I believe. > > Setting owner in a holder on enter. No this should not be a normally hand it that specific case. > > I couldn't find the problem and I had to add a global update routine that did nothing just to pick the properties changes. It was horrible. > > Turns out it was a pile problem but it took me way longer to find the problem Can you reproduce this?
Author
Owner

@rogerl50 commented on GitHub (Jul 14, 2022):

Can you give a little more explanation of what you'd like to see?

  • basic widgets: I'm not sure what you mean. When do you want to see additional things displayed? And what?
  • spinner: I'm guessing you want a line of debug output saying that the spinner was spun and what the result was.
  • seat: I'm guessing you want to know when the active player changes
  • timer: I'm guessing you want to know when the timer is paused or when milliseconds is reached
  • onEnter, onLeave, onPileCreation: I'm guessing you want a list of properties that are changed when these actions are taken.

At present, the debugger responds only when a routine is being executed. Thus even if the debugger is open, manually moving a card from one holder to another will not produce any debug output, even if the holders had an enterRoutine or a leaveRoutine. Are you proposing to change that behavior for just the above cases, or are you asking for the debugger to provide information about what happens any time there is a manual change in the room state? Or, are you asking to have the things above displayed as part of the debugger when these actions happen during routine execution?

@rogerl50 commented on GitHub (Jul 14, 2022): Can you give a little more explanation of what you'd like to see? - basic widgets: I'm not sure what you mean. When do you want to see additional things displayed? And what? - spinner: I'm guessing you want a line of debug output saying that the spinner was spun and what the result was. - seat: I'm guessing you want to know when the active player changes - timer: I'm guessing you want to know when the timer is paused or when `milliseconds` is reached - onEnter, onLeave, onPileCreation: I'm guessing you want a list of properties that are changed when these actions are taken. At present, the debugger responds only when a routine is being executed. Thus even if the debugger is open, manually moving a card from one holder to another will not produce any debug output, even if the holders had an `enterRoutine` or a `leaveRoutine`. Are you proposing to change that behavior for just the above cases, or are you asking for the debugger to provide information about what happens any time there is a manual change in the room state? Or, are you asking to have the things above displayed as part of the debugger when these actions happen during routine execution?
Author
Owner

@96LawDawg commented on GitHub (Jul 14, 2022):

If this gets done, for seats, I would also add turn.

@96LawDawg commented on GitHub (Jul 14, 2022): If this gets done, for seats, I would also add `turn`.
Author
Owner

@RaphaelAlvez commented on GitHub (Jul 14, 2022):

ok first of all for timer milliseconds probably shouldn't be added due to the frequency of the updates

As an example if you add a checker piece and click it you don't get any kind of debug even though there is some automation happening behind that changes one property

image
activeFace changed with no debug

Similarly, if you put a card in a holder you may flip all cards and have no debug. there is even more crazy automation you could do with onEnter and onLeave that have absolutely 0 information in debug.

@RaphaelAlvez commented on GitHub (Jul 14, 2022): ok first of all for timer milliseconds probably shouldn't be added due to the frequency of the updates As an example if you add a checker piece and click it you don't get any kind of debug even though there is some automation happening behind that changes one property ![image](https://user-images.githubusercontent.com/73476656/179026954-98a93a58-c4b4-4e3c-bc12-070d8796d9ec.png) `activeFace changed with no debug` Similarly, if you put a card in a holder you may flip all cards and have no debug. there is even more crazy automation you could do with onEnter and onLeave that have absolutely 0 information in debug.
Author
Owner

@rogerl50 commented on GitHub (Jul 14, 2022):

@RaphaelAlvez Here's what I'm trying to get at: currently the debugger runs only when a routine is being executed - it is kicked off by the top-level call to evaluateRoutine in widgets.js. It appears that you are asking for debug information to be given not only for actions started programmatically, but also for manual actions (things done directly by the user). Is that right?

I can see adding onEnter information (for example) for things moved under routine control, but expanding debugging to handle user interactions is (I think) a much larger project.

@rogerl50 commented on GitHub (Jul 14, 2022): @RaphaelAlvez Here's what I'm trying to get at: currently the debugger runs only when a routine is being executed - it is kicked off by the top-level call to `evaluateRoutine` in `widgets.js`. It appears that you are asking for debug information to be given not only for actions started programmatically, but also for manual actions (things done directly by the user). Is that right? I can see adding `onEnter` information (for example) for things moved under routine control, but expanding debugging to handle user interactions is (I think) a much larger project.
Author
Owner

@RaphaelAlvez commented on GitHub (Jul 14, 2022):

I believe it should also be triggered by normal click, onEnter, onLeave and onPileCreation

Exceptions would be x, y and milliseconds only because of the frequency they update.

@RaphaelAlvez commented on GitHub (Jul 14, 2022): I believe it should also be triggered by normal click, onEnter, onLeave and onPileCreation Exceptions would be x, y and milliseconds only because of the frequency they update.
Author
Owner

@rogerl50 commented on GitHub (Jul 14, 2022):

When you say "normal onEnter", just to be clear, you mean: by a user manually dragging a widget into a holder. Right?

@rogerl50 commented on GitHub (Jul 14, 2022): When you say "normal `onEnter`", just to be clear, you mean: by a user manually dragging a widget into a holder. Right?
Author
Owner

@RaphaelAlvez commented on GitHub (Jul 14, 2022):

Yes

Actually I think the best way to describe the issue would be: "debug should cover most player interactions"

@RaphaelAlvez commented on GitHub (Jul 14, 2022): Yes Actually I think the best way to describe the issue would be: "debug should cover most player interactions"
Author
Owner

@96LawDawg commented on GitHub (Feb 21, 2024):

Debug now supports all of this.

@96LawDawg commented on GitHub (Feb 21, 2024): Debug now supports all of this.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/virtualtabletop#439
No description provided.