Now the thing is, for my player animation design, pressing up on, say, the left thumbstick does a different movement or action depending on which state you're in. For example, when you're stood on your snowboard idling, pressing the left thumbstick forward makes the player shuffle along to start moving. When the player is jumping, pressing the left thumbstick makes him tilt forward, and so on.

A state machine works this way: One of its states is active. On each update of the state machine all outgoing transitions of the active state are investigated whether their conditions are true. At most one transition has to be chosen. If none is chosen then the state remains active, otherwise the state which is referred by the transition is the next active state. The condition is a boolean expression.

With this in mind, each of the states "idling" and "jumping" (taken from your post above) have their own transitions, and hence their own conditions, and hence may have different following states. Moreover, due to the separate states, the input configuration can bind one input trigger to different variables.

So a state definition like your example would be:

<state name="idle_board_on" initial="true">
    <transition name="idle_board_on-shuffle_forward" triggeredBy="shuffle" follower="shuffle_forward" />
    <!-- here more transitions outgoing from idle_board_on" -->
</state>
<state name="jump_board_on">
    <transition name="jump_board_on-tilt_forward" triggeredBy="tilt" follower="tilt_forward" />
    <!-- here more transitions outgoing from jump_board_on" -->
</state>
<!-- here more states -->

I don't see a problem here.

Sorry, yes, I had missed out the next state in each transition node for brevity.

I can't really use a triggeredBy of "shuffle" though, because I'd need some other logic completely separate from the state machine that says, pressing left stick up only results in "shuffle" being set to true if you're idling, otherwise it results in "tilt_forward" being set. My point is, this logic could be in the state machine for free, otherwise I'd need some other similar logic to do that.

Sorry if I'm labouring a point a bit, I appreciate your input

You misunderstand my posts, I think.

You have an input configuration that provides (besides others) the abstract inputs shuffle and tilt. The both are shown in the input configuration dialog as triggers. The player picks "gamepad" as input device and from that "controller up". He does so for both abstract inputs. This is possible because both abstract inputs are in distinct spaces. That means it is logically not possible to trigger both actions shuffle and tilt as the same time. The input configuration is aware of this and hence allows this duplicate binding.

When the game runs and the player triggers the "controller up" input, both the variables for shuffle and tilt are set to true by the player controller. Now comes the clue. If the state machine is currently in the state idle_board_on, there is a transition with the condition considering shuffle. Since shuffle is true also the condition is true and the transition is chosen. There is also a state jump_board_on with a condition considering tilt, but because jump_board_on is not current, it plays no role even its condition is true, too!

You see, the same physical input is used for both abstract inputs, but things work well. What exactly is meant when "controller up" is triggered is "the player asks for shuffle or tilt". What actually happens depends on the current state of the state machine. It may even happen that the trigger causes nothing because the transitions of the current state do consider neither shuffle nor tilt.

EDIT:Maybe the word "transition" is unclear. In a state machine a transition leads from one state to another. This has nothing to do with a time based blending between two animations, i.e. a kind of visual transition.

No I understand, my point is that I'm not sure i see the benefit of having the player controller set both "shuffle" and "tilt" to true. You get the same result if you just set "leftstick_up" to true. "Leftstick_up" here is abstract, so in the player's controller configuration it could actually physically equate to pushing the right stick up or pressing the trigger, etc.

Using only "leftstick_up" should still work because both states check this flag and as obviously only one state can be active, it would initiate the appropriate transition from that state.

Using both "shuffle" and "tilt" means that somewhere else in the code (perhaps the player controller) I need to set both of those when the [abstracted] left stick is pushed. For that to be hard-coded seems wrong and if it's to be data-driven, it would mean we've effectively got duplicated logic.

I understand the transition part of state machines, been doing a lot of research :-)

Making some pretty good progress with this now, thanks again guys