• Our software update is now concluded. You will need to reset your password to log in. In order to do this, you will have to click "Log in" in the top right corner and then "Forgot your password?".
  • Welcome to PokéCommunity! Register now and join one of the best fan communities on the 'net to talk Pokémon and more! We are not affiliated with The Pokémon Company or Nintendo.
    Register

Do bugs really discourage hackers???

Do bugs really bug you(hacker) ???

  • Total voters
    20
Froosty

Froosty

The_Learner
535
Posts
9
Years
Hi guys!

I have been hacking fire-red rombase for last few months..
And I have been encountering bugs more that the time I have been working on the rom hacking..

Its such that working on one thing I get a bug.... then I try to solve it and get some more error...

Then I start my work again from the scratch...
Again I somehow avoid the bug but later on get some more bug..

Its like a never ending cycle og getting bugs..


How do you guys tackle the bugs???

And what say, do the buts demotivate you from making hack....




Right now I have lost all my interest in rom-hacking due to never ending bugs!!!
 
miksy91

miksy91

Dark Energy is back in action! ;)
1,480
Posts
15
Years
What I personally do is to make backups around every hour I make new changes to the game and version the backups (Hack 0.01, Hack 0.02, ..., Hack 1.00, Hack 1.01, ...). Keeping most of these backups is mandatory if you want to be able to track down causes of bugs easily.

Now whenever I run into some kind of bug with the game that I can't track down by any good means (such as searching with a hex & asm editor, or by debugging), I try to search for the bug by "forking method". What this means is that I try to find two consecutive backup files such that the bug doesn't exist in the former one, but does exist in the latter one. As an example, these could be files "Hack 1.34" and "Hack 1.35".

Next what I do is to make an ips patch that tells what's changed between those two files. This can be done with Lunar IPS by selecting in this case "Hack 1.34" as unmodified rom file, and "Hack 1.35" as the modified rom file. Now the contents of the IPS contains:
1) A little bit of most likely useful, new data that I have written after Hack 1.34, and
2) The data that causes the bug to appear in version 1.35.

Next I would open the IPS patch with IPS Peek to check, what's exactly changed in the rom file between these two versions. The contents of the IPS patch simply tells where it writes data, and what data it writes there. Now small changes between "Hack 1.34" and "Hack 1.35" indicates that there is only a little bit of in the IPS patch, and tracking down the bug-causing data is simple! (And on the other hand, if you take backups only rarely, you would have lots of data in this IPS patch and tracking down the bug causing record would be more difficult.)

Now I simply check every "record" (= what data is written and where) with IPS Peek and track down, which are the bug causing one(s). After I have found what causes the bug in "Hack 1.35", I can be almost positive that the cause for the same bug is the same in the current version of "Hack" as well. Next I simply change that part of the (current version) rom file back to normal by taking a look at what the data is in the original rom file.

As an example, if I notice with IPS peek that the IPS patch tells to write 10 bytes of random garbage in address 0x123456, I check from the original rom file (or perhaps actually from Hack 1.34!) what those bytes starting at 0x123456, are and write them starting at 0x123456 to the newest rom file to correct the bug. And job well done! :)
 
Last edited:

Ammy175

169
Posts
7
Years
  • Age 28
  • Seen Jan 17, 2023
Oh most definitely. With me, at least, it goes so far that I refuse to use the various patches that add in extra attacks, abilities, Pokemon, etc., whether they're buggy or just incomplete, as interesting as they might sound.
 

BluRose

blu rass
811
Posts
10
Years
i avoid bugs by using hex editors for everything
if i need a tool--*coughs* mapping and graphics *coughs*--i end up doing all of the tool edits on like a "playground" rom which is probably buggy to hell and back by now. either way, i then take the .bin files and put them into the actual rom and then repoint where necessary~ and i backup like every day at the start and in hour-long increments if actively hacking, a lot like miksy said~

and yes, bugs would annoy me. a lot.
 

chrunch

1,344
Posts
14
Years
  • Seen Dec 10, 2021
miksy91 said:
What I personally do is to make backups around every hour I make new changes to the game and version the backups (Hack 0.01, Hack 0.02, ..., Hack 1.00, Hack 1.01, ...). Keeping most of these backups is mandatory if you want to be able to track down causes of bugs easily.

Now whenever I run into some kind of bug with the game that I can't track down by any good means (such as searching with a hex & asm editor, or by debugging), I try to search for the bug by "forking method". What this means is that I try to find two consecutive backup files such that the bug doesn't exist in the former one, but does exist in the latter one. As an example, these could be files "Hack 1.34" and "Hack 1.35".

Next what I do is to make an ips patch that tells what's changed between those two files. This can be done with Lunar IPS by selecting in this case "Hack 1.34" as unmodified rom file, and "Hack 1.35" as the modified rom file. Now the contents of the IPS contains:
1) A little bit of most likely useful, new data that I have written after Hack 1.34, and
2) The data that causes the bug to appear in version 1.35.

Next I would open the IPS patch with IPS Peek to check, what's exactly changed in the rom file between these two versions. The contents of the IPS patch simply tells where it writes data, and what data it writes there. Now small changes between "Hack 1.34" and "Hack 1.35" indicates that there is only a little bit of in the IPS patch, and tracking down the bug-causing data is simple! (And on the other hand, if you take backups only rarely, you would have lots of data in this IPS patch and tracking down the bug causing record would be more difficult.)

Now I simply check every "record" (= what data is written and where) with IPS Peek and track down, which are the bug causing one(s). After I have found what causes the bug in "Hack 1.35", I can be almost positive that the cause for the same bug is the same in the current version of "Hack" as well. Next I simply change that part of the (current version) rom file back to normal by taking a look at what the data is in the original rom file.

As an example, if I notice with IPS peek that the IPS patch tells to write 10 bytes of random garbage in address 0x123456, I check from the original rom file (or perhaps actually from Hack 1.34!) what those bytes starting at 0x123456, are and write them starting at 0x123456 to the newest rom file to correct the bug. And job well done! :)
Click to expand...
This is a similar method to what I do, but you don't need the whole step with IPS Peek. You can do it directly by using the compare file function in your hex editor to compare the two ROMs.
 
0

0

Happy and at peace. :)
556
Posts
7
Years
I have a git repo for the project I made, and I file every single script, so that, in the event of some catastrophic failure, I can re build everything. I have also found that a test ROM, separate from the main, is extremely helpful for testing new ideas, maps, and scripts.
 
Blah

Blah

Free supporter
1,924
Posts
11
Years
Nonibros said:
I have a git repo for the project I made, and I file every single script, so that, in the event of some catastrophic failure, I can re build everything. I have also found that a test ROM, separate from the main, is extremely helpful for testing new ideas, maps, and scripts.
Click to expand...

I had a peak at your repository. That's an interesting way to use git, to say the least. Though I'm quite happy to see the organization :)
 
0

0

Happy and at peace. :)
556
Posts
7
Years
FBI said:
I had a peak at your repository. That's an interesting way to use git, to say the least. Though I'm quite happy to see the organization :)
Click to expand...
Thanks. I couldn't really find a way to have the actual ROMs code changes reflect in the git, except by releasing version numbers. It did actually work for rebuilding, as I had to do that at one point early on.

I'm glad you like the organization. I find that many ROM hackers simply add stuff to the ROM, which I guess is fine, but if things break, they can't fix it.

Cheers!
 
DarkPsychic

DarkPsychic

146
Posts
11
Years
  • CO
  • Seen Mar 16, 2023
Bugs don't really discourage me either honestly, getting no result at all from a custom asm routine or xse script; now that bothers me >_< hahaha

Bugs every time I have one it always comes down to something I did wrong.
Whether it be not following a tutorial the proper way or not doing enough research and practice to understand whatever it is I'm doing at the moment.
Keeping backups and versions like Misky91 said is pretty much the best way to go about it.

Bugs aren't always bad though, I mean for instance there is MissingNo all the other Glitch Pokemon and even things like Coin Case Glitch from gen 2 and the Pomeg Glitch from Emerald...
All these being Bugs in GameFreaks code that actually had merit to it, with MissingNo being the most arguably famous Glitch ever!
Sometimes a Bug in ones code can bring about new and interesting results....
 
You must log in or register to reply here.
Back
Top