Currently custom configurations for input devices are stored in a pkty/mappingConfigs entry in local storage
They are being loaded when GameData is initialized, and fed to the inputs controller which keeps them in memory.
Then, whenever a device is detected, a configuration is initialized using the custom mappings stored in memory (as of #1297). This means even if a device was used a single time ever by a player, its mappings will be kept in local storage forever, and in turn, in memory at all times, even if not used.
They are being updated in local storage through the GameData object as well
- loading of custom mappings from local storage should only happen on demand, when a new device is detected.
- both loading and saving of custom mappings don't need to happen through the GameData object, and probably could be moved somewhere else to prevent potential bugs with unitialized GameData (see this discussion). Several other parts of the code also access local storage directly without going through GameData, like settings, so it would make sense for mappings to behave the same.
Currently custom configurations for input devices are stored in a
pkty/mappingConfigsentry in local storageThey are being loaded when GameData is initialized, and fed to the inputs controller which keeps them in memory.
Then, whenever a device is detected, a configuration is initialized using the custom mappings stored in memory (as of #1297). This means even if a device was used a single time ever by a player, its mappings will be kept in local storage forever, and in turn, in memory at all times, even if not used.
They are being updated in local storage through the GameData object as well