Do bugs really discourage hackers???

[Froosty]

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]

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! :)

 

[Ammy175]

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]

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]

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! :)

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]

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]

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.

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]

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 :)

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!

 

[Logan]

Bugs are bound to discourage people, it's human nature.

 

[Blah]

what are bugs and how do I get them?

 

[Deokishisu]

what are bugs and how do I get them?

They're those things that live outside. You've probably never seen one.

Bugs don't really discourage me much, but I make backups and don't overwrite important space with my garbage. Most bugs stem from people overwriting things or repointing incorrectly, I think, and less from actual routine hacking.

 

[DarkPsychic]

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....