Now I already do know how to integrate my (node based) weapon manger into my (node based) state machine. However, as someone who still considers themselves a beginner at coding, I don’t know how to get them to work together without negating the benefits of the state machine structure.

All my previous attempts at getting the scripts and nodes between these two entities( that being the state machine and weapon manager) to work together, results in brittle-like code that will be difficult to scale up smoothly if I need to make my FPS controller more complex.

Things got so complicated, I had to delete the project I was working and then retrieve a less complicated back up for it.

The reason why I want to get them to work together, is because:

1)I don’t want the player to be able to use weapons while sprinting
2)I don’t want the player to be able to switch weapons while sprinting
3)I want the player to have a different sprinting animation based on what weapon they’re holding.
4) I want the player to have a different animation for switching between the sprint state and any other state based on which weapon they’re holding.

I’ve managed to successfully accomplish 1) and 2) before. However, I wasn’t satisfied with my own solution for reasons I’ve stated previously; that being it results in brittle-like code that will be difficult to scale up smoothly if I need to make my FPS controller more complex.

I’ve also was able to achieve 4) but I scrapped my solution for the same reasons I scrapped my solution for 1) and 2).

Now despite looking quiet similar to each other where node hierarchy is concerned, the player’s state machine and the weapon manager functions quite differently from each other. The main difference between the two is that the weapon manager is completely responsible for switching what weapon the player is currently using; the codes and functions for weapon switching exist primary in the weapon manger’s script and none of it is referred the scripts for the weapons.
In contrast, the scripts for the player’s states do reference the function in the Player_FSM script that makes switching states possible.

I'd stay clear from this type of discrete state machine if you need to model complex states with overlapping sub-states. This is good only for making a very simple (and non-flexible) control mechanism. You can conceptualize the state as a data structure i.e. a collection of state variables, and then each frame act according to contents of that data structure.

    xyz I think I should just simplify how the controller works by keeping the state machine and weapon manager separate, then I can rework the sprint to feel less like Call Of Duty and more like Half-Life 2.