Fixed a typo, expanded the article and cleared a small misconception about binary hacking.

Why-should-I-use-this-over-binary-hacking.md

@@ -1,11 +1,15 @@
-Binary hacking is, for the most part, very limited. New features are hard to add without the base functionality being present already and tweaked as a result. On top of that, unlike source code, binary files are not readable by humans. While you may pass modified values to some functions, these values don’t necessarily correspond to a specific action. In addition to that, hurdles of debugging and binary patching are often required to even see something different.
+Binary hacking is, for the most part, very limited. New features are hard to add without the base functionality being present already and tweaked as a result. On top of that, unlike source code, binary files are not readable by humans. While you may pass modified values to some functions, these values don’t necessarily correspond to a specific action. In addition to that, hurdles of debugging and binary patching are often required to even see something different. While you can certainly inject code written in common languages such as C inside a ROM in binary hacking, the process involves external mechanisms such as the usage of a Python based template of sorts which still requires knowledge of the contents in the ROM.
 
-The decompilation, on the other hand, allows for the use of C code, in writing new functions and editing the game mechanics to one’s liking, with more clarity. Some statements in the code are self-explanatory, and unlike binary hacking, modifying the code can serve a person well in real life as it is a valuable skill to use in the industry.
+The decompilation, on the other hand, allows for direct usage of C code, allowing to write new functions and editing the game mechanics to one’s liking with more clarity and without extra overhead. Some statements in the code are self-explanatory, and unlike binary hacking, modifying the code can serve a person well in real life as it is a valuable skill to use in the industry.
 
 There is also another, if not _the_ most important advantage to using decompilations: **we do not care about offsets**. Unlike binary hacking, one can easily change the size, locations, even the members of variables at their will. The linker (`ld`) does the work for you, recalculating and modifying references to variables. Gone are the days of worrying about remaining free space; we just don’t do that here.
 
 Like binary hacking, we have a wealth of resources available to you that tweak things, add new features, Pokémon, moves, etc, and even a completely revamped battle engine. However, *unlike* binary hacking, instead of applying a "ROM base" patch at the beginning of your project, you can use **as many of those resources as you want,** and can add them **even in the middle of your project.** No more worrying about whether a patch will break something; it all just works. And for the same reasons that we stated above, these resources are typically much better-developed than their binary equivalents, with less bugs and more advanced features.
 
+Another advantage in using the decomps is that you won't be needing as many tools as you do while performing binary hacking. [Tilemap Studio](https://github.com/Rangi42/tilemap-studio), [Porymap](https://github.com/huderlem/porymap/) and [a source code editor](https://www.google.com/search?q=best+source+code+editors) will handle the majority of the work you will do in a decomp-based project on a regular basis where as binary hackers (granted; things have gotten significantly better in recent years) need to use multiple tools to comfortably edit multiple different things. Script editors, trainer editors, item editors, etc.
+
+This leads to yet another advantage which is not having to rely on fragile, ROM-corrupting and often times no-longer-supported programs to do your work. You don't need item editors when you can jump into `src/data/items.h` and edit an item's general parameters directly. You don't need script editors when you can go to `data/maps/LittlerootTown/scripts.inc` in order to edit the scripts inside Littleroot Town, etc.
+
 One final advantage is that there is no need to keep a folder full of ROM backups while developing your hack. Ask anyone who has successfully released a binary hack and they will tell you that they have a folder full of hundreds of backups with every little change in case something breaks down the road. With the decomps, you will be using a program called Git to make code backups for you (called **commits**) and upload them to Github (the website you are on right now). The difference is that Git makes a backup of the *code*, not the ROM. This is better for a lot of reasons; for example, you can easily see exactly what you changed between each commit instead of having to guess from a list of identical-looking ROMs. Also, if you find a bug, instead of having to boot ROM after ROM to find when it happened, then starting over from that point, Git has tools to test when a bug occurred, allowing you to fix it without losing any progress. Git also has a lot more advantages to hacking over binary; for example, you can have multiple people working on the hack at the same time because you are editing separate parts of the code instead of a single file.
 
-**Before you start hacking, it is recommended that you have some experience in coding in C, C++, Rust, C#, Java, or any other C-like programming language, if you want to use use the decompilation.**
+**Before you start hacking, it is recommended that you have some experience in coding in C, C++, Rust, C#, Java, or any other C-like programming language, if you want to use the decompilation to its maximum potential.**