Allowing upload of assets via Hash
Vatuu opened this issue · 47 comments
So, I'm working on a neat little feature that lets a game create images based on the current state of the game. But since the Rich Presence is restricted to pre-uploaded assets of the application used, I am in quite a pickle. Wouldn't it allow for more options to allow the DiscordRPC to upload pictures via a hash-key of the picture, instead of relying on pre-uploded assets? The profile pictures are send like that on a JoinRequest, so I doubt it should be that hard to allow it the other way around.
You should create the graphics for all states of the game ahead of time (also designing the images for the best possible appearance, as per https://discordapp.com/developers/docs/rich-presence/best-practices#have-interesting-expressive-art)
Of course, but with the limit of 140 Assets, it's impossible to prepare for all possible cases, that's why I have come up with this in the first place
I think if anything, you should be suggesting an increase to the asset limit, although I can't imagine a game with more than 150 actionable states.
With too many images, it would be hard to recognize that two people are even playing the same game...
Like I said, the images are generated by the game itself, based on various aspects and states of the game, that's one part why it is impossible. The other is, that even if one would create premade images of all cases, the assets limit would always be too low.
if we could upload temp assets that lasted for the duration of a rich presence state that would definitely be cool, or maybe being able to pass a url to the image key
Exactly, having a „dynamic assets“ for the small and big image that can be changed via direct url or image key
If the images are generated by the game, its going to take a lot of work to guarantee that all images will be bright, recognizable, and match for all players in the party. It also decreases recognition for two people playing the same game, as the art 'style' might be completely different if not carefully crafted.
It's probably best to encourage developers to spend time on strong, useful assets instead of encouraging them to just pull the current screen (or other less-designed aspects)
Simply because they are generated does not mean that they are not recognizeable. Besides, the work that has to be put in making it the same for all people in the party is minimal. Remember that the examples on the docs are guidlines and recommendations to ensure good quality, but that quality can equally be achieved by generating a picture.
Also, if there are so many possible states that you'd need images for, how can one be distinguished from another, from the standpoint of someone wanting to play with you? Your rich presence should represent one of a finite number of states, that anyone who also plays the game would recognize. I can see the 150 limit being low for some games (like League of Legends, which could potentially overflow that with the number of unique characters), but I'm sure that for large games like that they could request the limit be increased.
This is a valid request, and one that we've heard from a number of game developers. There are currently technical limitations around the way we handle assets that would require some work on our part to allow this to happen.
I unfortunately can't offer you anything other than condolences and my agreement that it would be nice at the moment. I hope that it's something we can implement in the future as well.
If you find yourself in a situation where you legitimately need more than 150 assets, you can contact us and explain your case and we'll see what we can do.
I'll keep this issue open as the de-facto "We want to be able to upload assets via the payload" request.
For me, I could boost from this HUGELY. Having the concept of temporary assets would be great, as a Mod like this (for Minecraft) could be used more widely than expected. The ability to use the Server Icon of a world would be awesome, but it brings the issue where if > 150 people use the mod on different servers or worlds, we run out of icons and are forced to use a "preset" icon. The ability to have near-unlimited (not unlimited, but like a HUGE amount like 10,000) temporary images that can't last for longer than 24 hours would be useful.
If the string length limit for image keys was raised, Base64 would be a good option to send over images. Another good option is allowing sending of SVGs, for those times when the SVG is simple and the bitmap is huge. (SVG also embeds images as Base64 if I remember.)
So, any progress/ideas/new thoughts on this? Since my project starts to reach a point where it becomes kind-of needed.
Since the Integration of the Spotify Integration is now a thing (for a while now, I somehow missed it) and is able to display the cover of the currently playing song, isn't that a sign that it becomes possible?
Espicially since it came to my attention lately that the INSTANCE and MATCH-SECRET are unused, they could be transformed into a String field taking a base64 image...?
It's not really as simple as opening up a field in the payload to accept base64 images. We'd have to make backend changes around our media proxy tools to support this as well. Unfortunately there's not currently any more information I have available—I update open feature requests and outstanding issues as I get new info, as you can see—but I will keep this open as the official feature request.
I'd like this too, we're integrating discord on our multi-system emulator frontend and it would be cool to be able to show a boxart of the game being played, or the latest unlocked achievement
I know you have alot of comments saying they would like this feature being added and you have already addressed it saying there would have to be backend changes.
I would also like this feature added in order to use it similarly to Spotify, where I have a source image of an album cover that I would like to use for the rich presence.
Perhaps making it only possible if the image is already uploaded to a website instead of directly sending it. I'm not familiar with how Spotify is handled with Rich Presence so I cant really weigh in on it.
+1 maybe just a ref to a URL of an image
This most likely wouldn't be what you want or what discord wants.
The Spotify implementation works this way, at least I think so because in the browser client you can see that the pictures are coming from Spotify CDN. This is most likely a deal between Discord and Spotify so Discord does not have to host/pay for the bandwidth of those pictures.
For a generic implementation this would not be ideal because Discord would allow anyone to display whatever they want in their client because you can't validate what the external link points to. Also this would increase the load on the specific hoster of the picture to an unknown amount (because every client would load the picture).
So the only possibility (if you want to do this by URL) would be that the Discord backend downloads whatever your URL points to and rehosts it for the Discord clients.
I hope that Discord comes up with a solution soon. This feature would be a great improvement for Rich Presence.
@vpontin I don't think that discussing possible solutions makes sense here because it is Discords decision how (or even if) to implement it. For the sake of ending this here, this would be a solution that makes sense to me (without knowing much about Discords infrastructure etc.):
- From a user/dev perspective I would add a new field in the struct with a limit of lets say 100kb, that holds a base64 encoded image.
- In the library (the .dll) a hash of the image would be calculated. The Discord API could be changed so that it responds to each Rich Presence update with OK/ERROR and the hash of the current image (I believe the OK/ERROR part is already there as there are callbacks for errors).
- The library could then check if the current image is the same as the image in the new update request that is in the queue. If the image is the same it doesn't need to be transferred, if not the base64 data will be sent to Discord.
- The image could be hosted on the same CDN as the pictures that you can post in the chat currently.
Maybe it would make sense to be able to restrict for how long these images will be hosted, either by an additional field or some hard limit by Discord (like 12h or something).
Designing this is a task for the Discord Team so there is no real use in discussing every bit and piece of this or making suggestions (the one in this post included). So lets end this here and wait for an official solution.
Anyway i was trying to help, since only telling "this isnt possible and will never be" isnt a good answer dev-wise.
Anyway discord devs are doing a great deal of ****** not finding (or wanting to find) a solution for this, since Retroarch is one of the most conspicuous emulation platforms out there. Why not add better support for this?
Perharps making some agreement with retroarch devs could delight retrogamers like me, to being able to share what i'm currently gaming, it could be better for the community. Turn the back for us isnt a nice thing, anyway.
@vpontin While retroarch would not be able to programmatically upload assets for things like game icons, there's no reason that the 150 predetermined assets couldn't be used to show the system being emulated, for example. I don't think there are >150 emulated game systems on retroarch.
The strings in the profile could be used to show game name, emulator name, whatever they want.
We can't support programmatic asset upload right now, but I think it's fairly disingenuous to say that we're turning our back on integrations because of it.
I don't think discord has to implement this.
It would be nice to have, that's all.
It's certainly not a show stopper but it narrows down the possibilities a bit (I had an idea for a game awareness pluging for retroarch that would show megaman from megaman X with the collected armor pieces for example)
Again, just ideas, would be nice to have, that's all.
Would be nice to dynamically update the photo for the presence, that way you don't need to preload the app with 150 photos.
Christ, this is almost a year old now .-.
How about we add it for the anniversary?
Hah, happy birthday issue 🎉 The stance, I suppose obviously, really hasn't changed. We don't have a good way to do this. The truth is that it's a fairly niche request for certain types of integrations: music, emulators, etc. etc. The vast majority of games fall well within the 150 asset limit and pre-upload them to be referenced. In fact, I'd wager than most of our integrations use < 5 assets altogether.
I'm happy to keep this issue open for the sake of it being tracked and acknowledged, but I don't think we're going to make this happen anytime soon.
Another aspect would be that if you have a team working on a project such as a game (the size / scope of it doesn't really matter) it's currently not that easy to give everyone the needed access to certain parts, artists for assets, programmers for implementation etc.
But the fact that it's all tied to a single discord account means you either have someone of the team act as a proxy that handles all the stuff (which can potentially lead to a bottleneck if said person happens to be not available) or basically make a dedicated account that can be shared with the team.
Being able to dynamically adjust assets (or even only upload them), if done right, can already reduce quite a bit of workload of that one person.
But yeah even then I'd probably also mark it niche, a proper permission handling per-application would probably work better in that case, but as that also isn't a thing.~
I mostly wrote this to maybe give it a different angle to look at it and maybe find a suitable solution along the way (however unlikely it is)
I believe that allowing multiple users to access/edit a single application was discussed and/or planned, which would solve your use-case better than uploading assets on-the-fly, @neico.
@msciotti you say stay tuned, but its 4 months later and still nothing. is one of those soon:tm:'s that never ever happen, or one of those soon:tm:'s that eventually happen like video chat
that was probably with regard to teams which already happened
well regardless we still need this
We really need that
Hey all, with #290 we'll be moving these feature requests over here: https://support-dev.discordapp.com/hc/en-us/community/topics
Could I ask that someone writes this up over there? I'm happy to do it as well if no one does by end of today.
Pending approval, but I hope you're happy https://support-dev.discordapp.com/hc/en-us/community/posts/360043570772-Allowing-upload-of-assets-via-Hash
Made this by hand and it took me a solid 30 minutes 😌
Pending approval, but I hope you're happy https://support-dev.discordapp.com/hc/en-us/community/posts/360043570772-Allowing-upload-of-assets-via-Hash
Made this by hand and it took me a solid 30 minutes 😌
Clicking the link shows an unauthorized page for me but im not sure if they're supposed to be public or not.
Trying to figure that out myself 🙃 first day with the new system.
@msciotti I know this is off topic, but why did Discord switch to using zendesk instead of github for feedback?
@sorenbug Would you mind editing so the body of the post is just a link to this issue + Vatuu's first post. This issue will close but still be readable, so I don't think we need to copy the whole conversation over.
@ifonefox it's easier for us to categorize requests and see community priorities via upvotes on the requests. It also allows our CX folks to moderate the, uh, less than kind comments that sometimes happen, rather than me 😄
That link still is dead
It's still pending approval /shrug
Approval to be displayed? That's dumb. There should be a simple profanity filter & a queue system to look at it after it's already been published
It actually did hit a profanity filter, which is why it was not published immediately. That link should be alive now, thank you! I'll close this issue in favor of that post.