AssetGuy

assetguy library lee la base configurada. assetguy sync la actualiza; assetguy search consulta el catálogo público de Fab; assetguy download obtiene archivos. Esto explicita el coste de cada acción. assetguy add exige los archivos en caché y, cuando faltan, indica el comando de descarga en lugar de transferir gigabytes silenciosamente.

Las URL de miniaturas llegan con los metadatos, pero descargar imágenes es opcional: el terminal no las dibuja y una biblioteca puede contener gigabytes de imágenes. La CLI permite estabilizar el comportamiento antes de que una GUI dependa de él.

El catálogo puede quedar desactualizado entre sincronizaciones. Acepté ese compromiso para que consultar tenga un coste previsible e independiente del marketplace. Los metadatos ausentes siguen visibles: una lista vacía no demuestra que no existan assets compatibles.

La biblioteca poseída, los detalles públicos, la búsqueda y la CDN de Fab tienen requisitos de autenticación distintos. Un cliente HTTP autenticado genérico trasladaría supuestos incorrectos entre rutas. El contrato describe operaciones: compras, detalle de listing, autenticación y entrega.

Los roles y capacidades separados permiten nombrar una operación sin soporte. Fab es el provider implementado hoy. El límite de la descarga es DownloadPlan: el provider convierte su manifiesto en un plan; obtención y ensamblado usan ese plan sin depender de los tipos de la API de Epic.

Esta frontera permite probar los flujos sin detalles HTTP y concentra los cambios de la API Fab en su provider. Todavía no demuestra soporte para otra tienda: un segundo provider deberá cumplir esos contratos con sus propios casos reales.

SQLite es la opción sin configuración; PostgreSQL ya está implementado. El backend elegido guarda catálogo, clasificación y estado de descargas/instalaciones. Cuatro roles limitan el acceso: AssetStore, CatalogWriteStore, CurationStore y DownloadStore. Una descarga no necesita reescribir categorías.

Los contratos de almacenamiento usan llamadas síncronas acordes con el driver SQLite bloqueante; las operaciones de red y provider son asíncronas. El SQL específico pasa por un límite de dialecto. El backend es configuración persistente; una conexión inválida falla explícitamente sin abrir otra biblioteca. Cambiar de banco no migra los datos existentes.

SQLite es el valor predeterminado para que el uso individual no requiera administrar un servidor. PostgreSQL aporta un catálogo común con el coste de conexiones, credenciales y operación del banco. Compartir metadatos y rutas no pone los archivos a disposición de otras máquinas; requiere la caché compartida aún no implementada.

Las categorías propias expresan reglas en lugar de un conjunto fijo de etiquetas. Los nuevos assets sincronizados pueden entrar automáticamente en esa organización. Versión del motor, formato, categoría de tienda y estado de caché son filtros distintos.

Las versiones Unreal se comparan por componentes: UE4.1 no debe significar UE4.10. Motor y formato permanecen separados; un formato Unity no implica que Fab proporcione versiones de Unity. Los metadatos ausentes y la cobertura parcial se informan para no confundir resultados vacíos con conocimiento completo del marketplace.

Sync obtiene primero la lista poseída, cuya paginación por cursor es secuencial. Después enriquece los assets con workers paralelos limitados. El presupuesto de peticiones controla la presión sobre la API sin presentarse como porcentaje del ancho de banda.

La lista poseída usa la sesión de la cuenta; los detalles públicos usan un cliente anónimo según el comportamiento observado de la API. Un listing retirado puede seguir siendo poseído y descargable; un tamaño ausente es desconocido, no cero. Inspeccionar el manifiesto permite conocer por separado los tamaños Unreal.

Las descargas obtienen chunks en paralelo pero ensamblan archivos con un writer ordenado, calculando SHA1 durante la escritura. Los archivos terminados y verificados forman el estado de reanudación; la identidad del manifiesto evita mezclar builds. Los archivos salen del directorio parcial al terminar.

Los chunks reutilizados tienen una caché de memoria limitada. El plan conoce el orden de escritura y descarta el chunk cuyo próximo uso está más lejano. Una recuperación adicional ocasional permite un techo de memoria previsible sin almacenar dos veces el asset completo en disco.

La escritura ordenada simplifica verificación y reanudación, pero puede esperar un chunk retrasado aunque otros ya hayan llegado. El límite de caché puede exigir volver a obtener un chunk. La decisión prioriza integridad y memoria previsible frente a maximizar el paralelismo a cualquier coste.

Los packs de contenido van a Content; los proyectos completos se copian como proyectos; los plugins siguen las rutas del manifiesto. Dry run permite inspeccionar la acción y las colisiones requieren force explícito. Las copias se preparan en el volumen de destino; el staging del motor queda fuera del scanner de plugins.

La instalación exige la raíz exacta de un motor registrado. Los archivos preceden a los registros del launcher: manifiesto, item, lista de instalaciones y EOSH se mantienen. Copias de respaldo y relectura protegen la lista. El launcher debe estar cerrado porque puede reescribir esos archivos desde su estado en memoria.

Instalar contenido en un proyecto y un plugin en un motor afecta a estructuras distintas. Los comandos separados hacen explícitos el destino y el efecto. Los registros del launcher son la integración más sensible: copiar la carpeta no basta para que la herramienta Epic reconozca instalación y eliminación.

La configuración está en el perfil itinerante; credenciales OAuth, caché y auditoría en el local. El login usa el navegador y devuelve un código ocultado en la auditoría según la identidad del comando. Las contraseñas del banco se proporcionan por separado de la URL almacenada.

El estado del launcher es de solo lectura para consulta y sincronización. install, uninstall y repair son las excepciones explícitas que escriben sus registros. La auditoría mensual local registra operaciones; doctor expone problemas de integridad sin pedir al desarrollador que invente consultas de diagnóstico.