Singletons currently in the project are somewhat unsafe, considering they can be disabled. They also don't follow any standard on "when" they're initialised, leading to potentially unpredictable/unwanted behaviour.
Safety:
A singleton script should consider the scenario where either the component itself or the game object it is attached to is disabled.
As the singleton instance can be accessed from anywhere at any time, we should handle the (likely unwanted) scenario where a singleton component is being disabled (either through the game object being disabled or the component itself being explicitly disabled).
Solution: do something in OnDisable in any singleton scripts - whether that be a warning log entry or otherwise, do something!
Initialisation:
As a singleton instance-field initialisation relies solely on itself, there is no reason - as I see it - for why any and all singletons should not be initialised in OnEnable, rather than in any of the later component messages. This may aid in reducing future annoyances in script execution order.
Solution: move static field initialisation (singleton) to OnEnable
Items - for now represented as scriptableobjects (simple objects with attributes such as name, description - this is what we extend with UnityEvent/delegates later on)
When returned to the Menu scene, PlayerInputs will be transfered back to the scene, but are unable to interact with the UI despite having their input action remapped back to "Menu".
This seems to be a problem with how the Unity UI natively subscribes to the first (And only the absolute first) newly joined playerInput and nothing else, but I've yet to 100% confirm this.
To test out the practical development side of the new augment system, it was decided that someone other than @SondreHus should try to implement some augments. (The game need more augments too, ofc)
To use Player Input Manager's built in split screen functionality, one needs to assign cameras to each playerinput prefab.
My suggested solutions is to update the playerInput prefab to hold some specific values and components (Camera, color tied to player, player ID, etc.), then declare a Set-able refference property to this player input in the matching player prefab.
This way the player prefab can easily access the playerInput and the necessary components it holds, while avoiding the playerInput to be destroyed with the player prefab. (In case the game wants to destroy the player)
Every single SetPlayerInput function wishes to do something with the InputManager.
The InputManager script already holds a public refference to the playerInput it's tied to, and should thus itself be argument wich we pass to the various SetPlayerInput functions instead of the PlayerInput component.