[Solved] Fire Red compiling error

[Krendall]

I tried to compile my latest changes (using msys2) and I keep getting this error:

tools/agbcc/bin/agbcc.exe <flags> -o build/firered/src/cereader_tool.o src/cereader_tool.c
src/cereader_tool.c:11: size of array `EReaderTrainerTowerSetFreeSpace' is negative
make: *** [Makefile:302: build/firered/src/cereader_tool.o] Error 1
make: *** Deleting file 'build/firered/src/cereader_tool.o'

I haven't even touched that file, but here it is up to the error line:

#include "global.h"
#include "gflib.h"
#include "util.h"
#include "save.h"
#include "cereader_tool.h"

#define SEC30_SIZE  (offsetof(struct EReaderTrainerTowerSet, floors[4]))
#define SEC31_SIZE  (sizeof(struct EReaderTrainerTowerSet) - SEC30_SIZE)

// The trainer tower data exceeds SECTOR_DATA_SIZE. They're allowed to use the full save sector up to the counter field.
STATIC_ASSERT(SEC30_SIZE + SEC31_SIZE <= SECTOR_COUNTER_OFFSET * 2, EReaderTrainerTowerSetFreeSpace);

I have no idea what could be causing the problem, how to figure out what the problem is, or how to fix it. Please help!

 

[Lunos]

I tried to compile my latest changes (using msys2) and I keep getting this error:


I haven't even touched that file, but here it is up to the error line:

#include "global.h"
#include "gflib.h"
#include "util.h"
#include "save.h"
#include "cereader_tool.h"

#define SEC30_SIZE  (offsetof(struct EReaderTrainerTowerSet, floors[4]))
#define SEC31_SIZE  (sizeof(struct EReaderTrainerTowerSet) - SEC30_SIZE)

// The trainer tower data exceeds SECTOR_DATA_SIZE. They're allowed to use the full save sector up to the counter field.
STATIC_ASSERT(SEC30_SIZE + SEC31_SIZE <= SECTOR_COUNTER_OFFSET * 2, EReaderTrainerTowerSetFreeSpace);

I have no idea what could be causing the problem, how to figure out what the problem is, or how to fix it. Please help!

If you grep up struct EReaderTrainerTowerSet you will find its declaration in include/cereader_tool.h.
Did you modify any of the variables or constants used in that particular struct?
For example, did you perhaps raise the value of MAX_TRAINER_TOWER_FLOORS, which is located in include/constants/trainer_tower.h?
If you did, try setting it back to its original value, which is 8.
That's about the best I can think because I never messed with the Trainer Tower myself.

 

[Krendall]

If you grep up struct EReaderTrainerTowerSet you will find its declaration in include/cereader_tool.h.
Did you modify any of the variables or constants used in that particular struct?
For example, did you perhaps raise the value of MAX_TRAINER_TOWER_FLOORS, which is located in include/constants/trainer_tower.h?
If you did, try setting it back to its original value, which is 8.
That's about the best I can think because I never messed with the Trainer Tower myself.

I didn't do anything with any of those files. I might have glanced at one or some of them, but I didn't change anything. I certainly didn't save anything when closing them.

Looking at that problem line, I take it it's assigning the value to EReaderTrainerTowerSetFreeSpace? If not, do you know what, exactly, it is doing?

I've also been trying to find where SECTOR_COUNTER_OFFSET is defined, but I'm having trouble finding it. Of course, how a formula like that can return a negative number is beyond me.

 

[Lunos]

Looking at that problem line, I take it it's assigning the value to EReaderTrainerTowerSetFreeSpace? If not, do you know what, exactly, it is doing?

So, Pret's decomps use asserts which are operations used to verify things, such as whether a variable or the sum of certain constants or whatever are bigger than they should be.
The assert that is located in src/cereader_tool.c and that is giving you an error here verifies if the sizes of constants and structs related to the game's savefile have the right value in your codebase.
They don't have the right size, and that's why you're getting an error.
The assert is calculating if the value the codebase gets from doing SEC30_SIZE + SEC31_SIZE is equal or smaller than SECTOR_COUNTER_OFFSET * 2.
In your case, the result must be bigger and that's why the assert makes the compiler throw an error at you to warn you about it.
This type of warning is a serious one though, since it deals with savefile sectors, so you should definitely not ignore it and actually try to sort it out somehow.

Without knowing what changes did you perform in your project it's gonna be very hard to give you more specific help. The only thing I can tell you is that the assert wouldn't pop up out of the blue and for no reason, otherwise every single other person using Pokefirered including myself would have come across it too.

 

[Krendall]

So, Pret's decomps use asserts which are operations used to verify things, such as whether a variable or the sum of certain constants or whatever are bigger than they should be.
The assert that is located in src/cereader_tool.c and that is giving you an error here verifies if the sizes of constants and structs related to the game's savefile have the right value in your codebase.
They don't have the right size, and that's why you're getting an error.
The assert is calculating if the value the codebase gets from doing SEC30_SIZE + SEC31_SIZE is equal or smaller than SECTOR_COUNTER_OFFSET * 2.
In your case, the result must be bigger and that's why the assert makes the compiler throw an error at you to warn you about it.
This type of warning is a serious one though, since it deals with savefile sectors, so you should definitely not ignore it and actually try to sort it out somehow.

Without knowing what changes did you perform in your project it's gonna be very hard to give you more specific help. The only thing I can tell you is that the assert wouldn't pop up out of the blue and for no reason, otherwise every single other person using Pokefirered including myself would have come across it too.

So it is doing what I thought. Good. I'm getting at least a small handle on how some of this code works. It's been a long time since I did any kind of programming, and what I did wasn't that advanced in the first place.

I'll try to sort this out, then. Worst case scenario is to just re-download the game files and start over. It wouldn't be that huge a loss at this point. What I should have done is backed up my last working compiled files, but hindsight, and all that.

EDIT:
FIXED! So, it turns out making Pokémon names longer is more involved than simply setting the string length from 10 to 12.

 

[Lunos]

FIXED! So, it turns out making Pokémon names longer is more involved than simply setting the string length from 10 to 12.

Ah. Yeah that makes sense.
The amount and the characters that form a Pokémon's nickname are all stored in the savefile, just like most if not all the Battle Tower related data.
Increasing the number of characters in a Pokémon's nickname would shift whatever data comes after it in the savefile structs (in this case SaveBlock1 and SaveBlock2 specifically, both located in include/global.h). Consequentially, if you don't have enough free space in those structs stuff would get pushed outside.
Asserts like the one in src/cereader_tool.c are added exactly to prevent users accidentally breaking their games like that.

 

[Krendall]

Ah. Yeah that makes sense.
The amount and the characters that form a Pokémon's nickname are all stored in the savefile, just like most if not all the Battle Tower related data.
Increasing the number of characters in a Pokémon's nickname would shift whatever data comes after it in the savefile structs (in this case SaveBlock1 and SaveBlock2 specifically, both located in include/global.h). Consequentially, if you don't have enough free space in those structs stuff would get pushed outside.
Asserts like the one in src/cereader_tool.c are added exactly to prevent users accidentally breaking their games like that.

Yeah, I figured it was something like that when I fixed it. Out of curiosity, would changing name lengths even be possible, then? I mean, I get that it would probably be an involved process of changing the savefile structure and all, I'm just curious if it's something that can be done.

 

[Lunos]

Yeah, I figured it was something like that when I fixed it. Out of curiosity, would changing name lengths even be possible, then? I mean, I get that it would probably be an involved process of changing the savefile structure and all, I'm just curious if it's something that can be done.

Yes, of course it can be done. You just have to remove stuff from the savefile structs to make room for the extra space that new name characters take.
For example, in the SaveBlock1 there's a handful of variables that are entirely unused and simply take space pointlessly, such as unused_632, unused_348C, the Trendy Man from Ruby and Sapphire that was carried into FRLG's codebase and such.
You either comment those out or remove them, and you get a certain amount of free KBs to use however you want.