FE_Builder_GBA -- If you have any questions, attach report7z

Isn’t he already one of them?
Without data to reproduce it, there is nothing we can do.
I cannot even rule out the possibility that you are hallucinating.

So you sent a report7z to discord with all tile moves set to 0.
You are too extreme.
255 means you can never move.
0 means you can move indefinitely.
Look at the other class settings to see what to do.

First you should read the title of this thread carefully.
Without data, it cannot be verified.
Without evidence, there can be no discussion.

The casual mode menu version is not a good hooking point and is susceptible to other patches.
By analogy, he is destroying himself by charging all the way into a fierce battleground where other patches hook into each other.
However, this is what the author of that patch is doing, so I have no control over it.

Modern Character Growth seems to be built in as part of SkillSystems.
I don’t use it, so I’m not sure.
maybe, you just need to enable Flag 0xEF.

Once you understand the AutoLevel specs and learn to use the Unit settings to raise the base value, there is no particular need to bother with other patches to compensate.

It is a method similar to bulking up a container.
It may be easier to understand as padding.

By adding a unit base value, you can make the enemy stronger.

The problem occurs when the game is beaten once. I think my solution for now would be to delete the save file itself after i play through it. The rom itself is fine its just weird and annoying, even looking through the lint tool it doesn’t find anything there.

I’ve tested Skillsystems and it doesn’t seem to have Modern Character Growth included. I set all the class growths to 100 and still got a normal levelup. Besides, there’s a separate patch listed for MCG that says it’s compatible with Skillsystems. This is what doesn’t seem to work, and why I thought it was broken.

I’m not sure what to put in a report.7z. The only evidence I could show would be a screenshot of a level gained while growths are set at 100. Should I do that? Or maybe just apply the Skillsystems and MCG For Skillsystems patches, then upload the report without any screenshots?

Thanks again!

Please send data that can reproduce the problem.
The code says to use Flag 0xEF to be valid.

You are talking without providing any evidence.
Please send me the data to support your evidence first.

There is nothing I can do for you unless you share your data.
Please attach a report7z that can reproduce the issue.

Hopefully this file is what you’re looking for.

I don’t see anything that says Flag 0xEF is needed, or how to enable it.

You just turn on the flag in an event, with an event command. Just like how you use event commands to load units or display dialogue.

1 Like

All you have to do is enable flag 0xEF.

There was a discussion about this the other day.

How will adding a command in Event Editor help me install the MGC For SkillSystems patch?

…actually, nevermind. Don’t worry about it. I’m not trying to do this for a mod myself - I just saw something that looked like it was broken, so I reported it. If it’s not broken, that’s all I need to know :slight_smile:

Thanks anyway!

After looking into it a bit more, I don’t get the issue when playtesting via the builder, but then I get the issue when playing through it normally.

I’ve sent the report on discord.

A major update of FEBuilderGBA was performed.
The ROM pointer constants have been modified.
This will allow FEBuilderGBA to open ROMs that are not readable by FEBuilderGBA or that intentionally do not let him read them.

ROMs have not one but multiple pointers.
For example, the Unit pointer is not only in 0x10108, but also in 0x104EC and 0x10538.
Until now, only 0x10108 has been used, but if this cannot be obtained, other pointers are looked for.
This allows us to open ROMs even if a particular pointer is damaged.

Allow users to define pointers directly for cases where there is only one pointer or where the above methods cannot be used to track it down.
If a file named YOURROMNAME.custom_pointer.txt is created with the same name as the ROM, its contents will be referenced.

This content is a tab-delimited key value type definition file.
For example, if portrait_pointer is moved to 0xA59B08 instead of the default 0x005524, you would define the following

portrait_pointer	0xA59B08
class_pointer	0x17ADC

YOURROMNAME.custom_pointer.txt for YOURROMNAME.gba, and so on.
Creating this file is a bit more difficult because of the knowledge of the FEBuilderGBA source code and the knowledge of ASM.

Please refer to this file to see what constants are available.
You can use C# reflection to rewrite all uint type constants.

4 Likes

If an author wants to hide something to prevent FEB find it, it means that he does not want the corresponding module to be misappropriated or modified by others. Sorry that such a comment might be a bit mean, but I don’t think it would be wise to force the author’s encrypted part to unpack.

If that is the case, I recommend developing more stronger encryption.
When a new format is developed, I would like to develop another routine for it.

In this case, the routine was requested about a year ago, and I had advance notice of its development.
However, it was a pain to create, so I kept it on hold for a long time, but this routine became absolutely necessary, so I implemented it.
That was when I was erasing unnecessary routines to save space on Kaitou.
When I erased all the debug routines, the menu definition pointer also disappeared, and I could no longer access the menu from FEBulderGBA.
By the time I realized this, I had already stored other data in that area, so it was a hassle to change it.
Therefore, I needed a routine that could keep track of the menu pointer even if it had been destroyed.
Without it, I would have to manually enter the address each time, which is inconvenient.
To implement it efficiently, it was necessary to modify the structure of the FEBulderGBA constants.
And if I were going to make it anyway, I aimed for a general-purpose routine that could handle ROMs with pointer corruption.

I think this method of using reflection is very convenient because it allows us to deal with more complex structures just by who makes the definition in custom_pointer.txt.

The recommended obfuscation routine for now is to swap the contents of the structure.
For example, the zeroth of the Unit structure contains the string ID of the name in the short type.
If you swap this with other data, it will not be recognized correctly by FEBuilderGBA.
If it is a BG, you can swap the lz77 data with the TSA data.
Just change ldr a little.
However, the side effects of this routine are extensive and may be troublesome to create.

FEBuilderGBA is strongly dependent on the contents of the structure, so I believe it would be quite difficult to deal with this.
Not impossible, of course, but …

In fact, this has led to the leakage of a lot of material that is not expected to be published. Including battle animation, and portrait and so on.

Not everyone wants their work F2U or even F2E. The leak of the material caused by the update of the new version has dampened the enthusiasm of many authors who contributed non-open source GBAFE materials. And forcing hackers who know programming have to rewrite encryption patches to fight thieves who use FEB to steal material. However, even so, those encrypted works that have been released cannot be recovered because of this update.

These are not assumptions I’m talking about, it’s what’s happening.

I strongly disapprove of FEB’s forcible re-exposure of the author’s actively encrypted parts to others. Suppose such a scenario, I made my own material that none open sourced, then you tell me, “ok, I have the right to decrypt even the actively encrypted material for anyone to steal since I think it should be open sourced” ?? What do non-open source authors think about this approach?

Let me take two examples,

FE10RE, after you open it with FEB, you can’t see the materials such as battle animes, etc. Guess why? Is it because the author’s level is too poor, which leads to a bug, or is it because they actively avoided FEB recognition?

Another example, such an battle animation, have you found it in the public F2E repo? No, because it is not open sourced. However, such a material is indeed under development. The original author stated that the project will not continue to develop until they find the effective way to prevent thieves dump them through FEB.

¯_(ツ)_/¯

I agree with you. It is our work, our efforts and we want to keep it with in secret.