traduccion Megaman Star Force 3

Yo no se como se hace eso, pero alguien sabe donde se puede encontrar un programa para desempaquetarlos

El programa no existe, así que tendrá que hacerse.

anonimeitor escribió:El programa no existe, así que tendrá que hacerse.

Ay... es que me ponen un formato tan estúpido delante que me da cosa no hacer el plugin...
El caso, si queréis extraer los archivos usad esta versión de Tinke:
http://dl.dropbox.com/u/3981393/Tinke/T ... v129-1.zip

En caso de que esto avance, o alguien se decida pues me lo decís y hago la segunda parte para comprimir los archivos (que ahora tengo sueño)

Por cierto Anonimeitor, he probado a decodificar algunos archivos que tienen la compresión LZX (LZ11 o Yaz0) y he encontrado que tanto la herramienta que usa Tinke (que próximamente será la tuya) y la tuya dan un error al descomprimir dos archivos (a lo mejor hay más pero mi pereza ha hecho que solo pruebe con los archivos que están en /datbin/com/title.bin), aquí te dejo los dos archivos en cuestión, el error que se obtiene con tu programa es este:

WARNING: unexpected end of encoded file!

http://dl.dropbox.com/u/3981393/Tinke/L ... oblems.zip

En teoría ese mensaje se muestra porque la longitud descomprimida no coincide con la indicada en el fichero, pero eso no significa que esté mal, de ahí que se muestre como "WARNING" y no como "ERROR". La diferencia es que la advertencia te genera el fichero comprimido y el error no. Seguramente algún byte de más o menos en los bytes que guardan la longitud y que no afectan en nada, pero luego lo miro con más calma para asegurarme. También habría que mirar si los ficheros se usan o no, que no sería la primera vez que me encuentro con ficheros basura que te hacen perder el tiempo y al final no son más que simples ficheros residuales cortados que no valen para nada, aunque no creo que sea el caso.

~~~ AÑADIDO ~~~
Pues a simple vista se ve el problema, que no lo es. La longitud indicada en los ficheros, bytes 1-2-3, es de 0x00C000 (49152 bytes) pero en realidad debería ser de 0x004391 (17297 bytes). Tiene toda la pinta de que lo han alineado a un múltiplo de 0x4000 por equivocación.

Si descomprimes el fichero y vuelves a comprimirlo te queda idéntico al original. La única diferencia es la longitud almacenada en la cabecera y que los originales que me has pasado tienen un byte más porque están alineados a 0x4000, curiosamente como el valor equivocado de la longitud almacenada. No puede ser casualidad, así que me inclino a pensar que es un bug tonto. OJO, que también puede ser que el fichero esté cortado, pero eso es algo que ya no puedo saber, y la longitud real sí sea de 0x00C000.

Ya me debes 3 cerveza más

~~~ MÁS AÑADIDO ~~~
¡¡¡So melón!!! Los ficheros están cortados. En realidad son dos ficheros idénticos, que extraídos deben ocupar 0xB794 bytes, y se descomprimen sin ningún tipo de advertencia.

Para sacarlos, sin descomprimir:

Código: Seleccionar todo

  // aquí se debe tener:
  // - buffer <--- fichero en memoria, unsigned char
  // - length <--- longitud del fichero, unsigned int
  // total, pos, len, i <-- unsigned int

  total = *(unsigned int *)buffer >> 3;
  for (i = 0; i < total; i++) {
    pos = *(unsigned int *)(buffer + 8 * i);
    len = i < total - 1 ? *(unsigned int *)(buffer + 8 * (i + 1)) : length;
    len -= pos;
    // aquí se graba el fichero, 'len' bytes a partir de 'buffer + pos'
    // Save(i, buffer + pos, len);
  }

(el último fichero sobra, pero es la costumbre de hacer todo en medio minuto)

Ya son otras 3 cerveza más

Joder, tienes razón, yo y mi afán de hacer las cosas rápido y sin probar. Para quitarle el bit que indica la compresión le hacía un AND con 7FFF, cuando al ser un uint es con 7FFFFFF... Bueno como extra por equivocarme, incorporo la función para comprimir. Si hay cualquier error decídmelo, que últimamente estoy que no doy una.

Descarga: http://dl.dropbox.com/u/3981393/Tinke/T ... v129-3.zip

Si al final me daréis la razón y dejaréis de beber cuando estéis delante del ordenador . Que lo haga yo, vale, que soy un alcohólico empedernido y soy de los que va a las reuniones de romhackers anónimos a decir eso de "Hola, me llamo CUE, y soy 'romjaker'" (¿por qué narices se llaman "anónimos" si luego van todos y se identifican?)

No te aconsejo hacer un AND 0x7FFFFFFF porque en teoría se usa todo el byte superior para indicar la compresión. Piensa que en el fichero comprimido el tamaño se almacena en 3 bytes, que son los que deben coincidir con los del BIN, dejando el restante para indicar la compresión, aunque creo que no se usa más que el bit superior para ello. Habría que mirar el código para asegurarse, pero además de alcohólico soy un vago, así que ...

Justo ahora iba a mandarte por privado lo que tengo, pero he recibido el correo indicando que ya habías escrito y veo que ya lo tienes hecho. Por si sirve para alguien, aquí van las cuatro líneas que hacen todo, reducidas a la mínima expresión (ya no necesito ni el total):

Código: Seleccionar todo

  for (i = 0; ; i++) {
    pos = *(unsigned int *)(buffer + 8 * i);
    if (!(len = *(unsigned int *)(buffer + 8 * i + 4))) break;

    if (len >> 24) len = *(unsigned int *)(buffer + 8 * (i + 1)) - pos;

    // aquí se graba el fichero, 'len' bytes a partir de 'buffer + pos'
    // Save(i, buffer + pos, len);
  }

Si se quiere, se puede controlar que el fichero sea un BIN correcto para la extracción poniendo al principio un par de líneas más (ahora sí se necesita el total y la longitud del fichero):

Código: Seleccionar todo

  total = *(unsigned int *)buffer >> 3;
  if (*(unsigned int *)(buffer + 8 * (total - 1)) != length) EXIT("El fichero no es un BIN válido");

Esto comprueba que el último offset coincida con el tamaño del fichero, lo que indicaría que el fichero es válido. El 'total' realmente no me sirve para nada porque se sabe que no hay más datos con el último offset, que lleva una longitud de cero, aunque siempre queda bonito poner cosas para rellenar, que así da la impresión que hacemos más (¡Ahhh, si la gente supiera lo poco que hacemos y el color que le damos!)