[garbear]

Maybe this were the wrong words. I totaly agree with this kind of philosophy as this is exaktly the same way as I work. Always have the big picture in mind. So what I tried to say is, the thing that is really necassery to start with are the names of the players. This can be relatively simple to implement. But already prepare the interfaces for the pictures/configurations/avatars.

Agreed, I'll add player names to my concept idea and evolve it from there.

For the use case that one controller is only used for kodi control, it would be the automatically generated player 1 and after onetime configuration the use will never see this diolog again. As I consider this the special case and not using controllers for play.

What needs to be manually set during this onetime configuration that can't be done automatically?

And this isn't the only special case. How are we going to handle keyboard players? How are we going to handle devices like the Tankstick that are two physical players but use keyboard drivers?

And again maybe the right thing would be to concept your player manager in a way that someday and not necasserly by you it can be expanded to become kodi's profile manager. Meanwhile it has to exist in paralell anyway.

Awesome, I think I'll go down this route and keep players general enough that it can one day be used for profiles.

Cheers

thanks for your input!

[lostwithouthope]

For the use case that one controller is only used for kodi control, it would be the automatically generated player 1 and after onetime configuration the use will never see this diolog again. As I consider this the special case and not using controllers for play.

What needs to be manually set during this onetime configuration that can't be done automatically?

And this isn't the only special case. How are we going to handle keyboard players? How are we going to handle devices like the Tankstick that are two physical players but use keyboard drivers?

My idea is that the user that wants to use his controller just to control kodi gets the same "select player" dialog on plugging in his device as everone else and has the option to enable "auto assign this device to selected player" (this could be handy anyway for all others also). This has to be done only once, next time his controller is detected it can be automtically assignet to a player (you do not even have to show that he is now assigned to player xxx) he does not need to see this dialog again until he reconsiders using his controller just to control and wants to change his name

The other special cases you meantioned above are all device that have no plugging in event and that is the only real difference for me between them and "normal" devices. So my suggestion is to emulate their "plugging in" with a manager to enable/disable emulated devices. Upon enabling you present the same player select dialog as for all others even with the auto assigment feature . The next thing that has to be considered is if this emulated devices should save their state on kodi restart or not: If yes the player select dialog for each device which is nit auto assigned has to / should be presented. If not, I think every thing would be clearer.
I would prefer not to save the state: just imagine a couple that controls their kodi with a wireless keyboard. He wanted to play mario but was to lazy to plug in a real controller and activated an emulated controller. And in the evening she starts kodi and just wants to watch a movie and now she isn't aware that the keyboard emulates a controller, for her some keys of the key board will do things she didn't want to as they are now used for emulation and no longer work as kodi hotkeys...

[MrTarantula]

I agree with the "zero configuration, powerful reconfiguration" philosophy. How about this for initial configuration?:

1. Controller is plugged in.
   
2. Controller is detected.
   
3. Notification appears: "Controller {name} has been assigned to player {#}. Press a button to change"
   
4. If button is pressed before notification disappears, enter the configuration screen. Otherwise continue like normal.
   

This is probably dependent upon there being a way to tap into the notification lifecycle.

[N3MIS15]

How about a timed popup (timing/off user configurable) that displays the designation that kodi has decided when launching game/emulator? If the user decides that they disagree with what is briefly displayed on screen then a button press could trigger a user configurable device/controller rearrange.

[da-anda]

when thinking about custom games in Kodi and not just emulators, IMO player profiles are a must have including avatars. Player profiles should be independent from Kodi users though. So all the stats etc should be in a separate database. As in some cases the player also might match a Kodi profile, we could have an option to map it to a Kodi profile and from then on use the available metadata from the Kodi profile. For that we'd need two kind of player implementations/classes, both ofc sharing the same interface so that the only thing having to know about the difference is the factory creating these player objects. The Kodi profile version would be some sort of "alias" with override methods to not deliver certain metadata from the game-player DB but from the connected Kodi profile while it shares/inherits all the other methods from the default player object.

Ofc the player system also needs some sort of guest mode with a dummy avatar (having these generated is optional IMO) and a default name "Player X". Btw, we should not forget to store the gender along with the player profile.

[MacGyver]

To me, the following scenario makes the most sense, physical controllers mapped to multiple virtual controllers

New controller gets plugged in (first time):
Prompt the user for a name for the controller (eg. Knockoff SNES controller).
Prompt the user to pick a device type (auto-populate with a default if known) eg. (Gamepad, Keyboard, Arcade Stick).
If there is a known button layout for the detected VEN&DEV ask if they want to use that,
If not a known (popular) controller, ask the user how many buttons their device has.
If they do want to use the known list, offer to let them override the default button assignments
Prompt the user to program the buttons using a list for how many buttons they chose, auto-populate if they choose that.
Ask them to assign labels to the buttons they programmed, eg X, Square, Select, Up.


Each emulator (and Kodi-GUI) should have its own virtual controller setup:
Adding a new virtual controller (first run):
Pick the Addon (emulator, kodi, standalone game)
Press "Add new virtual controller" (present the user with the known list of controller models for the system (for genesis a 3-button genesis gamepad or 6-button gamepad or arcade-stick; for a wii a nunchuk, etc)).
After a model is selected ask the user which currently connected physical controller they wish to assign to this virtual one.
If the controller was an exact match to a real controller connected (because it was popular) then the buttons should match up, but ask the user if they wish to override the match up.
Present the user with a button programming window and allow them to match the buttons on the virtual controller with the physical ones on their controllers (also allow the programming of a "shift-key" to allow them to set shift+button combos for any button they might be missing on their physical controller)

So if a user has a Genesis 6 button controller with a known USB adapter it will have a default button assignment available, after they set it up as a resource, they could create a virtual joystick for a genesis emulator and because the adapter was known (eg. popular) it could have a default match up. Hardly any configuration needed.
When the user creates a virtual NES joystick, they can select that Genesis USB adapter controller as the source, and when given the ability to remap, the user could map any of the 8 buttons to be the 4 the NES normally uses.

If the Genesis USB controller is still plugged in, and if the user adds a new physical NES controller and USB adapter second, when they create a new virtual controller under the NES emulator it should ask them which player it should be registered as player 1 or 2, whereas if the first Genesis controller wasn't there, it will be set up as the only one.

A keyboard resource could be setup as multiple controllers (designating the type as keyboard could allow this special use).

Just my two-cents worth. Thanks for all the work you guys have already done.

[Fail$tyle420]

when thinking about custom games in Kodi and not just emulators, IMO player profiles are a must have including avatars. Player profiles should be independent from Kodi users though. So all the stats etc should be in a separate database.

So much YES! Great idea!

[natethomas]

I've got a crazy alternative suggestion based, ridiculously enough, on playing Lego Harry Potter. Rather than assigning players at the time the controller is plugged in, assign player by listening for controllers after the game has launched. The first controller button touched upon game launch is "Player 1." The second controller with a touched button then becomes "Player 2." And so on. This may not be possible given how libretro cores work, but it would dramatically simplify everything, since the only time you really need to differentiate players is during game play. Possibly at launch you could have virtual controllers, so cores don't get insane, then as each controller has a button touched, that controller replaces the virtual controller invisibly.

edit: I think this would probably be the single easiest way for users, as it cuts out basically all decision making on their parts. They don't have to adjust things in a UI, because they never see a UI. It may not be as easy for developers though.

[andrego]

I've got a crazy alternative suggestion based, ridiculously enough, on playing Lego Harry Potter. Rather than assigning players at the time the controller is plugged in, assign player by listening for controllers after the game has launched. The first controller button touched upon game launch is "Player 1." The second controller with a touched button then becomes "Player 2." And so on. This may not be possible given how libretro cores work, but it would dramatically simplify everything, since the only time you really need to differentiate players is during game play. Possibly at launch you could have virtual controllers, so cores don't get insane, then as each controller has a button touched, that controller replaces the virtual controller invisibly.

edit: I think this would probably be the single easiest way for users, as it cuts out basically all decision making on their parts. They don't have to adjust things in a UI, because they never see a UI. It may not be as easy for developers though.

This - definitely this. A very user-friendly way to do it that gets the job done very quickly, easily, and 'stays out of the way'. I think users of modern consoles would feel at home with this approach as well. Games like Borderlands 2 and Diablo III work this way as well, for example. Hopefully it is feasible to take this approach in the code as well.

[natethomas]

@garbear, any thoughts on doing it this way?

[garbear]

Rather than assigning players at the time the controller is plugged in, assign player by listening for controllers after the game has launched. The first controller button touched upon game launch is "Player 1." The second controller with a touched button then becomes "Player 2." And so on.

..since the only time you really need to differentiate players is during game play.

You're right, we only need to differentiate during gameplay. One downside is that, if you're switching games often, the extra friction to launch a game might get annoying. We could remember the players and default to that for the next game.

How would this look? I've played through several lego games, so I have a general idea, but lego games have several advantages:

* Player 2 option is always visible because it's built into the in-game OSD
* Only 2 players in lego games, so having a "player 2 press start" at all times isn't annoying. We can't really have 4 or 8 "press start" elements overlaying the game at all times...
* The game gives you in-game feedback when a character joins, but we obviously don't have control over this, so we would have to do something else

So this is definitely a viable option. How would you tackle these points? Can you see any other difficulties we may encounter?

It may not be as easy for developers though.

That's unfortunately a possible reality. The controller configuration utility is sub-par because there's no visual feedback. I started down this road with OpenGL, but we support so many platforms, that anything low-level would have to be implemented multiple times. This isn't really feasible for me to do alone, but if games catch on and bring us more developers this might be possible.

[natethomas]

My guess is that the constantly launching games situation would ultimately mainly be an edge case, or a situation where it's primarily single player happenings. I guess the other possibility is something like a drinking party, but I think the only friction such a method would create is that player 2 might accidentally become player one, and vice versa.

The overlay would be tricky, but I've got an idea for that. For a second let's assume that we're using the standard Estuary OSD video overlay. At present, the top of the Estuary overlay is empty. Assuming we use the same basic overlay for games controls, when the OSD is launched, the number of players could be listed as little tabs at the top, and whichever player is currently interacting with the OSD would have his tab colored in. If more than one player has interacted with the OSD in the last 3 seconds or so, more than one tab would be colored. My assumption here is that if you are capable of listening for a button press and assigning a controller to a player in the game, you should also be able to remember which controller pressed that button and list it on the OSD. Two little tabs or 16 little tabs should just as easily all fit at the top. The tabs would pop up when a player joined and would fade out after a few seconds of that. They'd also always be visible whenever the OSD was visible.

So you have two smart items. A smart list of players logged into the game. And a smart list of players actively interacting with the OSD.

I'm not sure if you'd need to use OpenGL or not for this, as it seems to mainly just be a GUI/skinning job and possibly a database/memory job as Kodi would have to remember which controller was pressed when, so the data could be used to assign the overlay. Beyond that, I don't really know what would be required. Am I wrong in how the data chain would work? I'm not really clear on why this kind of data would need to be low level and why OpenGL would be needed at all.

And a player could drop out (much like in lego) by selecting a drop out option in the bottom half of the OSD. Since Kodi would know which controller pressed the drop out button, and would know which player was associated with that controller, dis-associating that controller with that player in the game should be easy? ™ Dropping out in this way would also allow players to fix any mistaken button presses. If somebody accidentally becomes player one, he could just drop out, and then the next person to press a button would automatically become player one, unless he'd already been assigned a player.

[Serg86]

I think it's fine simply assigning each controller to players as they are connected/detected, just adding them to the back of the list automatically, provided you can quickly and easily change the order. I already suggested this in the Input thread, but the ability to bring up the Player Manager at any given time, say <META>+Start for example, reassigning the player order on the fly and closing it back up dynamically during gameplay, would fix many issues, at least the ones I can come up with.

When a controller suddenly disconnects (batteries for example), keep the player order the same, but free up the assignment, so that the next time a controller gets connected or the same one reconnects, it gets the spot.

If you have 4 different controllers connected for example and you pick up your favourite, but it currently isn't assigned to player 1, a button combination could be implemented to make the current controller player 1, <META>+R1+Triangle on a Playstation controller for example. When you try to navigate Kodi with a controller that isn't player 1, show a popup message:

Controller is not primary.
Press META+R1+Triangle to make it primary.

Something along those lines. I don't know if you can show images/icons inside Kodi popups, well, you get where this is going.

Another potential issue I see with the second method I suggested, is when all connected controllers are connected, but player 1 needs to switch to player 2 for example, on the same controller. You could physically pick up the other controllers and free up the slots one by one, or player 1 could get the ability to remove all assignments by holding down the remove assignment button for ~3 seconds or so. Either that or force-swap to player 2 by holding down or up for a few seconds. That would probably be the better solution. Swapping between players like that should also only be possible for players 1 and 2, I don't know of any case where you would need to become player 3+ temporarily so correct me if there is, and it's really only 1 case I know of where you need to be player 2 in a single player game, fighting Psycho Mantis in Metal Gear Solid, and, at least at this point, some libretro SNES cores are a little wonky where player 2 input is considered player 1 input in some games like Super Mario Allstars.

Not quite sure where avatars and player names would come into play. I don't see the need for them since you'd never actually see them in-game anyway. If names would be easier as identifiers, if for example every controller is the same brand/type, fixed names instead of custom names, like Alpha, Bravo, Charlie, Delta etc. would suffice in my opinion, or you know, Atlantis, Babylon, Camelot, Dharma . As for different button layouts and profiles, I don't use profiles and don't know how the Kodi profile system works, but if possible, custom button configurations should be tucked into the Kodi profile in use, in my opinion, so that every Kodi profile has their own set of custom button profiles for controllers. Defaults would of course be global.

[ketterer]

I think it would be really cool if you had the ability to set player profile and avatar but not as a requirement. As in default to player 1. After that it could be guest p2 guest p3 and guest p4. The default p1 stores all info, can be renamed and edited, controller configs made and are and by default. The guest players all have temp info with the ability to save specific controller configs. Other primary acounts could be made but not only if a user chooses to.
When the first controller is plugged in the default one starts or you manually choose a profile. Every other controller to connect defaults to a guest with option to select a profile
Does this message sense ?

[MrTarantula]

I don't know if this is the right location for this feature request or if it belongs in input, but it would be nice for us inverts ( I invert Y-axis for camera/FPS controls) to be able to have our stick inversion follow either our player profile or controller. It would be nice to be able to configure per system or game, but that's really more of a wishlist item.