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

[Other] Stop Binary Hacking; It's Holding Back the Entire Community

Deokishisu

Mr. Magius
990
Posts
18
Years
  • 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.

    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:

    jiangzhengwenjzw

    now working on katam
    181
    Posts
    11
    Years
    • Seen yesterday
    I like to encourage others to use pokeemerald, but tbh this post just looks aggressive and makes no sense. Just let people do what they want.

    Detailed explanation here
     
    Last edited:

    haven1433

    Modder / Programmer
    42
    Posts
    10
    Years
    • Seen Jan 16, 2024
    Thanks for the name drop! Keep doing what you can to make hacking better for everyone, I'll keep doing the same. My new map editor, integrated into HMA, is trying to solve many of the same problems you mentioned (people using "buggy tools from over a decade ago") so I'm glad to see that we're on the same team :)
     

    Lunos

    Random Uruguayan User
    3,114
    Posts
    15
    Years
  • I don't disagree with the sentiment that binary hacking feels like a shackle that's limiting or holding back progress and better things, but sadly, many people just don't want to put up with the higher entry barrier the decomps have (that is, having to read a straightforward tutorial about setting up an environment with WSL and some installed packages that they never have to interact with manually), or with having to code in any new features that are not present at the Pokeemerald wiki or the Simple Modifications Directory (even though they'd also have to code any custom feature in binary too and that it's harder to do it there).
    At the end of the day, I prefer to stick to the "live and let live" or "to each their own" mottos, just like Jiang above.
    Let people use whichever method they think it's most appropriate for them and their project.

    I personally think that the way of thinking of the people that use the decomps is just not compatible with the way of thinking that people who decide to do binary hacking for these games in almost 2023 have.
    I feel that some people just want to make a by-the-numbers Pokémon game without having to do much of the work that is normally involved in making a game themselves and there's no changing that.

    People who understands the benefits and pros of the decomps will likely use them.
    I mean, those of us who do use them know they give more freedom than binary ever could and that they're easier to use once you've an environment set up.
    Meanwhile, the people who don't understand or don't want to understand will not. There's nothing that can be done about that. When there's a will there's a way, but the opposite holds true too.
     
    Last edited:

    Deokishisu

    Mr. Magius
    990
    Posts
    18
    Years
  • I've edited the original post to hopefully fix my unintended aggressive tone and cut out some of the fluff. I'm not angry or anything, I just genuinely want the scene to improve and there is no way to do that at a decent pace while binary hacking at its current scale continues to sap the community's attention, effort, and resources.
     
    Last edited:

    U.Flame

    Maker of Short Games
    1,326
    Posts
    15
    Years
  • It still sounds incredibly passive aggressive to call Skeli and Haven's efforts additional shackles holding the community back. People will gravitate towards whatever method ends up easier to pick up for them personally. While I encourage community effort and collaboration, I honestly don't think the community should be someone's first priority. I think anyone's number one priority should be their own enjoyment and fulfillment from their hobbies. Being part of this community is a great experience, but if you try to shame others for their methods or tell them not to do things the way they want, well, that makes you sound elitist.
     
    448
    Posts
    6
    Years
    • Seen May 6, 2024
    Thank you for taking the time to write this.
    I think a lot of people choose binary hacking because they simply don't know any better or because they have some misconceptions about the decomps, and I think posts like this can help people understand things better.

    I do however disagree with
    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.
    Because in practice you will quickly run into merge conflicts that you can't solve without understanding C. If you also don't know how to undo things with git you'll be in a situation where your project doesn't even compile.

    So while basic programming skills aren't strictly required, the lack of them can limit you from even using other people's code in certain cases.
     
    192
    Posts
    5
    Years
  • 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.

    What you said is very polemic, but many people are into binary hacking for the ease of changing bytes instead of going to the source code.
    Both hacking variables (decomps vs. binary) have advantages and disadvantages. Currently, I prefer binary for the ease with which values are changed.
    If people working with decomps could make patches or injections that make life easier for binary hacking users (Like me, hahaha), they would be balancing the whole rom hacking plot.
     

    The Falansh

    Banned
    44
    Posts
    1
    Years
    • Seen Dec 31, 2022
    What you said is very polemic, but many people are into binary hacking for the ease of changing bytes instead of going to the source code.
    Both hacking variables (decomps vs. binary) have advantages and disadvantages. Currently, I prefer binary for the ease with which values are changed.
    If people working with decomps could make patches or injections that make life easier for binary hacking users (Like me, hahaha), they would be balancing the whole rom hacking plot.

    I agree binary is fun for changing bytes
     

    The Falansh

    Banned
    44
    Posts
    1
    Years
    • Seen Dec 31, 2022
    Also i think , we take binary or decomps whatever mapping and scripting are needed and also it is on people they would take whate8ver suits them easy or hard they0 don't care then
     

    The Falansh

    Banned
    44
    Posts
    1
    Years
    • Seen Dec 31, 2022
    Not really, you can have fun messing around and breaking roms as a learning experience, or just to experiment. You never HAVE to know what you're doing really.

    Right and when i started everytthing i did was so simple , i used patches and when i found a new patch and patch i thought i am making best fire red hack xd. Then i understood things like how to insert asm , cfru .
     

    Asith

    Uwao
    237
    Posts
    3
    Years
    • Seen yesterday
    I want the scene to improve and there is no way to do that at a decent pace while binary hacking at its current scale continues to sap the community's attention, effort, and resources.

    Exactly, binary projects are secretly magic effort-vampires sucking the drive out of anyone working towards migrating to decomps. Hundreds of decomp hackers see a binary hack every day and think "I can't contribute to the decomp hacking scene today with this in my way". Timmy making a binary hack in his bedroom has single-handedly kept us from the gen4 decomp. Truly if everyone stopped making their projects how they want we would evolve faster. Indeed, making a binary project is like burning fossil fuels or... *checks notes* "investing in swords" because it uses up the entire community's collective time, resources, and well-being, and isn't just an individual choice that affects nobody else except the project maker and their audience! All our community tax dollars are being wasted by these accursed binary freeloaders stealing MY effort with their SILLY binary hack
     
    448
    Posts
    6
    Years
    • Seen May 6, 2024
    This is quite a passive aggressive approach to telling people "just git gud and stop being lazy, only real hackers do decomps".
    The whole point is the complete opposite of this. You don't need to be a "real hacker" to be able to use the decomp and even less skilled people could benefit from decomp hacking if they gave it a shot.
    For a lot of projects decomp hacking IS the "FASTER and EASIER" solution. The difficulty and slowness of decomp hacking is mostly only in the beginning stages of a project.

    You also equate decomp hacking to asm, which is a bit silly when one of the upsides of decomp hacking is that you will never need to learn asm.
     

    X_Zenith

    Banned
    145
    Posts
    3
    Years
  • Ahh man! The author has posted this everyone on rom hacking sites like reddit seriously by this some of the people will definitely hate decomps as it is becoming like forcing someone as the title says here stop binary hacking , we cannot force someone , we can only ask to try that thing.
     

    Deokishisu

    Mr. Magius
    990
    Posts
    18
    Years
  • It still sounds incredibly passive aggressive to call Skeli and Haven's efforts additional shackles holding the community back. People will gravitate towards whatever method ends up easier to pick up for them personally. While I encourage community effort and collaboration, I honestly don't think the community should be someone's first priority. I think anyone's number one priority should be their own enjoyment and fulfillment from their hobbies. Being part of this community is a great experience, but if you try to shame others for their methods or tell them not to do things the way they want, well, that makes you sound elitist.

    It would've been passive aggressive if I only alluded to them and made my references to their work vague in a, "You know who you are," sort of way. I acknowledged the incredible talent and skill of both of them, but that doesn't change the fact that their work is the biggest thing holding back the transition to decomp right now and justifying continuing to binary hack to a large group of people. It seems harsh, but it can't be put any other way. I didn't intend to shame people, only to inform.

    Because in practice you will quickly run into merge conflicts that you can't solve without understanding C. If you also don't know how to undo things with git you'll be in a situation where your project doesn't even compile.

    So while basic programming skills aren't strictly required, the lack of them can limit you from even using other people's code in certain cases.

    Yes, you are correct here. I didn't mention that because ordinarily the merge conflicts with pulling in the battle engine are some of the most common issues we see and people are always readily available to help out solving them. This is great for the end user, because it's an amazing first learning experience (the battle engine merge is generally the person's first or second interaction with git and C) and helps them get acclimated to the decomp community. Most of the merge conflicts are simple as well, which eases people in.

    Still, I should've mentioned it in that section. I'll go back and edit it in sometime today.

    What you said is very polemic, but many people are into binary hacking for the ease of changing bytes instead of going to the source code.
    Both hacking variables (decomps vs. binary) have advantages and disadvantages. Currently, I prefer binary for the ease with which values are changed.
    If people working with decomps could make patches or injections that make life easier for binary hacking users (Like me, hahaha), they would be balancing the whole rom hacking plot.

    Binary hacking offers no advantages unless you are doing the most simple and quickest of hacks. Like I said in my post, if you're going to spend more than a few hours on your hack, you should start it in the decomps. If all you're doing is changing the starters and swapping some graphics, then sure, depending on the scope doing it in binary may be faster. Once you get much more complex or much more involved than that, the disadvantages of binary hacking begin to compound. The longer you're binary hacking, the faster they grow.

    Making patches and injections for binary hacks using the decomps is part of the problem I tried to illustrate in my post that is artificially lengthening the relevance of binary hacking. Decomp hackers generally don't do that for binary hackers because we have been on both sides of the aisle and know that prolonging the binary era would do our binary counterparts a disservice.

    I agree binary is fun for changing bytes

    I'm sorry, but there is no person in this forum whose fun while hacking is derived entirely from "changing bytes." If that was the case, they'd be opening up random files in a hex editor and gleefully typing in random hex and wouldn't be here. I think that's a huge oversimplification of what most people like to do here, which is to create. The process of creation is easier, quicker, less frustrating, and less error-prone with the decomps. It is also less destructive, considering how common corruption is while binary hacking.

    Spoiler:

    ^ This is the whole post spoilered. Because it is so long I'm going to separate out some relevant quotes to respond to.

    Don't get me wrong, I think there is a lot of nuance here, but just like with any education system, you seem to be approaching this as though EVERYONE wants to become the next big thing. As though EVERYONE wants to make a "from scratch" kind of hack. As though EVERYONE wants to make the "best of the best" to offer.

    Mind you, most people, want to make hacks that are either:

    1) Harder
    Which can more or less be done with binary hacking or hacking tools. Since the vast majority of these hacks are just harder Pokemon teams, less item access, or disabling access to the Pokecenter or other areas.

    2) Containing just the Pokemon they like
    Which once again, with how easy most tools are (with the exception of GB/GBC, because tools for that are more or less crap anyways (with the exception of a VERY SMALL few)) can be done through binary or tools.

    3) Contain every Pokemon ever
    Considering there are bases made for that and tools for their bases, once again promotes binary hacking.

    4) Dex replacements / Map replacements
    Once again, now more than ever (especially in the GBA communities) it is absurdly easy to do this with tools and binary.

    I'm not implying that most people will want to be the best of the best. The vast majority of hacks, even the most popular ones, are incredibly simple to make. Every kind of hack on your initial list can be accomplished quickly and easily on the decomps. The first two are literally editing plain-text in any text editor. The third is merging the Pokemon expansion and/or battle engine and then editing wild Pokemon in porymap or plain-text files. The fourth is accomplished again through text edits and for map edits Porymap is better and easier to use than any mapping tool out there by orders of magnitude.

    1) "People should stop making EASE OF ACCESS tools." In which case, sounds like ELITISM, because you're not only telling people what they can and cannot do, but telling them that what they do is an insult to hacking in general.

    or

    2) "Only people who have the time/patience and skill to do ASM and DECOMP should be allowed to make hacks, because they are the only ones contributing to the community". Which once again is ELITISM because now you're GATEKEEPING hacking because it doesn't fit YOUR standards.

    It is neither elitism nor gatekeeping. Binary hacking takes more time and is more difficult and error-prone than decomp hacking in the long run. I am trying to save people time and frustration. Quite frankly, your attitude is coming from a place of ignorance of decomp hacking and how it works, and I invite you to join us in pret's Discord and try it out.

    I am indeed of the opinion that support for binary hacking should be abandoned, because it is prolonging a period where hacking is made more difficult for everyone for no real reason other than community inertia. All of the ease of access tools have been here since like 2010 (and the most important since well before then), and no meaningful progress on that front as been made between then and when decomps became usable. Further development in this area will slow the transition to decomp and split the community for no benefit.

    It's not about my personal standards, it's about objective truth: using the source code and creating a decomp hack that is open source contributes to the community with every little bit of progress made on the hack. There is no more room in the binary hacking space to discover anything or contribute any new knowledge because there is nothing new to be learned there. The documentation in the decomps has supplanted all research into the binary ROMs, and this is coming from someone who was very active in the old R&D threads pre-decomp days. This era is over.

    If the source code for the GBA games leaked in 2004 and we had all been using the source for this entire time, you would find the suggestion to return to binary hacking absurd. Your own post would be unthinkable. This is what I'm trying to get across to binary hackers. It's very hard to communicate the magnitude of the improvement and the ease that comes with working with the decomps compared to binary hacking. You all just have to try it and stick with it for a few days and you will see. This is why I tried to drop my credentials, as ridiculous as doing so in a community like this is, in the intro to my post to try to communicate that I know what I'm talking about here.

    Humans in general, and society as a whole, are all about INSTANT GRATIFICATION. We no longer pursue things that are LONG TERM. The longer it takes to achieve something, the less inclined MOST of us are to pursue it. When it comes to ROM HACKING, we are no different.

    Again, it takes longer to create a binary hack than it would to create the exact same hack on the decomps. Most binary hackers do not know this.

    So to sum this up:

    1) Should people work on improving to produce higher quality hacks? Yes.

    2) Will MOST people actually do this? Nope.

    I, and most other decomp hackers, don't care if hackers produce higher quality hacks. We care that people are intentionally clinging to a way of doing things that is actively hindering them and making their hacking harder. I don't play other people's hacks, with very very rare exceptions. The quality of random hacks does not concern me.

    Also, for the record, nowhere did I say binary hackers are lazy. In fact I implied that they work harder and put up with more crap to get their hacks out than decomp hackers, which is demonstrably true. It's also demonstrably true that they put up with all that for no reason when decomps are ready to go and have been for years.
     
    Last edited:
    18,811
    Posts
    21
    Years
  • Not really, you can have fun messing around and breaking roms as a learning experience, or just to experiment. You never HAVE to know what you're doing really.

    Hard disagree.

    If you're looking through the RAM viewer and tinkering, sure, it'll be fun. If you're looking through a ROM and changing bytes with some kind of hypothesis in what your edit would do, go right ahead. Hell, experimentation is exactly how established binary hackers got really started — Coolboyman for example. (And I note that even he saw the benefits of switching away.)

    But changing things wily-nilly without recourse may lead to undesirable results and hell, crashes. Bar what a tutorial may show, it's a lot to put on beginners.

    This is quite a passive aggressive approach to telling people "just git gud and stop being lazy, only real hackers do decomps".

    Don't get me wrong, I think there is a lot of nuance here, but just like with any education system, you seem to be approaching this as though EVERYONE wants to become the next big thing. As though EVERYONE wants to make a "from scratch" kind of hack. As though EVERYONE wants to make the "best of the best" to offer.

    I can understand your viewpoint, but I feel the need to dissect each of your points. I'll start with this point and break down most of your post below:

    1. Yes, we should accommodate to hobbyist hacks from time to time. PokéCommunity accepts either/or, as well. But a significant number of people see a hack and decide they want to develop something. Sometimes, these don't get very far, but we publish an insane amount of decent hacks and some of these certainly keep building to something amazing. For manipulating a single byte or two to change the starters, yes, pointing to a decomp is overkill. But a significant number of hacks starting out that get published to PC's Progressing Hacks sections aren't that, and Deokishisu does acknowledge that. These are not mere tinkerers.
    2. Where education is concerned, if you're serious about starting a game project, then there's no harm in pushing for someone to read code and understand what a game is doing. Hell, the skill transfer from doing so is immense — plenty of jobs are available for someone who has a grasp of programming, and the decomps aren't a bad approach for getting someone into it. Hell, the open-source community pushes a committed tinkerer to do this all the time. (That there's an easy route is cool and all, but they're not part of this discussion.)

    Mind you, most people, want to make hacks that are either:

    1) Harder
    Which can more or less be done with binary hacking or hacking tools. Since the vast majority of these hacks are just harder Pokemon teams, less item access, or disabling access to the Pokecenter or other areas.

    As above, tinkering is cool, but the majority of hacks we see are more than just this kind of hack. And the applicability of tinkering with a bit of source code to achieve a desired result is something you could apply in plenty of contexts. It's abstracted into maybe a random tutorial or two, or a mere tool, without allowing for too much critical thought for developing a binary hack.

    2) Containing just the Pokemon they like
    Which once again, with how easy most tools are (with the exception of GB/GBC, because tools for that are more or less crap anyways (with the exception of a VERY SMALL few)) can be done through binary or tools.

    3) Contain every Pokemon ever
    Considering there are bases made for that and tools for their bases, once again promotes binary hacking.

    Where one is installing tools vs. creating a development environment, yes, doing any of your first three points may be overkill. But these points really do feel like they're batting for a tinkering community. Which is fine, but they aren't the point. I don't think anyone is looking to completely kill off binary hacking (unless you ask me about it); it certainly has its uses.

    And hey, why not; let's talk about the tinkerer. In doing so, I'll probably retread a few points Deoki has made.

    Say they want to make a hack that contains every Pokémon ever so they can embark on their own personal journey through Kanto with 1000+ Pokémon. They're downloading this patch that makes it easy, but then maybe the patch was made so that hackers could then play with it further and put the Pokémon in the areas they want. So now, the tinkerer has to do more work, so they download AdvanceMap to start putting Pokémon in places. And now they've found out they need to make an INI adjustment or download a patched version to make it recognise the extended Pokémon. They also get to contend with tools that might be dated or do not recognise the latest changes made to the 1000+ patch, or they need to download another custom INI. Then they want to get harder trainers in, so they need to get a tool that works. And sure, Haven's made one that will fit some of those purposes. Good stuff, but more downloads, more tools, and a significantly higher chance one will run into problems.

    There is no one-size-fits-all approach for the tinkerer, either. Sure, they could pick up a quick complete patch that suits their needs from our Sideshow Showcase section. But even those patches may not fit what the user wants out of a game.

    4) Dex replacements / Map replacements
    Once again, now more than ever (especially in the GBA communities) it is absurdly easy to do this with tools and binary.

    Now for anyone who wants to do this for a full-scale hack, here's a couple things:
    1. Just try this replacement; oh, have you been writing some data for some new maps and scripts at a random offset? Let's hope the tool or patch doesn't overwrite it! Sure, you could go and recompile all your scripts, maps, music, etc. to fit around it, but this gets hairy when you've done significant work. You may as well start over.
    2. The RHH pokeemerald-expansion simplifies this by being easily pulled with all the changes you need. Of course, if you've already made significant progress with your decomp-based hack, you may end up contending with merge conflicts. But they are a hell of a lot easier to sort through, though they may start requiring a bit of C knowledge to resolve. But if you've made significant progress in your hack, you'll either know what to do, or you're unaffected because you haven't touched the engine.

    Now, there are two reponses you can give to this:

    1) "People should stop making EASE OF ACCESS tools." In which case, sounds like ELITISM, because you're not only telling people what they can and cannot do, but telling them that what they do is an insult to hacking in general.

    or

    2) "Only people who have the time/patience and skill to do ASM and DECOMP should be allowed to make hacks, because they are the only ones contributing to the community". Which once again is ELITISM because now you're GATEKEEPING hacking because it doesn't fit YOUR standards.


    See, the thing is this... the VAST majority of people that get into these communities, do it for FUN. We are also in an era where people are living by a quote that is far too familiar, known as "if it ain't broke, don't fix it". Which is basically saying "it works now, so why does more need to be done?"

    Humans in general, and society as a whole, are all about INSTANT GRATIFICATION. We no longer pursue things that are LONG TERM. The longer it takes to achieve something, the less inclined MOST of us are to pursue it. When it comes to ROM HACKING, we are no different.

    Many people would view the EASY ROUTE as another way of being LAZY, but this isn't true. In the same vain that people use calculators to solve math, use cash registers to sort and detail costs vs spending, in the same way we use computers and phones to talk to one another (rather than being on horseback delivering mail), and so many other parts of life, we as a society, have more or less agreed that "less work" is better.

    This isn't to say that people SHOULDN'T do more, but that you're talking into the void. Most people want to have things NOW, want to be finished NOW, want to experience it NOW. Telling people "hey, be patient" doesn't work. You ever seen any game related discord? Non-stop, every day, people are asking "is it completed yet?", "can I beat it yet?", "is it released yet?".

    So for what it's worth, PC does offer different things for anyone to play around, but I'm not about to suggest it's ever directly catered to tinkerers. Hell, a lot of tools and tutorials we've had posted aren't explicitly designed for the tinkerer. Take it from my fifteen years on-and-off moderating this section — from endless title screen modification tutorials to outdated scripting tutorials, to ASM insertion tutorials and ones that compile from C, I don't believe PC's ROM hacking culture caters to anyone but a fan game developer with some kind of vision for their game. They should not be satisfied with an easy route — because there isn't one. The instant gratification people seek would be irrelevant to them, because none of these tools provide that.

    And for those who do just want to be gratified with a game that does some tiny things or big things, they're (almost) instantly gratified with a half- or fully-completed game from the sections. They simply aren't considered with all the ROM hack development sections on PC. (Though if any of you feel as if they should, send me a PM and I'll propose it to the team!)

    If you want people to learn DECOMP and ASM, then it needs to be NOW, not LATER. It needs to be EASIER and FASTER, because the majority of hackers don't even have the time to complete or even work on their BINARY hacks. A good majority of them are still children in school or adults with full-time jobs, or people who have lives and just found this stuff to be mildly amusing.


    If you want people to become BETTER (since I guess BINARY hacks are less than acceptable to you), then you have to make the ENTRY into DECOMP and ASM easier. Cause at the moment, when you look at communities like PRET on discord, without an extensive knowledge of ASM and DECOMP already, getting help on there might as well be speaking a new language.

    One of the key issues is simply that, while tutorials can teach you the basics, they do not explain what stuff is, only how to get there. Most tutorials tell you the HOW and not the WHY, and when most people don't know the details behind the complex work, then people get stuck making that one thing that the tutorial taught them.

    I don't disagree, but the premise of Deoki's post is to push those more seasoned ROM hackers and aspiring ones from using binaries. And we have a significant amount of people continuing to push it — and for those who want to remain committed, one of the paths they might be pushed into choosing may lead to a world of hurt.

    It's my personal intention as part of our Fan Games staff to push for learning better approaches to making games. (And god, this sounds like a PC PR spiel.) Part of that will very much involve making decomps more accessible.

    All in all, yes, binary hacking has its uses — if someone wants to tinker and give themselves a Level 100 Charizard as a starter, then why build a development environment around it? But they are not the people the ROM hacking community at PC are setting their sights at working for. And when you're trying to develop something bigger, the existing binary-based approaches are failing us, and we really ought to stop pushing people toward it. For a dedicated ROM hacker, there is no instant gratification no matter what tools pop up.
     

    Deokishisu

    Mr. Magius
    990
    Posts
    18
    Years
  • The OP doesn't need to tell people to their face that "their hacks aren't as good" to basically say that. Most people, especially people who just got into hacking or prefer binary at the moment, will more than likely see this post as a big ol' middle finger.
    Again you are putting words in my mouth. Nowhere in my post did I disparage binary hacks or imply that they were inferior. I repeatedly point to the most popular binary hacks and put them up as an example of what is attainable through decomp to normal people with not a lot of programming knowledge, and I also praise the makers of the tools/CRFU I mention for their talent and drive.
     

    Skeli

    Lord of the Rings
    300
    Posts
    10
    Years
  • As someone who knows and understands full well the merits of your argument, if I were to ever consider making another hack, I still wouldn't use the decomps in their current state. For two reasons:


    1. The only aspects of ROM hacking that are even fun to me any more are solving the problems that people love to say about "you can't do that on binary." Sure, binary hacking can be frustrating at times, but I know what I'm doing and the joy comes from overcoming those frustrations. And yes, I know decomps have their own share of frustrations, but what I find fun is up to me and no one else.
    2. The Emerald battle engine upgrade is currently far inferior to the CFRU's. First off the CFRU's is actually complete, unlike Emerald's which is still missing several features. Second, the AI in the EBEU isn't nearly as good as the CFRU's. And third, most of the attack animations in the EBEU came from an older version of the CFRU. I've since updated many of those animations -- updates which are not reflected in the EBEU. So until the EBEU surpasses the CFRU's battle engine, I wouldn't willingly switch. And you could argue "But, Skeli, unless you quit binary hacking and improving the CFRU how are they supposed to pass it?". I'm one programmer who's barely done anything to it in the last year while they're a team of several. I think they have all the advantage they need.

    In a few years your argument might have more weight, though, but who knows.
     
    Back
    Top