Thanks. But how time consuming would it be to go ‘the proper way’? I’m no programmer, I learn as I go. Getting into C++ would take forever. And then again forever to learn Unreal’s classes and so on. And all this just for the save system. And how many people are in this boat?
Surprising to see this and other basic stuff overlooked in an engine such as Unreal.
But anyway, maybe I can pull it off with list view, seeing as it should only load what the player sees. If I can keep my save games small I should be fine.
As a complete novice it’ll take longer, but around 2 hours should cover it even with 0 knowledge of c++ (other coding skills/know how still required).
You can find tons of examples of reading files in c++ in just about any sauce you ask google for.
Making/figuring out the function header for the call is probably going to take a good 20m. But the positive thing of it is that is basically in every free c++ script you find out there like Rama BP nodes and similar.
On the rest, personally I think that it’s wholly unthinkable to make any videogame without knowing the basics of coding enough to generate and mange a single c++ class / coding bit (different engine, different languages).
You/anyone else in the same situation should probably re-think the project and pick up the very few basics needed to do simple things like this.
Which also helps you by making you able to snag some code off some old repo and deploy it to your project - say like adding the free Rama BP nodes i mentioned already for instance.
Or implementing a function that uses Doubles instead of floats for more precision, as another example…
But we drift way off topic here.
People who cannot “do” (doesn’t apply to you from what you wrote) end up buing marketplace kits/plugins instead.
While I don’t know any as I write my own stuff, I’m sure there’s tons out there that allow for proper file handling… some may even be free to you, in the form of c++ code you can throw into the engine as a class…
Thanks for the encouragement, but I think 2 hours is optimistic. More like 2 weeks to get an understanding of how it all works.
But anyway, I don’t know if C++ would help here. In order to access any data on one save file, you still need to load the whole save file, right? Say you want to display 5 thumbnails from 5 different save files, you’d still have to load all 5, right? That ‘metadata’ has to reside somewhere on disk, either on the save files or elsewhere.
Unless you can load part of a save file, through C++!?
Right. The native UE saving system in BPs is very undercooked. Almost raw and featureless. Hence this stuff gets to shine.
Say you want to display 5 thumbnails from 5 different save files, you’d still have to load all 5, right?
If I had some huuuge Save Games or too many small SGs to count, I’d create another dedicated SG that contains the data about all other SGs. Think a save game for save games! It contains only the information we want to present to the user, but not the game state data itself.
In a scenario where the player has 250 autosaves, we don’t want to load 250x5MBs to extract the time they last played. Instead, load that 1 tiny dedicated SG and show its content to the player. Once they’re happy with their selection, load the real 5MB thing.
You can read any amount of bytes off of any file, in the case of most save files you have to read the whole thing to undo its compression or encoding (base64 probbaly being the most common to prevent sheer cheating).
Still, if you write a custom file, you can encode portions of it and the. Retreive X numbers of bytes off it knowing it will decode.
It alsk makes it much harder if not somewhat impossible for a 3rd party to guess that X, leading to a somewhat increased Save Editor avoidance.
A thumbnail being data, and data in a save file being at a precise byte location, with some advanced work one can totally have the code pull put the byte blob of just thumbnails from each file without loading the whole thing, provided the encryption permits this.
I’d do a maximum of 5, and if forced to, a list of lists of save files so you can incrementally pull in another 5 tiles as you progress reviewing the history.
Also, make sure the thumbnail is a thumbnail. 124px by 124px is a miniscule amount of data.
1080p is already a significant and mostly useless amount of data when you then sheink it back to a thumbnail ond only display it as 124px wide…
On the other hand, Upsampling fro. 124 to 256 probably won’t look all that different - so you got some possible visually compromising optimiziations you can make if you really need to deal on thousands of thumbs…
.
We don’t really know the scope anyway. 5 is trivial. 5000, not so much. @AllGamesSuck You can also partially automate this process with PanelViews, they only fetch data when a visual needs representation, generating entries on the fly.
124px by 124px is a miniscule amount of data.
It sure is, that’s why I suggested a separate file that tracks just the pertinent bits of the larger save games we’re handling. Load that one file, loop 5000 (wait patiently for a couple of seconds until BPs laboriously churn through that (or move that part to C++ )), send it to a panel view with soft asset refs. Let it handle the rest of the async asset loading.
If the rest of SG file is eventually needed, load that one SG there and then.
I think making a blueprint function to fetch the entry - and running that entry on constructor of whatever is easier
Simply because you can make a button run that, and update the page without having to create a new panel and all that goes with it.
Same difference I suppose.
If you replace array entries with a function you automatically garbage collect anyway, so i doubt either approach makes any practical difference in the end.
)), send it to a panel view with soft asset refs. Let it handle the rest of the async asset loading.