Great question, we have some hard technical limitations that prevent us from enabling this kind of functionality, so there won’t be a way to do this in the near future.
1 Like
oh thank you, and I got other question if u can answer me, in the RDC they show that a video capture feature is coming for this API but in the RDC devforum post they don’t talk about it, there is anything like a date or how it will work that we should know? (sorry for my english is not my first lenguage 
)
Yes, we’re so excited about the video capture capability! It’s an upcoming feature so the details on a timeline are a bit sparse, but we’ll keep the community posted on updates as we can give them.
We invite you to give feedback on how you’d plan on using a video API! We got the chance to hear from several creators on this topic at RDC, and we would love to continue hearing feedback on it.
1 Like
I have a use case for the Capture APIs in general; allowing users to report abuse in my game through taking screenshots of the abusive content. It’s possible to have users take a capture and generate those images to be displayed in EditableImages in-game, however it’s not possible to transfer these externally to platforms like Discord. I guess this would be more of a feature request towards the EditableImages team. 
1 Like
It seems no matter what I try, using the content id from CaptureService | Documentation - Roblox Creator Hub in AssetService:CreateEditableImageAsync() will not work on a live server. It works in studio just fine. It says it hasn’t been enabled yet.
The API Doc does say “it must be associated with and/or owned by a creator of the experience, or it must have been created inside the experience” Does this not count as being created inside the experience?
I would just like to know for sure if this if for security purposes or I just need to wait? And if it is for security purposes, really what extra info could be recorded that couldn’t already be if a developer wanted to log every keystroke and cframe and send it offsite like has been mentioned? Thanks!
Currently EditableImage is in a Studio beta, so the API is not available in-experience yet.
When EditableImage is launched in experiences we do plan to allow you to use EditableImages with Captures but there will be security limitations.
The limitations have not been finalized yet but as an example we don’t want to make it possible for you to prompt a user to purchase an item and then take a screenshot of their Robux balance. So it’s likely that Captures where the CoreGui is visible will not be eligible to be used with EditableImage for user privacy reasons.
3 Likes
I finally tried this today and I’m pretty disappointed at how it works and some of what I’ve read here about its restrictions.
- The
IsContentSharingAllowedfield ofPolicyServicejust doesn’t exist. Why is there a paragraph dedicated to something that, based on reading this thread, has never existed? - There are differences between how developer initiated captures work and how player initiated captures work. Player initiated captures don’t at all respect
ScreenshotHudproperties. Not respecting those makes the capturing screenshots through the API a lot less appealing, and maybe unusable for people who really want to cut out all core GUIs. - There seems to be no way to detect whether or not sharing screenshots is available for the user. I would really like an API to check beforehand if sharing a screenshot is available so I can prompt a save in the event where it isn’t.
- It would be nice if sharing screenshots on PC did something despite there being no native interface for sharing stuff like on mobile. (Maybe prompting to copy the capture to their clipboard?)
- Only being able to initiate a capture for 13+ users restricts this feature from being worth using for anything meaningful for a pretty decent portion of the userbase.
- As far as I can tell captures a purely local which might be the most disappointing aspect of all here. It would be nice if there was a secure solution for taking screenshots and immediately sharing them with other users in the experience. Giving users the ability to show off their screenshots was probably one of the coolest things I thought about using this for but poses a security risk if I just let users share through editable images once they’re available.
Wouldn’t a better solution to this be to hide purchase GUIs no matter what during a capture? I would really prefer to be able to initiate capture when the game deems necessary and to not have arbitrary restrictions put on the screenshot because something was left in that, as far as I know, could be hidden as simply as other core GUIs are hidden during captures.
5 Likes
Any update on this? There still seems to be memory leaks and it’s been 4 months.
1 Like
Would it ever be possible to edit a screenshot before saving it to the captures gallery? For example:
- User takes a screenshot.
- Screenshot is turned into
EditableImageso it can be cropped/drawn on/etc. - Edited screenshot is then saved to captures with
PromptSaveCapturesToGallery.
I’d really like to be able to do this, but this is impossible at the moment because:
-
PromptSaveCapturesToGalleryonly takes an array of asset IDs; it doesn’t acceptEditableImages. You also can’t generate an asset ID from anEditableImage. - Even if you could do that, the screenshot would get shrunk down because of the 1024x1024 size limit of
EditableImages.
EDIT: Looks like this might be possible once Roblox finishes replacing all APIs to use the new Content data type.
Assuming that PromptSaveCapturesToGallery will be upgraded to use Content instead of asset URI strings, you should be able to generate a Content from an EditableImage through Content.fromObject(EditableImage), and then pass this to whatever new method that will replace PromptSaveCapturesToGallery.
The 1024x1024 size limit is still a problem, though.
1 Like
Why do SurfaceGui and BillboardGui always disappear for captures? Personally I’d prefer a case where I can hide specific GUIs (screen/surface/billboard) as separate options, but I was going to manually handle just hiding all the ScreenGui with HidePlayerGuiForCaptures set to false. Unfortunately, no matter whether the SurfaceGui and BillboardGui are parented to PlayerGui or not doesn’t matter. They will always be hidden during captures.
1 Like
Captures ALT - 1 keybind doesn’t appear to work in studio tests I have Next Gen Studio Preview and New Studio Camera Controls enabled.
Also please consider making it so when you click and hold/tap and hold on the capture button it opens up a settings menu so you can configure if you want to hide GUI/players etc.
Also please add a setting to save directly to file. I don’t want to have to go to captures and click download every time I take a photo if I want to preserve it.
It seems like CaptureBegan and CaptureEnded aren’t fired when we use :CaptureScreenshot(). Is this intentional or will it be resolved in the future? Are there any workarounds?
Hey sorry for the radio silence here. I’ll follow up internally to see where we’re at and update this message when I know. Thanks for the reminder.
1 Like
At the moment, this is intentional but it might make sense to not hide SurfaceGui and BillboardGui if HidePlayerGuiForCaptures is set to false. That way, you could hide whichever specific GUIs you’d like when the user capture is taken. I’ll check if this makes sense on our end.
1 Like
Really hoping it’s possible to control each of them individually. Generally I find that surface GUIs (and maybe billboard GUIs) are something i wouldn’t want hidden because they’re part of the 3D world and can be an important piece of the scenery. Being able to control the 3 separately would be great, but if that’s not possible then just having them not hide when HidePlayerGuiForCaptures would allow us to do that work ourselves, whereas right now it’s impossible to keep them during captures.
2 Likes
Unfortunately this is likely due to studio having different keybinds than experiences in general. I’ve found the best way to test alt + 1 keybind related logic is to spin up an experience to test.
Noted, thanks for the feedback. The hold interaction is currently occupied by draggability of the button for touch enabled devices, released yesterday. But we’re always thinking of ways to expand user optionality, especially if we introduce video capture.
Will keep in mind, thanks for the feedback.
You might be interested in the bulk save functionality that appears on the mobile app. It can be accessed by going to the captures tab in the in-experience menu and pressing the gear icon. In there, you can select multiple screenshots and save to device memory all at once. This may be a good signal for us to expand that functionality to desktop.
It’s not as directly related to the capture feature, but the selfie mode dev module also allows developers to enable users to save screenshots directly to their devices: Selfie Mode | Documentation - Roblox Creator Hub
This is intentional. CaptureBegan and CaptureEnded are for user-initiated captures. CaptureScreenshot is for developers to initiate screenshots in the experience, so developers would be in control of when the capture being taken. You can pass an onCaptureReady callback into the method to determine when the capture has ended.
3 Likes
Will we be able to save captures (or allow a player to upload their capture to Roblox and get a permanent image id from that) similar to The Haunt? The idea is you have a camera tool and you can snap photos that save into a book.
We want to make this happen, and one of our goals for The Haunt was accelerating some of the work we needed to make this available to developers. There are still a few things we need to figure out before we can open this up so I’d estimate that we will be able to release an API for this early next year.
1 Like
Thanks for your patience, I have a small update on this. At RDC, we announced that we’ll be introducing functionality to enable video capture for developers. As part of this change, we’ll likely roll forward by creating a new API that can universally take screenshot captures, take video captures, etc. This new method would also be an upgrade from the existing CaptureScreenshot method in that it would automatically manage memory.
To sum it up, we’re likely to create a new method to capture screenshots, and this method will address the memory leak issue.
2 Likes