Thread Id: 10405
Thread Name: CAMBIO MINI [RUBY_USA]
Primero que nada, creditos a Hackmew, ya que en su tutorial de ASM, me facilitó estos datos, y gracias a el trasteando los offsets, pude averiguar que se podia hacer eso.
Bien, iremos a la direccion 0x02024EA4, alli encontraremos lo siguiente:
02024EA4 - 02024EAB= Nombre protagonista. (en hexadecimal, para saber cada caracter usar la tabla.tbl) (8 BYTES)
02024EAC = Genero (00 si eres chico, 01 si eres chica, otros bytes otros minis, surf, bici..etc.) (1 BYTE)
02024EAD = ???? (Por investigar) (1 BYTE)
02024EAE - 02024EAF = Trainer ID (2 BYTES)
02024EB0-02024EB1 = Secret ID (2 BYTES)
02024EB2-02024EB3 = Horas jugadas (2 BYTES)
02024EB4 = Minutos jugados (1 BYTE)
02024EB5 = Segundos jugados (1 BYTE)
02024EB6 = Frames (1 BYTE)
02024EB7 = ???? (1 BYTE)
02024EB8-02024EB9 = OPCIONES (2 BYTES)
¿Que podemos modificar de ahí?
Cualquier cosa con WBTO, o con ASM. (Para unas cosas recomendaria asm y para otras wbto, por ejemplo para que te den un poke u otro dependiendo de si tu trainer id es par o impar.. usaria ASM, o para hacer un evento una vez transcurridas "X" horas de juego.. y usaria WBTO para cambio de mini, o para cambiarle el nombre al protagonista.)
Pero bueno, yo no he venido aqui a explicaros nada de eso, vamos a lo que nos interesa, EL CAMBIO DE MINI
Para ello empezaremos asi:
Empezamos nueva partida y elegimos boy en la eleccion de sexo, en la direccion 02024EAC, nos encontraremos "00" y si elegimos "girl" nos encontraremos "01", este byte conforme lo cambiamos obtendremos un mini u otro, por ejemplo el "02" es la bicicleta, creo recordar...
Por ende, podriamos usar este pequeño dato, para hacer el cambio de mini.
¿Como lo hariamos?
writebytetooffset 0x1 0x02024EAC
warp 0xbanco 0xmapeado 0xwarp 0x0 0x0
(El WBTO, escribe un byte para determinar que mini eres -sexo en realidad- y el warp es la unica manera que he visto hasta ahora de refrescar la pantalla completamente, ya que los fadescreen, o el special del setmaptile no funcionan..)
Con ese pequeño script, ahora mismo de haber elegido al chico, manejariamos a la chica.
(Si no usamos el minisprite de la chica en el juego, estaria libre, no supondría ningun problema. Así tendriamos dos minis diferentes para hacer dos roles distintos, con todo distinto.)
¿Cuando hay un problema?
Cuando el minisprite de la chica está ocupada -porque en nuestro juego hay chico y chica-, y tenemos que buscar otro mini, -por ejemplo el niño pequeño que creo que es "2F"-, al refrescar la pantalla por primera vez -entrando por un warp- CONTROLARIAMOS AL NIÑO PEQUEÑO!! pero el problema viene, cuando nos metemos en el menu pokemon o alguno de estos, ya que se refresca de nuevo la pantalla -de otra manera- y el mini vuelve a ser nuestro protagonista inicial, PERO si observamos en la direccion 02024EAC, el byte sigue igual que el que pusimos, por lo tanto para solucionar este problema habria que refrescar de nuevo la pantalla.
Pero como eso sería muy costoso, ¿qué tal si buscamos otra solucion mas adecuada a tener que estar refrescando la pantalla cada 2x3?
¿LA solucion a ese problema?
Se me ocurren 2:
(Por orden de preferencia, ya que uno de los problemas sucede tanto si vas a cambiar al mini de chica, como a otro...)
1)
Editar el evento de "warp" sin tener que verse los "flashes" previos, i asi se refresque completamente la pantalla.
2)
Evitar que se presione el boton start, mientras tengamos el control de dicho mini. (en caso de haber chico y chica y tengamos que usar otro mini, como el del niño pequeño)
Tengo una breve idea, y es usando el I/O comprobar que se presiona el "BOTON START" pase algo que te lo impida, -mediante un script de nivel de los que se ejecutan al abrir el menú..-
O cancelar la interrupcion de "start" brevemente con asm, algo más dificultoso...
-proximamente haré una investigacion sobre ello y haber que pasa, vosotros tambien podeis ayudarme, buscando alguna manera de que en el I/O, el byte que hace que sea START, no se produzca, o alguna otra manera que evite la entrada al menu pkmn
Bien, iremos a la direccion 0x02024EA4, alli encontraremos lo siguiente:
02024EA4 - 02024EAB= Nombre protagonista. (en hexadecimal, para saber cada caracter usar la tabla.tbl) (8 BYTES)
02024EAC = Genero (00 si eres chico, 01 si eres chica, otros bytes otros minis, surf, bici..etc.) (1 BYTE)
02024EAD = ???? (Por investigar) (1 BYTE)
02024EAE - 02024EAF = Trainer ID (2 BYTES)
02024EB0-02024EB1 = Secret ID (2 BYTES)
02024EB2-02024EB3 = Horas jugadas (2 BYTES)
02024EB4 = Minutos jugados (1 BYTE)
02024EB5 = Segundos jugados (1 BYTE)
02024EB6 = Frames (1 BYTE)
02024EB7 = ???? (1 BYTE)
02024EB8-02024EB9 = OPCIONES (2 BYTES)
¿Que podemos modificar de ahí?
Cualquier cosa con WBTO, o con ASM. (Para unas cosas recomendaria asm y para otras wbto, por ejemplo para que te den un poke u otro dependiendo de si tu trainer id es par o impar.. usaria ASM, o para hacer un evento una vez transcurridas "X" horas de juego.. y usaria WBTO para cambio de mini, o para cambiarle el nombre al protagonista.)
Pero bueno, yo no he venido aqui a explicaros nada de eso, vamos a lo que nos interesa, EL CAMBIO DE MINI
Para ello empezaremos asi:
Empezamos nueva partida y elegimos boy en la eleccion de sexo, en la direccion 02024EAC, nos encontraremos "00" y si elegimos "girl" nos encontraremos "01", este byte conforme lo cambiamos obtendremos un mini u otro, por ejemplo el "02" es la bicicleta, creo recordar...
Por ende, podriamos usar este pequeño dato, para hacer el cambio de mini.
¿Como lo hariamos?
writebytetooffset 0x1 0x02024EAC
warp 0xbanco 0xmapeado 0xwarp 0x0 0x0
(El WBTO, escribe un byte para determinar que mini eres -sexo en realidad- y el warp es la unica manera que he visto hasta ahora de refrescar la pantalla completamente, ya que los fadescreen, o el special del setmaptile no funcionan..)
Con ese pequeño script, ahora mismo de haber elegido al chico, manejariamos a la chica.
(Si no usamos el minisprite de la chica en el juego, estaria libre, no supondría ningun problema. Así tendriamos dos minis diferentes para hacer dos roles distintos, con todo distinto.)
¿Cuando hay un problema?
Cuando el minisprite de la chica está ocupada -porque en nuestro juego hay chico y chica-, y tenemos que buscar otro mini, -por ejemplo el niño pequeño que creo que es "2F"-, al refrescar la pantalla por primera vez -entrando por un warp- CONTROLARIAMOS AL NIÑO PEQUEÑO!! pero el problema viene, cuando nos metemos en el menu pokemon o alguno de estos, ya que se refresca de nuevo la pantalla -de otra manera- y el mini vuelve a ser nuestro protagonista inicial, PERO si observamos en la direccion 02024EAC, el byte sigue igual que el que pusimos, por lo tanto para solucionar este problema habria que refrescar de nuevo la pantalla.
Pero como eso sería muy costoso, ¿qué tal si buscamos otra solucion mas adecuada a tener que estar refrescando la pantalla cada 2x3?
¿LA solucion a ese problema?
Se me ocurren 2:
(Por orden de preferencia, ya que uno de los problemas sucede tanto si vas a cambiar al mini de chica, como a otro...)
1)
Editar el evento de "warp" sin tener que verse los "flashes" previos, i asi se refresque completamente la pantalla.
2)
Evitar que se presione el boton start, mientras tengamos el control de dicho mini. (en caso de haber chico y chica y tengamos que usar otro mini, como el del niño pequeño)
Tengo una breve idea, y es usando el I/O comprobar que se presiona el "BOTON START" pase algo que te lo impida, -mediante un script de nivel de los que se ejecutan al abrir el menú..-
O cancelar la interrupcion de "start" brevemente con asm, algo más dificultoso...
-proximamente haré una investigacion sobre ello y haber que pasa, vosotros tambien podeis ayudarme, buscando alguna manera de que en el I/O, el byte que hace que sea START, no se produzca, o alguna otra manera que evite la entrada al menu pkmn
Interesante Eing, pero no veo del todo factible las opciones que das, aunque no esta de mal probarlas a ver si funciona.
Para cambiar el mini por otro de una forma totalmente SEGURA es editando el code Asm que carga el mini(Haciendo algo parecido a la rutina shiny de mastermind) de forma que segun una var de la ram, carga tal mini.
Lo bueno de eso es que puedes cargar MUCHISIMOS minis con un simple setvar(Ya que las variables se guardan en la RAM). De hecho, ese es el metodo que utilize para crear mi sistema de multimapas.
Lo malo es que SI O SI, debes manejar el Asm a nivel de HEX, ya que a la hora de editar el code nativo de la rom los compiladores son muy impracticos, por eso yo hago mis rutinas en Hex.
No obstante considero que pruebes primero las opciones que has planteado y si no, pues Asm y Disassambler con eso.
:D
Para cambiar el mini por otro de una forma totalmente SEGURA es editando el code Asm que carga el mini(Haciendo algo parecido a la rutina shiny de mastermind) de forma que segun una var de la ram, carga tal mini.
Lo bueno de eso es que puedes cargar MUCHISIMOS minis con un simple setvar(Ya que las variables se guardan en la RAM). De hecho, ese es el metodo que utilize para crear mi sistema de multimapas.
Lo malo es que SI O SI, debes manejar el Asm a nivel de HEX, ya que a la hora de editar el code nativo de la rom los compiladores son muy impracticos, por eso yo hago mis rutinas en Hex.
No obstante considero que pruebes primero las opciones que has planteado y si no, pues Asm y Disassambler con eso.
:D
Bueno, pues a mi se me ocurre una opción 3 (que no sabría aplicar =P) como solución al problema :awesome:
Todo lo que diga a continuación será asumiendo que elegimos "BOY" en la intro...
Bueno, dices que al entrar a la mochila o al menú pokemon se refresca la pantalla de de un modo diferente a como lo hace el warp, y al hacerlo, la variable del mini se cambia por 00. Pero para saber que tiene que escribir 00 y no 01, tiene que leer esto de algún sitio, no? Y este sitio es...?
A) Otra variable
B) El sav??? <- No lo creo
C) [Se aceptan ideas para la opción C xD]
Por lo que creo que la 3ª opción sería investigar ese refresco de pantalla que aparece al entrar en el menú pokemon.
No se si estas cosas funcionan así, pero yo creo que lo primero sería descubrir en que momento se cambia la variable del mini por 00 (al entrar en el menú, al salir,en un momento que decide un cactus por el medio (?), etc.) Esto supongo que se puede hacer "surfeando" la ram y observando el sitio donde está escrita la variable. Y bueno, para descubrir de donde se lee el 01, no se me ocurre nada...
________________________________________________________________
Pero... pachachachan!
Se me ha ocurrido otra aplicación para esto!
La cosa es cambiar la elección de BOY/GIRL por otra que tenga 3 o 4 opciones, por ejemplo, teniendo así mas minis para elegir al principio :) .
Entonces, podríamos comparar la RAM de 4 partidas, una en que se hubiera elegido la opción 00, una en la que se hubiera elegido la opción 01, una de la 02 y una de la 03. Si realmente en el refresco se lee de otra variable, las 4 rams tendrían 2 vars diferentes. Una ya la conocemos, y está en este offset: 02024EAC y la otra es la que buscamos.
Si esto no funciona, pues supongo que habrá que asumir que mi teoría (poco probable) de que se sobrescribe con otra variable es falsa x:(
Bueno, pues espero que lo que he escrito sirva de algo =P
Dew!
EDIT: Otro método para descubrir donde está esa 2ª variable teórica, es comprobar el script inicial del profesor, que no debe ser muy diferente a un script normal, que en algún lugar apuntará a la 2ª variable teórica (pero puede que solo apunte a la que ya sabemos y la teórica no exista, por eso es solo teoría =P)
EDIT2: Ahora quiero que contrarrestéis mi teoría con buenos argumentos (haciendo que me maldiga a mi mismo por haber gastado tanto tiempo escribiendo esto =P)
Todo lo que diga a continuación será asumiendo que elegimos "BOY" en la intro...
Bueno, dices que al entrar a la mochila o al menú pokemon se refresca la pantalla de de un modo diferente a como lo hace el warp, y al hacerlo, la variable del mini se cambia por 00. Pero para saber que tiene que escribir 00 y no 01, tiene que leer esto de algún sitio, no? Y este sitio es...?
A) Otra variable
B) El sav??? <- No lo creo
C) [Se aceptan ideas para la opción C xD]
Por lo que creo que la 3ª opción sería investigar ese refresco de pantalla que aparece al entrar en el menú pokemon.
No se si estas cosas funcionan así, pero yo creo que lo primero sería descubrir en que momento se cambia la variable del mini por 00 (al entrar en el menú, al salir,
________________________________________________________________
Pero... pachachachan!
Se me ha ocurrido otra aplicación para esto!
La cosa es cambiar la elección de BOY/GIRL por otra que tenga 3 o 4 opciones, por ejemplo, teniendo así mas minis para elegir al principio :) .
Entonces, podríamos comparar la RAM de 4 partidas, una en que se hubiera elegido la opción 00, una en la que se hubiera elegido la opción 01, una de la 02 y una de la 03. Si realmente en el refresco se lee de otra variable, las 4 rams tendrían 2 vars diferentes. Una ya la conocemos, y está en este offset: 02024EAC y la otra es la que buscamos.
Si esto no funciona, pues supongo que habrá que asumir que mi teoría (poco probable) de que se sobrescribe con otra variable es falsa x:(
Bueno, pues espero que lo que he escrito sirva de algo =P
Dew!
EDIT: Otro método para descubrir donde está esa 2ª variable teórica, es comprobar el script inicial del profesor, que no debe ser muy diferente a un script normal, que en algún lugar apuntará a la 2ª variable teórica (pero puede que solo apunte a la que ya sabemos y la teórica no exista, por eso es solo teoría =P)
EDIT2: Ahora quiero que contrarrestéis mi teoría con buenos argumentos (haciendo que me maldiga a mi mismo por haber gastado tanto tiempo escribiendo esto =P)
Iniciado por cosarara97
Bueno, pues a mi se me ocurre una opción 3 (que no sabría aplicar =P) como solución al problema :awesome:
Todo lo que diga a continuación será asumiendo que elegimos "BOY" en la intro...
Bueno, dices que al entrar a la mochila o al menú pokemon se refresca la pantalla de de un modo diferente a como lo hace el warp, y al hacerlo, la variable del mini se cambia por 00. Pero para saber que tiene que escribir 00 y no 01, tiene que leer esto de algún sitio, no? Y este sitio es...?
A) Otra variable
B) El sav??? <- No lo creo
C) [Se aceptan ideas para la opción C xD]
Por lo que creo que la 3ª opción sería investigar ese refresco de pantalla que aparece al entrar en el menú pokemon.
No se si estas cosas funcionan así, pero yo creo que lo primero sería descubrir en que momento se cambia la variable del mini por 00 (al entrar en el menú, al salir,en un momento que decide un cactus por el medio (?), etc.) Esto supongo que se puede hacer "surfeando" la ram y observando el sitio donde está escrita la variable. Y bueno, para descubrir de donde se lee el 01, no se me ocurre nada...
________________________________________________________________
Pero... pachachachan!
Se me ha ocurrido otra aplicación para esto!
La cosa es cambiar la elección de BOY/GIRL por otra que tenga 3 o 4 opciones, por ejemplo, teniendo así mas minis para elegir al principio :) .
Entonces, podríamos comparar la RAM de 4 partidas, una en que se hubiera elegido la opción 00, una en la que se hubiera elegido la opción 01, una de la 02 y una de la 03. Si realmente en el refresco se lee de otra variable, las 4 rams tendrían 2 vars diferentes. Una ya la conocemos, y está en este offset: 02024EAC y la otra es la que buscamos.
Si esto no funciona, pues supongo que habrá que asumir que mi teoría (poco probable) de que se sobrescribe con otra variable es falsa x:(
Bueno, pues espero que lo que he escrito sirva de algo =P
Dew!
EDIT: Otro método para descubrir donde está esa 2ª variable teórica, es comprobar el script inicial del profesor, que no debe ser muy diferente a un script normal, que en algún lugar apuntará a la 2ª variable teórica (pero puede que solo apunte a la que ya sabemos y la teórica no exista, por eso es solo teoría =P)
EDIT2: Ahora quiero que contrarrestéis mi teoría con buenos argumentos (haciendo que me maldiga a mi mismo por haber gastado tanto tiempo escribiendo esto =P)
Te equivocas rotundamente con el script del profe cosarara, ya que como veras ES PURO CODE ASM, por lo que no LO PUEDES ABRIR CON XSE. Para aprender de el tienes que saber Asm.
-------------------------------
Eing!! me e fijado en lo que dijiste de que el warp es la unica forma de refrescar la pantalla, y debo decirte que eso no es cierto!!.
Lo que pasa es que como te dije por perfil, al refrescar la pantalla se resetea solo la VRAM, pero la WRAM sigue intacta. Entonces, el mini no cambia porque la rom ya paso el "Codigo" que carga el mini. Lo que hay que hacer es encontrar una forma de resetear también la WRAM, o hacer de alguna manera que la rom vuelva a pasar por el code que carga los minis en pantalla :P
Me la he pasado mucho intentando refrescar la pantalla con algún especial o algo.
Gut me dijo que probara el special "8E" que es el que se usa para refrescar la pantalla cuando se hacen los setmaptiles, pero como dijieron arriba: no hemos encontrado una forma de resetear la WRAM que es la que se modifica al hacer esto. Ahora.. miren esto:
Este tio con ASM puede cambiar facilmente la imagen mostrada.
La respuesta: ASM
Gut me dijo que probara el special "8E" que es el que se usa para refrescar la pantalla cuando se hacen los setmaptiles, pero como dijieron arriba: no hemos encontrado una forma de resetear la WRAM que es la que se modifica al hacer esto. Ahora.. miren esto:
Este tio con ASM puede cambiar facilmente la imagen mostrada.
La respuesta: ASM
Si, la respuesta mas correcta siempre fue ASM, pero hay unas cuantas otras maneras de hacer eso.
Por desgracia, solo tengo como hacer eso en FireRed, pero no debe ser mucho dificil hacer el mismo en Ruby. Me voy a investigar eso. Pero, para firered, es lo siguiente:
La primera manera:
Con advance-map 1.95 , van a los behavior bytes de un overworld y ponen el behavior '0B'.
In-Game, lleguen cerca de ese mini y abran un menú, cualquier cosas que refresque el ecran. Vuelven al overworld y tcharan! Son ese mini!
La segunda forma:
En el offset 0203707D esta presente el numero del overworld que controlas. El player es el numero 00 y el resto son los demás overworlds.
La manera 'correcta':
Editen la rutina presente en el offset 0805E72c, mas precisamente por vuelta de 0805E7C2, que tien la instrucion ldr r1,[r7, #0x1C]. Esto hace con que el offset del grafico del player sea guardado en 02020648, que es donde el juego va a buscar el puntero del mini del player!
Saludos de Sonicarvalho.
Voy a tentar hacer el mismo en Ruby, pero no puedo asegurarle que consiga. :/
Por desgracia, solo tengo como hacer eso en FireRed, pero no debe ser mucho dificil hacer el mismo en Ruby. Me voy a investigar eso. Pero, para firered, es lo siguiente:
La primera manera:
Con advance-map 1.95 , van a los behavior bytes de un overworld y ponen el behavior '0B'.
In-Game, lleguen cerca de ese mini y abran un menú, cualquier cosas que refresque el ecran. Vuelven al overworld y tcharan! Son ese mini!
La segunda forma:
En el offset 0203707D esta presente el numero del overworld que controlas. El player es el numero 00 y el resto son los demás overworlds.
La manera 'correcta':
Editen la rutina presente en el offset 0805E72c, mas precisamente por vuelta de 0805E7C2, que tien la instrucion ldr r1,[r7, #0x1C]. Esto hace con que el offset del grafico del player sea guardado en 02020648, que es donde el juego va a buscar el puntero del mini del player!
Saludos de Sonicarvalho.
Voy a tentar hacer el mismo en Ruby, pero no puedo asegurarle que consiga. :/
Bueno veo que poco a poco todos aportamos, para intentar lograr hacer esto...
Bueno, iré al grano...
Según mi "teoria" del primer post, podremos cambiar el mini, tan solo cambiando un byte, que ese CAMBIA cuando ponemos la bicicleta desde el menu -se refresca al seleccionarla- entonces.. me puse a pensar.
¿Cuando hacemos surf, de cualquier modo se "refresca" la pantalla?
¿Alguien podría copiar aquí el script de surf? -Si no cuando llegue a casa yo edito y lo coloco, ahí debe haber alguna "pista"-
-El que hacemos al hablar con el agua donde el movimiento permitido es "4"-
digo esto, porque al hacer surf, cambiamos el mini, y no se refresca la pantalla de alguna forma "fuera de lo comun -warp,fadescreen,flashes..etc.- asi que creo que ahí debe estar el secreto.
@Mariofan: Es cierto, la WRAM no se refresca, al entrar en un warp, por lo cual el byte colocado sigue igual..
@Trollfiud:Claro, pero en cuyo caso que usaramos ASM, habria que cargar tambien las paletas.. supongo =S -aun soy algo novato en asm-
@sonicarvalho: Tal vez eso del comportamiento byte del mini de "0B" tambien sirva para rubí, pero seria un problema, ya que siempre que "refresques" el menú, serias el otro mini.. aunque tal vez con un script -como el del gimnasio 2º de Hoenn se pueda hacer algo para evitar que se active el script mientras tu no quieras-
La tercera forma, la veo mas correcta, dado que seria con puro ASM y sería todo mas "limpio", simplemente cambiar los punteros, a donde apunta al mini actual, y poner otro puntero.
Ademas, los punteros son 32 bits, (AABBCCDD) -8x4=32- por lo cual con un .word 0xdireccion, leeriamos los 4 bytes y editariamos todo facilmente.
Bueno, iré al grano...
Según mi "teoria" del primer post, podremos cambiar el mini, tan solo cambiando un byte, que ese CAMBIA cuando ponemos la bicicleta desde el menu -se refresca al seleccionarla- entonces.. me puse a pensar.
¿Cuando hacemos surf, de cualquier modo se "refresca" la pantalla?
¿Alguien podría copiar aquí el script de surf? -Si no cuando llegue a casa yo edito y lo coloco, ahí debe haber alguna "pista"-
-El que hacemos al hablar con el agua donde el movimiento permitido es "4"-
digo esto, porque al hacer surf, cambiamos el mini, y no se refresca la pantalla de alguna forma "fuera de lo comun -warp,fadescreen,flashes..etc.- asi que creo que ahí debe estar el secreto.
@Mariofan: Es cierto, la WRAM no se refresca, al entrar en un warp, por lo cual el byte colocado sigue igual..
@Trollfiud:Claro, pero en cuyo caso que usaramos ASM, habria que cargar tambien las paletas.. supongo =S -aun soy algo novato en asm-
@sonicarvalho: Tal vez eso del comportamiento byte del mini de "0B" tambien sirva para rubí, pero seria un problema, ya que siempre que "refresques" el menú, serias el otro mini.. aunque tal vez con un script -como el del gimnasio 2º de Hoenn se pueda hacer algo para evitar que se active el script mientras tu no quieras-
La tercera forma, la veo mas correcta, dado que seria con puro ASM y sería todo mas "limpio", simplemente cambiar los punteros, a donde apunta al mini actual, y poner otro puntero.
Ademas, los punteros son 32 bits, (AABBCCDD) -8x4=32- por lo cual con un .word 0xdireccion, leeriamos los 4 bytes y editariamos todo facilmente.
Iniciado por eing
Bueno veo que poco a poco todos aportamos, para intentar lograr hacer esto...
Bueno, iré al grano...
Según mi "teoria" del primer post, podremos cambiar el mini, tan solo cambiando un byte, que ese CAMBIA cuando ponemos la bicicleta desde el menu -se refresca al seleccionarla- entonces.. me puse a pensar.
¿Cuando hacemos surf, de cualquier modo se "refresca" la pantalla?
¿Alguien podría copiar aquí el script de surf? -Si no cuando llegue a casa yo edito y lo coloco, ahí debe haber alguna "pista"-
-El que hacemos al hablar con el agua donde el movimiento permitido es "4"-
digo esto, porque al hacer surf, cambiamos el mini, y no se refresca la pantalla de alguna forma "fuera de lo comun -warp,fadescreen,flashes..etc.- asi que creo que ahí debe estar el secreto.
@Mariofan: Es cierto, la WRAM no se refresca, al entrar en un warp, por lo cual el byte colocado sigue igual..
@Trollfiud:Claro, pero en cuyo caso que usaramos ASM, habria que cargar tambien las paletas.. supongo =S -aun soy algo novato en asm-
@sonicarvalho: Tal vez eso del comportamiento byte del mini de "0B" tambien sirva para rubí, pero seria un problema, ya que siempre que "refresques" el menú, serias el otro mini.. aunque tal vez con un script -como el del gimnasio 2º de Hoenn se pueda hacer algo para evitar que se active el script mientras tu no quieras-
La tercera forma, la veo mas correcta, dado que seria con puro ASM y sería todo mas "limpio", simplemente cambiar los punteros, a donde apunta al mini actual, y poner otro puntero.
Ademas, los punteros son 32 bits, (AABBCCDD) -8x4=32- por lo cual con un .word 0xdireccion, leeriamos los 4 bytes y editariamos todo facilmente.
Lamento decirte eing que el script de surf no oculta ningun modo de refrescado en su sintaxis.
El cambio de mini se efectua mediante un doanimation(O era un setanimation? xD), pero el punto es que al poner ese comando, el player cambia y comienza a surfear.
Te lo digo, si de verdad deceas refrescar la pantalla si o si, deberas meterle al asm, bien sea como sugeri yo, o bien como dijo nuestro amigo sonicarvalho.
En fin, suerte con la investigacion!! :D
Hola! Esta vez traigo algo "útil" de verdad (nah, en realidad no va a servir de nada xD)
Bueno, resulta que después de investigar bastante he encontrado el lugar en la ram donde esta escrito el tileset en el que está el mini.
La dirección es esta: 0x6010000
Y el primer tile del mini es este: 0x6010040
Para verlo podéis usar el tileset viewer, con char base 0x6010000 y la barra de paleta a la izquierda del todo.
El problema es que estos bytes se actualizan cada frame, así que cambiarlos con wbto no sirve :(
Ah por cierto, también he investigado un poco el OAM, y he encontrado lo siguiente:
Si cuando estamos dentro del camión, abrimos el OAM viewer, encontraremos 3 objetos.
1 - Caja
2 - Caja
3 - Mini player
Sobre cada objeto nos da mas información, pero no da el offset de su casilla en el oam (que es como una tabla)
Y yo he encontrado 2 casillas, la de una caja y la del mini :)
Esta es la casilla del mini (en binario porque así está bit por bit)
--- [OBJ Attribute 0] [OBJ Attribute 1] [OBJ Attribute 2]
--- 00111000 10000000 01110000 10000000 00000000 00001000 ---
Segun esta (no censuréis el link) info, estos bits significan lo siguiente:
Mira pongo la casilla otra vez:
--- [OBJ Attribute 0] [OBJ Attribute 1] [OBJ Attribute 2]
--- 00111000 10000000 01110000 10000000 00000000 00001000 ---
Tenemos:
OBJ Attribute 0 - 00111000 10000000
00111000 - Y-Coordinate (0-255)
1 - Rotation/Scaling Flag
0 - Como el anterior es un 1, Double-Size Flag (0=Normal, 1=Double)
00 - OBJ Mode (0=Normal, 1=Semi-Transparent, 2=OBJ Window, 3=Prohibited)
0 - OBJ Mosaic (0=Off, 1=On)
0 - Colors/Palettes (0=16/16, 1=256/1)
00 - OBJ Shape (0=Square,1=Horizontal,2=Vertical,3=Prohibited)
OBJ Attribute 1 - 01110000 10000000
01110000 X-Coordinate (En esto la creo que info es erronea, la X tambien son 8 bits)
1 - Rotation/Scaling Flag
00000 - Rotation/Scaling Parameter Selection (0-31)
______(Selects one of the 32 Rotation/Scaling Parameters that
_______can be defined in OAM, for details read next chapter.)
00 - OBJ Size (0..3, depends on OBJ Shape, see Attr 0)
______Size Square Horizontal Vertical
______0 8x8 16x8 8x16
______1 16x16 32x8 8x32
______2 32x32 32x16 16x32
______3 64x64 64x32 32x64
OBJ Attribute 2 - 00000000 00001000
00000000 00 - Character Name (0-1023=Tile Number)
00 - Priority relative to BG (0-3; 0=Highest)
1000 - Palette Number (0-15) (Not used in 256 color/1 palette mode)
Lógicamente cada uno de los valores que hemos separado hay que convertirlo a decimal o hex según nuestras necesidades, siendo el valor de Y-Coordinate (00111000) 38 en hex y 56 en dec, o el Palette Number (1000) 8 en hex y dec.
Repito que de momento, haber sacado esto no me ha servido de nada, pero seguramente alguien lo pueda usar :)
Bye!
EDIT: Tengo el tema medio creado, mañana por la tarde la acabaré.
Bueno, resulta que después de investigar bastante he encontrado el lugar en la ram donde esta escrito el tileset en el que está el mini.
La dirección es esta: 0x6010000
Y el primer tile del mini es este: 0x6010040
Para verlo podéis usar el tileset viewer, con char base 0x6010000 y la barra de paleta a la izquierda del todo.
El problema es que estos bytes se actualizan cada frame, así que cambiarlos con wbto no sirve :(
Ah por cierto, también he investigado un poco el OAM, y he encontrado lo siguiente:
Si cuando estamos dentro del camión, abrimos el OAM viewer, encontraremos 3 objetos.
1 - Caja
2 - Caja
3 - Mini player
Sobre cada objeto nos da mas información, pero no da el offset de su casilla en el oam (que es como una tabla)
Y yo he encontrado 2 casillas, la de una caja y la del mini :)
Esta es la casilla del mini (en binario porque así está bit por bit)
--- [OBJ Attribute 0] [OBJ Attribute 1] [OBJ Attribute 2]
--- 00111000 10000000 01110000 10000000 00000000 00001000 ---
Segun esta (no censuréis el link) info, estos bits significan lo siguiente:
OBJ Attribute 0 (R/W)
Bit Expl.
0-7 Y-Coordinate (0-255)
8 Rotation/Scaling Flag (0=Off, 1=On)
When Rotation/Scaling used (Attribute 0, bit 8 set):
9 Double-Size Flag (0=Normal, 1=Double)
When Rotation/Scaling not used (Attribute 0, bit 8 cleared):
9 OBJ Disable (0=Normal, 1=Not displayed)
10-11 OBJ Mode (0=Normal, 1=Semi-Transparent, 2=OBJ Window, 3=Prohibited)
12 OBJ Mosaic (0=Off, 1=On)
13 Colors/Palettes (0=16/16, 1=256/1)
14-15 OBJ Shape (0=Square,1=Horizontal,2=Vertical,3=Prohibited)
OBJ Attribute 1 (R/W)
Bit Expl.
0-8 X-Coordinate (0-511)
When Rotation/Scaling used (Attribute 0, bit 8 set):
9-13 Rotation/Scaling Parameter Selection (0-31)
(Selects one of the 32 Rotation/Scaling Parameters that
can be defined in OAM, for details read next chapter.)
When Rotation/Scaling not used (Attribute 0, bit 8 cleared):
9-11 Not used
12 Horizontal Flip (0=Normal, 1=Mirrored)
13 Vertical Flip (0=Normal, 1=Mirrored)
14-15 OBJ Size (0..3, depends on OBJ Shape, see Attr 0)
Size Square Horizontal Vertical
0 8x8 16x8 8x16
1 16x16 32x8 8x32
2 32x32 32x16 16x32
3 64x64 64x32 32x64
OBJ Attribute 2 (R/W)
Bit Expl.
0-9 Character Name (0-1023=Tile Number)
10-11 Priority relative to BG (0-3; 0=Highest)
12-15 Palette Number (0-15) (Not used in 256 color/1 palette mode)
Mira pongo la casilla otra vez:
--- [OBJ Attribute 0] [OBJ Attribute 1] [OBJ Attribute 2]
--- 00111000 10000000 01110000 10000000 00000000 00001000 ---
Tenemos:
OBJ Attribute 0 - 00111000 10000000
00111000 - Y-Coordinate (0-255)
1 - Rotation/Scaling Flag
0 - Como el anterior es un 1, Double-Size Flag (0=Normal, 1=Double)
00 - OBJ Mode (0=Normal, 1=Semi-Transparent, 2=OBJ Window, 3=Prohibited)
0 - OBJ Mosaic (0=Off, 1=On)
0 - Colors/Palettes (0=16/16, 1=256/1)
00 - OBJ Shape (0=Square,1=Horizontal,2=Vertical,3=Prohibited)
OBJ Attribute 1 - 01110000 10000000
01110000 X-Coordinate (En esto la creo que info es erronea, la X tambien son 8 bits)
1 - Rotation/Scaling Flag
00000 - Rotation/Scaling Parameter Selection (0-31)
______(Selects one of the 32 Rotation/Scaling Parameters that
_______can be defined in OAM, for details read next chapter.)
00 - OBJ Size (0..3, depends on OBJ Shape, see Attr 0)
______Size Square Horizontal Vertical
______0 8x8 16x8 8x16
______1 16x16 32x8 8x32
______2 32x32 32x16 16x32
______3 64x64 64x32 32x64
OBJ Attribute 2 - 00000000 00001000
00000000 00 - Character Name (0-1023=Tile Number)
00 - Priority relative to BG (0-3; 0=Highest)
1000 - Palette Number (0-15) (Not used in 256 color/1 palette mode)
Lógicamente cada uno de los valores que hemos separado hay que convertirlo a decimal o hex según nuestras necesidades, siendo el valor de Y-Coordinate (00111000) 38 en hex y 56 en dec, o el Palette Number (1000) 8 en hex y dec.
Repito que de momento, haber sacado esto no me ha servido de nada, pero seguramente alguien lo pueda usar :)
Bye!
EDIT: Tengo el tema medio creado, mañana por la tarde la acabaré.
Iniciado por cosarara97
Hola! Esta vez traigo algo "útil" de verdad (nah, en realidad no va a servir de nada xD)
Bueno, resulta que después de investigar bastante he encontrado el lugar en la ram donde esta escrito el tileset en el que está el mini.
La dirección es esta: 0x6010000
Y el primer tile del mini es este: 0x6010040
Para verlo podéis usar el tileset viewer, con char base 0x6010000 y la barra de paleta a la izquierda del todo.
El problema es que estos bytes se actualizan cada frame, así que cambiarlos con wbto no sirve :(
Ah por cierto, también he investigado un poco el OAM, y he encontrado lo siguiente:
Si cuando estamos dentro del camión, abrimos el OAM viewer, encontraremos 3 objetos.
1 - Caja
2 - Caja
3 - Mini player
Sobre cada objeto nos da mas información, pero no da el offset de su casilla en el oam (que es como una tabla)
Y yo he encontrado 2 casillas, la de una caja y la del mini :)
Esta es la casilla del mini (en binario porque así está bit por bit)
--- [OBJ Attribute 0] [OBJ Attribute 1] [OBJ Attribute 2]
--- 00111000 10000000 01110000 10000000 00000000 00001000 ---
Segun esta (no censuréis el link) info, estos bits significan lo siguiente:
[quote]OBJ Attribute 0 (R/W)
Bit Expl.
0-7 Y-Coordinate (0-255)
8 Rotation/Scaling Flag (0=Off, 1=On)
When Rotation/Scaling used (Attribute 0, bit 8 set):
9 Double-Size Flag (0=Normal, 1=Double)
When Rotation/Scaling not used (Attribute 0, bit 8 cleared):
9 OBJ Disable (0=Normal, 1=Not displayed)
10-11 OBJ Mode (0=Normal, 1=Semi-Transparent, 2=OBJ Window, 3=Prohibited)
12 OBJ Mosaic (0=Off, 1=On)
13 Colors/Palettes (0=16/16, 1=256/1)
14-15 OBJ Shape (0=Square,1=Horizontal,2=Vertical,3=Prohibited)
OBJ Attribute 1 (R/W)
Bit Expl.
0-8 X-Coordinate (0-511)
When Rotation/Scaling used (Attribute 0, bit 8 set):
9-13 Rotation/Scaling Parameter Selection (0-31)
(Selects one of the 32 Rotation/Scaling Parameters that
can be defined in OAM, for details read next chapter.)
When Rotation/Scaling not used (Attribute 0, bit 8 cleared):
9-11 Not used
12 Horizontal Flip (0=Normal, 1=Mirrored)
13 Vertical Flip (0=Normal, 1=Mirrored)
14-15 OBJ Size (0..3, depends on OBJ Shape, see Attr 0)
Size Square Horizontal Vertical
0 8x8 16x8 8x16
1 16x16 32x8 8x32
2 32x32 32x16 16x32
3 64x64 64x32 32x64
OBJ Attribute 2 (R/W)
Bit Expl.
0-9 Character Name (0-1023=Tile Number)
10-11 Priority relative to BG (0-3; 0=Highest)
12-15 Palette Number (0-15) (Not used in 256 color/1 palette mode)
Mira pongo la casilla otra vez:
--- [OBJ Attribute 0] [OBJ Attribute 1] [OBJ Attribute 2]
--- 00111000 10000000 01110000 10000000 00000000 00001000 ---
Tenemos:
OBJ Attribute 0 - 00111000 10000000
00111000 - Y-Coordinate (0-255)
1 - Rotation/Scaling Flag
0 - Como el anterior es un 1, Double-Size Flag (0=Normal, 1=Double)
00 - OBJ Mode (0=Normal, 1=Semi-Transparent, 2=OBJ Window, 3=Prohibited)
0 - OBJ Mosaic (0=Off, 1=On)
0 - Colors/Palettes (0=16/16, 1=256/1)
00 - OBJ Shape (0=Square,1=Horizontal,2=Vertical,3=Prohibited)
OBJ Attribute 1 - 01110000 10000000
01110000 X-Coordinate (En esto la creo que info es erronea, la X tambien son 8 bits)
1 - Rotation/Scaling Flag
00000 - Rotation/Scaling Parameter Selection (0-31)
______(Selects one of the 32 Rotation/Scaling Parameters that
_______can be defined in OAM, for details read next chapter.)
00 - OBJ Size (0..3, depends on OBJ Shape, see Attr 0)
______Size Square Horizontal Vertical
______0 8x8 16x8 8x16
______1 16x16 32x8 8x32
______2 32x32 32x16 16x32
______3 64x64 64x32 32x64
OBJ Attribute 2 - 00000000 00001000
00000000 00 - Character Name (0-1023=Tile Number)
00 - Priority relative to BG (0-3; 0=Highest)
1000 - Palette Number (0-15) (Not used in 256 color/1 palette mode)
Lógicamente cada uno de los valores que hemos separado hay que convertirlo a decimal o hex según nuestras necesidades, siendo el valor de Y-Coordinate (00111000) 38 en hex y 56 en dec, o el Palette Number (1000) 8 en hex y dec.
Repito que de momento, haber sacado esto no me ha servido de nada, pero seguramente alguien lo pueda usar :)
Bye![/quote]
Fuck, habia escrito una parrafada y se me ha borrado .__.'
Iré al grano, esta investigacion que has realizado cosara, es MUY interesante, por lo cual creo que debería tener su tema aparte, ya que gracias a los datos que nos has facilitados, sacados de las "casillas" de la tabla del OAM, podremos hacer cantidades de cosas, de hecho el mitico "FOLLOWME" se hace mediante la informacion extraida del OAM, ya que nos muestra muchas cosas..
Eso si, cosara, cuando postees tu tema, informanos, de varias cosas que se te han olvidado, y dudas que al leerlo, se me han planteado -pero que está muy bien explicado-
¿De donde has sacado esas "casillas", Del "ROM" o de la "RAM"?
Porque dependiendo donde estén son más faciles de editar o menos, por ende, si están en la ram, tal vez sean dinámicas, ya que pude observar en el OAM, que el primer minisprite que carga, dpende de la coordenada que estés, y de los minis que haya on screen, pero bueno aun se deberia investigar más...
Y la otra duda es, ¿Cómo has logrado encontrar dichas casillas?
Para así en el futuro tema que crees, podamos todos ayudar, mostrando las distintas casillas.
------------------
Por otro lado, referente al "tileset" donde se ubica el mini, la direccion 06010000, he estado observandolo y no he encontrado nada interesante, tal vez sea que no lo he hecho a fondo, pero no he encontrado ninguna rutina que cargue el mini ni nada por el estilo.
Lo único que he encontrado, ha sido dos cosas.
1)Que el rom interpreta los colores invisibles como "00", ya que si te fijas la primera "casilla" es toda de color invisible, y si vas a mirarlo encontrarás puro "00".
En cambio cuando se haya un píxel que no es color invisible, te sale un byte, que no es "00", no sé si será el equivalente al color o qué, pero lo que sé es que variará en cada rom, puesto que no todos los minis ocupan el mismo espacio..
2)Que la carga "Real" del mini, dependerá del tamaño de este, puesto que ahí se mostrarán los bytes que cambiarán, además dependiendo del frame en el que esté.
Buena aportacion, y como te dije creo que debería tener su propio tema, así tal vez quien sabe, poder hacer o intentar hacer nuestro propio followme... u más investigaciones referente a ello.
PD: Mientras tanto, creo que seguiré buscando alguna forma de evitar que se pulse el pause, cuando hay otro mini que no sea el del sexo femenino, o puede que busque la forma de hacer un warp, pero sin efectos, para que se cargue de nuevo todo en la ram, y se refresque, menos donde hicimos el cambio de ese byte, ya que no cambia...
PD2: O tal vez busque la rutina, nosé.. haha ultimamente ando liado investigando otras cosas D:
Hacía tiempo que no me pasaba por aquí.. haha
Igualmente, traigo la solución "mas" sencilla para que cuando hagamos un cambio de mini, no se note casi el warp, ni ningun efecto.
Dejaré un manual de scripts de nivel por si acaso alguien no sabe, o no se acuerda..
(manual scripts de nivel)
Primero haremos nuestro script.
#org 0xoffset
checkflag 0x1200
if 0x1 goto 0xoffset_vacio
//Sucesos del script (Aquí pongan el suceso del script..)
fadescreen 0x1
writebytetooffset 0x1 0x02024EAC
setvar 0x40FE 0x1
warp2 0xbanco 0xmapeado 0xwarp 0x0 0x0
//O warpmuted.. vamos, que habreis de usar el warp silencioso, y colocar el warp en el mapa JUSTO en la coordenada, donde estabamos al usar el warp, y también dejar el escenario, tal y como estaba justo antes del warp.
(Hacia donde miraba el personaje, hacia donde te miraba la otra persona, la gente de alrededor..etc. y en caso de que el pj esté mirando a un lugar que no sea "abajo", debereis llevar el warp, realmente a una zona totalmente oscura -para que aun parezca que está en el fadescreen- y usar un applymovement para que mire al lado que miraba antes de usar el warp, seguido de esto, por ultimo un movimiento de camara instantaneo hacia el lugar donde se ejecutaba el script, para poder continuar con él.
Despues de haberse ejecutado este script, actuará el warp, y nos enviará al mismo lugar a donde estabamos antes, y aquí entra en accion el script de nivel, que ha de ser"Validates values, loads handler to 0x03000EB0".
Dicho script, estará configurado en el AM para que se ejecute siempre y cuando la variable 40FE sea 1, y como la hemos activado antes por el script de gatillo/persona, ahora se ejecutará, tras el paso del warp.
Entonces pasemos al contenido del script despues del warp, que no será otro que la continuacion del script.
Sería algo asi...
#org 0xscript
//Sucesos
setvar 0x40FE 0x2
setflag 0x1200
end
Y una vez echo esto, habremos realizado nuestro cambio de personaje, sin tiempos de espera apenas, decimas de segundo si me apuras, ya que despues del warp, ejecuta otro script, que será la continuacion, y de paso usamos el fadescreen, para simular que se ha cambiado la ropa.
Aclaraciones:
-Solo vale para Rubi ING.
-Los scripts no están completos, has de completarlos tú, yo solo he puesto lo esencial, para cambiar el minisprite y que continue el script como tal, luego la trama del script es cosa tuya...
-Los // son comentarios, dentro del script, asi que cuando copien la estructura básica del script, estos // borrenlos.
-Si, sigo usando el sistema de scripting del primer XSE (donde estaban los callstd) y no uso los famosos #dynamic o como se digan.
Saludos y cualquier duda preguntenla por perfil o MP.
Igualmente, traigo la solución "mas" sencilla para que cuando hagamos un cambio de mini, no se note casi el warp, ni ningun efecto.
Dejaré un manual de scripts de nivel por si acaso alguien no sabe, o no se acuerda..
(manual scripts de nivel)
Primero haremos nuestro script.
#org 0xoffset
checkflag 0x1200
if 0x1 goto 0xoffset_vacio
//Sucesos del script (Aquí pongan el suceso del script..)
fadescreen 0x1
writebytetooffset 0x1 0x02024EAC
setvar 0x40FE 0x1
warp2 0xbanco 0xmapeado 0xwarp 0x0 0x0
//O warpmuted.. vamos, que habreis de usar el warp silencioso, y colocar el warp en el mapa JUSTO en la coordenada, donde estabamos al usar el warp, y también dejar el escenario, tal y como estaba justo antes del warp.
(Hacia donde miraba el personaje, hacia donde te miraba la otra persona, la gente de alrededor..etc. y en caso de que el pj esté mirando a un lugar que no sea "abajo", debereis llevar el warp, realmente a una zona totalmente oscura -para que aun parezca que está en el fadescreen- y usar un applymovement para que mire al lado que miraba antes de usar el warp, seguido de esto, por ultimo un movimiento de camara instantaneo hacia el lugar donde se ejecutaba el script, para poder continuar con él.
Despues de haberse ejecutado este script, actuará el warp, y nos enviará al mismo lugar a donde estabamos antes, y aquí entra en accion el script de nivel, que ha de ser"Validates values, loads handler to 0x03000EB0".
Dicho script, estará configurado en el AM para que se ejecute siempre y cuando la variable 40FE sea 1, y como la hemos activado antes por el script de gatillo/persona, ahora se ejecutará, tras el paso del warp.
Entonces pasemos al contenido del script despues del warp, que no será otro que la continuacion del script.
Sería algo asi...
#org 0xscript
//Sucesos
setvar 0x40FE 0x2
setflag 0x1200
end
Y una vez echo esto, habremos realizado nuestro cambio de personaje, sin tiempos de espera apenas, decimas de segundo si me apuras, ya que despues del warp, ejecuta otro script, que será la continuacion, y de paso usamos el fadescreen, para simular que se ha cambiado la ropa.
Aclaraciones:
-Solo vale para Rubi ING.
-Los scripts no están completos, has de completarlos tú, yo solo he puesto lo esencial, para cambiar el minisprite y que continue el script como tal, luego la trama del script es cosa tuya...
-Los // son comentarios, dentro del script, asi que cuando copien la estructura básica del script, estos // borrenlos.
-Si, sigo usando el sistema de scripting del primer XSE (donde estaban los callstd) y no uso los famosos #dynamic o como se digan.
Saludos y cualquier duda preguntenla por perfil o MP.
Bien, 1 año después de mi post en este tópico... En esa altura, yo no sabia tanto de ASM comparado con el que sé hoy, aún no tenia descubierto safari ni nadie de ese tipo!
BIEN, sin mas charlas............
Hoy os trago el que tanto quieren! El cambio de OW!
Mientras estudiando el comando 'Show Sprite', descubrí en la RAM donde esta el offset del gráfico del player... Pero no es bien el offset del grafico, es algo mas como el "Animation pointer"... Pero que es esto? Bien, vosotros sabeis que hay 250 personas o así en ruby, y en NSE/OW editor, cada OW tiene 'FRAMES'. Es a eso que me refiero!
Entonces, como cambiar?
El offset es 02020010! En ese offset esta el animation pointer. Para aquellos que no me perciben, aquí esta una imagen:
Como pueden ver, ese pointer es el 'Pointer 3' del NSE. Como cambiar?
SIMPLE: En NSE, busquen un sprite cualquier, y sustituyan ese pointer en la ram por el 'pointer 3' del sprite que eligieron, utilizando un WriteByteToOffset.
Pero hagamos un teste:
Sustituyan ese pointer (0836e050) por 0836f248. Verán que el player se transforma en Prof Birch!
Bien, por ahora es todo ;)
Saludos!
Gracias por tu corrección Eing!:D
BIEN, sin mas charlas............
Hoy os trago el que tanto quieren! El cambio de OW!
Mientras estudiando el comando 'Show Sprite', descubrí en la RAM donde esta el offset del gráfico del player... Pero no es bien el offset del grafico, es algo mas como el "Animation pointer"... Pero que es esto? Bien, vosotros sabeis que hay 250 personas o así en ruby, y en NSE/OW editor, cada OW tiene 'FRAMES'. Es a eso que me refiero!
Entonces, como cambiar?
El offset es 02020010! En ese offset esta el animation pointer. Para aquellos que no me perciben, aquí esta una imagen:
Como pueden ver, ese pointer es el 'Pointer 3' del NSE. Como cambiar?
SIMPLE: En NSE, busquen un sprite cualquier, y sustituyan ese pointer en la ram por el 'pointer 3' del sprite que eligieron, utilizando un WriteByteToOffset.
Pero hagamos un teste:
Sustituyan ese pointer (0836e050) por 0836f248. Verán que el player se transforma en Prof Birch!
Bien, por ahora es todo ;)
Saludos!
Iniciado por eing
Solo se realiza con exito si el mini tiene la misma paleta.. Si no te sale con las paletas mal...
Para arreglar eso has de buscar las paletas del nuevo mini en al ram, y substituirlas por las viejas...
Pd. Al entrar a cada mapa habrias de colocar un script de nivel haciendo de nuevo el cambio de mini y paletas -encaso de que fuese necesario-
Saludos!!
Gracias por tu corrección Eing!:D