Deokishisu
Mr. Magius
- 993
- Posts
- 19
- Years
- If I'm online, it's a safe bet I'm at a computer.
- Seen Apr 27, 2025
This is aimed mostly at Gen 3 hackers, but will apply to all generations as their decomps also reach maturity. Binary hacking for Gens 1 and 2 is already dead.
I normally do not venture out of my hack's thread, but news of the new binary hacking tools and "engines" filter through the scene to me and I feel like I have to explain to those who may not know or aren't as informed about the state of the scene why both individual hackers and the entire community would be better off if binary hacking was entirely abandoned.
For those who don't know me, I'm Deokishisu, and I've been trapped in the Pokemon hacking scene for over 18 years. Yes, that is longer than some (perhaps even most) of you have been alive. I've seen every major era of ROM Hacking and have been a part of almost all of it. This means I've seen every transition, every paradigm shift, every fad, every new tool (I was around and hacking before we had Advance Map, as an example), and I've seen every big player come and go. I can tell you that the introduction of a complete, matching decompilation for the Gen 3 games with robust documentation is the biggest and most influential shift in the scene that has ever or will ever happen, but most of you aren't taking advantage of it. It's akin to our community suddenly discovering fire, yet somehow nearly the entire scene still prefers to eat uncooked slop in the dark.
I'm sure many will call me an elitist for spelling it out this plainly. I am not an, "elite," I just have more experience than 99% of you. Your math teacher trying to pass down some of their understanding isn't an "elite" because they are a subject-matter expert and you are not. I am a subject-matter expert when it comes to this hobby. I say that not to make anyone feel bad or lord it over anyone, but to hopefully illustrate why you should consider my words. I am not trying to hide any knowledge from you (in fact, everything I've ever done with the decomps is open source), but to share what I know freely to improve the community and the scene.
Decomp is short for decompilation. The quick and dirty definition is that a group of amazing people took the Pokemon ROMs and reverse-engineered (or decompiled--which is the opposite of compiled) them, producing the source code. The ROM file is the binary file that is the result of compiling the source code into a .gba executable, which is why working on the compiled ROM is called binary hacking. Having the source code enables you to do literally anything the GBA hardware is capable of in your hack.
Almost as monumental as being able to edit the source code directly (because let's face it, most of you will not be doing huge rewrites of the code), is the fact that working with the source enables you to use a version control system, such as Git. A version control system allows you to see a history of every single change you have ever made to your work. This makes it so you always have a clear record of what you've done, and will be able to identify any bugs you've introduced and fix them without restarting your entire project. Your hack never becomes irreparably corrupted, and all of the oopsies you make are undoable or fixable as long as you're making your commits (akin to Windows system restore points for your code) at sensible intervals.
The version control system also allows you to incorporate other people's work easily into your hack through a process called merging. There is a complete battle engine upgrade that decomp hackers have put together, for example, that you can merge right in. Because you have the full history and control of the source code, you can easily merge any bug fixes or updates to the battle engine without destroying your work. These processes involving version control are what real devs use in their actual jobs, so the tooling is robust and designed to make things as easy as they reasonably can be. It really cannot be overstated how monumentally important having a version control system is.
Another major benefit that everyone who uses the decomps over binary hacking gets immediately is that there are no fixed offsets. You never have to search for free space. You never have to repoint. You never have to worry that you'll overwrite something important. All offsets are relative and everything will be automatically shifted around so that it always fits without overwriting anything. Overwriting things that you (or a buggy tool, more on that later) thought was free space is probably 90+% of the unrecoverable corruptions that destroys the hard work of binary hackers. It will literally never happen to you when working with the decomps, because it is impossible.
Let me answer this with another question, why do you tolerate the gradually-increasing threat of corrupting your ROM and losing your work with every little change? We've all been there where you discover that some change you made eons ago corrupted your ROM and now you're faced with either restarting or accepting gamebreaking bugs or crashes. If you haven't been there yet, you will be, and it's devastating.
Why do you tolerate having no real control over what you're actually doing to your hack? Using buggy tools from over a decade ago whose creators had incomplete (at best) knowledge of the game's code when they were implementing their features should be a non-starter for most people. On top of this, you're layering these targetted changes on top of other tools and random patches (that were also made with unreliable tools on incomplete information) and end up with this rats nest of hacks on top of hacks that is impossible for anyone to untangle, much less a novice.
The patches floating around are buggy on their own, and because they're being applied to binary hacks at fixed offsets, are very difficult for the end user to update to new versions. Because of the time period they were created in, the creators of these tools and patches have less knowledge about the actual code and what their stuff is doing under the hood than people just starting out with the decomps do. Just like you wouldn't eat uncooked meat from a tribe that didn't have fire, you shouldn't be trusting hours of your hard work to people that barely have a greater understanding of what you're doing than you do. The decomps offer you fire, the binary toolmakers offer you a slightly-better version of a club you already have.
If you're binary hacking, you are using 2004-era knowledge in a field that is about to be in 2023. I know this because I was active in 2004, and the only leap that binary hacking has made in that time period has been C injections whose modern-day sophistication was directly enabled by progress in the decomps. A good example of this is the CRFU, which only exists because the decomps allowed Skeli to read and manipulate the source code. CRFU was made in a time when the decomps were not complete enough to be used by the general public, and I'm not discounting the effort and skill it took to make it (Skeli has done a phenomenal job), but now it is a weight holding back the community and delaying the full transition to the decomps that needs to be cast off. All of the most-sophisticated modern patches and engines routinely applied to binary hacks owe their existence to the decomps, but are packaging those leaps in a way that can only stifle you and the rest of the community.
Similarly to the CRFU, Haven's new tools are also an anchor holding the community back. Let me be clear, new tools will never be able to fix the inherent problems and limitations of working with the binary ROM instead of the source code. With the decomps, you never need to hex edit. Everything you want is in plain-text and can be edited in Notepad (or preferably something like VS Code), including things that are not properly-interpreted by Haven's tools. The fancy hex editor that shows you what the hex for the base stat table means or whatever? That information looks like this in the decomps. All of the things you used to have to hex edit are in similar data files in the decomps in plain-text that you can read and instantly understand.
Haven's upcoming map editor is nicer than Advance Map, but the decomps have Porymap, which is leagues better than Advance Map, open source, feature-rich, and mature already. By the same dev is Poryscript, which is a complete replacement of XSE-style scripting that makes things faster and easier. Poryscript is so much better than XSE-style scripting that I can not adequately put into words how much more quickly it enables me to work. With it, you can write complex scripts multiple times faster than with XSE-style scripting, and its ease of use helps prevent you from making mistakes in your scripts.
The people at pret (who decompiled the games) have created an entire ecosystem and infrastructure for you to get going with decomp hacking that has already been superior to binary hacking for years, but binary hackers cling to a method that only limits their potential, regularly ruins their work, and slows them down.
The work binary tool and patch-makers are doing right now is being tragically wasted, and I hate to see such talent and drive locked into a restrictive and obsolete way of doing things. Ironically, their impressive work is actively harming the scene by delaying the transition to the decomps.
I understand that it is daunting to have the entire source code in front of you alongside grappling with setting up a development environment so you can build your decomp hack and work efficiently. The truth of the matter is, if you're starting from zero and doing a hack that will require you to do more than two or three hours of work, it is more efficient to start with the decomps than to roll the dice with binary hacking. Once you have an environment set up to work with the decomps, it is always, in all situations faster and more efficient for you to use the decomps. Only the absolute simplest of hacks are viable as binary if you're not already set up to use the decomps.
Here's a little secret. You don't really need to know how to code to use the decomps. The most popular binary hacks around are largely graphics, mapping, and scripting hacks that slotted in engine upgrades that other people made. Your hacking heroes don't know how to code either. You don't need to know how to code to script, map, or change the graphics. You could make the same caliber hack as the most popular binary hacks more quickly, more easily, and with fewer bugs than they did if you just start with the decomps. Knowing the absolute basics of the C language is helpful, obviously, but those are things that you will probably pick up if you're observant enough.
There are three big obstacles that I see people who are just starting out with the decomps struggling with. The first is setting up the initial environment, and it is all bark and no bite. There are tutorials on this very site going through it step-by-step, and every decomp's readme links to install instructions to set this up. You should not be afraid of the command line. This is set-it-and-forget-it, which means you only have to deal with this once.
The second is getting used to using version control systems. Git is the one that everyone uses, and it does have a bit of a learning curve. You can memorize the six or so commands you need to know and be good for 99% of what you'll be doing. In exchange, you get the full history of all of your changes like I explained earlier. That is too powerful to give up.
The third is just getting to know the structure of the source code itself. Where everything is, how to find the things you're looking for, etc. This comes with time and with playing around, but again, if you're doing the same caliber hack as the most popular binary ones, you will not be messing with the entire source code at once and will not need to know where everything is at all times.
It depends on what you want to be doing. Like I said, the vast majority of hacks out there could be recreated on the decomps with zero coding knowledge because most binary hacks were made with and most binary hackers have zero coding knowledge. The people that do have coding knowledge in the binary side of things are the ones who made the tools and the C injections, which can be used without being understood. Similarly, you can merge in things from decomp hackers who do know how to code without understanding them, all while never having to worry that you'll overwrite something and destroy your hack.
Do I personally think you should put in some effort to learn a little bit of C and try it out? Yes, I do think it is worth your while to try to learn the basics. If you are young, it may ignite a love of programming that you can leverage into a career in the future. If you are already in a career and doing this as a hobby, a basic understanding of programming can make you more marketable or propel you into learning something like Python more easily so you can automate some of your daily tasks. Decomp hacking is infinitely closer to actual programming experience than the blind groping-around-in-the-dark of binary hacking, and therefore the things you learn while using the decomps can more easily transfer into useful, real-world skills.
Pulling back to your actual decomp hack, learning a little bit of C will open up many more possibilities for your hack than not knowing any. Again, with the source code, you can do literally anything the GBA hardware can handle. Nothing is impossible for you to implement. If you learn some C, you won't run into scenarios where you'll be like, "I want to do this, but I'm not skilled enough to figure out how." You can just read the code to figure out what is going on, and then do it.
As an aside, most people will pick up some programming knowledge while working with the decomps, which raises the skill level of the entire community, enriching all of us.
Working to advance binary hacking is like working to advance fossil fuel technology. We are in a transition period between an outdated and worse way of doing things and a newer, better one. Any resources spent on improving the worse way of doing things just prolongs its inevitable demise. This energy-transition metaphor is even more apt for decomp hacking because decomp hacking is already mature and ready for mass adoption right now. There is no reason to continue to binary hack. There is a community-wide toll being taken on all of us every time someone's time or resources are wasted on advancing binary hacking over decomp hacking. It's like being a nuclear power and focusing your country's R&D on improving sword technology. Why would we willingly choose to waste our collective time and resources on something that is already obsolete and doesn't help any of us?
The community toll is vast, as every day of drag that keeps people into binary hacking holds back hackers that could be entering the decomp space and doing amazing things that we could all benefit from, but the individual toll cannot be understated. Even if everything goes perfectly right, a binary hacker will have taken way more time, way more effort, and have way more difficulty in producing the same hack than if they had started on the decomps. They will also not ever discover something along the way that will enrich community understanding, nor will they learn useful and directly translatable real-world skills. And that's assuming a perfect scenario with no corruption or bugs. And, because people's decomp hacks are generally open source, anything that any decomp hacker does automatically contributes to the wider community. The version history of each of our hacks becomes a library that all of us can learn and benefit from. This isn't true in the slightest for binary hacks.
The real scenario is that binary hackers will work tirelessly on a passion project just to see their labor of love lost to some random corruption, or will have setback after setback where they'll have to continually revert back to a previous copy of their hack and redo changes in the hopes of not destroying their work. How many of us have lost hours of work to something like that? I know I've lost hundreds over my 13ish years of binary hacking. How many hours have we collectively lost to this? How many great hacks got abandoned because of it? How many kids quit the scene in tears that could've been amazing hackers? How many of these kids would've been great programmers if they were led to the decomps instead of binary hacking tools?
It is time to stop binary hacking. Both the individual and community-wide cost is too great to continue. There is nothing that you can do through binary hacking that cannot be done better and safer with the decomps. No tool, neither those available now nor those released sometime in the future, will ever be able to overcome the massive shortcomings inherent in binary hacking compared to just using the source code.
If you have an existing binary hack that is already massive and almost done, then by all means finish it. If your hack is only a few Gyms in, or is very simple in scope, it is worth it to restart on the decomps. The time and frustration you will save will more than make up for the time it takes you to transition. Porymap can import maps and tilesets from Advance Map, by the way.
We need a concerted effort from the community to divert newcomers away from binary hacking and into the decomps moving forward, and support each other as existing binary hackers transition to the decomps. Binary hacking should be highly discouraged. All the resources needed to transition are out there and available, and I promise you that you will thank me once you get up to speed.
Introduction
I normally do not venture out of my hack's thread, but news of the new binary hacking tools and "engines" filter through the scene to me and I feel like I have to explain to those who may not know or aren't as informed about the state of the scene why both individual hackers and the entire community would be better off if binary hacking was entirely abandoned.
For those who don't know me, I'm Deokishisu, and I've been trapped in the Pokemon hacking scene for over 18 years. Yes, that is longer than some (perhaps even most) of you have been alive. I've seen every major era of ROM Hacking and have been a part of almost all of it. This means I've seen every transition, every paradigm shift, every fad, every new tool (I was around and hacking before we had Advance Map, as an example), and I've seen every big player come and go. I can tell you that the introduction of a complete, matching decompilation for the Gen 3 games with robust documentation is the biggest and most influential shift in the scene that has ever or will ever happen, but most of you aren't taking advantage of it. It's akin to our community suddenly discovering fire, yet somehow nearly the entire scene still prefers to eat uncooked slop in the dark.
I'm sure many will call me an elitist for spelling it out this plainly. I am not an, "elite," I just have more experience than 99% of you. Your math teacher trying to pass down some of their understanding isn't an "elite" because they are a subject-matter expert and you are not. I am a subject-matter expert when it comes to this hobby. I say that not to make anyone feel bad or lord it over anyone, but to hopefully illustrate why you should consider my words. I am not trying to hide any knowledge from you (in fact, everything I've ever done with the decomps is open source), but to share what I know freely to improve the community and the scene.
What are the Decomps?
Decomp is short for decompilation. The quick and dirty definition is that a group of amazing people took the Pokemon ROMs and reverse-engineered (or decompiled--which is the opposite of compiled) them, producing the source code. The ROM file is the binary file that is the result of compiling the source code into a .gba executable, which is why working on the compiled ROM is called binary hacking. Having the source code enables you to do literally anything the GBA hardware is capable of in your hack.
Almost as monumental as being able to edit the source code directly (because let's face it, most of you will not be doing huge rewrites of the code), is the fact that working with the source enables you to use a version control system, such as Git. A version control system allows you to see a history of every single change you have ever made to your work. This makes it so you always have a clear record of what you've done, and will be able to identify any bugs you've introduced and fix them without restarting your entire project. Your hack never becomes irreparably corrupted, and all of the oopsies you make are undoable or fixable as long as you're making your commits (akin to Windows system restore points for your code) at sensible intervals.
The version control system also allows you to incorporate other people's work easily into your hack through a process called merging. There is a complete battle engine upgrade that decomp hackers have put together, for example, that you can merge right in. Because you have the full history and control of the source code, you can easily merge any bug fixes or updates to the battle engine without destroying your work. These processes involving version control are what real devs use in their actual jobs, so the tooling is robust and designed to make things as easy as they reasonably can be. It really cannot be overstated how monumentally important having a version control system is.
Another major benefit that everyone who uses the decomps over binary hacking gets immediately is that there are no fixed offsets. You never have to search for free space. You never have to repoint. You never have to worry that you'll overwrite something important. All offsets are relative and everything will be automatically shifted around so that it always fits without overwriting anything. Overwriting things that you (or a buggy tool, more on that later) thought was free space is probably 90+% of the unrecoverable corruptions that destroys the hard work of binary hackers. It will literally never happen to you when working with the decomps, because it is impossible.
Why Should We Abandon Binary Hacking?
Let me answer this with another question, why do you tolerate the gradually-increasing threat of corrupting your ROM and losing your work with every little change? We've all been there where you discover that some change you made eons ago corrupted your ROM and now you're faced with either restarting or accepting gamebreaking bugs or crashes. If you haven't been there yet, you will be, and it's devastating.
Why do you tolerate having no real control over what you're actually doing to your hack? Using buggy tools from over a decade ago whose creators had incomplete (at best) knowledge of the game's code when they were implementing their features should be a non-starter for most people. On top of this, you're layering these targetted changes on top of other tools and random patches (that were also made with unreliable tools on incomplete information) and end up with this rats nest of hacks on top of hacks that is impossible for anyone to untangle, much less a novice.
The patches floating around are buggy on their own, and because they're being applied to binary hacks at fixed offsets, are very difficult for the end user to update to new versions. Because of the time period they were created in, the creators of these tools and patches have less knowledge about the actual code and what their stuff is doing under the hood than people just starting out with the decomps do. Just like you wouldn't eat uncooked meat from a tribe that didn't have fire, you shouldn't be trusting hours of your hard work to people that barely have a greater understanding of what you're doing than you do. The decomps offer you fire, the binary toolmakers offer you a slightly-better version of a club you already have.
If you're binary hacking, you are using 2004-era knowledge in a field that is about to be in 2023. I know this because I was active in 2004, and the only leap that binary hacking has made in that time period has been C injections whose modern-day sophistication was directly enabled by progress in the decomps. A good example of this is the CRFU, which only exists because the decomps allowed Skeli to read and manipulate the source code. CRFU was made in a time when the decomps were not complete enough to be used by the general public, and I'm not discounting the effort and skill it took to make it (Skeli has done a phenomenal job), but now it is a weight holding back the community and delaying the full transition to the decomps that needs to be cast off. All of the most-sophisticated modern patches and engines routinely applied to binary hacks owe their existence to the decomps, but are packaging those leaps in a way that can only stifle you and the rest of the community.
Similarly to the CRFU, Haven's new tools are also an anchor holding the community back. Let me be clear, new tools will never be able to fix the inherent problems and limitations of working with the binary ROM instead of the source code. With the decomps, you never need to hex edit. Everything you want is in plain-text and can be edited in Notepad (or preferably something like VS Code), including things that are not properly-interpreted by Haven's tools. The fancy hex editor that shows you what the hex for the base stat table means or whatever? That information looks like this in the decomps. All of the things you used to have to hex edit are in similar data files in the decomps in plain-text that you can read and instantly understand.
Haven's upcoming map editor is nicer than Advance Map, but the decomps have Porymap, which is leagues better than Advance Map, open source, feature-rich, and mature already. By the same dev is Poryscript, which is a complete replacement of XSE-style scripting that makes things faster and easier. Poryscript is so much better than XSE-style scripting that I can not adequately put into words how much more quickly it enables me to work. With it, you can write complex scripts multiple times faster than with XSE-style scripting, and its ease of use helps prevent you from making mistakes in your scripts.
The people at pret (who decompiled the games) have created an entire ecosystem and infrastructure for you to get going with decomp hacking that has already been superior to binary hacking for years, but binary hackers cling to a method that only limits their potential, regularly ruins their work, and slows them down.
The work binary tool and patch-makers are doing right now is being tragically wasted, and I hate to see such talent and drive locked into a restrictive and obsolete way of doing things. Ironically, their impressive work is actively harming the scene by delaying the transition to the decomps.
But I Don't Know How to Code! Starting With Binary Hacking Is So Much Easier!
I understand that it is daunting to have the entire source code in front of you alongside grappling with setting up a development environment so you can build your decomp hack and work efficiently. The truth of the matter is, if you're starting from zero and doing a hack that will require you to do more than two or three hours of work, it is more efficient to start with the decomps than to roll the dice with binary hacking. Once you have an environment set up to work with the decomps, it is always, in all situations faster and more efficient for you to use the decomps. Only the absolute simplest of hacks are viable as binary if you're not already set up to use the decomps.
Here's a little secret. You don't really need to know how to code to use the decomps. The most popular binary hacks around are largely graphics, mapping, and scripting hacks that slotted in engine upgrades that other people made. Your hacking heroes don't know how to code either. You don't need to know how to code to script, map, or change the graphics. You could make the same caliber hack as the most popular binary hacks more quickly, more easily, and with fewer bugs than they did if you just start with the decomps. Knowing the absolute basics of the C language is helpful, obviously, but those are things that you will probably pick up if you're observant enough.
There are three big obstacles that I see people who are just starting out with the decomps struggling with. The first is setting up the initial environment, and it is all bark and no bite. There are tutorials on this very site going through it step-by-step, and every decomp's readme links to install instructions to set this up. You should not be afraid of the command line. This is set-it-and-forget-it, which means you only have to deal with this once.
The second is getting used to using version control systems. Git is the one that everyone uses, and it does have a bit of a learning curve. You can memorize the six or so commands you need to know and be good for 99% of what you'll be doing. In exchange, you get the full history of all of your changes like I explained earlier. That is too powerful to give up.
The third is just getting to know the structure of the source code itself. Where everything is, how to find the things you're looking for, etc. This comes with time and with playing around, but again, if you're doing the same caliber hack as the most popular binary ones, you will not be messing with the entire source code at once and will not need to know where everything is at all times.
Should I Learn to Code to Decomp Hack?
It depends on what you want to be doing. Like I said, the vast majority of hacks out there could be recreated on the decomps with zero coding knowledge because most binary hacks were made with and most binary hackers have zero coding knowledge. The people that do have coding knowledge in the binary side of things are the ones who made the tools and the C injections, which can be used without being understood. Similarly, you can merge in things from decomp hackers who do know how to code without understanding them, all while never having to worry that you'll overwrite something and destroy your hack.
Do I personally think you should put in some effort to learn a little bit of C and try it out? Yes, I do think it is worth your while to try to learn the basics. If you are young, it may ignite a love of programming that you can leverage into a career in the future. If you are already in a career and doing this as a hobby, a basic understanding of programming can make you more marketable or propel you into learning something like Python more easily so you can automate some of your daily tasks. Decomp hacking is infinitely closer to actual programming experience than the blind groping-around-in-the-dark of binary hacking, and therefore the things you learn while using the decomps can more easily transfer into useful, real-world skills.
Pulling back to your actual decomp hack, learning a little bit of C will open up many more possibilities for your hack than not knowing any. Again, with the source code, you can do literally anything the GBA hardware can handle. Nothing is impossible for you to implement. If you learn some C, you won't run into scenarios where you'll be like, "I want to do this, but I'm not skilled enough to figure out how." You can just read the code to figure out what is going on, and then do it.
As an aside, most people will pick up some programming knowledge while working with the decomps, which raises the skill level of the entire community, enriching all of us.
Why Is the Continuation of Binary Hacking Bad for All of Us?
Working to advance binary hacking is like working to advance fossil fuel technology. We are in a transition period between an outdated and worse way of doing things and a newer, better one. Any resources spent on improving the worse way of doing things just prolongs its inevitable demise. This energy-transition metaphor is even more apt for decomp hacking because decomp hacking is already mature and ready for mass adoption right now. There is no reason to continue to binary hack. There is a community-wide toll being taken on all of us every time someone's time or resources are wasted on advancing binary hacking over decomp hacking. It's like being a nuclear power and focusing your country's R&D on improving sword technology. Why would we willingly choose to waste our collective time and resources on something that is already obsolete and doesn't help any of us?
The community toll is vast, as every day of drag that keeps people into binary hacking holds back hackers that could be entering the decomp space and doing amazing things that we could all benefit from, but the individual toll cannot be understated. Even if everything goes perfectly right, a binary hacker will have taken way more time, way more effort, and have way more difficulty in producing the same hack than if they had started on the decomps. They will also not ever discover something along the way that will enrich community understanding, nor will they learn useful and directly translatable real-world skills. And that's assuming a perfect scenario with no corruption or bugs. And, because people's decomp hacks are generally open source, anything that any decomp hacker does automatically contributes to the wider community. The version history of each of our hacks becomes a library that all of us can learn and benefit from. This isn't true in the slightest for binary hacks.
The real scenario is that binary hackers will work tirelessly on a passion project just to see their labor of love lost to some random corruption, or will have setback after setback where they'll have to continually revert back to a previous copy of their hack and redo changes in the hopes of not destroying their work. How many of us have lost hours of work to something like that? I know I've lost hundreds over my 13ish years of binary hacking. How many hours have we collectively lost to this? How many great hacks got abandoned because of it? How many kids quit the scene in tears that could've been amazing hackers? How many of these kids would've been great programmers if they were led to the decomps instead of binary hacking tools?
Conclusion
It is time to stop binary hacking. Both the individual and community-wide cost is too great to continue. There is nothing that you can do through binary hacking that cannot be done better and safer with the decomps. No tool, neither those available now nor those released sometime in the future, will ever be able to overcome the massive shortcomings inherent in binary hacking compared to just using the source code.
If you have an existing binary hack that is already massive and almost done, then by all means finish it. If your hack is only a few Gyms in, or is very simple in scope, it is worth it to restart on the decomps. The time and frustration you will save will more than make up for the time it takes you to transition. Porymap can import maps and tilesets from Advance Map, by the way.
We need a concerted effort from the community to divert newcomers away from binary hacking and into the decomps moving forward, and support each other as existing binary hackers transition to the decomps. Binary hacking should be highly discouraged. All the resources needed to transition are out there and available, and I promise you that you will thank me once you get up to speed.
Last edited: