[grumpygamer]

First, a fundamental change I would make is to change "cores" to "platforms". The vision of zero-configuration emulation means that RetroPlayer decides the appropriate emulator based on the platforms listed in core's addon.xml, among other things. So the user would configure the controller loadout for NES, and RetroPlayer would present all NES emulators with the same loadout.

This is easily doable from a visual standpoint, the idea is great too.

With this change, in order for us to create your idea we'll need a taxonomy of game platforms. This means gathering some platform lists from game info providers (like http://thegamesdb.net/platforms/ ) and creating a superset of platforms, then grouping these into platform families that support similar controllers. That way, the user can configure GBA once, and all cores that support Game Boy, Game Boy Color and GBA are automatically configured.

Is this something you could help create? It wouldn't require any coding, just some research. In addition to your manager, it'll be used for the game library, so this would be really beneficial to the RetroPlayer project.

Sure I'll give it a shot.

Basically when the controllers are plugged in they appear at the top

This presents two difficulties.

First, we assume an infinite number of proprietary and DIY controllers, so it's not possible to have an image for every controller. Maybe we can show the image of the peripheral add-on presenting the controller?

Well we just have a generic image for all DIY controllers.

Second, some controllers use keyboard drivers. There's no way to detect these, so we have to assume a large, unknown number of connected keyboard-based controllers at any time. How can we modify your idea to include this assumption?

Can't we just have "generic keyboard controller" for all of these?

My vision is the ultimate zero-configuration bliss. Necessarily, we'll need to generalize to unseen data. More powerful generalization requires increasing complexity. Increasing complexity means increasing maintenance costs and reduced scalability. These are my two greatest coding offenses, because maintenance cost affects other people, and scalability affects future performance.

Therefore, generalization in Kodi is unacceptable. To avoid this, I've added the assumption of an "oracle" that always returns the most likely configuration. According to this assumption, all controllers are always mapped, so we can't indicate that a particular controller is unmapped. How should we handle this?

What you wrote here is WAAAY too abstract for me... what does this mean??