Thank you for sending the data.
I analyzed the data and found some problems.
I may not be able to completely remove the error from this ROM.
I'm sorry, could you redo from the last backup in February?
For individual problems, we have taken measures at the latest version.
(It was fixed in ver 20180320.20.)
However, there are still other problems with this ROM.
On the reason why abnormal data number is displayed in battle animation.
The cause is caused by I being halfway compliant with FEditor's Hint Length.
FEditor writes the number of data to the table outside the table (table address - 0x4).
FEBuilderGBA used this value if it had this value.
In some Hack ROMs, invalid data may be inserted in the middle.
In that case, the search routine of FEBuilderGBA to continue searching until an invalid value comes up is because we could not find the termination data of battle animation because of invalid data sandwiched in the middle.
Therefore, if there was a hint on the number of data of FEEditor, it was referring.
However, its value is 4 byte number,
And it is written out of the table (table address - 0x4).
Therefore, I do not know if this value is a reliable value.
Ignored if it was a strange value (0xFFFF or more).
However, this time happened to be less than that value,
but this problem occurred because quite a large number of data was written.
As a result, searching for data beyond the end of the data was executed.
I do not know why a large value was written.
Originally, the address outside the table (table address -4) is outside the frame, so there is a possibility that another data may be written.
I should not use this address.
I would like to avoid using the FEEditor's hint area anymore.
Since it will be necessary when opening a Hack ROM created before, I will have it in the option.
As this may cause problems, turn it OFF by default.
As a result, the search for an abnormal number of data will no longer occur.
About data securing logic.
I am changing it in March.
It works properly in my test environment, but this may be related to something.
I definitely want to secure safety, so I think I will return to the logic before this.
When data was placed at the end of the ROM, we modified it so that you do not have to reserve it when resizing the data.
This routine saves ROM size.
However, this may cause something bad results.
Once I cancel this fix.
About problems that can not be backed up.
Here too, it is correct in my test environment.
However, we are revising it in the second half of February.
There was a problem that the archive library you use does not work properly if there is a directory written in French.
Therefore, in order to avoid directories written in French, we changed to routines to get from absolute path routines, if possible, relative paths.
This may be the cause.
I did not take into account the possibility of the compression routine failing during backup.
If backup data can not be compressed with relative path, I decided to try compression with absolute path.
If it fails even with an absolute path, I saved the data as uncompressed.
Also, if it does not work, in addition to the condition that the compressed file was not created when an error is returned,
Under the additional condition, if an abnormally small file of 1 k bytes or less is created, it is treated as an error.
With this fix, I believe it will not occur anymore.
About another problem of this ROM
There is data that the frame data was damaged around the time of the battle animation.
Also, when you start with NewGame, it freezes at the world map start event.
After chasing with the debugger, it is falling with the following order.
However, there is no strange thing about this order and its order.
Looking at the arguments when the 60C3 (C360) instruction is invoked, there is a difference in work memory arguments.
ROM with bug
I do not know why this work ROM has different work memory.
I am not confident that I can solve this bug.
So, I am sorry to you, will not you do it again from the backup in February?