Failing a Scenario

In Luminous Flow, a "failure" typically arises when a user executes a step out of its intended sequence. While this principle seems straightforward, it's nuanced in application.

If a user performs a step correctly, it will never be flagged as a failure.

Say, if we've configured Flow to register using a grinder (a specific object) as a failure, this rule will be disregarded if the step explicitly requires the use of the grinder.

Diving into Failure Scenarios

Let's explore some nodes associated with failures using a hypothetical scenario with snappable objects.

Global Exception Node

This node lays out the global exceptions. Let's visualize three Failure Exceptions. The first, "All Snap Object or Zone" is deactivated for both Practice and Assessment modes. So, if during the scenario a user snaps an object wrongly (either in timing or placement), it results in a failure. If we're reassembling a complicated machinery, ensuring each part fits perfectly, this setup is ideal.

However, for other objects, such stringent rules might be limiting. Consider a permit on our toolbelt, accessible at any point in the scenario. With our current setup, returning it to our belt triggers a failure. This brings us to our next exception.

Specific Object Exceptions

The "Snap Object or Zone" exception can specify objects. When we add the permit to this exception, it overrides our previous rule, allowing the permit to be snapped back anytime without causing a failure. Similarly, another exception is created for a walkie talkie, offering the same flexibility.

To refine this further, let's say we're required to display the permit only during a certain task phase, but not otherwise. We'd need more detailed rules to prevent erroneous snapping of the permit during its designated display time.

Removing Global Exceptions

To address the above, we can use the "Remove Failure Exception" node. By removing the earlier global exception for the permit, we can configure it to fail if snapped anywhere else after being attached to the worksite fence.

What if we later want the freedom to review and snap the permit freely after the worksite is cleared?

Adding Global Exceptions

By applying the "Add Global Exception" to the permit, we stipulate that it should never trigger a failure upon snapping.

A Contrasting Approach

Suppose the bulk of a scenario involves objects we can position freely, but there are a handful we want to restrict. In this situation, we can flip our strategy. Rather than designating all snap objects to potentially result in a failure, we can allow unrestricted snapping for all objects by default. Only specific items would be flagged for potential failures upon incorrect placement.

Embracing Flexibility with Exceptions

Using this reversed approach, we grant universal snapping freedom for objects, with the exceptions clearly defined for those few we wish to monitor more closely.

Visualizing Exceptions as Tokens

Imagine exceptions as tangible tokens given to nodes. When endowed with this token, we're essentially saying, "This won't cause a failure." Removing it means the action could now lead to a failure. This analogy can help conceptualize the outcome of a specific user action.

In Summary

We first set broad rules for snap zones and fine-tuned them for specific objects. This allowed a dynamic setup where certain objects could be snapped freely, while others had restrictions that could be adjusted based on the scenario's progression.

In this thought exercise we only looked at snappable object but the same logic applies to other functionality such as Grabbing, Using etc. In contrast we then looked at how we could do the inverse and set only specific objects to fail rather than all of them.