Originally Posted by
Downloader
Calling a setter? That's not what happened.
I already compensated and shortened the script with a combo position for instead of writing a comboat(x,y) and shortened it into a 0-175 for instead.
Then I went and wrote out hundreds of lines of code to save the data and set it back at the push of a button in the same similar fashion as I wrote out in my example code for a hypothetical situation and got the results I was looking for which in no way "called a setter" but instead saved the combo data of every combo on an entire map by equating their values to a combo number on an array just as I described.
The only difference is that I had to manually write an array for every individual screen instead of an array that accesses other arrays as I had suggested for a future release.
I did this because the maps indices are limited to the point of 256 total maps, whereas writing all combo data to a series of arrays bypasses that limitation.
Also, I didn't call setters and expecting a return, those lines of code would in fact write to an array, not return anything.
2.60 might support some form of shorthand format for invoking pseudo-2D arrays, but this will still use multiple arrays within the scope in which it is defined. This is a fatal flaw in ZC, as there are only 255 free global registers, and thus, every global array reduces the free registers for scripts, by one.
@Grayswandir
was working on syntax to allow it, but, at a global scope, woud need to be careful, and it is just a shorthand way of array index offsets.
The error in your code, is in this line:
Code:
ComboData[screen][comboposition]=Game->SetComboData(Game->GetCurMap(),screen,comboposition,ComboData[screen][comboposition]);
Note how you call SetComboData() in an assign here.
If you want to save stack space, define your combo arrays inside functions, per map. That way, you can populate one global array using a function with the combos from any virtual map, at any time.
The 2.54 ZScript spec allows direct access to mapdata and combodata:
Code:
combodata cur_map_combos[128*176]; //array size cap is 214748, so you could store four maps per array not including layers
mapdata m;
bool StoreScreenCombos(in map)
{
for ( int q = 0; q < 128; ++q )
{
m = Game->LoadMapData(map,q); //(map,screen)
combodata cd;
for ( int w = 0; w < 176; ++w )
{
cd = Game->LoadComboData(m->ComboD[w]); //Could also store as an int if you want. (All datatypes can now be global arrays.)
cur_map_combos[q*128+w] = cd;
}
}
return true;
}
...Something like that. I may increase the maximum map count, in which case, it will be possible to clone maps using mapdata, combodata, and other resources.
There is no logical way around the array size limit, though. It is a ZC maths cap, because all values are fixed-place at (val/10000), so the 32b system limit is the controlling factor. Thus, even with 2D arrays, you would not be able to have a 2D array with a total size greater than 214748 indices (in any combined format).
int myArr[107374][2] or similar, would be as large as you could go. This works for arr[256][256] and similar, but not for an array to hold that many variables in one place.