FE_Builder_GBA -- If you have any questions, attach report7z

If you know the TSA data that builds the panel, I might be able to help like a battle screen editor.
For now, there is no way.
If you change the part with width == 32, I think that it will be a little easier.

You are using Chinese.
about Chinese translation.
Currently the value output by google translation.
Please tell me if there is a mistranslation.
config/translate/zh.txt is the translation file.

I corrected it。
patch\FE8J、data、translate\zh。

link:https://pan.baidu.com/s/1dFCSz53

download

In other words, it isn’t worth the effort.
Okay that’s an answer I can deal with.

thanks for your patience :wink:

Thank you for sending me a translation.
I will use this data when we issue the next update.

Merging has ended except patch’s system.
Because patch does not want to change the file name, it is necessary to merge the contents.
There are plenty of files in patch’s system and it seems that it will take time to merge.

Hello! There is a serious mistake when I write the plot!

Please see the picture


The two ways of writing are the same
It becomes blank as long as it is written to the data

The problem is only in the Chinese version

When using Chinese, please use within the range not using Anti-Huffman.
Please use it within Huffman encoding possible range.(Do not apply Anti-Huffman Patch)

1.By using tbl, FE8CN assigns a Chinese code on the mapping at Japanese character code.
2.FE8J (FE8CN) can not display half-width characters by standard.
3.When I ported the Anti-Huffman patch to FE8J / FE7J, I mapped it to the most efficient SJIS for Japanese development environment.
4.In the environment where the Anti-Haffman patch is applied, writing a character string outside the range of Huffman encoding will automatically become an Anti-Haffman.
This is a consideration for the English environment where Haffman coding violation occurs frequently.

I think it is the result of complicated intertwining of these 4 problems.

By virtue of adding you one-byte character string, We violated the rule of (2) and (4).
Therefore, the character string is in Anti-Huffman format and stored in uncompressed format.

According to the conversion rule of FEEditorAdv, the character string is stored in 1 byte.
By multibyte conversion rule I added, multibyte is recorded in 2 bytes in SJIS format.

And there Chinese <-> Japanese translation on tbl is added.
As a result, I think the character string has broken.

As a countermeasure, I think it is two.

A.please,use characters in Huffman encoding. (Do not apply Anti-Huffman patch.)

Or

B.Develop the countermeasure routines , When the Chinese environment, the character string is modified to be stored by Chinese encoding.
Or let FE support UTF-8.

The problem is that FE8CN uses TBL and assigns Chinese code to Japanese code.
It does not allocate all the character strings, it allocates fragments of the code table.
I think that it is very difficult to reassign to Chinese code while maintaining compatibility with this state.

As a further problem, I do not know anything about Chinese character codes.
Under this condition, it is still impossible to develop.

In that case, I think that there is no choice but to use it within the range that does not use Anti-Huffman patch by the method of (A).

Thank you for this program.
By the way, can I translate the program to my own language(German)?

If you can help translating, it is possible to translate.
I will make a translation to be a base in machine translation, so please correct the part that is a mistranslation for it.

It will take some time to prepare, so please wait until tomorrow.

1 Like

Thanks, but you can just copy the English translation file and make it possible to choose as German, and I will just translate the second English text file in the config folder, that will save both my and your time. What do you think?

I dont know if I’m missing something (I probably am, so sorry if that is the case), but it appears that you can’t extend the stat boosts table.
Why is that and how do I make new ones?

I tried the maximum LV10 option in FE6. But it doenst work. It still goes up to 11 and above.

Does it only work in FE7/8? Or is it bugged?

I’m pretty sure it’s FE 8 only, but I honestly don’t know.

Since I can prepare translated into German based on Japanese, please wait for a moment.
Now I have new features under development so please wait a while.

However, you may gain better results based on English.
From Japanese to German translation, English to German are more grammatically closer, so accuracy seems to rise.

For now, I will prepare Japanese-based ones for tomorrow, so please wait.
(If you do not like machine translation, you can also rebuild it based on English translation.)

The statbooster is described in this document.
From the item editor you can define a new statbooster.
http://ngmansion.xyz/wiki/hackfe/index.php?解説/FEBuilderGBA/Item_characteristics_EN#w4e18273

It is necessary to distinguish whether it is a skill extension bug or my transplant is incorrect.
Can you reproduce the bug without using the skill extensions provided by FEBuilderGBA?

I did not make skillsystem, so I may not be able to help you.

It may be a flag only for FE 8.
Investigation is necessary.

That bug is a bug in the Skill System, not FEBuilder. The debuff patch has odd behavior when you load more than 16 units in a single group.

Anyone looking to fix that issue should just break the units on that map, into smaller groups so that there’s less than 16 units in each group. Might be 15, not super sure at what point it breaks.

That bug is a bug in the Skill System, not FEBuilder. The debuff patch has odd behavior when you load more than 16 units in a single group.

Thank you.
Once the skill system has been updated, I would like to update.