Currently, I am developing a routine to solve the problem that the menu added by the patch disappears when SkillSystems is updated.
Currently being tested.
I think it will take some time to test because it is a very troublesome issue, but I think we can publish it in the near future.
1 Like
Are the two >> after âWaitâ intended to be there?
Also by clicking right you will go to a second menu with only âWaitâ without the â>>â and âItemâ,
Is it intended to work like that?
Copy the vanilla ROM header.
You can recover by copying the range of 0x00-0x100.
I also need to create a routine that automatically recovers this too.
I have a lot of things to do.
This is the way it was intended to work.
I have not placed a â>>â in the Wait menu when you press the right button.
Why do you put â>>â in the first Wait menu?" The reason for this is to tell the player that there is a menu that may be switched by pressing the right button.
We havenât installed the second menu because we donât need to tell them that.
If you want to install it, you can.
If you have the second menu, then you have the first menu as well, so just change the Wait in the second menu to âWait >>â.
I just donât think this makes sense to me.
As I mentioned at the beginning, the meaning of â>>â is to tell the player that with the right button (still the left button) they can switch between menus.
So I donât see why itâs necessary to tell the player that they can switch menus again once theyâve switched.
Thatâs why I didnât put a â>>â on the second menu Wait.
Omg I am an idiot, Iâm really sorry.
I thought that the âdisplay submenuâ patch was needed for the âCallEventMenuâ event while they where two complete separated things. It all makes sense now, thank you very much for the explanation.
Oh, I had no idea it would be so easy to fix. Seems like I might have wasted your time with such a simple problem, but I appreciate the help! Now I know how to fix it if it happens again somehow. Thank you again.
The latest version has solved some menu problems.
At the very least, updating SkillSystems doesnât erase the existing menu.
The order will return to the original, but the items will not disappear.
You gave me a help.
You told me this happened if you changed the unitâs support.
With the latest version, when writing support to ROM when changing support, Iâve made it more rigorous.
It also has a routine that automatically recovers if the ROM header is damaged.
Now, if something goes wrong, I think we can recover immediately.
Oh, alright, Iâm glad I didnât just waste your time, and Iâm glad my little issue could bring about some good.
Alright, I was told to come here if I had any issues.
Whenever I attempt to start up any chapter through any means, the screen goes straight to black with no events being executed whatsoever. I have no clue as to why this occurs.
This is because you corrupted the data on Song 0x00.
Song ID 0x00 must have 0 tracks.
Thank you for your help 
When attempting to go past the title screen, the game freezes. On bootup, the emulation box that appears displays the message "Could not read data (Page 02, Page 03). Need help understanding what this means and how to correct the freeze.
This is because you broke multiple data.
A patch to draw SaveSlot from text was corrupted, so I restored it.
Also, the title background music SongID 0x43 was corrupted, so I had to restore it.
Also, the prologue event you created did not have an Erase BackGround command, so it wasnât working properly.
Iâve fixed this one as well.
There were three problems in total.
Thatâs pretty serious.
You should do a few more tests properly.
Letâs do a test before writing.
Long premise
I am writing an event to repair weapons but I canât figure out were is the problem.
This is the event:
![3|690x272]
In the first part I will put a menu to let the player decide âhow muchâ he wants to repair the weapon, so I will save in memory slot 5 the possible values: (1;5;20;99), for now, I just put directly the value since Iâm only trying to make the thing work.
This is (1)
After that, I get the type of weapon and the current uses of the weapon from the inventory of the merchant.
Then there is in (2) an event that should control if the player has chosen a number too big (like the weapon has lost only 8 but the player selected 20) and lower the value of memory slot 5 to the value of
that number.
That LABEL is there because I plan to copy-paste the event and change the number for every ID of the weapons, this is for the Iron Sword, so, I set the slot 6 to 50 (durability of the Iron Sword), then, in slot 2 I should have put the current uses of the weapon, so Slot 4= slot 6 - slot 2 should be the missing uses of the weapon.
Then I check, if slot 5 is < of slot 4, I can proceed to evaluate price etc⌠if slot 5 is > of slot 4 I have a problem, and I must reduce slot 5 to the value of slot 4 (in this version is really stupid how I do it, but I was not thinking very well in that moment.)
The problem, is that the event works perfectly if I set the slot 5 to 7 or less, and it does nothing if I set it to 8 or more, I canât figure out why.
Here is the patch and the save Iâm using to test it: https://mega.nz/file/TchU1CgZ#NnfDPZrP9nWtWb_8d8YkFLm6c3lKFZG7Xa_bB7r-6n0
The ROM works! I tried to rush things, and it taught me a lesson just about as hard as possible. Iâll try to be more careful in the future.
Thank you so much,.
If youâre having issues with memory slots, perhaps you should edit it as its event assembler form. FEBuilder puts common commands on the same line to be user-friendly so people donât need to worry about memory slots.
For example Imm BNE (result != 0x1) is really set memory slot 7 to 0x1 then BNE slot 0xC and slot 0x7.
Hope this helps. I can take more of a look later.
1 Like
Thanks, if you want to look at the event from the root, the main event starts in 9B9DC74 and the ârepairâ event is the fifth one called.
The problem SHOULD be in 9B9F590 since the others works ok, but really I have no idea what is causing it since with a 7 itâs all ok and with a 8 itâs not.
How do you edit in the event assembler form?
