[FE8] FreeMovement Rework

Resources Assets
,
21

FreeMovementControlProc is not being properly initialized.

Because procs are placed in memory dynamically, there is no guarantee that the proc previously occupying the same space didn’t leave behind data. in pFMU_OnInit, it is assumed that FMUnit is initialized to 0. If a proc has previously placed a value here, then the unit pointer used ends up being junk data:

Solution: Add initialization to pFMU_InitTimer

void pFMU_InitTimer(struct FMUProc* proc){
	proc->uTimer = 0;
	proc->FMUnit = 0; //fix
	return;
}

This runs once prior to pFMU_OnInit, which means the field is always initialized to 0 as expected

5 Likes
22

I endure the quirks of free roam so everyone else doesn’t have to.

23

got it

1 Like
24

pFMU_InitTimer seems to run when changing units, meaning the currently controlled unit can’t change beyond the first in the unit array. Instead I initialized proc->FMUnit to 0 in a new function in the first block of the proc code. So far so good.

	FreeMovementControlProc:
	_6C_SET_NAME(FreeMovementProcName)
	_6C_SET_MARK(2)
	_6C_YIELD
    _6C_CALL_ROUTINE(pFMU_InitFMUnit)
	_6C_CALL_ROUTINE($801C895) // ClearActionAndSave
    .
    .
    .

Really thought I was going mad with this one. The blue menu background is drawn on BG1.

  • The tiles are in VRAM.
  • Priority-wise it made sense, BG1 should be drawn over BG3.
  • Window0 was enabled, but disabling it still didn’t get BG1 to show.
  • No HBlankHandlers are active, LCDIOBuffer should reflect memory block 4 exactly.
  • Everything adds up, why doesn’t BG1 show!?
    Turns out BG1 was blending with BG3, so much so that BG1 was invisible. Suddenly feel nostalgic; Somehow I always overlook blending as an option when it comes to these display errors. Anywho, the issue can be solved by clearing windows and blend/BLDY effects before starting the menu.
bool FMU_OnButton_StartMenu(FMUProc* proc){
    gLCDIOBuffer.dispControl.enableWin0 = 0;
    gLCDIOBuffer.dispControl.enableWin1 = 0;
    gLCDIOBuffer.dispControl.enableObjWin = 0;
    gLCDIOBuffer.blendControl.effect = 0;
	StartMenuAdjusted(&FreeMovementLMenu,0,0,0);
	return 1;
}
4 Likes
25

Most users do not wish to modify their EMS patch to install this, and the without EMS link is broken. This means that suspending and resetting the emulator will put you out of free movement mode.

I believe the non-ems version just changes this line:
https://github.com/MokhaLeee/FreeMovement/blob/main/cFreeMU/FreeMovement.event#L14
to a padding byte in chapter data / gPlaySt struct, such as 0x202bd35.

ALIGN 4
FreeMoveFlag:
	WORD 0x0202bd35

I recommend most users just use this address instead of 0x2028924.

1 Like
26

(Eham I hope it’s okay for me to post idk the etiquette sorry >_<)

I am pretty new to FE Romhacking, but wanted to try experimenting with freeroaming.
In FEBuilder I went Run → Insert Event in Event Assembler and selected FreeMovement.event, but when I try loading the script it says this:

3 errors encountered:
File _MU6Cfix.event, Line 4, Column 1: No code named jumpToHack found.
File _MU6Cfix.event, Line 7, Column 1: No code named jumpToHack found.
File _MU6Cfix.event, Line 10, Column 1: No code named jumpToHack found.

I… don’t really now what to do from here… Not even if what I was doing in the first place is right… If anyone has clues it would really make my day!

(I was very self-concious about posting in this thread cause it was 3 years old last time I checked, but I guess it isn’t anymore ehe)

27

Thank you very much @Vesly!

I was always wondering why resetting the Rom got you out of Free Movement, so I had to write a turn event that just puts you back into it as well as setting the turn to the last turn that you were in before Free Movement but now it just stays in it. That is reeeeeeaaally helpful!
And good thing I was able to just change the flag data in the hex code to work :melting_face:

1 Like
28

as was solved by vesly in the discord server a few days ago, if you want to use free movement with their own auto save patch, exiting the game and choosing resume on the main menu will sometimes lock the player into normal gameplay tile movement mode and possibly soft lock them entirely. to fix this they came up with the solution to replace WORD 0x02028924 in theFreeMovement.event installer with WORD 0x0202BD35 and reinstall the ea file. I can confirm this fixed it and hasn’t caused any other issues with either free movement itself or the rom as a whole! thanks vesly!