No, 7743, I think he means extending the map sprites to 0xFF for 255 map sprite slots. It seems that some glitches appear when he does it.
@Yami do you have any images of the visual glitches?
Almost. I’m speaking of the idle sprite animations, not the walking ones.
I have a custom sprite on 80 set up correctly with the class but it shows the male Lord sprite in game. Before 80 works fine. 80 and onward displays the wrong class.
1 Like
If I had to guess, and that’s all I can do, it isn’t updating pointers correctly when the map sprite data is expanded. What happens if you do a map sprite at 0x81, 82, etc? I think it’s rolling around from 0x01, 0x02, etc.
Think you’re right. It goes to female Lord afterwards and just cycles through the classes.
1 Like
Good catch. That’s definitely a FEbuilder bug. It’s inserting the images into the rom correctly, but just not calling them in the correct order.
You mean it’s a game bug, not FEBuilder
The 0x80 bit gets shaved off when getting the map sprite id, so it rolls back to 0, 1, 2, 3
there was a thread for fixing this if I remember correctly
Found it:
Precisely:
this post.
1 Like
I see.
Thank you for telling me the patch >> Kirb.
It corresponded with ver 20180310.07.
After updating, apply “Extended to Moving Map Animation 0xFF” Patch.
Quick work! Thanks Kirb and 7743. The patch has made it so the correct sprite shows, but it is not animated. It’s a minor issue, but worth pointing out.
1 Like
I’m not 100% sure the solution in that thread was perfect. I ran into some odd map sprite bugs while using it where standing sprites would turn into different classes. It also had an issue with not allowing you to display the full 255 standing sprites, but that wasn’t an issue at the time since there weren’t enough custom standing sprites in the community to reach that number back then.
2 Likes
It seems necessary to change it other than this address.
Even for this address, I did not notice that the discussion continued.
0x26A52:0x00 0x20
I fixed the patch.
Please update to ver 20180310.09.
Then adapt this patch again.
Version 20180312.23 added a function to Automatic detection of the bug from the backup data.
Automatic detection of bugs by 3 points DIFF
http://ngmansion.xyz/wiki/hackfe/index.php?解説/FEBuilderGBA/Automatic%20detection%20of%20bugs%20by%203%20points%20DIFF_EN
FEBuilderGBA always gets backed up when writing changes to ROM.
If you save this backup without erasing, the backup data gives you a hint for finding bugs automatically.
If you encounter difficult bugs that cause the game to freeze, you can use the “Tool-> Difference Debug Tool” to automatically infer the problem by comparing it with “latest backup data that works correctly”.
2 Likes
Content deleted by accident when trying to reply to you.
Please write more concretely.
I do not really understand the meaning.
Do you mean that we want you to support patches?
Or, do you mean that something has happened if you patch in EA?
about range fix patch.
I already support two implementations in FE8U
NAME=Range Display Fix (freerange / Implementation with Binary by icecube)
NAME=Range Display Fix (Implementation with EA by StanH)
1 Like
I mean in Teq’s patch it says that the patch need free space from 0x400,000 on. I am asking if that would interfere with any patch from FEBuilder.
free space from 0x400,000
That’s way too big.
I think that 0x400,000 == 4 MB is some mistake.
Since there are various patches, I do not know whether or not to interfere.
Various patches hook various addresses.
You have no choice but to actually try it.
To test whether it does not completely interfere, adapt the patch and do a clear test.
After adapting the patch, start new game and play up to ending with both routes.
Usually, We can not spend such time, so I think that we are experimenting with only the first stage such as the prologue and chapter 1.
Just in case it was me that misunderstood something, here is the entire readme
FE8-Modified Crit Stuff
By Tequila
This hack consists of two parts.
The first part makes weapons with 255 (0xFF) crit unable to crit. They will display – on the Equipment tab of the Inventory page and while using the R-button examine.
The second part modifies items with the Negate Criticals ability (0x80 in Weapon Ability 2) so that anything that is not an item with that effect only activates if equipped. For example, if you give an iron axe this ability, and Garcia has it in his inventory but is wielding a hand axe, the crit negation will not take effect. Likewise, if you trade that axe to someone who cannot wield axes, nothing will happen.
NOTE: Stone (item 0xB5) used to be hardcoded to show 0 crit, but I hijacked that space to branch to my new routine. Unless you set its crit to 255, it will have a displayed crit (which will do a grand total of absolutely nothing, although I suppose it’d be amusing to see).
Make sure that your free space is in the first 0x400,000 bytes of the ROM. It’s currently written to free space beginning at 1C1EC0, but you can change that. If you’ve moved your item table, be sure to modify that definition as well.
Since this hook is done with BL at this patch, it is necessary to put the patch in the range that can be fired by BL.
The default free space is #define Free_Space 0x1C1EC0.
Therefore, I think that it will work if it is set by the default setting.
If there is something else in the default space, you will have to change it.
However, this is not a problem of FEBuilderGBA, so I can not do anything.
In FEBuilderGBA, even when you insert a check mark in the checkbox for definition of free area when inserting EA, you just insert ORG at the beginning of the script.
ORG 0x01000000 //<<this
#include "main.event"
It does not define “#define FreeArea” etc.
In the very old version, there was also a time when I was defining, but now I have not done it anymore.
The reasons are that the way of writing changes slightly,
such as “FreeArea” or “Free_Area” or “FreeSpace” or “Free_Space”.
And there are lots of code that does not specify multiple define checks.
Then it becomes multiple definition definition and fails to insert the script.
Therefore, I do only the ORG specification which is the least harmful.
If the ORG specification is written in the script, that will take precedence.
Did some hand-englishing ;). One thing I cannot fix is… 
The circled section is “Class Editor” within the “Class Editor” browser. It uses the same base text pointer as “Class Editor” from the default app page…
The circled one just needs to be given another pointer and be titled “Base Stats”.
Here’s an updated en.txt. It should fix some of the text boxes that don’t display their full text and cleans up a whole lot of other areas. I had a file explaining some of the changes but it got really long and I gave up about halfway through… Still, if you want that I can link it, too. https://www.dropbox.com/s/4tv6xam06ouv7st/en.txt?dl=0
Edit: I edited this in my update but it is currently a mistake so I’ll revert it: The same problem occurs with “Item Icons”. In the “Item Editor”, “Item Icons” appears as “Item”. In this instance, it needs a new pointer that reads simply as “Icon”.
2 Likes
Thank you.
Merged into the latest version.
About the value of the class status.
I made it the name “Class Base Status”.
Those who originally translated into English gave the name “Editor” to be the same as “nightmare”.
I do not know if this is necessary.
In the Japanese version of FEBuilderGBA, “Editor” is attached to only “Map Editor”, others are not “Editor” attached.
Because Most of the buttons are “Editor”.
Therefore, I do not need to attach “Editor”.
However, this may be a strange opinion in English-speaking countries.
Automatic testing was introduced from the latest version.
If there is an error in the chapter being edited, an error will be displayed in the simple menu.
If you click on the error, you can see the details and jump to the error location.
Also, Lint function to detect errors from all chapters was installed.
If you choose Tool->Lint from the menu, error checking is executed for all chapters.
The error check still checks only a few items.
Whether there is contradiction in the event condition.
Whether there are some errors in the values referenced in the event.
Whether the character string referenced in the conversation exceeds two lines or the width does not exceed the screen.(In the English version, it is only FE8.I will correspond to FE 7, 6 later as well.)
Whether you are not using an unavailable flag.
Whether writing to MemorySlot 0 is not done.
Invalid event is not set up.
In the future, I would like to expand the scope.
Since it is a static analysis, 100% error detection can not be done.
That is impossible.
However, you should be able to find it before you perform a common mistake.
2 Likes