Por qué el pack crece tras el Escrow
Respuesta rápida
No existe una cifra publicada de cuánto cambia Asset Escrow el tamaño de un resource. Cualquier afirmación del tipo "el escrow agrega X%" es inventada. Lo que sigue separa lo que Cfx documenta, lo que la gente observa, y lo que podría explicar la diferencia.
Dificultad: Avanzado · Afecta a: LEGACY · Evidencia mixta — lee las etiquetas
Info
Búsqueda: tamaño con escrow, más grande después del escrow, 40%, creció, overhead, compresión, por qué pesa más.
Verificado por última vez el 31 de agosto de 2026 · Cfx Asset Escrow · FAQ de desarrolladores de Cfx.
Hecho confirmado
Esto viene de la documentación de Cfx:
- Subes un resource zipeado. Se procesa para encriptarlo y se te devuelve como un asset con escrow.
- Los tipos que se encriptan son Lua, YFT, YDD, YDR. Los YTD, YMT y
.metano se encriptan. - Se agrega un archivo
.fxapal resource y hay que conservarlo. - El tamaño máximo de un asset con escrow es 1 GB.
- Volver a subir reemplaza la versión en tu cuenta; los clientes que ya descargaron una versión más vieja se la quedan.
Cfx nunca publicó un porcentaje de overhead, una especificación de compresión, ni una garantía de tamaño antes/después.
Comportamiento observado
Reportado por creadores y dueños de servidores, no verificado por nosotros:
- El número que la gente compara suele no ser el mismo número dos veces: el tamaño de la carpeta fuente, el del zip que se sube, el del asset descargado y el de la caché en disco son cuatro medidas distintas.
- Los archivos encriptados se comprimen peor que los originales, así que el zip de un resource con escrow puede pesar más que el zip del mismo sin escrow aunque el contenido descomprimido sea parecido.
- Los packs dominados por texturas YTD — que nunca se encriptan — muestran menos diferencia que los packs dominados por modelos YDD, que sí se encriptan.
Explicación posible
Razonamiento, no documentación. Tómalo como hipótesis:
| Efecto | Por qué cambiaría el tamaño |
|---|---|
| Padding de encriptación | La encriptación por bloques redondea cada archivo hacia arriba hasta el límite del bloque |
| Pérdida de compresión | Los bytes encriptados son prácticamente aleatorios y no se comprimen |
| Metadata agregada | El .fxap y las cabeceras de escrow por archivo |
| Reempaquetado | El archivo comprimido se reconstruye, posiblemente con otros ajustes de compresión que los tuyos |
Nada de esto está confirmado por Cfx, y el peso relativo de cada factor es desconocido.
Qué hacer al respecto
Mide tus propios packs en lugar de confiar en un porcentaje:
- Anota el tamaño de la carpeta fuente descomprimida.
- Anota el tamaño del zip que subes.
- Descarga el asset procesado y anota el tamaño de su zip.
- Descomprímelo y anota el tamaño en disco.
Compara lo comparable entre versiones de tus propios packs. Eso te da un número real de planificación para el techo de 1 GB, que es el único lugar donde esto importa de verdad.
Advertencia
No publiques un porcentaje de overhead a tus clientes como si fuera una especificación de Cfx. Si necesitas decir algo, di el método de medición y el pack del que salió.