A hang-up detection feature will be added to automatic feedback.
Since it is detected on the FEBuilderGBA side, you can use this feature without having to do anything if your game uses automatic feedback.
A hang-up here refers to a phenomenon in which the emulator stops with a strange screaming sound.
Infinite loops and forced resets are not included. (This is because we have not come up with a method to reliably detect infinite loops and forced resets.)
Screaming hangups often occur when the stack is destroyed.
In the event of a hangup, the chapter and save data are sent with the message Hang-up detection.
If the debugger is connected to the emulator for a long time and then suddenly disconnects, and the disconnection continues for more than 3 seconds, a feedback report will be sent, indicating that a crash has occurred.
Since it is difficult to notice a hang-up in a full-length game, it is best to understand that this is one more way to detect it early.
Of course, it is assumed that the game supports automatic feedback and that the player is playing using FEBuilderGBA.
This feature is experimental, so please let us know if there are any false positives.
Detecting a forced reset or a simple infinite loop can probably be done if the value of the r15 register can be obtained.
However, the registers are too small to locate in the emulator’s memory.
Currently, we can only see the 0x02000000 and 0x03000000 areas, so detecting these there seems unfortunately impossible.
The world map is difficult, so if you don’t understand it, don’t get it.
You must understand the relationship between worldmap base, worldmap node, and worldmap event to make it work.
When you are issuing SKIPWN for the opening event, give up already.
You have not initialized the world map correctly.
Also, the worldmap node table has less number of cases than vanilla.
You must be doing something strange.
At this point, you should probably give up on worldmap already.
in fact, I was trying to follow this other one and I don’t understand what happened, the first one worked, but the one that followed it didn’t work anymore.
If you include this in the updateinfo, it will disable the cheat function in FEBuilderGBA.
The default is DISABLE_CHEAT=0, which enables the cheat function.
Users are seeing the FEBuilderGBA debugger more and more often, e.g., via autofeedback.
It is human nature to want to press the cheat button when it is present.
For this reason, we have added a function to disable the cheat function.
It is a simple lock, so it can be removed quickly if you want to, but I think it is sufficient for casual users.
Then, Open rom by FEbuilderGBA, press F5, and have a player unit with 1 HP assault the enemy.
A report of the death should be added to the following site
This sheet is public auto feedback.
It is provided for testing auto feedback.
If you want to create your own sheet(private sheet), you will need to do some more configuration.
You can zip myhack.ups and myhack.updateinfo.txt for distribution so that you can see other people’s play reports.
Hi,
I was wondering if it exist a patch or a edit of someone that made fe8 able to have a item similar to second seal, which will completly change a character class based on the unit ID.
If not, is there a way to make promotion based on a unit ID instead of a class?
Slightly change the version information sent.
Add the emulator name to the VERSION field.
Only mGBA displays the version number correctly.
The others display the date of the emulator exe as yyyyMMDD.
fe8kaitou //ROM Name
20230611 //ROM file time yyyyMMDD
32750 //ROM capacity kb 32750kb(32MB)
VisualBoyAdvance-M //Emulator Name
20150526 //Emulator version or time yyyyMMDD
fe8kaitou //ROM名
20230611 //ROM file time yyyyMMDD
32750 //ROM capacity kb 32750kb(32MB)
mGBA //Emulator Name
0.10.1.0 //Emulator version or time yyyyMMDD
chapter 0x07 is loaded as an extra map instead of a chapter so the win condition for beating the boss is not activated and the win condition for beating everyone is activated as if it were a skirmish.
This problem was caused by your use of the world map.
Anyway, I disabled the world map completely with MNC2fix and proceeded again from ch1 and it worked.
The data in ch7 is lost in skirmish and should be discarded.
I think ch6 is also giving an opportunity to stray into SKIRMISH.
Also, the EndEvent for ch7 was blank, so it took a long time to verify.
It was hard to verify if it was cured or not, so I added MNC2.
What is “const u16 *icon”?
Is this a pointer to an uncompressed image?
Why u16 instead of “const byte *icon”?
I think this structure is sizeof()==8bytes.
Similar patches include the following patches.
NAME=章タイトルを表示する時のフレームなどの素材画像を章ごとに変更する(Editor)
NAME.en=Change material frames image when chapter titles for each chapter(Editor)
INFO=新規に画像をImportするときは、アドレス、PALETTEに0かFFFFFFFFを設定した後で、Importしてください。\r\nそうしないと、既存の画像を上書き変更します。
IF:0x20252=0x00 0x00 0x00 0x4B
//STRUCTパッチとして実装します
TYPE=STRUCT
TAG=#ENGINE
//データへのポインタ
POINTER=$GREP4END 0x07 0x4B 0x18 0x47 0xF0 0xBC 0x02 0x02 0xA8 0x3D 0x08 0x08 0xFF 0xFF 0xFF 0xFF 0x00 0x40 0x01 0x06 0x50 0x2F 0x01 0x08 0xB0 0x02 0x02 0x08 0xB8 0x02 0x02 0x08 0x5D 0x02 0x02 0x08
//データサイズ(10進数)
DATASIZE=12
//データ個数 00 が出てくるまで
DATACOUNT=$GREP12 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
//リストに表示されるのはマップIDです
LIST=$B0:MAP
//データを定義します
B0:MAP_ANYFF=MAPID(0xFF=ANY)
B1=Edition(0xFF=ANY)
W2:FLAG=Flag(0x00=ANY)
P4:PatchImage_ZIMAGE=Image
P8:PatchImage_PALETTE=Palette
WIDTH=256
HEIGHT=32
//利用パレット数
PALETTE=1
INFO.en=To import a new image, please set the address, PALETTE to 0 or FFFFFFFF, then import it.\r\nOtherwise, overwrite the existing image and change it.
NAME.zh=在为每个章节显示章节标题时,更改帧等素材图像(Editor)
INFO.zh=要导入新图像,请将地址PALETTE设置为0或FFFFFFFF,然后导入。\r\n否则,覆盖现有图像并进行更改。
Perhaps it would look something like this
NAME=SkillInfo(Editor)
INFO=edit SkillInfo, something.
//What address can I look at to be sure the patch is installed?
IF:0x20252=0x00 0x00 0x00 0x4B
//STRUCTパッチとして実装します
TYPE=STRUCT
TAG=#ENGINE
//Where is the pointer to struct?
//GREP4END means that the ROM is examined in 4-byte increments and a pointer to struct is at the end of the next data.
POINTER=$GREP4END 0x07 0x4B 0x18 0x47 0xF0 0xBC 0x02 0x02 0xA8 0x3D 0x08 0x08 0xFF 0xFF 0xFF 0xFF 0x00 0x40 0x01 0x06 0x50 0x2F 0x01 0x08 0xB0 0x02 0x02 0x08 0xB8 0x02 0x02 0x08 0x5D 0x02 0x02 0x08
//What is the sizeof(struct)?
DATASIZE=8
// What is the end of the data?
// If it is a fixed number, write a value such as 255.
//If the number is indefinite, write a method to find the end data.
//In this example, the search is done in 8-byte increments until a null-terminated 8-byte is found.
DATACOUNT=$GREP8 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
//The name to be displayed in the list.
LIST=$W0:TEXT
//define struct
//Following the windows data format, BYTE=1byte, WORD=2byte, DWORD=4byte.
//Note that the meaning of WORD is different from that of EA.
W0:TEXT=msg
W2=_pad_(00)
P4:PatchImage_IMAGE=Image
//I am not sure if PatchImage_IMAGE will work as this is probably my first time using it.
//This is because most of the data is PatchImage_ZIMAGE.
//PatchImage_IMAGE specifies the pointer to the uncompressed image pointer.
//If it is a lz77 compressed image, it will be prefixed with a Z, i.e., PatchImage_ZIMAGE.
//Specify the width and height of the image.
WIDTH=32
HEIGHT=32
//Number of pallets to be used
PALETTE=1
// I think this time it is a common palette, so you need to write a pointer to the palette.
// If the location of the palette is indefinite, use $GREP4END, etc. to find the pointer to the palette.
PatchImage_PALETTE=0x05E0B0 //08603F98
//Specifies that the palette should not be rewritten by import since it is a common palette.
KEEPPALETTE=1
Does anyone know of a way to create an AOE damaging event to occur after an enemy is defeated? Something like an enemy that explodes after being defeated damaging units around it.