FE_Builder_GBA -- If you have any questions, attach report7z

[7743]

Finally it is your turn.
In the meantime, I want to check the problem.

Can you help me solve the problem with the following patch?
If this doesn’t work, please send the ups or report7z

NAME.en=Stat Bar Max Length
INFO.en=Modifies the maximum value that the yellow stat bars properly display\r\nThese bars by default have errors after exceeding 31.\r\nThis patch allows the bars to display 63 in each stat.\r\nHowever, if this is set too high, the bar will expand beyond the statbox on the Status Screen.

[Mkol]

Hi! A while back, I made an FE6 + FE7 + FE8 enhancement patch, which is really just a collection of community patches for people who aren’t in the hacking community. However, I recently got a notification from somebody that there was an issue with one of the hacks.

The Casual Mode for FE6 doesn’t work. What is supposed to happen is this: whenever global flag A0 is triggered, characters don’t stay dead. This part works. The problem is that whenever the player closes the game and then reopens it, flag A0 is reset to false. This means that the player has to beat the game in one sitting or they lose access to casual mode

I think that whoever made the patch thought that flag A0 was a flag that wasn’t cleared when the game was turned off. To fix this, I think you would just have to set the Casual Mode flag to a flag that isn’t reset when the game is shut off.

I made a report for this issue here: FE6 (ENG).REPORT.20221004151135.report. To test the problem, all you need to do is enable flag A0 on an English patched FE6 ROM, then turn the game off and load, then load a save to see that the flag has been disabled.

[7743]

It seems that flags are only stored up to 0x8C in FE6.
Therefore, I have created a casual mode patch that changes 0xA0 to 0x8C.
I created ups with new patches re-installed.
https://cdn.discordapp.com/attachments/470029781795078175/1027188111307972708/FE6_ENG.PATCH.20221005203204.7z

[Norikins]

Cormag, Vanessa, Kyle and sometimes Forde freeze upon promotion

FE1 style.REPORT.20221003231419.report.7z

[7743]

Certain units freeze the game upon using a promotion item. In testing chapter 3C, Vanessa, Cormag, and Kyle have this behavior. However, in the given save file, Forde also causes a freeze. The likely cause is a slightly modified version of the “Gaiden Style Promotion Gains” ASM hack.

The cause is an invalid jump code in the Promotion routine.
Look at 0x0802bdd6 in the ApplyUnitPromotion(0x0802BD50) function.

If it is caused by some strange code you created, then you have the wrong label name for the ASM bne.
This is why the code is generating a jump to itself.
Therefore, when this bne jump is established, an infinite loop is generated.

[Norikins]

I was attempting to replace the jump code in macplustree’s original asm which would only reset the level if promoting from an unpromoted to promoted class.

[FE8] Gaiden Style Promotion Gains ASM Hack

Paste the following at 0x2BD50 in a hex editor of your choice: F0 B5 04 1C 08 1C ED F7 75 FB 06 1C 0B 23 F1 5C 12 22 A3 5C 8B 42 01 D2 C9 1A 5B 18 13 21 71 5C 8B 42 00 DD 0B 1C A3 54 00 27 0C 23 DB 19 F1 5C 14 22 D2 19 A3 56 8B 42 01 D2 C9 1A 5B 18 14 21 C9 19 71 5C 8B 42 00 DD 0B 1C A3 54 01 37 04 2F EB DD 00 27 28 21 2C 22 C9 19 D2 19 63 5C B2 5C 93 42 00 DA 62 54 01 37 07 2F F3 DD 66 60 A8 6A 08 21 09 04 01 40 00 29 0E D1 01 21 09 02 08 40 B2 6A 11 40 00 28 FE D1 00 29 0A D0 20 7A 14 28 02 …

If there is no easy solution, I will just use the promoted class flags. I didn’t want exp gain to be affected by promotion which is why I unflagged them.

[7743]

Ask that author.

[MovingStone]

Hi, I had a problem with stat boosting items. I added an item called “Hanan Tear” that is supposed to boost all stats. But no matter what I do, it’s always unusable. I set up the “When Used” menu to make it a stat booster, and even changed it to be treated as the Power Ring, but it never works. How should I fix it?

Report:
https://drive.google.com/file/d/1TzB8xHriCZtJ81d3UCkBFmc1L2N9Cc_4/view?usp=sharing

[shinybidoof]

Here is ups of vanilla fe8 w/ skill systems (most recent version) and luck max changed to 50 but bar length doesn’t change.

luck bar issue PATCH.20221006161502.ups

[knabepicer]

You set its useability to a stat booster, but did not assign these other pointers:

[7743]

There is no problem at all in vanilla.
Therefore, it is confirmed that SkillSystems is doing something wrong.
I’ll look into it later.

[7743]

Finally found the culprit in SkillSystems.

.macro draw_luck_bar_at, bar_x, bar_y
  mov     r0, r8
  blh     LuckGetter
  mov     r1, r8  
  mov     r3, #0x19
  ldsb    r3, [r1, r3]     
  str     r0, [sp]     
  mov     r0, #0x1e  @cap is always 30 <<<<<<<<<<<<<<<<<
  str     r0, [sp, #0x4]    
  mov     r0, #0x6   
  mov     r1, #(\bar_x-11)
  mov     r2, #(\bar_y-2)
  blh     DrawBar, r4
.endm

add patch

NAME=Stat Bar Max Length Luck Caps(SkillSystems)
INFO=Modifies the luck's maximum value that the yellow stat bars properly display\r\nThese bars by default have errors after exceeding 31.\r\nThis patch allows the bars to display 63 in each stat.\r\nHowever, if this is set too high, the bar will expand beyond the statbox on the Status Screen.\r\nWith the skill system, the upper limit of the luck bar is hard-coded, so it needs to be handled separately in this patch.\r\nDefault is 30\r\n

[vilk]

Hi, i’ve run into what seems like a bug with FE7. After editing text, characters’ mouths won’t move when they speak. This is a fresh rom with no changes made to it:

This is after changing only this dialogue (and applying anti-huffman patch):

This doesn’t happen when editing FE8. I think it might have started happening some time this year because i remember being able to edit text in FE7 without trouble before, but i don’t have all my files from back then so i can’t be entirely certain. I have tried two different roms but the same thing happens with both.

[Contro]

Just to be sure, has [ToggleMouthMove] been used at all? What happens if you use it right before Bazba speaks? (As a check to see if it’s off or not).

[7743]

Please send ups or report7z so I can check the phenomenon first.

[shinybidoof]

Worked perfectly, thank you!

[vilk]

@Contro

Just to be sure, has [ToggleMouthMove] been used at all?

No. Literally only those words (and installing anti-huffman patch to allow that).

@7743

Please send ups or report7z so I can check the phenomenon first.

Here.

[7743]

This “[OpenFarLeft]” is the cause.
If you remove it, it will work correctly.

If you really want to write “[OpenFarLeft]”, it is recommended to put it at the beginning.

[vilk]

Huh! That is a very simple solution. Thanks!

[redlightning]

I had a virtually identical issue in the past, and it taught me to always double check the source text window once you run into any dialogue issues. I’ve never figured out why, but sometimes the text editor just leaves in a ghost command or inserts an extra something when you’re using the simple editor.