New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Games: Add Player Viewer (aka "Player Manager Light") #23548
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice feature. I don't have much to comment. The code is nice and almost 100% new.
{ | ||
if (agent->GetPeripheralLocation() == peripheralLocation) | ||
{ | ||
activation = agent->GetActivation(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just return instead of assigning the temporary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like to avoid early returns so that there's a single path out of the function. If we returned early here, we would also have a return at the end of the function.
That said, I like the for-if-break pattern less, so I'll add the early return.
#define CONTROL_AGENT_LIST 5 | ||
|
||
// GUI button IDs | ||
#define CONTROL_AGENT_CLOSE_BUTTON 18 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can these defines be constexpr instead?
CGUIMessage msg(GUI_MSG_REFRESH_LIST, m_guiWindow.GetID(), CONTROL_AGENT_LIST); | ||
CServiceBroker::GetAppMessenger()->SendGUIMessage(msg, m_guiWindow.GetID()); | ||
} | ||
break; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
break inside braces?
void CGUIGameControllerProvider::InitializeItems() | ||
{ | ||
m_items.resize(ITEM_COUNT); | ||
for (unsigned int i = 0; i < ITEM_COUNT; ++i) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for (unsigned int i = 0; i < ITEM_COUNT; ++i) | |
for (auto item& : m_items) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice
#include <vector> | ||
|
||
class CScroller; | ||
class TiXmlElement; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Superfluous? im not seeing a need to forward declare this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch
After build 5, CI errors still seem to be unrelated. |
Just implementing this into my skin and wondering whether I'm missing something, but differently than other color control tags (like the colordiffuse tag), controllerdiffuse doesn't seem to interpret variables here... When I input a color name or a color value, it works, but using a variable nothing happens, if I press a button of one of the listed input devices. Any ideas? 🤔 |
It looks like I didn't add support for skin variables or info labels in the |
I checked the code and |
Will check with |
Can you give an example of how you're using $VAR[]? (I haven't used vars before in skinning). I'll look into this when I get a chance. |
Sure... Here you can find a line where a VAR is used with a colordiffuse: https://github.com/osmc/skin.osmc/blob/bd340735b7b1762a98d5b0ccf9593ecbd3437b61/xml/AddonBrowser.xml#L48 This then points to my colour variables file that I created to store some colour sets toggled by skin settings: https://github.com/osmc/skin.osmc/blob/bd340735b7b1762a98d5b0ccf9593ecbd3437b61/xml/Variables_Colours.xml#L95 This works everywhere without issue, but in this new diffuse we have here 🙂 |
I've pushed my initial Omega skin support now, so you can see the diffuse that doesn't work here now: https://github.com/osmc/skin.osmc/blob/f6641f8fec35294acbc63936466deadef2ce3d3b/xml/Coordinates_DialogGameControllers.xml#L835 All other diffuses in that very same file do work though 😊 |
I downloaded the skin and was able to reproduce. I've been short on Kodi time the last two months but when I get a chance I'll debug the problem. Do you have a repo for the skin? Any skin with game support I'll include a repo for in my test builds, and if I personally have easy access to the skin I can test new RetroPlayer features in it before I release. |
Unfortunately, we don't have a repo for it - it's only released with OSMC updates and thus a repo wouldn't help us, I'm afraid 😕 |
Description
This PR a new window that I call the "Player Viewer". I basically stripped the in-progress Player Manager of, well, management.
However, I ended up with a still relatively useful and not-terrible new feature.
Even though you can't fine-tune control over player assignments yet, you can still change the emulator's ports, which will intelligently re-assign players after #23482.
And you can finally change controller settings like appearance and deadzones from within the game, instead of having to hunt down the heavily buried Input settings.
Plus, all controllers have the rad highlighting added in #23521. Because you can see active controllers, this enables a low-tech kind of player management called "just hand the controller to the other player".
Review should be similar to the port dialog (#20505). To manage a hefty PR I made every effort to have a safe diff with only lines added and very few logical lines changed.
Motivation and context
I was hesitant to PR the window because it's not fully complete. Like, controller settings are per-driver, not per-controller, which leaves something to be desired.
My monthly allocation of Kodi time is drawing to a close though, so it's either PR part of my vision, or let it linger for yet more years. And despite my hesitation, I've gotten a lot of positive feedback for even the incomplete version, so I'll share it in the current state and ship a cool new feature in v21.
As they say, perfect is the enemy of good.
How has this been tested?
Included in test builds for the last few weeks: https://github.com/garbear/xbmc/releases
Screenshots (if appropriate):
Added a "Players" item to the main in-game OSD:
Player Viewer showing a button being pressed on a controller:
Existing Port Dialog when you select the "ports" button:
Existing Peripheral Settings Dialog, opens when you select a controller
What is the effect on users?
Types of change