This defines a bunch of data, and finally stores it as written strings, so not constant access.
Is this a completely ridiculous approach, or a better way with structs!?!
It is completely ridiculous. With DS data structures, you convert to and from strings because there was no built-in way to nest lists in grids (or any other heterogenous pairing other than map-list). With structs and arrays, they can nest inside each other in their native live states, without converting to and from strings.
It looks like structs would shortcut accessing the data ... But storing/managing it remains as laborious and robust as ever
Serializing structs and arrays has NOT been difficult since the introduction of
json_stringify
and
json_parse
in GMS 2.3.1.
Often these two functions are coupled with these corresponding helper script functions for use in files:
GML:
function json_export(data, filename) {
var _jsonStr = json_stringify(data);
var _f = file_text_open_write(filename);
file_text_write_string(_f, _jsonStr);
file_text_close(_f);
}
function json_import(filename) {
var _buffer = buffer_load(filename);
var _jsonStr = buffer_read(_buffer, buffer_string);
buffer_delete(_buffer);
var _jsonData = json_parse(_jsonStr);
return _jsonData;
}
Given that your top-level data consists only of structs, arrays, reals, strings, undefined and boolean inside, saving it to a file is a single function call:
GML:
json_export(global.ITEM, working_directory + "items.json");
And so is loading it from a file:
GML:
global.ITEM = json_import(working_directory + "items.json");
Robust, but not at all "laborious". At this point, saving or loading data with any more than a single line now looks ridiculous to any genuine post-2.3 GML developer.
Perhaps I'm mistaken, but I'm not seeing the use of structs here with "realistic" or large multi-dimensional data
I don't understand this sentiment. Every dimension is just a level of nesting. How good something is for multi-dimensional data depends on how well it supports nesting and serializing nested data.
Structs and arrays excel at nesting and deep serialization. They can be nested at will in their native live states (i.e. WITHOUT having to transform to/from a string the way you did in your example), have a convenient literal syntax, and can be deep-serialized using a single function call. They are ideal for multi-dimensional data, and have since become the medium of choice for informed post-2.3 GML developers.
Data structures suck at nesting and deep serialization. They need manual marking for lists and maps, don't nest properly any other way (e.g. lists in grids), and their opaque serialization format is only one layer deep (e.g. you can't
ds_grid_write
a grid of lists without manually handling the lists inside). They are a pig to use for multi-dimensional data, and their utility is completely nullified for experienced users who have spent time studying post-2.3 GML.
So it's all constant access in RAM? Idk I'm not sold that structs are a cure all for this
I fear if I converted all of my stowed away written data (for some reason?) to constant access structs, the low-end laptop players would be screeeeewed.
You are much more likely to screw low-end users with code related to graphics or sound, than code related to structs.
I appreciate the structs and the cool stuff they can do as light-weights and with functions, but eh... Idk about replacing enum/DS.
DS data structure abandonment is happening, and the only people not noticing it are legacy GML dinosaurs and novices using tutorials too old for their own good. In addition to structs and arrays becoming more full-featured, an unintended change in the DS read/write format broke a range of commercial projects in the GMS 2.3.1 timeframe. Everyone who used DS data structures for saving data lost user data, and it could not be easily remediated because of the opaque DS read/write format. The more modern JSON-reliant demographic was largely unaffected.
Enums and macros will still have their uses, but the "arrays-pretending-to-be-structs" use case will be losing its halo.
Regardless, a variable containing a written DS (a string) takes the SAME memory as a open / live / constant access DS?
Absolutely not. A live DS data structure will always be smaller than its DS-write string equivalent. It is like how a buffer is always smaller than its Base64 representation, or how a struct/array is always smaller than its JSON representation.
On top of that, the current DS read/write format is opaque and notoriously bloated. See for yourself how much extra goes into it:
GML:
var list = ds_list_create();
ds_list_add(list, "foo", "bar", "baz");
show_debug_message(ds_list_write(list));
ds_list_destroy(list);
Code:
2F010000030000000100000003000000666F6F0100000003000000626172010000000300000062617A