Users browsing this thread: 1 Guest(s)
My Hacked Rom crashes...will EXPLAIN

#1
Posts: 471
Threads: 39
Thanks Received: 6
Thanks Given: 6
Joined: Aug 2010
Reputation: 3
Status
Runic
I only use three patches, the weapon axe patch(by PocoLoco), the FFIV Boss Battle Music Patch, and the FFIV Battle Music Patch(credit to metroidquest), and I change the sprites but my hacked rom crashes. I use a regular FFVI rom from coolrom.com and I am able to patch them roms successfully but my rom crashes after I enter about two random battles, for example in Narshe I get to the point of where the Narshe guard says "We got 'em trapped now!" I enter battle like normal and then the game crashes. Any explanation for this?
  Find
Quote  

#2
Posts: 3,970
Threads: 279
Thanks Received: 236
Thanks Given: 58
Joined: Oct 2011
Reputation: 65
Status
Tissue-aware
FFIV Boss battle music patch and FFIV Battle Music patch should only affect the C5 bank where the instruments numbers used for each song are. As for the song data it should have changed bytes in bank C8 and C9 depending which songs they are replacing. As for Poco's patch, it's a graphic patch and shouldn't enter in conflict with any of the other two. If the 3 patches have been proved to work correctly, it could be the fact that your ROM has a header and one or all 3 patches are made for a header-less ROM, or vice versa. This would have as effect to change other data than what it's suppose to.

If you enter the first battle correctly, maybe something related to the battle formation or mould of the second formation has been corrupted. You can always run a report with Lunar IPS. You simply take a clean ROM and by having the patch in the same folder, you apply the patch. A text file with the bytes changed will appear. Repeat this process with 2 other copies of your clean ROM and the 2 other patches and you'll be able to see if there is a conflict or which data has been changed.
  Find
Quote  

#3
Posts: 471
Threads: 39
Thanks Received: 6
Thanks Given: 6
Joined: Aug 2010
Reputation: 3
Status
Runic
Is it preferable I do the cosmetic edits with FF3USME before or after I patch the rom or roms? I use a Final Fantasy III Version 1.1 rom for hacking the game, if you know where I can find a headerless rom for the game, it'd be appreciated if I can't find the issue I am having.
  Find
Quote  

#4
Posts: 3,970
Threads: 279
Thanks Received: 236
Thanks Given: 58
Joined: Oct 2011
Reputation: 65
Status
Tissue-aware
(02-13-2012, 07:57 PM)CrumpledMedal Wrote: Is it preferable I do the cosmetic edits with FF3USME before or after I patch the rom or roms?

You should be able to do them before and after applying the patches if they work correctly unless I'm mistaken. Maybe Poco Loco could give you more in about his weapon patch and what does it change exactly. It's the only thing I'm totally ignorant about.

(02-13-2012, 07:57 PM)CrumpledMedal Wrote: I use a Final Fantasy III Version 1.1 rom for hacking the game, if you know where I can find a headerless rom for the game, it'd be appreciated if I can't find the issue I am having.

There are small differences between version 1.0 and 1.1 but I don't know exactly what they are. You should also find out if your patches require a headered ROM or not, and that should be said in the documentation that comes with the patch, if there is any... To see if your ROM has a header, open a Hex editor and if the 200 first bytes are 00 (except the first few) then you have a header. They are some tools available to remove or apply a header if you can't do it manually. I can point you out to a FF3us ROM 1.0 with header in a PM.
  Find
Quote  

#5
Posts: 471
Threads: 39
Thanks Received: 6
Thanks Given: 6
Joined: Aug 2010
Reputation: 3
Status
Runic
Thanks, I think I figured out what the problem was...thanks for fixing it.
  Find
Quote  

#6
Posts: 2,769
Threads: 88
Thanks Received: 24
Thanks Given: 87
Joined: Jun 2009
Reputation: 25
Status
None
using 1.1 is the problem since most patches work for 1.0

Zeemis actually did the axe patch (which I need to redo actually)


"Sometimes ninjas do wrong to each other, and in dat way the force of tha earf' comes around da moon - and at that presence, da dirt, it overshadows the grass, so you're like, I can't cut dis grass, there's no sun comin' through. So in order to enable each other the two fruits have to look each other in da eye and understand we can only be right, as da ripe is wrong, you know what I mean?"

-HNIC
Quote  

#7
Posts: 471
Threads: 39
Thanks Received: 6
Thanks Given: 6
Joined: Aug 2010
Reputation: 3
Status
Runic
1. That may have been the trouble, the music patches work on V 1.1 however the weapon patch does not.

2.Poco, dude what's wrong with the patch, as in why does it need to be redone? I'm just curious...
  Find
Quote  

#8
Posts: 1,261
Threads: 250
Thanks Received: 11
Thanks Given: 7
Joined: Jun 2009
Status
Traitor
I'm also curious why it needs to be redone.
  Find
Quote  

#9
Posts: 3,970
Threads: 279
Thanks Received: 236
Thanks Given: 58
Joined: Oct 2011
Reputation: 65
Status
Tissue-aware
(02-13-2012, 09:56 PM)CrumpledMedal Wrote: 1. That may have been the trouble, the music patches work on V 1.1 however the weapon patch does not.

Have you tried the weapon patch with version 1.0?

I just did a IPS log with it and I even used two different ROM (1.0 with header) and it came out to that in both cases:

Code:
Offset    Size    RLE    IPS_File_Range       IPS_File_Size
------    ----    ID     00000000-00000004        5
126423       D    No     00000005-00000016       12 (palette change)
126454       C    No     00000017-00000027       11 (palette change)
126492       E    No     00000028-0000003A       13 (palette change)
134790      30    No     0000003B-0000006F       35 (unknown data change...not on the ROM map)
1348C8      21    No     00000070-00000095       26 (unknown data change...not on the ROM map)
1348F0       4    No     00000096-0000009E        9 (unknown data change...not on the ROM map)
2CE680       4    No     0000009F-000000A7        9 (previously unused space)
2CE802       1    No     000000A8-000000AD        6 (graphics change)
2CE80A       1    No     000000AE-000000B3        6 (graphics change)
2EB41E       8    No     000000B4-000000C0        D (previously unused space)
2F4C46    52D1    No     000000C1-00005396     52D6 (world maps data and tiles graphics)
------    ----    EOF    00005397-00005399        3

The $52D1 bytes at the very end are not good news I think but I haven't tested the patch myself...

Edit: The $52D1 bytes changes is because Zeemis used FF3usME that switch WOB and WOR map data. It isn't creating the bug at all...Silly me!Cover

There is 3 palette changes for the 3 axe colors which make sense and what is at D3/4790 to D3/48F4 is usually labeled as "unknown data". These offsets might be related to graphics, palette or something else but there is 3 different changes (respectively 30, 21, and 4 bytes)...

Aside of that there is 2 data writing on unused space. I don't know what they are but these also shouldn't affect gameplay either. Let's just assume that data is used correctly by the game since there was nothing there before. Worst case scenario it is not used at all, but then why would there be data at these two places? It could be other patches that Zeemis had on his ROM because a lot of patches created use the originally unused spots in the ROM.

There is two graphics change of 1 byte each, it could be the weapon graphic change but I don't know how much space a change from a sword to an axe graphic is suppose to take so I can't tell...Zeemis could tell you more about that maybe because knows the offset of the graphics he changed.

If the patch works correctly with version 1.0 then it means one of the data at an offset that the patch changed is not the same from version 1.0 to 1.1...We can exclude the data shift of one or more byte by importing in YY-CHR because the rest of the ROM would have been shifted as well. What really bugs me are the 3 changes at D3/4790 to D3/48F4, because I don't know what kind of data is suppose to be there...

Finally, we can say that this patch was made for a ROM with a header because some starting offsets, such as the WOR tiles graphics, match with the ROM map if we substract the header.

All that long edit and I didn't found the problem..What a shame>_>
  Find
Quote  

#10
Posts: 2,769
Threads: 88
Thanks Received: 24
Thanks Given: 87
Joined: Jun 2009
Reputation: 25
Status
None
the problem is

zeemis imported the image

when you import an image in yy-chr 90% of the time data gets re-arranged

when I create custom weapons I put them in manually that way nothing else is affected

-edit-

this is vital

if data gets re-arranged in a 1.0 rom and its patched and u apply it to a 1.1 rom

the effects can be lethal


"Sometimes ninjas do wrong to each other, and in dat way the force of tha earf' comes around da moon - and at that presence, da dirt, it overshadows the grass, so you're like, I can't cut dis grass, there's no sun comin' through. So in order to enable each other the two fruits have to look each other in da eye and understand we can only be right, as da ripe is wrong, you know what I mean?"

-HNIC
Quote  



Forum Jump:

Users browsing this thread: 1 Guest(s)


Theme by Madsiur2017Custom Graphics by JamesWhite