One important example would be df.global.world.world_data.region_map, where the size of the array is based on the width of the world, a value that can be found in world_width in the parent struct, with the elements themselves being (pointers to) arrays of a size determined by the world height element.
A trickier case would be the very next element, currently called unk_1c4, which is a 2D matrix with dimensions controlled by the same parameters.
The immediate purpose of the suggestion would be to provide writers/readers of the XML with a standardized method for describing these relations, while the longer term objective would be to allow code and scripts to access the info (imagine gui/gm-editor being able to show the region_map elements for all the world tiles, for instance).
Possible names for such attributes might be ref-count, ref-count1, ref-count2, ref_count3 (taking cues from "ref-target", and "count" for static arrays, for the respective parts). ref-count and ref-count1 would be identical in function, with the difference being that the "1" version would imply to a reader that there are more than 1 dimensions.
The presence of one or more ref-count attributes implies the "is-array='true'" attribute functionality, and thus ought to be mutually exclusive in the .xsd file.
One important example would be df.global.world.world_data.region_map, where the size of the array is based on the width of the world, a value that can be found in world_width in the parent struct, with the elements themselves being (pointers to) arrays of a size determined by the world height element.
A trickier case would be the very next element, currently called unk_1c4, which is a 2D matrix with dimensions controlled by the same parameters.
The immediate purpose of the suggestion would be to provide writers/readers of the XML with a standardized method for describing these relations, while the longer term objective would be to allow code and scripts to access the info (imagine gui/gm-editor being able to show the region_map elements for all the world tiles, for instance).
Possible names for such attributes might be ref-count, ref-count1, ref-count2, ref_count3 (taking cues from "ref-target", and "count" for static arrays, for the respective parts). ref-count and ref-count1 would be identical in function, with the difference being that the "1" version would imply to a reader that there are more than 1 dimensions.
The presence of one or more ref-count attributes implies the "is-array='true'" attribute functionality, and thus ought to be mutually exclusive in the .xsd file.