24221-\[GBC]_Consejos_Utiles_para_Script_GBC
#0
Chamber4315♪ 26330


ATENCION: Esta NO es una guía sobre scripts. Esta es una guía de consideraciones y consideraciones que ayuden a mejorar el rendimiento al momento de scriptear en GBC.
La presente guía está enfocada a los usuarios que inician el scripting pero que tienen conocimientos medio-avanzado de hacking GBC.

Recuerdo que cuando inicie en el RH lo primero que intente hacer fue un script, pero como todo novato lo único que logre fueron horas de no saber lo que hacía hasta que al fin termine arruinando una parte del juego.
Ahora que ya que comprendo mejor como funciona un juego de GBC vengo a compartirles mis experiencias que a más de uno les puede servir.

1.-Dominar el Repoint. Es necesario que antes de querer scriptear dominen el tema del Repunteo, ya que los comandos importantes requieren el uso de pointers. Hay facilidad al hablar de pointers en PKSV por que los bytes están invertidos, lo que ocasiona que en un pointer de 2-bytes los últimos 3 dígitos sean iguales que el del offset.

Ejemplo: el 2-byte pointer de $1AE345 es 0x6345

Como se determina entonces el primer digito del pointer (que esta en azul)? Fácil, lo determina el banco donde se encuentra el offset. Recuerden que cada banco se compone de 0x4000 bytes, por lo tanto, TODOS los bancos en el juego inician con 0x4000, 0x8000, 0xC000 y 0x0000. Lo único que hay que hacer es sacar la diferencia entre el inicio del banco y el 4 digito del offset de izquierda a derecha y al resultado le sumamos +4.

En nuestro ejemplo usamos el offset $1AE345, por lo tanto el inicio del banco es $1AC000. Entonces a 0xE le restamos 0xC y nos da como resultado 2.
A 2 le sumamos +4 = 6. De esta manera tenemos el inicio del pointer 0x6345.
Si en lugar de 0xE fuera 0xF entonces el pointer seria 0x7345.

2.-Las herramientas ideales del Scripting son PKSV + JohtoMap. Hay muchos hackers que hacen scripts directamente en Hex, pero siempre es más cómodo tener un entorno grafico. Recuerden que aunque JohtoMap y PKSV se integran, no son una misma herramienta, siempre que se haga el cambio de una herramienta a otra hay que re-abrir el ROM para evitar perder información.

3.-No compiles tu script hasta el final. Cuando trabajen en PKSV lo mejor es guardar el archivo en la PC y trabajarlo ahí. Eviten compilar (guardar) un script en el Rom hasta que no hayan revisado que los comandos, los pointers, los scripts secundarios y los textos sean los correctos, con esto evitan dañar la Rom por accidente.

4.-Sean ordenados. Un script de nivel medio se compone de scripts secundarios, que a su vez pueden tener también otros scripts. Lo mejor es seguir el orden que toma el PKSV, empezando por el script primario y siguiendo con los secundarios que vayas encontrando de arriba hacia abajo. En caso de usar el comando “applymovement” lo mejor es dejar las instrucciones de movimiento hasta el final.

5.- Hay que prever. Generalmente cuando uno cree que termino un script, pasa el tiempo y cuando lo vuelves a revisar vez algo que no te gusto o simplemente quieres seguir agregando más comandos, pero oh sorpresa, ya no tienes mas espacio. Para que esto no te pase hay que dejar cierta holgura en cada script. A que me refiero con esto? Veamos un script de ejemplo de lo que NO se debe hacer.

En este ejemplo (mirar spoiler) el script principal comienza en $15B700 y pesa 0x49 bytes.
El script secundario comienza en $15B749, ósea inmediatamente después de terminar el script principal. No aconsejo que hagan eso, porque en caso de querer expandir el script en un futuro, ya no tienen espacio y lo que tendrían que hacer es volver a programar los scripts secundarios junto con sus pointers, lo que se traduce en perdida de tiempo. En su lugar dejen unos cuantos bytes para poder estar modificando. Recomiendo de 0x10 a 0x20 bytes o lo que se les facilite para redondear.



6.-Bancos de texto. Agrupen el texto de un solo banco en un solo lugar. Si en una misma ciudad tienen múltiples scripts lo recomendable es que manden el texto de todos los scripts a un mismo lugar. Yo destino los últimos 0x1000 bytes de cada banco al texto, por ejemplo, si estoy en el banco 56 que abarca de $158000 a 15C000 (realmente hasta 0x15BFFF), dejo libre de $15B000 en adelante solo para texto.

Qué ventaja nos trae el agrupar el texto?
Al estar concentrados en que el script salga bien pocas veces prestamos atención a los diálogos, por esto es más fácil pensar en la historia del hack después y editarlos, pero para no estar lidiando los tediosos formatos de texto del PKSV podemos usar la herramienta POKETEXT que facilita el proceso de edición, de este modo no tenemos que preocuparnos por los gialogos de nuestros personajes. Recomiendo dejar entre 0x40 y 0x80 bytes para un dialogo normal de NPC.

Para que POKETEXT reconozca nuestro “banco de texto” solo hace falta editar el archivo “.ini” y agregar los datos con el siguiente formato:

[Nombre]
Start=$OFFSET + 1

Para nuestro ejemplo anterior quedaría algo como esto:


[Texto de Chamber]
Start=$$15B001

Para usar este método de edicion, el texto tiene que ir siempre pegado uno detrás del otro y restarle un byte, es decir, si el primer texto de nuestro banco comienza en $15B000 y el primer texto mide 0x65 bytes, el segundo debe empezar en $15B065 -1 = $15B064. Si no se aplica la regla del -1, POKETEXT no puede leer todos los textos que pongamos.

Otro consejo práctico es darle holgura. Aunque nuestro texto mida 0x65 rellenen con espacios en blanco para que mida 0x71 o 0x81, así tienen espacio de sobra por si quieren cambiar diálogos. Pero porque “0x81” en lugar de “0x80”??
Recuerden la regla del “-1” para que el POKETEXT lea nuestros bancos de texto, si agregamos 0x81 estamos redondeando automáticamente a 0x80 y nos quebramos la cabeza al momento de asignar pointers al texto y sabemos fácilmente que el texto esta ordenado. Ejemplo:


#ORG: data
-> 0x15B700 (0x81 bytes)
-> 0x15B780 (0x81 bytes)
-> 0x15B800 (0x81 bytes)
-> 0x15B880 (0x81 bytes)
-> …


7.- "3jump", nuestro major amigo. Se han preguntado qué pasa si disponemos de poco espacio en un banco y queremos hacer muchos scripts? Para esto hay dos soluciones, mudar toda la información a otro banco en blanco, pero esto conlleva mover gran cantidad de datos y repuntearlos, lo que es muy tardado y laborios… o pueden usar el comando "3jump".
Lo que hace "3jump" es enlazar un script con otro en cualquier lugar del Rom, asi como su nombre lo indica, hace un “salto” con un pointer de 3-bytes, por lo que podemos extender un script sin importar el espacio.

Si usan este método igual recomiendo que hagan un banco de puros scripts para que tengan todo mejor organizado.

"3jump" tiene su hermano malvado llamado “3call”, con la única diferencia de que al finalizar el script “con salto” se regresa al script principal y continua de manera normal. Esto es muy útil si quieres modificar un script existente en lugar de hacer un script de cero.

NOTA: El único inconveniente que he visto al usar "3jump" es que no es compatible con el comando "winlosstext" que se usa en las peleas contra Trainers. Parece que no son compatibles por que "winlosstext" no identifica que estas en un nuevo banco e intenta retomar el banco original para llamar el texto, por lo que se congela el juego, asi que eviten combinar estos dos comandos.

8.-Mejor un script nuevo. Recomiendo siempre trabajar sobre espacio en blanco y crear los acripts desde cero por si en un futuro quieren retomar algún script original sin que se vea afectado. Esta recomendación es muy personal, pero mas vale prevenir.

9.-“Como hago tal o cual cosa?”. La mejor manera de aprender es experimentar, así que si quieres hacer un script y no tienes ni idea de que comandos usar busca siempre en el juego original. Muchos me preguntan cómo pueden hacer encuentros con pokemon Shiny y la mejor respuesta es “mira el script del Red Gyarados”. Si después de intentar por tu cuenta las cosas no salen bien, ahora si no dudes en preguntar a otro usuario.

10.- Paciencia. Nadie nace sabiendo, todo es un proceso largo de aprendizaje. No se desesperen si las cosas no salen bien a la primera, al contrario, esmérense en encontrar el fallo para no volverlo a repetir. Si las cosas no fueran difíciles, entonces cual sería la satisfacción de hacerlo bien?


================================


Espero estos consejos sean útiles para los que quieren aprender Scripting, ya que el orden nos ayuda a tener menos fallos y hacer futuras ediciones con mas facilidad.

Por mi parte es todo, si alguien tiene alguna duda o quiere aportar de su experiencia personal los invito a comentar.

Hasta la próxima y suerte!