With the vast improvement (IMO) of making the YAML screens more cohesive, I would like to suggest changing the top level sequence:
found in scripts and in the top level of choose statements to be changed to actions:
This would save me from trying to remember which is where and it applies the same name to the same function.
It would also prevent weirdness like this:
where the same word has different meaning / feature set.
I do not want to change the lower level word
‘’'sequence:```
as the functions for that key are different, and the word sequence fits there perfectly.
Reference this exchange where we are all mixed up for a while, especially me, until we figure it all out.
Changing the top level word should provide feature parity. in that the top level actions: are always actions:
Largely agree, but I think it should be taken further. The current CR, as written, re-creates the problem further down the chain. Example below. To mitigate this I suggest going further and fully merging sequence with actions, and allowing actions to be directly referenced with !input tags and the like. The end result would be
actions can contain a list of actions and action objects.
actions would have the option to run parallel, just like sequence
The removal of the sequence keyword would also simply documentation, and a simple statement that actions can contain both action and actions objects would make it more clear where these things can be used together, which is different than today where one has to go back and forth between blueprint, script, and action sections of the documentation to still not fully understand if sequences and actions can be merged together, and what the appropriate way to do so is.
Additionally, the blueprint selector is the Action Selector, but the content gets anchored in a sequence, which isn’t fully intuitive.
Example of the CR as written re-creating the problem down the chain:
actions:
- sequence:
- sequence: !input downReleased
- action: CHANGE_SOME_STATE
- action: SOME OTHER THING
New YAML after my suggested changes could look like:
actions:
- actions:
- actions: !input downReleased
- action: CHANGE_SOME_STATE
- action: SOME OTHER THING
which to me is more clear to users about how to nest things correctly.