thanks.
However, when change anime to animation,
The number of characters becomes too long, and it does not enter the button.
Therefore, leave the anime as anime.
All other things were adapted.
The mystery of JavaSerialize has been solved.
0x75 0x71 0x00 0x7E 0x00 0x??
I did not understand the part “??”.
This part is obtained by 0x7E0000 + object_id.(big endian 3byte)
In FEEditorAdv, it depends on the number of animation sheets in front.
byte object_id = 0x08 + (sheets.Count * 2);
For example, if the number of sheets.Count is 4,
byte object_id = 0x08 + (4 * 2);
object_id == 16 That is, it becomes 0x10.
Therefore, it becomes the following value.
0x75 0x71 0x00 0x7E 0x00 0x10
Err, do you mean these buttons?
“Animation” fits fine. Maybe it messed up on a different button though, Idk.
Thanks!
Ah, gotcha. Good catch, then!
Yes, however the 2 .ups that I send you before has all the patches I inputted except for the fix to the skill system made by arch.
I’m pretty sure v0 can be set. if you don’t set velocity, I think the default value is 127. much like how if you remove all VOL commands the default value is 127.
Hey I was wondering if we could have the option of disabling the disassembler popping up when pressing “A” in the Hex Editor. It gets somewhat annoying having to close it anytime i press the A key on my keyboard.
This is a bug.
It was fixed in the latest version.
I’m pretty sure v0 can be set. if you don’t set velocity, I think the default value is 127. much like how if you remove all VOL commands the default value is 127.
the v000 instruction exists.
About this, I was wrong.
.equ v000, 0 @
However, even though, I think that the specification of VOL 0 does not become an explanation of the problem which is invalidated by velocity designation.
In order to solve this problem,
We need to investigate the sound source implementation code and see how VOL and velocity affect the final volume.
In order to solve the conflict of work memory among patches, we need set rules.
It is necessary to clarify that this work memory will be used in my patch.
It is like a port number in TCP or UDP.
It is like a traffic rule.
It is necessary for each person to make a statement and give way to each other.
Otherwise, conflicts in memory space will continue in the future.
Thanks for making this program, it’s very useful. However I encountered an issue. I was editing the English translation of FE6 and made a UPS patch, specifying the original Japanese game as the original. After opening another game and reopening my first game, I noticed that all the English text in my edited ROM seemed to be in Japanese.
On further investigation the game itself was still in English, but something seems to have changed with the fonts with Japanese characters overwriting/being substituted for the English letters. The only thing that comes to mind is making the UPS patch but I didn’t think it would affect the ROM directly. Oh well, lesson learned.
EDIT: Thankfully your program makes backups so it wasn’t that big of a deal.
- The backups also have the japanese text, maybe it was a different issue and it was seen because I closed and reopened FEBuilder. At least I can still play it.
I think it’s a translation error, but parts of your explanation doesn’t make sense.
There’s limited space in RAM, and if different patch makers use the same area they’ll obviously conflict. So you need each patch to report which area it’s using and have a way to move them around until there are no conflicts.
Please apply the TBL file.
FEBuilder GBA automatically adapts if TBL is required.
Whether TBL is necessary or not is judged by the name of Plain tile.
It is because it is a hard-to-change part.
I think that you have rewritten this part.
Therefore, TBL is no longer adapted automatically.
//config/data/tbl_cond_ALL.txt
//NAME VER enc POINTER VALUE
FE6U 6 2 60D010 82 BD 82 E6
FE6CN 6 1 60D010 8C E2 85 E1
FE7CN 7 1 C542F4 8D FC 86 87
FE8CN 8 1 8617CC 8D BD 85 F9
First of all, there are things you have to understand as a premise.
Officially, only FE 6 comes out in Japanese.
The English version of FE 6 exists as the Japanese version of FE 6 Hack Rom.
The problem is that FE 6 has no alphabetic font.
For this reason, alphabet fonts are forcibly mapped on the Japanese fonts of FE 6.
For this, TBL is used.
1 Like
In order to eliminate the collision accident of the RAM area, we made a article to write down the RAM area used by each patch.
I would like you to write skill patch information.
http://feuniverse.us/t/information-on-the-ram-area-that-the-patch-uses-independently/
Thank you very much for the explanation 7743. I get it now, that makes sense since I did change the Plain tile name.
It was fixed in the latest version. (ver 20180218.12)
Please update , and apply break_save patch.
How to make victory conditions
Japanese
http://ngmansion.xyz/wiki/hackfe/index.php?解説/FEBuilderGBA/勝利条件イベント_JP
English translation
http://ngmansion.xyz/wiki/hackfe/index.php?解説/FEBuilderGBA/How%20to%20make%20Victory%20condition_EN
I added QA.
http://ngmansion.xyz/wiki/hackfe/index.php?QA_EN
Question:I can not automatically update FEBuilderGBA.
Two cases are conceivable.
Together, the latest version has been fixed.
Please re-download again.
http://ngmansion.xyz/wiki/hackfe/index.php?解説/FEBuilderGBA/How%20to%20download%20FEBuilderGBA_EN
1.When trying to update, version: 0 is displayed.
It occurs in the cultural area where the decimal point is represented by “,”.
3.141592
3,141592 //This case.
FEBuilderGBA uses the decimal point for the date part of the version number.
In the case of a cultural zone where the decimal point is written with “,”, acquisition of the version number fails at the time of update.
The Double.tryParse function will result in an error and will eventually return 0.
As a result, the version number becomes 0, and the update fails.
This problem has been fixed in the latest version.
2.When using version earlier than 2017 / November.
Because the update mechanism has been changed, automatic update can not be done.
Please download it manually,again.