This is the problem.
for ( int i = 0; 1 < 255; i++) {
It is true that Link->Item indices aren't validated as they ought to be, but that would still hang the game.
Oops. I'm shocked that I didn't see that. Managed a numeral 1 instead of an i there. Infinite for loop, huzzah.
So right, looks like it was my fault.
Now I need to go back and see if fixing that has any other issues, but what I've done works, and gives me a second utility function to use for other purposes.
---
I aced it out: I had another typo set there, with > instead of < in a few spots. That's the result of typing with a cat sitting next to the laptop, on my chest.
I was still shocked that ZC died, entirely. Usually any infinite loop would cause it to freeze, not terminate; but I suppose there are exceptions.
So, right. If I ever see ZC do that again, I'll look for a random numeral where a variable belongs.
---
The final functions are as follows:
void RestoreEquipment(){
//int state;
for ( int i = 0; i < 255; i++ ) {
if ( Link->Item[i] == true && Equipment_BAK[i] == false ) {
Link->Item[i] = false;
}
else if ( Link->Item[i] == false && Equipment_BAK[i] == true ) {
Link->Item[i] = true;
}
//Waitframe();
}
}
void BackupEquipment(){
//int state;
for ( int i = 0; i < 255; i++ ) {
if ( Link->Item[i] == true && Equipment_BAK[i] == false ) {
Equipment_BAK[i] = true;
}
else if ( Link->Item[i] == false && Equipment_BAK[i] == true ) {
Equipment_BAK[i] = false;
}
//Waitframe();
}
}
I likely don't need those if / else statements, but ZC can become angry when modifying Link->Item if you don't use them, so they're required in the restore function. I left them in the saving function for my own peace of mind.
As to why there is a commented out 'state' var there, it's for future use with BackupEquipment(int state). Just a reminder to do that, for future multiple states.
I think a boolean array gets initialized as false anyways but ya its probably a wise idea to have a function that wipes and initializes arrays. I think Zoria thought that putting {false} would initialize the whole array to false but really I think that only would do the first array position.
The array is not initialized properly. You need to initialize every element of array, like here:
bool BackItems[256];
for( int i = 0; i<256; i++){
BackItems[i] = false;
}
Not true... You can't declare an array with a specified index size in ZC, without declaring at least one index value. The way that I do it, is the way that ZC expects me to do it, and that's why I have stuff like:
I stand corrected.
---
If you want an array with values other than the default, you'd need to wipe it with a for loop. Thus, if my default value is 'true', I'd need to do that, which is why I code boolean arrays around false being their base.
The same applies to float, or int arrays. If I needed them to initialise with each element !=0 , then I'd need to perform an array-wide change like that, but I try to code myt functions around 0 as a default. There are only a few places where '1' as a default is required, such as searching some ZC (internal) arrays, and for those, it'd be handy.
That of course, primarily applies to nesting arrays into functions. I'll probably need to do that when I write the backup tables for Screen->NPCs, and all of their associated arrays (NPC_Weapon, etc.) and to track existing EWeapons, and such; but things like FFCs, and ghosted enemies won't obey these types of commands, unless I hardcode them to report all of their vars to other arrays, and that mates, will become messy.
The best solution I have there, is to track the position of FFCs, and hope for the best, because trying to savestate exactly what a ghosted enemy is doing would be painful, and this isn't meant for that.
I might do that for my own scripted enemies, and bosses, to make playtesting/bugtesting them easier, but I'd need to set up arrays for BossPhase, and such, and have them report to that array, so that the game can restore to the player, while the ghosted enemy is doing a function that I need to debug.
[ ...]
bool checks[4096]={false};
...does work. Index [0] is set to false manually, and indices [1] to [4095] are set to false by the compiler.
Other compilers permit you to declare an array of a fixed size without declaring any of its elements, but ZC/Buffalo does not.
The alternative, or manually entering false, or cipher elements, would be hideously tedious.
I don't think that Saffith or Gleeok could fix this, as it's a compiler quirk.
I am however curious if returning optimisation is useful in ZC with large arrays, and how large an array needs to be before it becomes important; e.g.:
for (int i = 1; i < 200; ++i)
...versus...
for (int i = 1; i < 200; i++)
The overall result is the same, but one may favour one over the other, and one of the two may provide more optimal performance. Not that it matters in general. I use i++ or i-- in my for loops most of the time.
Edited by ZoriaRPG, 10 May 2015 - 09:01 AM.
