Registrarse

[pokeemerald] Cómo empezar un proyecto usando la Pokeemerald Expansion

KevinXDE

Usuario mítico
Una vez tenemos nuestro entorno de trabajo listo (WSL, Cygwin o MSys2), ya conocemos lo básico para compilar una ROM de Pokeemerald.
En este tutorial aprenderéis a:​
  • Crear un proyecto de Pokeemerald funcional usando la Pokeemerald Expansion.​
  • Crear un nuevo repositorio de GitHub para mantener el proyecto y vincularlo a nuestro repositorio local (recomendado).​
Al terminar este tutorial, deberías tener dos repositorios en funcionamiento: un repositorio local y otro online en GitHub, en el cual la gente podrá: ver las modificaciones que decidas subir, notificar de posibles errores en tu proyecto, recomendar cambios en forma de Pull Request, etc.

Empecemos por configurar nuestro proyecto local.

Configurando la Pokeemerald Expansion
El objetivo aquí es compilar una copia de Pokeemerald que contenga la nueva expansión, compuesta de: battle_engine, item_expansion y pokemon_expansion.
Anteriormente era mantenida por DizzyEgg pero por falta de tiempo ahora está en manos de ROM Hacking Hideout.

¿Qué contiene la expansión?
Contiene 3 proyectos que aspiran a mejorar ciertos aspectos de Pokémon Esmeralda.​
  • battle_engine: una revisión masiva del sistema de combate. Añade ataques, habilidades y mecánicas de las recientes generaciones de Pokémon.​
  • item_expansion: un proyecto que añade los objetos existentes de los últimos juegos.​
  • pokemon_expansion: un proyecto que añade todos los Pokémon existentes hasta la 7ª generación, incluyendo Pokémon Let’s Go Pikachu/Eevee.
Nota: Se está trabajando en insertar el contenido de la 8ª generación. Aún falta contenido, así que cualquier ayuda para implementar nuevo contenido se agradece.

Nota (importante)
-Antes de empezar con este tutorial ya deberías saber cómo compilar una ROM de Pokémon Esmeralda usando Pokeemerald. Hay 3 tutoriales vinculados al inicio de este tema. Aquí compilaremos un repositorio de Pokeemerald, así que entender cómo hacerlo es un prerrequisito obvio.

Instrucciones
Hay dos opciones que puedes tomar a partir de aquí. El método 1 te enseña a crear un proyecto con una rama que ya contiene las 3 ramas de la expansión. Esta rama se actualiza de una manera más lenta que el método 2, pero el proceso de configuración es mucho más rápido.
El método 2 te enseña a crear un proyecto fusionando las 3 ramas en una manualmente, actualizada con los últimos cambios.

Método 1 – Rama máster
1) Abre tu terminal y clona el repositorio de Pokeemerald-expansion que contiene las ramas. Para hacerlo, escribe:
git clone https://github.com/rh-hideout/pokeemerald-expansion nombre_de_la_carpeta

Nota: Incluyo la última parte porque si vienes de uno de los anteriores tutoriales, es posible que ya tengas una carpeta llamada “pokeemerald”. En cuyo caso deberías darle un nuevo nombre. De ejemplo para el tutorial usaremos "pokeemerald_egg":

git clone https://github.com/rh-hideout/pokeemerald-expansion pokeemerald_egg


2) Tampoco debes olvidar instalar agbcc en este nuevo repositorio. Escribe los siguientes comandos:

cd agbcc
./build.sh
./install.sh ../pokeemerald_egg
cd ..


Nota: Si ya habías compilado pokeemerald anteriormente, lo cual es requisito para este tutorial, este paso no debería dar problemas. El proceso de ./build.sh puede tardar algo de tiempo en terminar.


3) Habiendo clonado el repositorio e instalado agbcc en éste, nos moveremos a él escribiendo lo siguiente:

cd pokeemerald_egg

Eso sería todo. La rama por defecto de un repositorio clonado es la rama máster, y como esta rama ya contenía las 3 ramas de la expansión, ya está lista para ser usada. Puedes confirmar que te encuentras en la rama máster escribiendo el siguiente comando:

git branch

Ten en cuenta que necesitarás crear una cuenta en GitHub para actualizar tu proyecto con los futuros cambios de la expansión. Una vez rellenes los campos de registro y actives tu cuenta con tu email, te llevará directamente a la página donde puedes crear un repositorio. Si no te importan las actualizaciones o tener tu proyecto online, los siguientes pasos son opcionales.

4) Ponle un nombre y una descripción a tu repositorio, ponlo como público o privado según te apetezca. No inicialices el repositorio con un README, ya que el proyecto ya tiene uno. No añadas un .gitignore o una licencia, no necesitas una. Para terminar haz clic en “Create Repository”.


5) Ahora hay que vincular tu cuenta de GitHub con tu copia local de Git introduciendo los siguientes comandos en tu terminal:

Git config --global user.name "Inserta tu nombre de usuario de GitHub aquí"
Git config --global user.email "Inserta tu correo usado en GitHub aquí"


Después de eso tendrás acceso a git pull, un comando de Git que te permite introducir nuevas actualizaciones añadidas en la rama. En este caso, tendrás que usar

git pull origin master

para actualizar tu repositorio.

Para vincular tu proyecto con el repositorio de GitHub, dirígete a la sección “Vinculando nuestro proyecto con su repositorio de GitHub” de este tutorial.

Método 2 – Configuración manual
1) Abre tu terminal y clona el repositorio de Pokeemerald-expansion que contiene las ramas. Para hacerlo, escribe:

git clone https://github.com/rh-hideout/pokeemerald-expansion nombre_de_la_carpeta

Nota: Incluyo la última parte porque si vienes de uno de los anteriores tutoriales, es posible que ya tengas una carpeta llamada “pokeemerald”. En cuyo caso deberías darle un nuevo nombre. De ejemplo para el tutorial usaremos "pokeemerald_egg":

git clone https://github.com/rh-hideout/pokeemerald-expansion pokeemerald_egg


2) Tampoco debes olvidar instalar agbcc en este nuevo repositorio. Escribe los siguientes comandos:

cd agbcc
./build.sh
./install.sh ../pokeemerald_egg
cd ..


Nota: Si ya habías compilado pokeemerald anteriormente, lo cual es requisito para este tutorial, este paso no debería dar problemas. El proceso de ./build.sh puede tardar algo de tiempo en terminar.


3) Habiendo clonado el repositorio e instalado agbcc en éste, nos moveremos a él escribiendo lo siguiente:

cd pokeemerald_egg

Antes de seguir con el siguiente paso, vamos a situarnos. Has clonado un repositorio de Pokeemerald en una carpeta llamada “pokeemerald_egg”. La rama por defecto es la rama máster, una rama que contiene versiones algo desactualizadas de las ramas de la expansión. Puedes comprobarlo escribiendo:

git branch


4) Para crear una rama con la expansion manualmente, usaremos de base la rama “battle_engine”, que contiene los cambios relacionados con el sistema de batalla de DizzyEgg. Esta rama será donde hagamos todo el trabajo a partir de ahora. Así que, como ahora mismo nos encontramos en la rama máster, vamos a movernos a la rama “battle_engine” escribiendo lo siguiente:

git checkout battle_engine


5)
Bien, ya tenemos la battle_engine funcionando, así que ahora introduciremos las otras 2 ramas. Antes de continuar con el siguiente paso, el comando que vamos a usar requiere que creemos una cuenta en GitHub vinculada a nuestra copia local de Git. Una vez rellenes los campos de registro y actives tu cuenta con tu email, te llevará directamente a la página donde puedes crear un repositorio.

Ponle un nombre y una descripción a tu repositorio, ponlo como público o privado según te apetezca. No inicialices el repositorio con un README, ya que el proyecto ya tiene uno. No añadas un .gitignore o una licencia, no necesitas una. Para terminar haz clic en “Create Repository”.


6) Ahora hay que vincular tu cuenta de GitHub con tu copia local de Git introduciendo los siguientes comandos en tu terminal:

Git config --global user.name "Inserta tu nombre de usuario de GitHub aquí"
Git config --global user.email "Inserta tu correo usado en GitHub aquí"


Nota: si usas WSL y te sale el siguiente error: "error: could not lock config file /path/.gitconfig: No such file or directory.", se puede solucionar repitiendo los comandos de este paso dentro de la carpeta del repositorio clonado, pero sin el párametro --global


7) Bien, ahora que hemos terminado con eso, vamos a fusionar las ramas en nuestro proyecto. Antes de empezar escribiremos lo siguiente en la terminal:

git config --global merge.renameLimit 999999

Lo que hace el anterior comando es poner un límite de 999999 al número de archivos que Git puede detectar para operaciones relacionadas con cambios de nombre. Si el límite era sobrepasado, esas operaciones podían detenerse sin completarse, lo cual podía dar problemas.

Una vez hecho esto, podemos continuar fusionando las ramas. Empezaremos con la rama “item_expansion”, ya que es la más fácil. Para añadirla a nuestra rama “battle_engine”, usaremos:

git pull origin item_expansion

Nos aparecerá el primer obstáculo, llamado conflictos de fusión.


¿Qué es un conflicto de fusión?
Un conflicto aparece cuando introduces cambios en un archivo que solapan otros cambios hechos anteriormente, de tal manera que Git no sabe con qué cambios quedarse.

Para encontrar los conflictos iremos a los archivos que nuestra terminal ha detectado (src/battle_util.c por ejemplo). En él haremos Ctrl+F y buscaremos "<<<<<<< HEAD", el cual marca el inicio de un conflicto. Justo debajo tenemos el código antiguo, el código que había antes de que ejecutáramos git pull. Si bajamos, en algún punto deberíamos encontrar "=======", el cual funciona como un separador. El código a continuación es el nuevo código introducido por el git pull. Por último, encontraremos ">>>>>>> (commit hash ex: f95a335c0daeba5e5f4861b7cb5eba7da685d9fa)", el cual marca el final del conflicto.

Hemos detectado un conflicto, entonces, ¿qué hacemos ahora? Cada conflicto debe solucionarse manuamente por parte del usuario. Tienes que decidir con qué parte del código te quedarás: el que ya estaba de antes, el que ha sido añadido posteriormente, o incluso una mezcla de ambos.

Voy a mostrar un ejemplo antes de listar las soluciones para cada conflicto.


Este es un conflicto del archivo src/wild_encounter.c que actualmente ya no ocurre, así que lo vamos a usar de ejemplo para aprender a resolver los conflictos. Lo que vemos aquí es el proceso siguiente:

Si el comportamiento del tile en el que nos encontramos permite un encuentro salvaje usando surf, comprueba si el jugador cumple los requisitos para que este sea un combate doble. Si no los cumple, será un combate individual.
Ahora le dice al juego que el encuentro salvaje sí fue usando surf, haciendo que el código devuelva el valor TRUE para confirmarlo. Este código es parte de la función StandardWildEncounter del archivo src/wild_encounter.c, así que también estamos haciendo que la función devuelva el valor TRUE aquí.

¿Qué deberíamos hacer? 2 cosas.
Primero borraremos la parte BattleSetup_StartWildBattle(); introducida por el merge (fusión). Y segundo, moveremos gIsSurfingEncounter = TRUE; y lo pondremos encima de if (TryDoDoubleWildBattle())

De este modo la función permitirá que el efecto de la Buceo Ball surja cuando sea necesario, y permitirá que el encuentro salvaje sea doble cuando se cumplan las condiciones.

Por ultimo borraremos las lineas introducidas por Git para marcar los conflictos, y el resultado debería ser algo así:

Pasemos a solucionar el resto de conflictos que aparecen al fusionar las ramas item_expansion y battle_expansion.

.github/workflows/build.yml
Ignora este, es un falso positivo y no hay ningún conflicto en este archivo.

data/battle_ai_scripts.s
Aquí tampoco hay ningún conflicto que resolver. Git nos advierte de que la acción git pull ha restaurado este archivo que no existe en la rama battle_engine. Bórralo, ya sea manualmente desde el explorador de archivos de Windows, o escribiendo en la terminal

sudo rm -rf data/battle_ai_scripts.s

data/battle_scripts_2.s
Ningún conflicto por aquí tampoco. Borra las 3 líneas añadidas por git y continúa.

graphics/items/icons/orb.png
Por supuesto que aquí tampoco hay un conflicto, este archivo es un sprite. Git advierte que este sprite fue borrado en la rama item_expansion, pero ha retenido la version de la rama battle_engine. Puedes decidir si lo borras o no, ya que el archivo no se usa.

include/constants/expansion_branches.h
Como el comentario dice, estas constantes fueron añadidas para vincular las 3 ramas de la expansión. Solamente borramos las 3 lineas añadidas por Git y pasamos al siguiente archivo.

include/pokemon.h
Otro falso positivo. Ignora este archivo

src/battle_script_commands.c
En este archivo hay 8 conflictos.

El primero se trata de sTerrainToType, que maneja el cambio de tipo al usar el ataque Camuflaje. Este código fue expandido en la battle_engine, y lo que hace el código de la item_expansion es revertirlo a su estado original. Nos quedamos con el código de la battle_engine y borramos las 3 lineas añadidas por Git.

En el segundo conflicto en Cmd_critcalc, haremos exactamente lo mismo que antes.

El tercer conflicto es exactamente igual que los dos anteriores.

Como nota, los conflictos que hemos visto se podían solucionar todos viendo el archivo de la battle engine. Este no siempre es el caso, pero a menudo preferiremos quedarnos con el código de la battle engine en archivos que involucran al sistema de batalla del juego.

El cuarto conflicto ocurre en Cmd_tryswapitems, y de nuevo, quédate con el código de la battle_engine y borra el otro.

A partir de ahora es cuando se vuelve visualmente confuso. No te preocupes, suena peor de lo que es. Los siguientes 4 conflictos ocurren todos dentro de la misma funcion, Cmd_handleballthrow.

El quinto "conflicto" no es un conflicto, borra las 3 líneas añadidas por git y ya.

El sexto conflicto es como los anteriores que hemos visto. Tenemos que quedarnos con el código que da valor a gLastThrownBall, así el sistema de "Última Pokeball Usada" seguirá funcionando correctamente. Borramos el código de la item_expansion y las 3 líneas añadidas por git.

El séptimo conflicto parece confuso a primera vista, pero no es nada nuevo. Borramos el código nuevo y dejamos el viejo. Y para asegurar que vamos bien, dejo aquí este .gif


El octavo y último conflicto parece peor, pero la solución es igual al anterior conflicto. Borramos el código nuevo y conservamos el viejo.

src/data/items.h
Simplemente copia y pega el archivo de la rama item_expansion y continúa con el siguiente conflicto.

src/battle_util.c
Hay 2 conflictos en este archivo, y ambos ocurren dentro de la función ItemBattleEffects. Ambos se solucionan de la misma manera, borramos el código nuevo y conservamos el código viejo.

Guardamos los archivos y ya habremos terminado. Ahora que hemos arreglado todos los conflictos, hacemos un commit para almacenar los cambios que acabamos de hacer.

¿Por qué hacemos un commit?
Porque la fusión no se completó correctamente al haber un conflicto de fusión, con lo cual los cambios que se introdujeron de la rama item_expansion no quedaron bien registrados.

¿Cómo hacemos un commit? Simple.

git add *

Esto le dice a Git que incluya en el siguiente commit todos los cambios hechos en cualquier archivo de la carpeta pokeemerald_egg

git commit -m "Inserta mensaje aquí"

Esto creará un commit con un título a nuestro gusto. Por ejemplo:

git commit -m "Merged branch 'item_expansion'"

El cual crearía un commit titulado "Merged branch 'item_expansion'".

Felicidades, ya tienes un repositorio de Pokeemerald con las ramas battle_engine E item_expansion incorporadas.

Explicando de una manera rápida, lo que hicimos fue coger todos los cambios de la rama item_expansion e implementarlos en nuestra rama actual.

Continuemos. El siguiente paso va a ser algo tedioso, así que prepárate.


8) Tal cual hicimos con la rama item_expansion, vamos a incorporar la rama pokemon_expansion usando el comando git pull.

git pull origin pokemon_expansion

Después de usar el commando verás algo como esto:


Vamos a hacer una pausa para entender lo que nos está diciendo. Tenemos muchas líneas empezando con "CONFLICT". Esto significa que esta vez tendremos que lidiar con muchos conflictos, y no solo unos cuantos.

Para dejarlo claro, lo que estas líneas significan es que la rama que estamos incorporando contiene cambios en archivos específicos que no compaginan con los cambios hechos de esos mismos archivos en commits anteriores. Por esa razón es que hay que resolver los conflictos.

Procedo a lidiar con cada conflicto de forma individual:

.github/workflows/build.yml
Otro falso positivo, como antes. Ignóralo y pasa al siguiente archivo.

asm/macros/event.inc
Borra las 3 líneas de Git. Añade .endm al final del macro totemboost_evas2 y continúa al siguiente archivo.

data/specials.inc
Solamente borra las 3 líneas añadidas por Git y ya.

include/constants/expansion_branches.h
Como antes y por las mismas razones, aquí solo hace falta borrar las 3 líneas introducidas por Git.

include/constants/pokemon.h
Dos conflictos por resolver. El primero es fácil, simplemente borra las 3 líneas de Git.

El segundo conflicto también es fácil, borra el código viejo y quédate con el nuevo. Justamente lo contrario que hemos hecho en anteriores conflictos.

include/pokemon.h
En el primer conflicto, borramos el código nuevo que está intentando remplazar al de la battle engine. Tambien borraremos las 3 líneas de Git, claro. Eso significa que nos quedarmos con /* 0x16 */ u16 abilities[NUM_ABILITY_SLOTS];

El segundo "conflicto" no es nada. Borra las 3 líneas añadidas por Git y continúa al siguiente archivo.

src/battle_gfx_sfx_util.c
El primer conflicto ocurre dentro de la función BattleLoadMonSpriteGfx. Este es el primer conflicto algo complejo, ya que requiere de mezclar código antiguo y nuevo, y también borrar la función HandleLoadSpecialPokePic_DontHandleDeoxys, ya que ya no existe en nuestro proyecto y fue eliminada por la rama pokemon_expansion.

Empezemos por borrar el código nuevo y quedarnos con el viejo. Eso nos deja con un if/else.
Dentro del else hay otro if/else. Resumiendo, dentro del primer else nos quedaremos solo con el código del segundo else.

El resultado sería este:


Ahora, debes renombrar todas las líneas HandleLoadSpecialPokePic_DontHandleDeoxys en este archivo, remplazándolas con HandleLoadSpecialPokePic

Si leemos el código que queda, notaremos que esta función cargará el sprite frontal en batalla cuando el último parámetro bool32 opponent sea TRUE. Y al contrario, cuando este parámetro sea FALSE, cargará el back sprite.
Eso se hace en este mismo archivo, en las funciones BattleLoadOpponentMonSpriteGfx y BattleLoadPlayerMonSpriteGfx.
Es una optimización del código de Game Freak que unifica la carga de sprites en una sola función, en vez de tener 2 que son casi idénticas.

Hablando de BattleLoadPlayerMonSpriteGfx, podemos ver que está relacionado con el segundo conflicto de este archivo.
Borraremos todo el código nuevo y nos quedaremos con el código antiguo. No te preocupes por la línea BattleGfxSfxDummy1 que acabamos de borrar, ya que es una función completamente vacía que no se usa en ningún lugar.

Ahora, el tercer y útimo conflicto, el cual ocurre dentro de la función HandleSpeciesGfxDataChange. Este no es nada serio, solo borra las 3 líneas de Git.

src/data/pokemon/base_stats.h
Coge el código de la rama pokemon_expansion.

Recientemente, ITEM_STICK ha sido renombrado a ITEM_LEEK, como se hizo en Pokémon Espada y Escudo. Sustituye todas las instancias de ITEM_STICK por ITEM_LEEK y continúa.

src/data/pokemon/egg_moves.h
Coge el código de la rama pokemon_expansion y continúa.

src/data/pokemon/evolution.h
Coge el código de la rama pokemon_expansion.

Recientemente, ITEM_UP_GRADE ha sido renombrado a ITEM_UPGRADE en la rama item_expansion, como se hizo en Pokémon Espada y Escudo. Sustituye todas las instancias de ITEM_UP_GRADE por ITEM_UPGRADE y continúa.

src/data/pokemon/level_up_learnsets.h
Coge el código de la rama pokemon_expansion, y borra las 2 barras que comentan la mayoría de ataques del archivo.
Estos ataques fueron comentados para permitir usar la rama pokemon_expansion a la gente que no quería usar las ramas battle_engine o item_expansion.

Y te preguntarás "¿entonces por qué hay nuevas habilidades en el archivo base_stats.h?"
Realmente las nuevas habilidades redirigen a ABILITY_NONE cuando la battle_engine no se está utilizando.

Copia y pega el archivo, y con Ctrl+H remplaza todas las instancias de
//LEVEL_UP_MOVE por LEVEL_UP_MOVE y continúa con el siguiente conflicto.

src/data/text/abilities.h
Coge el código de la rama battle_engine y continúa.

src/data/text/move_names.h
Coge el código de la rama battle_engine y continúa.

src/pokemon.c
Este archivo tiene 4 conflictos.
Para resolver el primer conflicto, simplemente borra las 3 lineas añadidas por Git.
Para resolver el segundo conflicto, borra las 3 mismas líneas y toda la función sDeoxysBaseStats.
Para resolver el tercer conflicto, haz lo mismo que en el primero.
Y para resolver el último conflicto, borraremos el código nuevo y las líneas añadidas por Git.


9) No te preocupes, prácticamente hemos terminado. Sería genial que hicieras un commit ahora mismo. Añade los cambios al commit usando

git add *

Despúes simplemente escribe

git commit -m "Merged branch 'pokemon_expansion'"


10) Ya podemos compilar la ROM.

make -jN
Nota: "N" significa el número de hilos del CPU que quieres asignar al compilador. Cuantos más hilos, más rápido irá.
Pista: El comando nproc te dirá cuantos hilos tiene tu CPU. Puedes usar tantos como tengas.



Si todo ha ido bien, verás esto en tu terminal, y una ROM se habrá compilado correctamente.


También debo decir que, aunque en este caso he sugerido hacer commit antes de compilar la ROM, normalmente prefiero hacer commit después de asegurarme que los cambios funcionan correctamente. En otras palabras, después de asegurar que la ROM se puede compilar.


Dicho esto, ya hemos completado la primera parte del tutorial. Tenemos una copia de Pokeemerald que contiene los proyectos de DizzyEgg y que en RHH nos hemos esforzado tanto por hacer. También tienes una cuenta en GitHub y un repositorio donde se encuentra tu proyecto.

De aquí en adelante, vamos al siguiente paso que realmente no tiene que ver con decompilación.
Antes de esto, vamos a situarnos de nuevo. Tienes una copia de Pokeemerald con las 3 ramas battle_engine, item_expansion y pokemon_expansion.

Bien, vamos a la última parte del tutorial.

Vinculando nuestro proyecto con su repositorio de GitHub
Ya tenemos nuestro proyecto y un repositorio en GitHub, y nuestra cuenta de GitHub vinculada con nuestra copia local de Git.

1) Lo primero que haremos será ajustar los repositorios que nuestro proyecto esta rastreando.

Ahora mismo, si usamos git remote –v, veremos algo así:


Esto nos dice que el único repositorio que estamos rastreando es el de RHH, y la clave que usamos para interactuar con él se llama “origin”.

¿Qué deberíamos hacer? Vamos a asignar una nueva URL a origin, que será la URL de nuestro repositorio en GitHub.

Lo haremos usando:

git remote set-url origin https://github.com/NOMBRE_DE_USUARIO/NOMBRE_DEL_REPOSITORIO

El resultado es algo así:


Con esto estamos diciéndole a nuestra copia local de Pokeemerald que la nueva casa del proyecto será la URL que acabamos de dar a origin.


2) Pero, ¿ahora qué pasa si queremos actualizar las ramas battle_engine, item expansion o pokemon_expansion mediante pull?
Para solucionarlo vamos a rastrear el repositorio original con git remote. De ese modo tendremos nuestro propio lugar para nuestro proyecto en GitHub y también podremos añadir cualquier cosa de cualquier rama.
Lo haremos usando:

git remote add keyword link_al_repositorio

"keyword" será una palabra que queramos, la cual usaremos como atajo para el repositorio de Pokeemerald de RHH.
"link_to_the_repository" será la URL del repositorio.
En otras palabras, algo así:

git remote add rhh https://github.com/rh-hideout/pokeemerald-expansion

De ese modo podemos hacer git pull rhh battle_engine y demás cuando nos dé la gana.
Y básicamente ya estamos.

Tenemos nuestra carpeta pokeemerald_egg con su rama battle_engine por defecto, la cual contiene las 3 ramas de la Pokeemerald Expansion; junto con un repositorio de GitHub vinculado a ésta. ¿Por qué no intentas subir tus commits al repositorio? Solo tienes que hacer:

git push origin battle_engine

Después de usar este commando, deberás escribir tu nombre de usuario y token de nuestra cuenta GitHub.
Sí, has leído bien: token

¿Qué es un token?

Recientemente GitHub ha abandonado el sistema de contraseñas y lo ha sustituido por tokens de acceso personal.
Lo que hice personalmente fue generar un token que me concediera todos los permisos y guardarlo para poder usarlo cuando lo necesitara.

¿Cómo generamos un token? Es más sencillo de lo que parece.
Ve a https://github.com/settings/tokens
Ahí, haz click en "Generate new token" y rellena los campos.
En "Note", pon una descripción del token, en "Expiration Date" escoge la opción "No expiration", y marca todas las casillas en negrita en la sección "Select scopes".
Con todo en orden, puedes dar click en "Generate token".

Te aparecerá lo siguiente:


La parte censurada es tu token. Cópialo y guárdalo, lo usarás cada vez que tengas que hacer git push o como sustituto de tu contraseña de GitHub.

No te preocupes si no puedes ver el token una vez pegado en la terminal.
Información personal como contraseñas, o los mismos tokens que funcionan como tal, no se pueden leer. Aparecen invisibles. Es una medida de seguridad.

Eso llevará el contenido de tu rama battle_engine a tu repositorio de GitHub. Si la rama no existe ahí, se creará automáticamente.
Ya que es la primera y única rama que hemos subido a nuestro repositorio de GitHub, se convertirá en nuestra rama por defecto ahí también.

Y creo que eso es todo realmente.

Sí, sé que es MUCHA información que procesar. Tómate tu tiempo y no te des prisa, no es tan difícil como parece.

También, recordad que los conflictos son el demonio algo con lo que tendréis que lidiar muy a menudo. Si se intentasen fusionar las ramas de la expansión en un proyecto avanzado, es muy probable que apareciesen más y diferentes conflictos que los que hemos visto aquí. No hay nada que se pueda hacer al respecto, pero espero que esta guía te facilite solucionar los conflictos que te aparezcan en un futuro.

Deberías ser capaz de solucionarlos siguiendo las explicaciones que he dado sobre la naturaleza de los conflictos. Si no te ves capaz, vuelve a leer esa parte, buscando "¿Qué es un conflicto de fusión?" haciendo Ctrl+F.​

Post original (desactualizado):
https://pastebin.com/ium3E0ss

Adaptación al español del
tutorial original creado por: @Lunos
 
Última edición:

ZenJM

Rider.
Es un buen tutorial, yo no acostumbro a usar decompilacion, pero seguro este tutorial será de mucha ayuda a todo usuario que lo vea, incluyendome, espero y así sea.
 

Lunos

Enfrentando a La Organización
Miembro insignia
Honestamente hace varios meses que tenia pensado traer el tutorial hasta acá, pero me daba muchisima pereza.
Gracias.
 

KevinXDE

Usuario mítico
Actualizado con los últimos conflictos (espero no haberme dejado nada, pero si hay algún problema decidlo)
 

Jlvs22

Usuario de oro
Buenas, muchas gracias por el tutorial y lo agradezco bastante, pero un amigo y yo tenemos un pequeño error y no sabemos como solucionarlo, el error es el siguiente:
Sin título.png


Agradecería mucho que me explicaran el por que ocurre este error y obviamente como solucionarlo.
 

Lunos

Enfrentando a La Organización
Miembro insignia
Buenas, muchas gracias por el tutorial y lo agradezco bastante, pero un amigo y yo tenemos un pequeño error y no sabemos como solucionarlo, el error es el siguiente: Ver el archivo adjunto 7191

Agradecería mucho que me explicaran el por que ocurre este error y obviamente como solucionarlo.
Dificilisimo poderte ayudar cuando lo unico que posteás es una linea de error sin ningun tipo de contexto.
¿Que fue lo que hiciste exactamente para encontrar ese error?
 

Jlvs22

Usuario de oro
Dificilisimo poderte ayudar cuando lo unico que posteás es una linea de error sin ningun tipo de contexto.
¿Que fue lo que hiciste exactamente para encontrar ese error?
Vea, explico con contexto.

Todo el procedimiento funciono al exito, pero a la hora de vincular el proyecto con el GitHub, en esta parte especifica:
Tenemos nuestra carpeta pokeemerald_egg con su rama battle_engine por defecto, la cual contiene las 3 ramas de la Pokeemerald Expansion; junto con un repositorio de GitHub vinculado a ésta. ¿Por qué no intentas subir tus commits al repositorio? Solo tienes que hacer:
Es cuando aparece ese Error... Y sencillamente creo que es lo mejor que puedo explicar, porque segui todo al pie de la letra y justamente en esa parte (porque lo he hecho 3 veces), es cuando ocurre
 

Lunos

Enfrentando a La Organización
Miembro insignia
Vea, explico con contexto.

Todo el procedimiento funciono al exito, pero a la hora de vincular el proyecto con el GitHub, en esta parte especifica:
Tenemos nuestra carpeta pokeemerald_egg con su rama battle_engine por defecto, la cual contiene las 3 ramas de la Pokeemerald Expansion; junto con un repositorio de GitHub vinculado a ésta. ¿Por qué no intentas subir tus commits al repositorio? Solo tienes que hacer:
Es cuando aparece ese Error... Y sencillamente creo que es lo mejor que puedo explicar, porque segui todo al pie de la letra y justamente en esa parte (porque lo he hecho 3 veces), es cuando ocurre
Es decir, cuando intentas usar git push origin battle_engine, ¿correcto?
El error probablemente te está diciendo que la historia de commits de la rama battle_engine del repositorio de tu proyecto en GitHub, y la historia de commits que tienes localmente, difieren.
Por lo que veo, tu repositorio en GitHub está totalmente vacio, pero.

Quizá sea por las credenciales de GitHub. Recientemente GitHub dejó de utilizar contraseñas y pasó a usar un sistema de "tokens". Codigos de identificación personales para cada cuenta. Lo he tenido en la mente durante un tiempo ya, pero siempre me olvido de editar el tutorial.
Aquí se explica todo bastante a detalle.

EDITO: Editada la sección "Vinculando nuestro proyecto con su repositorio de GitHub" del tutorial original.
Pegale una ojeada luego @KevinXDE.
 
Última edición:

KevinXDE

Usuario mítico
Buenas, muchas gracias por el tutorial y lo agradezco bastante, pero un amigo y yo tenemos un pequeño error y no sabemos como solucionarlo, el error es el siguiente: Ver el archivo adjunto 7191

Agradecería mucho que me explicaran el por que ocurre este error y obviamente como solucionarlo.
No pensé que lo de los tokens pudiera causar algún problema, pero Lunos tiene razón. Igual, he actualizado el tutorial. Si por algún motivo sigues teniendo problemas, puedes probar GitHub Desktop como dijo kakarotto, ya que es bastante intuitivo. Si no, comenta aquí de nuevo
 

Lunos

Enfrentando a La Organización
Miembro insignia
Paso a comentar que le dí una lavada de cara al tutorial original.
Hace un par de meses decidimos empezar a trabajar en la rama Master y tirar a la basura el asunto de las ramas individuales, tras concluir con una votación posteada en varios servidores de Discord (incluido el de Wah) que la inmensa mayoria usaba la rama Master, un grupete fusionaba las 3 ramas individuales, y practicamente nadie usaba 1 o 2 y nada más, por ende, el nuevo tutorial es más sobre Git que otra cosa.
Se clona el Pokeemerald-expansion, se sugiere al usuario que se mueva a la rama "upcoming" y se habla sobre eso, despues se habla sobre los comandos de Git basicos que un usuario necesita saber, sobre los conflictos de fusión, sobre como hostear un proyecto en GitHub, y poco más.

Asi que eso, a trabajar @KevinXDE 😂
 
Arriba