Thread Id: 15581
Thread Name: La mejor opción para trabajar en un rom

Querría saber cual es la mejor forma de trabajar en un rom en un grupo, porque por ejemplo, si hay bastantes mienbros, no todos pueden estar al mismo tiempo en el hack, o eso creo.

Quería saber cual es la mejor forma de trabajar y pasar scripts (?) si esque se puede hacer.
gracias:D

Pues no sé xd. Eso depende de como os organizeis. Lo que yo siempre he hecho es hacer primero la base, (Pokemons insertados, y tiles) Y luego empezar con los mapas y los scripts.
Pero eso depende de los horarios que tengais, lo que querais cambiar, etc...
Cada cual va a su paso y a su ritmo.

A ver, cuando se hace algo en grupo lo más importante siempre es la comunicación.
Lo mejor es tener un sistema de chat y uno "persistente" (sí, seguro que hay una palabra más apropiada).
Chat:
Aquí a todo el mundo le gusta el MSN Messenger, no se porqué (a mi no, en realidad solo tengo MSN Messenger por wah). Es una opción. Otra más interesante es el IRC, podeis abrir un canal en un servidor cualquiera y ya está.
Sistema persistente:
Podeis usar simples MPs, pero yo optaría por el clásico email. Si enviais los mensajes a todo el equipo puede serviros para manteneros al día sobre lo que haceis unos y otros, además de poder adjuntar IPS.
Un foro también puede servir, pero puede que sea demasiado.

También es muy importante que todo el grupo sepa que hay que hacer en cada momento, así que podeis tener a alguien que se encargue de organizar.

Yo creé un grupo en MSN en el que añadí a todos los participantes en el Amatista.. además de tener a Jose en Skype, que es bastante más útil y rápido que usar cualquier método de texto.

Luego para realizar, creo que lo mejor es irse turnando. Otros dejan los scripts para el final, otros los gráficos... En mi equipo por ejemplo el hack suele seguir este orden : Zekro > Yo > ReoNeky
El método de parches es efectivo pero solo con ciertas cosas.

¡Ah! otra cosa muy importante, aseguraos TODOS de tener el mismo Pokémon Rubí, para que si tenéis que trabajar juntos en una cosa, investigar o algo así, no haya confusiones.

Soy de opinion de Cosarara. Solo tengo MSN por WaH. Y también Deryko, Skype es mucho más eficiente que cualquier método de texto.

Pero bueno, mí idea es muy compleja, pero aí va...
tener la rom en un servidor, y asignar ese servidor a un camino de red en vuestros ordenadores.
Programas como XSE, HxD, las tools hechas por GUT/Mariofan, UNlz gba no necesitan la rom siempre abierta, así que podrian estar haciendo scripts mientras otro podría estar insertando gráficas en la rom al mismo tiempo, en la misma rom.

No me preguntáis como hacerlo, porque yo no sé, solo sé que es posible hacerlo.

Saludos

Iniciado por Sonicarvalho
Soy de opinion de Cosarara. Solo tengo MSN por WaH. Y también Deryko, Skype es mucho más eficiente que cualquier método de texto.

Pero bueno, mí idea es muy compleja, pero aí va...
tener la rom en un servidor, y asignar ese servidor a un camino de red en vuestros ordenadores.
Programas como XSE, HxD, las tools hechas por GUT/Mariofan, UNlz gba no necesitan la rom siempre abierta, así que podrian estar haciendo scripts mientras otro podría estar insertando gráficas en la rom al mismo tiempo, en la misma rom.

No me preguntáis como hacerlo, porque yo no sé, solo sé que es posible hacerlo.

Saludos

Servidor CIFS + Sistema de backups automatizado podría funcionar, pero podría haber problemas dependiendo de como funcionan las herramientas.
Imaginemos una herramienta que trabaja de la siguiente forma:

• Al "abrir" un ROM, lo que hacemos es cargar ese ROM en RAM, y leer unas variables.
  
• Después de modificar esas variables, guardamos. Cuando guardamos, la parte que no hemos modificado se lee de esa copia que tenemos en RAM y se junta todo en un ROM nuevo, que sustituye al viejo.
  

No se que métodos usan otras herramientas para modificar un byte (las herramientas escritas en C seguro que lo hacen de otro modo), pero el que uso yo en las mías es el siguiente:
A = (todo lo que hay antes del byte)
B = (todo lo que hay después del byte)
NuevoROM = A + NuevoByte + B
Así que si, al contrario de lo que hace, por ejemplo, mi compilador, una herramienta al "abrir" un ROM no solo coge el camino hacia el archivo si no que carga realmente el ROM, podría haber problemas del tipo:
A abre el ROM
B abre el ROM
B hace sus cambios y guarda
A acaba sus cosas y también guarda
Y los cambios de B han mágicamente desaparecido.

Así que no se exactamente como funciona Unlz, pero el único método "bueno" sería el siguiente:
Al abrir el ROM cargar todos los sprites.
Al guardar un cambio re-leer el ROM, escribir el cambio (usando como base el ROM que acaba de leer) y cargar otra vez los sprites.

En realidad el único problema que tenemos aquí es que trabajamos con binarios. Si no fuera así, cualquier sistema de control de versiones como git o svn nos serviría.