Playmaker Forum
PlayMaker Feedback => Feature Requests => Topic started by: Broken Stylus on May 18, 2021, 08:58:11 AM
-
Enhanced Breakpoints
The current breakpoint technology only allows a pause (break) when the flow enters a state. No action is ran inside said state yet.
It is therefore an Entry Breakpoint and represented by a vertical red rectangle located inside the state, on its left edge.
Let's have more functions :
1. Exit Breakpoint
Pauses the software when the flow exits a state.
Vertical rectangle located inside the state, on its right edge.
2. Internal Breakpoints, AKA Action Breakpoints
To be inserted between two actions, or at the top or bottom of the action stack inside a state.
Therefore depending on where the user puts it, it will either pause the flow before it enters any action (top of the action stack), or before a specific action (inserted, therefore it will also double as a pause after the previous action has been exited), or after it has exited all actions (bottom of the stack, and only if the stack wasn't exited through a transition event earlier on by a former action).
It's represented by a little red square inside the state.
Now, imagine that the state rectangle's width represents the height of the action stack (all the actions inside the state on Y). It is literally the height of the stack that is taken into account here because some actions tend to be very small and some others very long and simply positioning the red square based on the action's place number would not reflect exactly where the action breakpoint appears in the stack. The red square would be positioned on X at the top of the state (right underneath the top edge). Simply put, if the action breakpoint is inserted somewhere in the middle of the stack, then the little square will appear at the middle top position inside the state's rectangle (50% or 0.5 on X). Think in terms of percentages of position. The "state rectangle's width" used here is understood as not including the little width spaces necessary for the left and right red rectangles, to avoid an overlap: the red squares' space must be exclusive.
The maximum number of action breakpoints is n+1 where n = the number of actions in the stack.
3. Conditional Breakpoints
That one is a bit tricky but I think it could be valuable.
- A conditional entry breakpoint could appear not on the state but on the Global/Entry/In event (the dark rectangle that floats above a state). Since states can have many Global transitions used to enter them, knowing which one did this would be useful without having to add actions such as get event or else or having to look into the FSM Log (not saying the FSM Log is useless but it's simply quicker to see the runtime being paused the moment a Global event knocks on the door). This would require the Graph View to be able to draw an outline around the proper black rectangle.
The same function could be used on "exit" transitions. Now that one might seem odd to new users who may assume that transitions can only be activated from inside the state and therefore ignore that they can also be activated by external event from the local FSM or even outside. So this very specific type of conditional entry breakpoint would immediately reveal that a given "exit" transition has actually been triggered by such an external event in case of a pause, and not by an action inside its parent state.
- A conditional exit breakpoint could appear not on the state but on the exit transition's rectangle (would work on any transition, even the FINISHED). The rectangle would be red and vertical and located on the right edge, even if the transition's arrow is forced to exit to the left instead of the right as it is defined by default.
- A variable value breakpoint. In other words, the user would take any action that compares values and declare this action to activate a pause if a specific value has or hasn't been found. This condition could be applied to an entry, action or exit breakpoint. It would be linked to a specific action that compares values. Said action's card (the space in takes in the action stack) would be expanded downward to include a temporary extra area (in sort of grayish-red) that reflects the presence of a breakpoint link and what breakpoint it is linked to, whether an entry, action or exit breakpoint.
All conditional breakpoints would be represented by red triangles in the Graph View instead of rectangles or squares.
Breakpoints should be reflected inside the FSM Log.
-
Sometimes I wish I could observe a specific instance of a prefab by using breakpoints without having to break the "purity" of its "instanceness" if I may say so.
Fiddling with the revert option is risky and not convenient at all. I do not wish to disconnect the instance from its prefab model.
Would it be possible to add breakpoints without disconnecting the instance?
It would be very helpful!