Alright, so this one’s for the slate & programming teams.
Would the team consider implementing a way to read and write in capture data for slate / UI menus to use, without having to go through the content browser? Or, if failing that, would the devs consider allowing for SceneCaptures, Matinee Movie Dumps and/or tiledshots to be stored in the content browser at runtime for slate and native access?
I was looking through FileManager.h and FileHelpers.h based on an old discussion I had with Bob Tellez. There are some functions in there related to file handling, but there doesn’t appear to be much you can really do with the list of functions currently available. You have your basic move/copy stuff and accessor functions for file handling. But there’s nothing really in terms of reading or direct writing to files, or the serialization (and encryption!) of data as might be expected from BasicSaveObject/BasicLoadObject. If it’s handled somewhere else and I’m just unaware, I’d appreciate some insight.
Anyways, I’ll point to an example of how this might be used in practice. in my DataHive project, I wanted to enhance my current save system by getting a snapshot of the current save area and reading them into my Flash save menu*. I would give the saved thumbnails a specific naming convention to distinguish them from other files. In this way, the thumbnail system would be completely procedural. Unfortunately that proved to be unworkable b/c of how UE3’s content packaging system was designed.
Now in terms of implementation, one way is to provide accessor functions for reading in files and doing the usual vetting to check for bad or invalid content. Treat it almost like a content browser import, except this would operate at the native level.
Or if direct reads are too risky, then perhaps allowing for a new and improved screencapture2D, matinee dump, or shot command to save its captures into the content browser at runtime.
The basic premise here would be that you could create a file that is vetted by native architecture, and thus is assured to be clean (or as clean as this architecture can make a file…). All that’s left is a way for slate menus, blueprints, etc. to read in the newly generated capture files.
-
(Yes, I’m aware Scaleform isn’t supported anymore, I’m just talking about the general idea now as it pertains to Slate)