discord: added new discord-rpc statuses & updated discord-rpc calls to stay more consistent

[winneon]

This PR adds and changes a number of things in regards to RetroArch's discord-rpc implementation. Below is a list of the changes.

• Removed the counter/stopwatch while in RetroArch's menu. There is no reason to be counting playtime if the user isn't in fact playing anything.
• Added new playing/paused statuses that track when the currently playing core pauses and unpauses.
• Added new playing/paused icons to go along with the new statuses, displayed in the smallImage field of the RPC widget.
• Modified the playtime counter/stopwatch to account for when the currently playing core pauses and unpauses. The new behavior includes the counter pausing when the core pauses and unpausing when the core unpauses.
• Added a new "In-Game" status to go along with the In-Menu status already present. This keeps the presentation of the RPC widget more consistent.
• Because of the above change, moved the currently playing platform & core status from the third line of the RPC widget to the hover-over text for the largeImage field of the RPC widget.

Not said in the above list is a temporary modification to the largeImage field to a standard "core" image (the rocket icon already available in RetroArch). The reasoning for this is explained in the discord.c file itself so anyone who attempts to contribute to the file will know about it. However, I will post the reasoning here as well, below.

At the present time, there is no consistent or clean way to present what platform
or core the user is playing on/with. If we were to present the platform as an icon,
some cores have multiple platforms, such as Dolphin with the GC or Wii, or blueMSX
with the MSX or MSX2. The libretro API has no way of determining what platform a
selected content is associated with; it only knows what core it's playing under.
The platform is determined by the core itself during initialization, not viewable
by the libretro API. A solution to this problem would be associating the content
with the first platform available in the core's information file, but that solution
doesn't work when someone sees another users playing Super Mario Galaxy with a
GameCube icon. It's not good enough. Another solution would be exposing what
platform is associated with inside the core itself, visible through the libretro
API, but this would require updating every libretro core to support this feature,
and the support would be too slow and limited for it to really work as a solution.

If we were to present the core as an icon, there are a few options available, and
none of them are desirable either. If we were to provide an icon for each core based
on that core's logo or name, then we'd need new assets for every single libretro
core available, AND each asset would need to be consistent with each other, in a
similar vein to the XMB themes of RetroArch, which would be another massive
undertaking. If we were to provide an icon for each core based on that core's
platform, then we have the same issue as earlier, except this time we're additionally
limited by the amount of assets a Discord RPC application is allowed to have: 150.
There are currently 173 core information files available within RetroArch, which goes
over that number by a bit. Now if that were determined by platform instead of core,
that number goes significantly down as there are many cores with multiple platforms,
but then we have the issue as described earlier.

Because of this dilemma, for now the provided icon for the In-Game status will be the
standard/default "core" icon, at least we can come up with a solution that's clean
and consistent.

I would love to hear everyone's thoughts on this and any suggestions anyone might have.

---

Below is a showcase of the RPC widget in the form that this PR will provide.

Any feedback would be much appreciated.

Before this PR is merged, please ensure all assets are uploaded to RetroArch's official RPC application. Below is a zip of the assets required for this PR, at the least. All of the assets are correctly named.

images.zip

---

This PR request is related to #5690. @twinaphex @bparker06 @fr500

[alfrix]

i've made several proposals discord.zip

someone sees another users playing Super Mario Galaxy with a
GameCube icon

if you are that nitpicky, i could make dolphin just a dolphin, bluemsx, use the b logo, and mgba can use the advance logo, since the gba has retrocompatibility, etc

[alfrix]

i would put this instead for dolphin discord-dolphin-ishiiruka.zip

[andres-asm]

Just use the playlist icon when available. Otherwise fallback to a default icon for the core (I mean, a genesis pad for GPGX is more than enough to convey it's something SEGA)
The status shouldn't be related to the core at all. Problem is that discord doesn't tell us what the limit for the strings is

For instance

super_nintendo works
super_nintendo_entertainment_system doesn't

So I decided to announce the core name itself.
As I stated in my PR, I made it quickly and to prove a point. The feature was stagnating because noone wanted to put out the effort to add 3 lines of code to make it work properly.

Now what you need is... parametrization, let the user pick what they want show from a host of options, and add the required icons to the APP itself so all those options can be shown properly.

[winneon]

@alfrix I suppose you're right that it doesn't need to be THAT specific on what platform the content is playing under. I appreciate your effort into porting over the XMB icons into the correct format as an example, 3 times even. I think going with the first example will be the best.

@fr500 That's another good idea, I don't know why I thought of that, considering I even added a playlist check for the content name. Using the core name seems to be the only way to go about doing associating the icon with an asset name that discord will like. I just hope a solution will be made by the time we go over the 150 asset limit.

[alfrix]

We are currently using the monochrome batch with the monochrome dolphin of the second post.

[winneon]

That’s great then! I’m at work, but when I get back I’ll commit the required changes.

[winneon]

@alfrix Side note: are all of the monochrome icons plus the monochrome dolphin icon uploaded to the RetroArch RPC application? I probably should’ve asked earlier, but was short on time.

[alfrix]

they are, and should be working, i have tested a few and everything seemed ok

[winneon]

@alfrix Some of the icons do not work because they're the wrong name. Examples include mednafen's cores. Please re-upload the icons with the names based on the "corename" attribute within the core's info file, not based on the filename of the info file. Spaces should become underscores and everything should be lowercased.

An example of this would be "Beetle GBA" named as "beetle_gba". Remove base.png and rename RetroArch.png to base.png. That way, all of the icons will stay consistent. Make sure the other necessary assets are uploaded as well: playing.png, paused.png, and core.png namely. These can be found in the original zip file in the OP.

I have pushed the necessary commits for this PR to function properly in upstream. Once you have re-uploaded the icons and renamed RetroArch to base, this PR can be merged.

[alfrix]

Uploaded the icons to https://github.com/alfrix/retroarch-discord-icons
so we can get the changes needed, before turning them over.

[inactive123]

OK guys, how should we proceed here?

What is the consensus on this? Can this PR be merged as-is, or are there still things that need to be addressed?

Do some Discord icons still need to be updated as things stand, or are we good there?

[winneon]

@twinaphex I didn't work on the icons last night because I came home very fatigued. I'll be sending in a PR to the repository @alfrix linked to fix the icons, and once the icons are up on RetroArch's official RPC application, this PR can be merged.

[inactive123]

OK. As soon as that happens, @alfrix can let me know so that I can update the Discord section again.

[alfrix]

It seems that i misnamed some of them, i made a custom discord app to test the changes, but ran into a nasty segfault, i'll let you know when everything is ready ```cpp Thread 1 "retroarch" received signal SIGSEGV, Segmentation fault. 0x000000000046385f in string_to_lower (s=0x0) at libretro-common/string/stdstring.c:40 40 for ( ; *cs != '\0'; cs++) (gdb) bt full #0 0x000000000046385f in string_to_lower (s=0x0) at libretro-common/string/stdstring.c:40 cs = 0x0 #1 0x0000000000a64098 in discord_update (presence=DISCORD_PRESENCE_GAME) at discord/discord.c:106 system_name = 0x7fffee83853c <__GI___libc_free+76> "H\203\304([]A\\A]\303f\017\037\204" label = 0xffeee4da <error: No se puede acceder a la memoria en la dirección 0xffeee4da> current_playlist = 0x1620000009a system = 0x10b66c0 <runloop_system> core_info = 0x203d6d0 #2 0x00000000004457e7 in command_event (cmd=CMD_EVENT_DISCORD_UPDATE, data=0x7fffffffdd90) at command.c:2926 userdata = 0x7fffffffdd90 discord_inited = true boolean = false #3 0x000000000043e22d in runloop_iterate (sleep_ms=0x7fffffffde60) at retroarch.c:3422 userdata = {status = DISCORD_PRESENCE_GAME} i = 5 input_nonblock_state = false settings = 0x7fffdd527010 max_users = 5 #4 0x00000000005672c6 in ui_application_qt_run (args=0x0) at ui/drivers/qt/ui_qt_application.cpp:178 ret = 1 sleep_ms = 14 #5 0x0000000000436419 in rarch_main (argc=1, argv=0x7fffffffdfe8, data=0x0) at frontend/frontend.c:157 args = 0x0 ui_application = 0x10aeb20 <ui_application_qt> #6 0x0000000000567344 in main (argc=1, argv=0x7fffffffdfe8) at ui/drivers/qt/ui_qt_application.cpp:202 No locales. ``` El lun., 20 de ago. de 2018 a la(s) 09:58, Twinaphex ( notifications@github.com) escribió:

…

OK. As soon as that happens, @alfrix <https://github.com/alfrix> can let me know so that I can update the Discord section again. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7089 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABMIBT3Sb61kPvW2ZMeNpsVJyDKzMQ56ks5uSrKAgaJpZM4WCeQZ> .

-- Alfredo Monclus

[winneon]

@alfrix I'm in the process of renaming them. There's also a few missing icons as well that I'm trying to figure out what to do with. For example: Daphne is a WIP core that's available on the nightly buildbot and has an info file, but doesn't have an icon. bNES is another one: it has an info file but it's not on the buildbot and you can't download it through RetroArch itself either.

[winneon]

I just pushed a commit that converts any forward slashes in the corename info attribute to an underscore because forward slashes are not valid characters for a filename in any filesystem. Examples for the use of a forward slash in the corename attribute include almost every bSNES core.

[inactive123]

BTW, please keep in mind that we only have a limited amount of icons left on Discord Developers page for Assets -

107 out of 150 max assets are already in use.

[winneon]

@twinaphex All of those assets will be replaced by the icons we finalize. I am concerned about the limit, however. There may need be a hardcoded list within discord.c that keeps track of which cores don't have an icon in the end. The reason it has to be hardcoded is because of the limitations of Discord's RPC API. It's not possible to retrieve a list of what assets are uploaded to an RPC application, so we'd have no way of knowing what cores have an icon other than a hardcoded list.

[winneon]

@twinaphex @alfrix The pull request has been submitted to https://github.com/alfrix/retroarch-discord-icons that renames every icon to its respective converted corename attribute. However, there are 63 missing icons. Some are non-trivial like libretro's testing cores, but others should certainly get an icon. Below is a table of the missing icons and whether they're on the buildbot or not. I think the ones that are readily available on the buildbot should receive an icon. Some of them should probably be just a plain "core" icon (like the rocket icon already used in RetroArch), while others (like MAME's cores) should receive proper icons.

corename	Buildbot?
3D Engine	✔
Advanced Test	❌
BlastEm	❌
Cannonball	✔
Caprice32	✔
CrocoDS	✔
Cruzes	❌
Daphne	✔
Dolphin Launcher	❌
EasyRPG	❌
FB Alpha 2012 CPS-3	❌
FFmpeg	✔
fixGB	❌
fixNES	❌
fMSX	✔
FreeJ2ME	❌
Frodo	❌
FS-UAE	❌
Game Music Emu	✔
Imageviewer	✔
Lutro	✔
MAME 2003 Midway (0.78)	❌
MAME 2003 Plus	✔
MAME 2009 (0.135u4)	❌
MESS 2014 (Git)	✔
MPV	❌
Mupen64Plus (GLES3)	❌
OpenTyrian	❌
ParaLLEl (Debug)	❌
PascalPong	❌
PCem	❌
PCSX ReARMed [Interpreter]	❌
PCSX ReARMed [NEON]	❌
PCSX1	❌
PocketCDG	✔
Reicast NAOMI	❌
REminiscence	✔
RemoteJoy	✔
Rustation	❌
Dungeon Crawl Stone Soup	❌
TempGBA	❌
Test	❌
netplay-test	❌
TestAudio Callback	❌
TestAudio NoCallback	❌
TestAudio Playback Wav	❌
TestGL ComputeShaders	❌
TestGL	❌
TestGL (FF)	❌
Button Test	❌
Test RetroLuxury	❌
TestSW	❌
TestSW VRAM	❌
TestVulkan AsyncCompute	❌
TestVulkan	❌
Theodore	✔
ThePowderToy	✔
UAE4ARM	❌
UME 2014 (Git)	✔
uzem	❌
vecx	✔
VeMUlator	✔
VICE SDL	❌

[inactive123]

Some of those test cores honestly don't matter all that much, and it would be a waste of icons since already we are rapidly running out of space (test SW, TestVulkan, etc).

I repeat again, we cannot add any more icons beyond those 150 max assets. So the last thing we need to do here now is start adding icons for stuff that is not essential.

[winneon]

@twinaphex Every icon that is currently on the RetroArch RPC application should/will be replaced with the renamed icons over at https://github.com/alfrix/retroarch-discord-icons. All 107 of the currently available assets on the RetroArch RPC application will be replaced with the 107 icons at that repository. The remaining 43 slots should be used for the cores that are available on the buildbot (in the list I listed in my previous comment).

I am very concerned about the 150 limit; I'm also thinking about the future and cores that will eventually need icons. So, my thinking here is that any non-essential cores in the list above that have a buildbot build available should be hardcoded into discord.c to have a standard "core" asset. In the https://github.com/alfrix/retroarch-discord-icons repository, there already is a "core" asset called core.png. That should be the one used for those non-essential cores.

As for essential cores in the list above that have a buildbot build available (like MAME's 2003-plus core), they should receive proper icons for their platform.

In the end, for now we'll be well under the 150 limit. The reason for the hardcoded list is because of that limit. Thoughts?

[inactive123]

OK. Is it an option to talk with Discord devs to see if we can get an exemption for the max 150 assets limit based on our usecase/needs here?

[winneon]

Temporarily until we get Discord's exemption from the 150 asset limit, non-essential cores with a missing icon that have a buildbot build available have been hardcoded into discord.c to use the core asset. At this point, we're just waiting on @alfrix to approve the remaining icons I submitted to https://github.com/alfrix/retroarch-discord-icons, and after all of the icons in that repository are uploaded to the RetroArch RPC application, we can finally merge this.

[andres-asm]

Why do you need an exemption? There aren't 150 different cores are there? I mean, there is at least 7 bsnes cores, and 4 snes9x cores, and 5 mame cores, just use the same icon for them.
Also, nope, discord/discord-rpc#70

And... harcoding core names... really? that's really lame, that was one thing that was never compromised before. There wasn't a single core specific hack in the codebase.

No idea why that is required, either, if you set an invalid imagekey the image is just blank.

[winneon]

@fr500 If you're against the idea of hardcoding the core names temporarily, then do you have an alternative to the problem? I'm against the idea as well, but sometimes you need to go against what you want in order to make things work correctly.

We need an exemption because in the future we will likely run out of the 150 assets slots that Discord allows an RPC application to have. 112 of those are currently going to be used. That number would be much higher if the core names that are hardcoded, weren't. The core names that are hardcoded are considered non-essential; they don't have an established platform and/or don't have an established icon. Almost all of them are game engines or tech demos.

Since we don't have an icon for them right now, they use the standard "core" asset that we will use as a default asset, but uploading that same asset over and over just renamed to each specific core to the RPC application will bring us very close to that 150 asset limit. And what if we don't get that exemption? Then we're essentially wasting a bunch of asset slots for no real reason. The Discord RPC API doesn't allow a GET fetch of the assets of an RPC application, so we have no way of knowing what core icons are uploaded or not. Thus, brings us to hardcoded values. I want an alternative, but I don't have one.

It would help if you read the comments of this PR; it would have saved me the trouble of me writing this and your frustration.

EDIT: Also, the reason why an image is required is because the platform & core names are tied to a hover-over of the largeImage asset, the asset that is currently under debate. The reason why it's tied to the largeImage asset is because it's more consistent with what Discord RPC use should look like; Discord even has an example image showing as such.

[andres-asm]

It's quite simple
Announce super_nintendo instead of snes9x then you use 1 icon for snes instead of 16
#7043

I did mention this in the first implementation actually, core name was a quick dirty hack

I tried just using system_name but it seems the discord API doesn't like long strings and there is nothing in the documentation that indicates a max size (https://discordapp.com/developers/docs/rich-presence/how-to) So I wouldn't know how to truncate them otherwise (so core name seemed easier)

I think it should just have no icon for cores that have no icon, it's even fitting and will encourage people to contribute artwork.
Another lame but less lame alternative might be to add another field for RPC icon to the core info.
Actually a good solution would be to use the playlist_name as a system, you could also use the rom parent dir, or even the extension, there are plenty of possible solutions, and all of them are less annoying than adding core specific hacks to the codebase. Making it use the system name would also mean less work for the person maintaining the discord APP, instead of updating assets for 16 snes cores, update them once.

I'm not annoyed at you tbh, you're just doing some work, and I have no veto power over it. I don't merge or veto PRs.
I'm annoyed at the lack of direction.

[winneon]

@fr500 Where would we get super_nintendo exactly if we were to load an .sfc or .smc ROM? Core information files do not have it. We could load it from a playlist, but that's only an optional scenario as playlists aren't always used. Core information files are wildly inconsistent. Some core info files don't specific a systemname the same way as others do. One of the only consistent values in a core info file is its corename.

Having no icon for a core looks wrong when it's going from something that has an icon, like another core or the RetroArch menu. It's also not within Discord RPC's guidelines. I believe that a standard "core" asset like the rocket icon RetroArch is currently using is equally motivating for others to create unique icons for platforms/cores with no specific icon.

[winneon]

If you would like an example of this inconsistency with core info files, Genesis Plus GX's systemname attribute is Sega 8/16-bit (Various), which is very broad and not consistent with other Master System or Game Gear emulators' core info files. Their database attribute is Sega - Game Gear|Sega - Master System - Mark III|Sega - Mega-CD - Sega CD|Sega - Mega Drive - Genesis|Sega - PICO|Sega - SG-1000. If we were to grab the first one of that list, it would be Game Gear, but the Genesis Plus GX is not used for the Game Gear primarily, it's used for the Mega-Drive/Genesis and the Sega CD.

Gear System's systemname attribute is Sega 8-bit (MS/GG), which is also entirely incompatible with Genesis Plus GX's systemname and other Sega system emulators. There are other examples I could find and point to, to showcase this inconsistency with core info files.

[andres-asm]

Well, no core specific hacks is some sort of intrinsic guideline we had too.
Honestly I'd be much more comfortable fixing core info files than adding that, but yet again, I have no veto power, I'm just expressing my opinion.

You are free to pursue this path, I'm not on board with the idea but you don't need me to be.

[alfrix]

i was testing this and discord doesn't accept parenthesis ( ) which creates problems with some names,
i'm sided with @fr500 on this, lets fix systemname if we need to...
very much prefer to have to create 1 icon for all the arcade cores than 10 different ones mame + something

[winneon]

@fr500 Listen, I'm talking with you about this because I want everyone to come to an agreement. If someone's not happy, I'd rather fix that than just continue. That's why I'm asking for your input.

Fixing core info files would also be a solution; I brought it up in the OP. I didn't go through with it because it requires modifying almost every core info file and I don't know how core info files are managed, whether they're all centralized in one place or not. If they are, then that should be the direction we should go in. I don't want to hardcode anything if I don't have to.

[alfrix]

usually @RobLoach makes the core_info changes at https://github.com/libretro/libretro-core-info

[winneon]

Is that the master repository of all core info files? It also seems to be managed at https://github.com/libretro/libretro-super. How are they connected? When you update your info files via RetroArch, does it download from either of those repositories, or another mirror someplace else?

[andres-asm]

Core Infos are just text assets, they are really inconsistent as you have said. They are supposed to reflect the internal core information for instance (for core name at least) and in many cases they don't. I think this applies for many bsnes cores, and mupen GLES3 on android for instance. I still think it's better to fix those than to add core specific workarounds to the source.

…

On Mon, Aug 20, 2018 at 7:31 PM Jesse Bryan ***@***.***> wrote: @fr500 <https://github.com/fr500> Listen, I'm talking with you about this because I want everyone to come to an agreement. If someone's not happy, I'd rather fix that than just continue. That's why I'm asking for your input. Fixing core info files would also be a solution; I brought it up in the OP. I didn't go through with it because it requires modifying almost every core info file and I don't know how core info files are managed, whether they're all centralized in one place or not. If they are, then that should be the direction we should go in. I don't want to hardcode anything if I don't have to. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7089 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABpC0K7mHia_MJpqE-BLJq0_Aluc1eqXks5uS1TxgaJpZM4WCeQZ> .

[winneon]

Then I'd rather go with your solution, then. I'll work on updating all of the core information files, I just need to know which repository to do that with. Is it libretro-core-info, or is it libretro-super?

[andres-asm]

the buildbot uses libretro-super at least.

…

On Mon, Aug 20, 2018 at 7:49 PM Jesse Bryan ***@***.***> wrote: Then I'd rather go with your solution, then. I'll work on updating all of the core information files, I just need to know which repository to do that with. Is it libretro-core-info, or is it libretro-super? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7089 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABpC0M_hnvDzBe5i7_CyCXllKWgH9XiWks5uS1kMgaJpZM4WCeQZ> .

[winneon]

Ok, then I'll work with libretro-super unless told otherwise. I appreciate your input, I really do!

[winneon]

discord.c, core_info.c, and core_info.h have all been updated to support a new core info attribute: rpcname. This has the benefit of supporting more cores without icons, reducing the amount of icons from 112 to 61, and removing all signs of hardcoded core names.

Pull requests have been submitted to libretro/libretro-super#860 and alfrix/retroarch-discord-icons#3 to add the new attribute to all available info files with an established platform & icon, and to update all the current icons to support the new attribute. Once both PRs have been merged and the new icons have replaced all of the older icons on the official RetroArch RPC application, this PR can be merged. In the end, there should be 61 assets in total on the RPC application.

@twinaphex @alfrix @fr500 Thoughts?

[RobLoach]

Seems like we could use rpcname elsewhere... Seems similar to the systemname, so possibly rename it to systemid?

[winneon]

@RobLoach Seems like a good idea; it has been changed for a more wider use.

[inactive123]

OK, I uploaded @alfrix's images.and removed the old ones.

@winneon Can you fix the merge conflict now so we can merge this PR? Thanks.