How to start a project using DizzyEgg's works [OUTDATED!]

dizzyeggs_works.txt

[CENTER]So, we have our environment set up and ready to go [I]([B][URL="https://www.pokecommunity.com/showthread.php?t=432351"]WSL[/URL][/B] or [B][URL="https://www.pokecommunity.com/showthread.php?t=425246"]MSys2[/URL][/B])[/I], we know the basics of building a ROM in Pokeemerald.
What can we do now? Well, a lot of things.

Today I'll teach you all, how to:
[list]
[*] Set up a working Pokeemerald project including DizzyEgg's works.
[*] Create a new GitHub repository for our project needs.
[*] Link up our local project with the GitHub repository we just created for it.
[/list]

By the end of this tutorial, you should be able to have a working repository locally and a working repository online via GitHub, which will be a place where people can see whatever modifications you decide to push there, where they can submit changes to your project in the form of Pull Requests, where they can tell you about any bugs your project may have thanks to GitHub's Issues tracker, etc.

So, let's start by setting up our local project.

[H2][B][SIZE="5"]Setting up DizzyEgg's works[/SIZE][/B][/H2]
[spoiler]
My objective here will be to build a copy of Pokeemerald containing DizzyEgg's works; [B][url=https://github.com/rh-hideout/pokeemerald-expansion/tree/battle_engine]battle_engine[/url][/B], [B][url=https://github.com/rh-hideout/pokeemerald-expansion/tree/item_expansion]item_expansion[/url][/B] and [B][url=https://github.com/rh-hideout/pokeemerald-expansion/tree/pokemon_expansion]pokemon_expansion[/url][/B].
As of recently, Egg hasn't been capable of working on these projects as often as he used to, because of that, they are now mantained by the ROM Hacking Hideout Organization.

[B]What are DizzyEgg's works?[/B]
3 self-contained projects that aim to enhance certain aspects of Pokémon Emerald.
[list]
[*][B]battle_engine[/B]: A massive overhaul of the game's battle system. Adds moves, abilities and mechanics from the newer Pokémon games.
[*][B]item_expansion[/B]: A project that adds various held items from the newer games.
[*][B]pokemon_expansion[/B]: A project that adds all the Pokémon up to Gen. VII [I](including LGPE)[/I]
[/list]
[I][B]Note[/B]: Gen. VIII content is very slowly being worked on, but it's there. Any help to implement missing content is appreciated.[/I]

[H2][B][SIZE="5"]Notes[/SIZE][/B]
[size=3]Please read, don't ignore them. They're important. I promise.[/size][/H2]
-You should know how to build a ROM of Pokémon Emerald with Pokeemerald before coming here. There's 3 different tutorials to do it linked at the beginning of the post.
What we'll be doing here is to compile a repository of Pokeemerald after all, so understanding how to build one is an obvious prerequisite.

-As a result, this tutorial can be seen as some sort of continuation or extension for my tutorials on how to build Pokeemerald which are, again, linked at the beginning of the post.

[H2][B][SIZE="5"]Instructions[/SIZE][/B][/H2]

There are 2 sets of instructions that you can follow from here on out.
Method 1 teaches you how to set up a project using a branch containing the 3 feature branches. It may be slightly out of date and is updated every once in a while.
Method 2 teaches you how to set up a project by merging the feature branches manually, giving you their latest changes at the time of merging.

Method 1 - Master Branch
[spoiler]
[B]1)[/B] Open your terminal and clone the Pokeemerald-expansion repository that contains the feature branches.
To do this, we'll use:
[code]git clone https://github.com/rh-hideout/pokeemerald-expansion (name_of_the_folder)[/code]

[i][b]Note[/b]: I'm including the last bit because if you come from one of my previous tutorials, it's possible you already have a folder called "pokeemerald".
In which case, you should give a name of its own to this new folder, like... I don't know, "pokeemerald_egg" for example.[/i]

[b]To make things easier for everyone, from here on I'll assume you called your folder "pokeemerald_egg".[/b]

[b]Also, don't forget to install agbcc to this new repository![/b]

[B]2)[/B] Having cloned the repository, we'll move to it in our terminal by using:
[code]cd pokeemerald_egg[/code]

Congratulations, that's it.
Yes, I'm not kidding, this is quite literally all there is to it.
The default branch that a cloned Git project is set to is the master branch, and as I said before, this repo's master branch has slightly out of date versions of the 3 feature branches ready to use.
You can further confirm this by using the [icode]git branch[/icode] which'll tell you the branch you're currently sitting on.

Do keep in mind that you'll need to create a GitHub account in order to pull any updates done to the Master branch down the road.
Making an account on GitHub is as easy as going to the main page, hit the Sign Up button, filling in the required fields and then activating your account via email.

Once you have activated your account, GitHub will automatically take you to the page where you can create a repository.
If you want to host your project on GitHub instead of keeping it local, this is something we can take advantage of. Otherwise, feel free to skip this.
Set the repository name and its description to your liking.
Set it to Public or Private as you see fit.
Don't initialize it with a README, our project already has one.
Don't add a .gitignore or a license, you don't need one.
And then hit the "Create Repository" button.

After that, you will need to link your account with your local copy of Git by introducing these commands on your terminal:
[code]
git config --global user.name "Insert your GitHub account's username here"
git config --global user.email "Insert your GitHub account's email here"
[/code]

And then you will have access to [icode]git pull[/icode], a feature of Git that lets you pull any new commits submitted to the branch at will.
In this case, you will have to use [icode]git pull origin master[/icode] whenever you want to update your branch.

In order to link your project with the GitHub repository you created for it, please refer to the "Linking our project with its GitHub Repository" section of this post.
[/spoiler]

Method 2 - Manual Merge
[spoiler]
[B]1)[/B] Open your terminal and let's begin by cloning the Pokeemerald repository that contains the most recent version of the branches.
To do this, we'll use:
[code]git clone https://github.com/rh-hideout/pokeemerald-expansion (name_of_the_folder)[/code]

[i][b]Note[/b]: I'm including the last bit because if you come from one of my previous tutorials, it's possible you already have a folder called "pokeemerald".
In which case, you should give a name of its own to this new folder, like... I don't know, "pokeemerald_egg" for example.[/i]

[b]To make things easier for everyone, from here on I'll assume you called your folder "pokeemerald_egg".[/b]

[b]Also, don't forget to install agbcc to this new repository![/b]

[B]2)[/B] Having cloned the required Pokeemerald repository, we'll move to it in our terminal by using:
[code]cd pokeemerald_egg[/code]

Before moving onto the next step, allow me to put you in situation.
You have cloned a repository of Pokeemerald in a folder called "pokeemerald_egg".
Currently, your branch is set to "master", a merged branch containing slightly outdated versions of the 3 feature branches. You can check this by using:
[code]git branch[/code]

So, are we good? Yes? Then let us proceed.

[b]3)[/b] To manually create a merged branch, we'll use the branch called "battle_engine" as our starting point.
It contains all the changes related to the battle_engine of DizzyEgg.
That branch will be where we'll do our work from here on, okay?

So, since we're currently on the master branch, let's move to the battle_engine branch by using:
[code]git checkout battle_engine[/code]

[B]4)[/B] Good. Now that we have the battle_engine ready to go, let's incorporate the other 2 branches to it.
Before we get to that though, we'll have to make a little detour. The command we're about to use to incorporate Egg's branches into our project requires us to have a GitHub account linked to our local copy of Git, which as you know, it's one of the packages that we had to install in our environments to use the decomps.

So, what will you do? You'll go to [B][URL="http://www.github.com/"]GitHub[/URL][/B], click the "Sign Up" button in the top right corner, and create an account as you normally would.

Once you have activated your account, GitHub will automatically take you to the page where you can create a repository.
If we want to host our project on GitHub instead of keeping our work local, this is a good thing we can take advantage of. Otherwise, skip this and proceed to the next step.
Set the repository name and its description to your liking.
Set it to Public or Private as you see fit.
Don't initialize it with a README, our project already has one.
Don't add a .gitignore or a license, you don't need one.
And then hit the "Create Repository" button.

[B]5)[/B] With this, we just created an account on GitHub and a repository to host our project in later on if we want to.

Let's go back to our shell/terminal now and link our account. It's pretty simple, we just need to use 2 commands:
[code]
Git config --global user.name "Insert your GitHub account's username here"
Git config --global user.email "Insert your GitHub account's email here"
[/code]

[I][B]Note[/B]: If you're using WSL and you get the following error: "[I]error: could not lock config file /path/.gitconfig: No suck file or directory.[/I]", don't panic.
I had it happen to me as well. To fix it, I just had to set my GitHub account's name and email on a per-folder basis, meaning that each time I clone Pokeemerald, I'd have to use these commands within the project's folder on WSL, but without the [icode]--global[/icode] parameter.
I'm not completely sure if it's the best way to go about it, but it's a solution that works.[/I]

[B]6)[/B] Alright, now that we've put that out of the way, let's begin merging the branches into our project.
Before that though, we'll quickly type the following command in our terminal:
[icode]git config --global merge.renameLimit 999999[/icode]
What this does is set the limit of files that Git can detect for renaming related operations to 999999.
If the regular limit is reached, those operations would be halted even if they weren't completed, which could be troublesome.

With that out of the way, we'll start with the item_expansion branch because it's the easiest to handle.
To add it into our battle_engine branch we'll use:
[code]git pull origin item_expansion[/code]

As soon as we do this, we will meet our first obstacle; merge conflicts.
[IMG]https://i.imgur.com/qQ8RipA.png[/IMG]

[B]What is a merge conflict?[/B]
A merge conflict happens when you introduce changes to a file, that don't play nice with other changes already done to the same file previously.
It is effectively a conflict between changes in 2 different commits brought upon by the action of merging.

To spot a Merge Conflict we'll go to one of the files our terminal found a merge conflict in [I]([icode]src/battle_util.c[/icode], for example)[/I] and then Ctrl+F "[B]<<<<<<< HEAD[/B]".
That marks the beginning of a Merge Conflict.
Right under it we have a piece of code which is "the old code". It's what was there before our last git pull.
At some point you should be seeing a "[B]=======[/B]" which acts as a separator. The code that comes after it is the new code brought upon by our last git pull.
What you see right after it is a "[B]>>>>>>> [I](commit hash ex: f95a335c0daeba5e5f4861b7cb5eba7da685d9fa)[/I][/B]", which marks the end of the Merge Conflict.

So, we located a merge conflict. What should we do now?
Well, each merge conflict has to be addressed by the user individually.
As I explained above, they're caused when we merge conflicting changes from 2 different commits that affect 1 same file.
You have to decide which piece/s of code to keep. The ones that were there from the start, the ones that come from the merging, or even a mix of them.

I'll present a quick example before listing the solutions for each merge conflict.

[spoiler]
[IMG]https://media.discordapp.net/attachments/419214240277200898/773512946482544660/Untitled786.png[/IMG]

This is a merge conflict that is no longer present, involving the [icode]src/wild_encounter.c[/icode] file.
I'll proceed to use it as an example on how to solve a merge conflict.

The code that we see on this picture does the following process:
If the current tile's behavior allows us to trigger a surfing encounter, let's check if the Player meets the conditions to trigger a double wild battle.
If they don't, let's trigger a regular wild battle.
Then let's tell the game that this encounter was a surfing encounter, and make the snippet of code return [icode]TRUE[/icode] to reiterate it.
This entire code is a part of the [icode]StandardWildEncounter[/icode] function of the [icode]src/wild_encounter.c[/icode] file, so we're also making that function return [icode]TRUE[/icode] here.

And what should we do here? 2 things.
First, we will remove the [icode]BattleSetup_StartWildBattle();[/icode] introduced by the merge.
And secondly, we will move [icode]gIsSurfingEncounter = TRUE;[/icode] putting it right above [icode]if (TryDoDoubleWildBattle())[/icode].

This way the function will enable the variable that the Dive Ball's effect needs to do its thing when it's due, and execute either a double wild battle or a regular wild battle if the correct conditions are met.

Lastly we'll delete the automatic lines introduced by Git in order to point out merge conflicts, and the result should look like this:
[img]https://i.imgur.com/vPF5mcf.png[/img]
[/spoiler]

And that's basically how it goes.

Alright, time to get to the actual merge conflicts that appear when merging the item_expansion into the battle_engine.

[size=4][b].github/workflows/build.yml[/b][/size]
[spoiler]Ignore this. It's a false positive of sorts. There isn't a conflict to solve here.
[/spoiler]

[size=4][b]data/battle_ai_scripts.s[/b][/size]
[spoiler]There isn't a conflict to solve here either. Instead, Git warns us that the action of [icode]git pull[/icode]ing restored this file that doesn't exist in the battle_engine.
Delete it, either manually from within the Windows Explorer, or by using [icode]sudo rm -rf data/battle_ai_scripts.s[/icode].
[/spoiler]

[size=4][b]data/battle_scripts_2.s[/b][/size]
[spoiler]There isn't an actual conflict to solve here either. Delete the 3 lines added by Git to point out a merge conflict and move on.[/spoiler]

[size=4][b]graphics/items/icons/orb.png[/b][/size]
[spoiler]Of course there isn't a conflict here, this is a sprite lmao.
Git just warns us that while the file was deleted in the item_expansion, Git still retained the battle_engine's copy of it.
You can delete the file and save a whooping 1 KB of space since the sprite is completely unused, or you can keep it. Your call.[/spoiler]

[size=4][b]include/constants/expansion_branches.h[/b][/size]
[spoiler]As the informative comment present in this file says, we need to keep the 2 constants used by the BE and the IE respectively to detect each other.
That means we'll remove the 3 lines added by Git and move to the next file.[/spoiler]

[size=4][b]include/pokemon.h[/b][/size]
[spoiler]Another false positive. There are no conflicts here. Ignore this file.[/spoiler]

[size=4][b]src/battle_script_commands.c[/b][/size]
[spoiler]
There's 8 conflicts in here, so hold on tight.

The first one involves an array labeled [icode]sTerrainToType[/icode] that is used to determine the type of a Pokémon that uses the move Camouflage.
This array was expanded in the battle_engine, and what the changes coming from the item_expansion do is to revert it to its vanilla state.
Here, we'll delete the incoming code and keep the old code, and we'll also delete the 3 lines Git adds automatically to point out merge conflicts.

The second conflict happens in the [icode]Cmd_critcalc[/icode] function and it's solved in the exact same manner. Delete the incoming code and keep the old one.

The third conflict is solved exactly the same, keep the old code and delete the new code.

As a side note, the conflicts we've seen so far in this file can all be solved by looking at [B][URL="https://github.com/rh-hideout/pokeemerald-expansion/blob/battle_engine/src/battle_script_commands.c"]the battle_engine's copy of the file[/URL][/B].
This isn't always the case and we'll see that soon enough, but more often than not, it remains true that we'll want to keep the battle_engine's code in files that involve the battle engine of the game.
Let us move on.

The fourth conflict happens in [icode]Cmd_tryswapitems[/icode] and it's yet again a case where you'll want to keep the old code and ditch the incoming code.

Now this is where things get a bit visually messy. Don't worry, it sounds worse on paper than it really is.
The next 4 conflicts all happen inside one same function, [icode]Cmd_handleballthrow[/icode].

The fifth conflict is a no-conflict. Remove the 3 lines added by Git and move on to the next.

The sixth conflict is like some of the previous ones we've seen.
We need to keep the statement that sets the value of [icode]gLastThrownBall[/icode] so the battle_engine's "Last Used Ball" feature can work correctly.
Remove the incoming code, and also the 3 lines added by Git, and then move to the last conflict of this file.

The seventh conflict looks messy at a glance, but it's nothing new by now. Remove the new code and keep the old one.
And just to make sure we're both in sync, you and me, here's a .gif
[spoiler][IMG]https://i.imgur.com/WhQ8l73.gif[/IMG][/spoiler]

The eighth and last conflict looks messier, but the solution isn't different than the previous conflict. Remove the new code and keep the old one.
[/spoiler]

[size=4][b]src/data/items.h[/b][/size]
[spoiler]
We'll copy-paste [b][url=https://raw.githubusercontent.com/rh-hideout/pokeemerald-expansion/item_expansion/src/data/items.h]the item_expansion's own copy of this file[/url][/b] and move on.
[/spoiler]

[size=4][b]src/battle_util.c[/b][/size]
[spoiler]
There's 2 conflicts in this file at the time of writing, and both happen inside the [icode]ItemBattleEffects[/icode] function.
Both conflicts are solved in the same manner; delete the new code and keep the old code.
[/spoiler]

And just like that, we're done.
Now that we solved all the merge conflicts, let's make a [B][url=https://www.atlassian.com/git/tutorials/saving-changes/git-commit]commit[/url][/B] to store the changes we've just done, alright?

[B]Why, you may ask?[/B]
Because the merging was not completed successfully as a result of the Merge Conflict that blocked our path, and that means that the changes that were introduced by having merged in the item_expansion branch overall are kind of floating around.

So, how do we make a new commit? Pretty simple.
[code]git add *[/code]
This tells Git to include in the next commit all the changes done to files anywhere in the Pokeemerald_egg folder.
[code]git commit -m "Insert a Message Here"[/code]

This will create a [B][url=https://www.atlassian.com/git/tutorials/saving-changes/git-commit]commit[/url][/B] with a title of our own choice.
For example, if I wanted to make a commit myself, I'd probably use:
[code]git commit -m "Merged branch 'item_expansion'"[/code]
Which would create a commit titled "[i]Merged branch 'item_expansion'[/i]".

[b]AAAnd congratulations, you now have a repository of Pokeemerald with DizzyEgg's battle_engine AND item_expansion branches incorporated.[/b]

For a quick explanation, what we did just now was getting all the changes done in the item_expansion branch, and then we implemented them in our current branch.

Alright. Let us proceed. The next step will get a bit tougher, so brace yourself.

[B]7)[/B] So, just as we did with the item_expansion branch, to incorporate the pokemon_expansion branch we'll have to use the [b]git pull[/b] command.
[code]git pull origin pokemon_expansion[/code]

And after using this command, you'll see something like... this.
[img]https://i.imgur.com/InIUhad.png[/img]

Let's make a pause and read what our shell is telling us.
We have a lot of lines starting with "[b]CONFLICT[/b]". That means this time we'll have to deal with a lot of merge conflict and not just a few.

I think I made it clear before, but to reiterate, what these lines mean is that the branch we just incorporated contains changes to specific files that don't play nice with the changes to those same files made by previous commits and for that reason we have to solve those conflicts and restore balance to The Force.

I'll proceed to address each Merge Conflict separately.

[size=4][b].github/workflows/build.yml[/b][/size]
[spoiler]A false positive, just like before. Ignore it and move to the next file.[/spoiler]

[size=4][b]asm/macros/event.inc[/b][/size]
[spoiler]Delete the 3 lines Git adds to point out a merge conflict, add a [icode].endm[/icode] at the end of the [icode]totemboost_evas2[/icode] macro, and move to the next file.[/spoiler]

[size=4][b]data/specials.inc[/b][/size]
[spoiler]Delete the 3 lines Git adds to point out a merge conflict and move to the next file.[/spoiler]

[size=4][b]include/constants/expansion_branches.h[/b][/size]
[spoiler]Just like we did before and for the same reasons too, we'll delete the 3 lines that Git adds to the file automatically and that's it.
[/spoiler]

[size=4][b]include/constants/pokemon.h[/b][/size]
[spoiler]2 conflicts to solve.
The first one is easy, delete the 3 lines added by Git and move to the next conflict.

The second one is also easy; delete the old code and keep the new code.
Yes, it's the opposite of something we did many times by now.
[/spoiler]

[size=4][b]include/pokemon.h[/b][/size]
[spoiler]
The first conflict is another instance of deleting the new code that's trying to replace the battle_engine's, and the 3 lines added by Git to point out a conflict.
That means we'll keep [icode]/* 0x16 */ u16 abilities[NUM_ABILITY_SLOTS];[/icode].

The second one is a non-conflict. Delete the 3 lines Git adds and move on to the next file.
[/spoiler]

[size=4][b]src/battle_gfx_sfx_util.c[/b][/size]
[spoiler]
The first conflict happens inside the [icode]BattleLoadMonSpriteGfx[/icode] function.
This is the first actually tricky merge conflict, because we have to mix old code and new code, but we also need to modify what's left as, for example, the [icode]HandleLoadSpecialPokePic_DontHandleDeoxys[/icode] function does not exist in our project, since it was removed by the pokemon_expansion.

Let's start by removing the new code and keeping the old one. That leaves us with an [icode]if[/icode]/[icode]else[/icode] statement.
Now, this [icode]else[/icode] statement nests [I]another[/I] [icode]if[/icode]/[icode]else[/icode] statement. For this [icode]else[/icode] statement we'll only keep what's within the nested [icode]else[/icode].

Thus, the result is:
[spoiler][IMG]https://i.imgur.com/sPY1cPr.png[/IMG][/spoiler]

Now, rename [b][u]every usage[/u][/b] of [icode]HandleLoadSpecialPokePic_DontHandleDeoxys[/icode] [b][u]in the file[/u][/b], replacing it with [icode]HandleLoadSpecialPokePic[/icode], and we're done here.

If we read the code that's left, we'll notice that this function will load the front sprite inside of the battle scene when it's called with its last parameter, [icode]bool32 opponent[/icode], set to [icode]TRUE[/icode].
Coincidentally, the function will load the back sprite instead when that last parameter is set to [icode]FALSE[/icode].
This is done within this same file, in the functions [icode]BattleLoadOpponentMonSpriteGfx[/icode] and [icode]BattleLoadPlayerMonSpriteGfx[/icode].
It's an optimization over Game Freak's code that unifies the loading of the sprites into one single function, instead of having 2 functions that are mostly copy-pastes.

Speaking of [icode]BattleLoadPlayerMonSpriteGfx[/icode], we can see that it's involved in the second merge conflict of this file.
Delete all the new code and keep the old code. Pretty simple. Don't worry about the [icode]BattleGfxSfxDummy1[/icode] we just deleted. It's an empty function, completely unused by the game's code.

And now, the third and last conflict, which happens inside the [icode]HandleSpeciesGfxDataChange[/icode] function.
This conflict is not as serious as it looks. Delete the 3 lines automatically added by Git to point out merge conflicts and move on to the next file.[/spoiler]

[size=4][b]src/data/pokemon/base_stats.h[/b][/size]
[spoiler]
Grab [B][url=https://raw.githubusercontent.com/rh-hideout/pokeemerald-expansion/pokemon_expansion/src/data/pokemon/base_stats.h]the pokemon_expansion's copy[/url][/B].

Recently, [icode]ITEM_STICK[/icode] was renamed to [icode]ITEM_LEEK[/icode] in the item_expansion branch to comply with the standards set by Pokémon Sword and Shield.
Thus, rename the instances of [icode]ITEM_STICK,[/icode] in this file to [icode]ITEM_LEEK,[/icode] and then move on.
[/spoiler]

[size=4][b]src/data/pokemon/egg_moves.h[/b][/size]
[spoiler]
Grab [B][URL="https://raw.githubusercontent.com/rh-hideout/pokeemerald-expansion/pokemon_expansion/src/data/pokemon/egg_moves.h"]the pokemon_expansion's copy[/URL][/B] and move on.
[/spoiler]

[size=4][b]src/data/pokemon/evolution.h[/b][/size]
[spoiler]
Grab [B][url=https://raw.githubusercontent.com/rh-hideout/pokeemerald-expansion/pokemon_expansion/src/data/pokemon/evolution.h]the pokemon_expansion's copy[/url][/B].

Recently, [icode]ITEM_UP_GRADE[/icode] was renamed to [icode]ITEM_UPGRADE[/icode] in the item_expansion branch to comply with the standards set by Pokémon Sword and Shield.
Rename the instances of [icode]ITEM_UP_GRADE[/icode] in this file to [icode]ITEM_UPGRADE[/icode] and then move on.
[/spoiler]

[size=4][b]src/data/pokemon/level_up_learnsets.h[/b][/size]
[spoiler]
Grab [B][URL="https://raw.githubusercontent.com/rh-hideout/pokeemerald-expansion/pokemon_expansion/src/data/pokemon/level_up_learnsets.h"]the pokemon_expansion's copy[/URL][/B], and remove the 2 slashes that comment out many of the moves in the file.
Those moves were commented out in order to make the branch viable for people who may be not interested in adding the BE and/or the IE into their projects.
[I]And you may ask "then why are there new abilities being used in the base_stats.h file?"
They're not being used per se. [B][URL="https://github.com/rh-hideout/pokeemerald-expansion/blob/pokemon_expansion/include/constants/pokemon_config.h#L176-L373"]Those labels direct to [icode]ABILITY_NONE[/icode] when the battle_engine is not being used[/URL][/B].[/I]

So yeah, copy and paste that file, Ctrl+H, look for [icode]//LEVEL_UP_MOVE[/icode], replace with [icode]LEVEL_UP_MOVE[/icode] and move onto the next Merge Conflict.[/spoiler]

[size=4][b]src/data/text/abilities.h[/b][/size]
[spoiler]
Grab [B][URL="https://raw.githubusercontent.com/rh-hideout/pokeemerald-expansion/battle_engine/src/data/text/abilities.h"]the battle_engine's copy[/URL][/B] and move on.
[/spoiler]

[size=4][b]src/data/text/move_names.h[/b][/size]
[spoiler]
Grab [B][URL="https://raw.githubusercontent.com/rh-hideout/pokeemerald-expansion/battle_engine/src/data/text/move_names.h"]the battle_engine's copy[/URL][/B] and move on.
[/spoiler]

[size=4][b]src/pokemon.c[/b][/size]
[spoiler]
This file has 4 merge conflicts.

To solve the first merge conflict, simply delete the 3 lines added by Git automatically.
To solve the second one, delete the 3 lines and the [icode]sDeoxysBaseStats[/icode] array.
To solve the third one do what you did for the first one. Delete the 3 lines added by Git automatically and nothing else.

Now, to solve the 4th and last merge conflict in this file, we'll do what we did many times before.
Delete the new code, and also delete the 3 lines that Git adds automatically in order to point out a conflict.
[/spoiler]

[B]8)[/B] Wow, it's been a ride, huh? Worry not, we're practically done here.
This would be a great time to save all your changes in a commit.
Git was already in the process of making one, as a matter of fact, back when we decided to [icode]git pull[/icode] the pokemon_expansion branch.
That merge attempt is currently still ongoing and unfinished, so let's finish what we started.
Add all the changes to the unfinished commit by using [icode]git add *[/icode].
Then simply use [icode]git commit[/icode] and then Ctrl+X to exit and leave everything as is.

[B]9)[/B] And now, we're finally ready to build a ROM.
[code]make -jN[/code]
[i][b]Note[/b]: "N" stands for the number of CPU Threads you want to assign to the compiler. The more threads, the faster it'll go.
[b]Protip[/b]: The command [icode]nproc[/icode] will give you the amount of threads your CPU has. You're free to use as many of them as you want.[/i]

If everything worked out correctly, [B][URL="https://i.imgur.com/iyHAc0m.png"]you'll see this in your shell/terminal[/URL][/B] meaning that a ROM was built successfully.

It's worth noting that, while in this very specific case I suggested to make a few commits [I]before[/I] building a ROM, normally, I prefer to make commits after I'm sure that things are working correctly. In other words, after making sure that a ROM can be built.[/spoiler]
[/spoiler]

And just like that, we have completed the first part of this tutorial, yaay.
We have a working copy of Pokeemerald containing the bigger projects that DizzyEgg and we at the RHH Org. poured our souls into.
We also have an account on GitHub and a repository to host our project in too.

From here on, we'll move to the next step which is not really related to the decomps.

Before that though, let me put you in situation. Again.
You have a copy of Pokeemerald containing its 3 biggest feature branches; [B][url=https://github.com/rh-hideout/pokeemerald-expansion/tree/battle_engine]battle_engine[/url][/B], [B][url=https://github.com/rh-hideout/pokeemerald-expansion/tree/item_expansion]item_expansion[/url][/B] and [B][url=https://github.com/rh-hideout/pokeemerald-expansion/tree/pokemon_expansion]pokemon_expansion[/url][/B].

Alright then, let us move on to the last part of this tutorial.

[H2][B][SIZE="5"]Linking our project with its GitHub Repository[/SIZE][/B][/H2]
[spoiler]
So, we have our project ready, a GitHub Repository eager to host it and we have already linked our account with our local copy of Git.
We're ready. Let's do this.

[b]1)[/b] The first thing we'll do, is to fix or rather adjust the repositories that our project is tracking.
Right now, if we use [b]git remote -v[/b], we'll see something like this:
[img]https://i.imgur.com/HREMiQ7.png[/img]

This is telling us that the only repository we're tracking is RHH's, and the "keyword" we use to interact with it is called "origin".
So, what should we do? Let's set a new URL for origin, the URL to our GitHub Repository.
We'll do this by using:
[code]git remote set-url origin https://github.com/USERNAME/NAME_OF_YOUR_REPOSITORY[/code]

The result should be something like this:
[img]https://i.imgur.com/YdMppPo.png[/img]

With this, we're telling to our local copy of Pokeemerald that the new home for our project will be the URL we just set origin to.

[b]2)[/b] But now, what happens when/if we want to pull any updates from the battle_engine, the item_expansion or the pokemon_expansion?
To address that, we'll track the original repository via git remote.
That way we'll have our own home for our project in GitHub, and we'll also be able to pull stuff from any of the branches at will.

We'll do this by using:
[code]git remote add keyword link_to_the_repository[/code]

"[b]keyword[/b]" will be the word of our choice that will act as the shortcut to RHH's Pokeemerald Repository.
"[b]link_to_the_repository[/b]" will be the URL to it.

In other words, something like...
[code]git remote add rhh https://github.com/rh-hideout/pokeemerald-expansion[/code]

That way, we could do [b]git pull rhh battle_engine[/b] and stuff like that whenever we wanted.

And just like that, we're basically done here.

We have our pokeemerald_egg folder set to its battle_engine branch containing DizzyEgg's 3 biggest works, a GitHub repository and we've properly linked them both.
So, why don't you try to push your commits to your repository?
Come on, it's easy! You just have to:
[code]git push origin battle_engine[/code]

After using this command, we'll have to type in the username and [B][U]token[/U][/B] of our GitHub account.
Yes, you read that right; "[B][U]token[/U][/B]".

Now, [B]what is a token?[/B]
GitHub recently ditched passwords as a mean to interact with the website, and instead implemented tokens of personal access.
What I personally did, was to generate a token granting me all the permissions, and then I stored it somewhere so I could use it whenever I needed.

How do we generate a token? It's simpler than it sounds.
Go to [url]https://github.com/settings/tokens[/url].
Once there, hit "Generate new token" and fill in the data.
Write a description where it says "Note", set an Expiration Date of "No expiration" and hit all the checkboxes with bold font in "Select scopes".
With all set, click on "Generate token".

You'll be met with this:
[IMG]https://i.imgur.com/9OAZuQ0.png[/IMG]

The censored part is your token. Copy it, and use it whenever you need to [icode]git push[/icode].
You can just copy it somewhere, and then paste it whenever the time comes to type in your GitHub password.

[B]Don't worry if you can't see the token after you paste it into the terminal[/B].
Sensitive information like passwords, and these tokens that act like passwords, can't be read. They appear invisible. It's a security measure.

This will push the contents of your battle_engine branch to your GitHub Repository.
If the branch does not exist there, it will be created automatically.

Since this is the first and only branch we've pushed to our GitHub Repository, it will be set as the main branch for the project there.
[/spoiler]

And I think that's pretty much it really.

Yes, I know, it's [b]A LOT[/b] of stuff to process.
Take your time, don't rush, it's not as hard as it may look.

Also, please remember that Merge Conflicts are [s]the devil[/s] something you'll have to deal with pretty often, and they should be taken care of on the user's end.
If you try to merge Egg's branches in an advanced project, it's possible that you'll get more and different Merge Conflicts than the ones I show here.
There's nothing anyone can do about that, but at the very least, I hope this guide lessens your pain a little bit, as I more or less taught you how to solve them.

You should be able to solve conflicts following the explanation I gave above about the nature of merge conflicts.
If you feel that you can't, then go and re-read it by Ctrl+F'ing "[I]What is a merge conflict?[/I]".[/CENTER]

[I]Original post [I](outdated, only posted for archival purposes)[/I]:
[url]https://pastebin.com/ium3E0ss[/url][/I]