AssetGuy

assetguy library lit la base configurée. assetguy sync la met à jour ; assetguy search consulte le catalogue public Fab ; assetguy download récupère les fichiers. Cela explicite le coût de chaque action. assetguy add exige les fichiers en cache et, s’ils manquent, indique la commande de téléchargement au lieu de transférer silencieusement des gigaoctets.

Les URL des vignettes arrivent avec les métadonnées, mais télécharger les images reste facultatif : un terminal ne les affiche pas et une bibliothèque peut en contenir des gigaoctets. La CLI permet de stabiliser le comportement avant qu’une GUI en dépende.

Le catalogue peut devenir obsolète entre synchronisations. J’ai accepté ce compromis pour rendre le coût des requêtes prévisible et indépendant de la disponibilité du marketplace. Les métadonnées absentes restent visibles : une liste vide ne prouve pas qu’aucun asset compatible n’existe.

Bibliothèque possédée, détails publics, recherche et CDN de Fab ont des exigences d’authentification différentes. Un client HTTP authentifié générique transporterait de mauvaises hypothèses entre ces routes. Le contrat décrit plutôt des opérations : achats, détail d’un listing, authentification et livraison.

Les rôles et capacités séparés permettent de nommer une opération non prise en charge. Fab est le provider implémenté aujourd’hui. La frontière du téléchargement est DownloadPlan : le provider traduit son manifeste en plan ; récupération et assemblage utilisent ce plan sans dépendre des types de l’API Epic.

Cette frontière permet de tester les parcours sans les détails HTTP et concentre les changements de l’API Fab dans son provider. Elle ne prouve pas encore le support d’une autre boutique : un second provider devra satisfaire ces contrats sur ses propres cas réels.

SQLite est le choix sans configuration ; PostgreSQL est déjà implémenté. Le backend choisi conserve catalogue, classement et état des téléchargements/installations. Quatre rôles limitent les accès : AssetStore, CatalogWriteStore, CurationStore et DownloadStore. Un téléchargement n’a pas besoin de réécrire les catégories.

Les contrats de stockage utilisent des appels synchrones adaptés au driver SQLite bloquant ; les opérations réseau et provider sont asynchrones. Le SQL spécifique passe par une frontière de dialecte. Le backend est une configuration persistante ; une connexion invalide échoue explicitement sans ouvrir une autre bibliothèque. Changer de base ne migre pas les données existantes.

SQLite est le défaut pour éviter l’administration d’un serveur en usage individuel. PostgreSQL apporte un catalogue commun au prix de connexions, identifiants et exploitation du serveur. Partager métadonnées et chemins ne rend pas les fichiers accessibles sur d’autres machines ; cela demande le cache partagé encore absent.

Les catégories personnelles expriment des règles plutôt qu’un ensemble figé de tags. Les nouveaux assets synchronisés peuvent rejoindre automatiquement ce classement. Version du moteur, format, catégorie du marketplace et état du cache sont des filtres distincts.

Les versions Unreal sont comparées par composants : UE4.1 ne doit pas signifier UE4.10. Moteur et format restent distincts ; un format Unity n’implique pas des versions Unity fournies par Fab. Métadonnées absentes et couverture partielle sont signalées, évitant de confondre un résultat vide avec une connaissance complète du marketplace.

Le sync récupère d’abord la liste possédée, dont les curseurs imposent une pagination séquentielle. Il enrichit ensuite les assets avec des workers parallèles limités. Le budget de requêtes contrôle la pression sur l’API sans prétendre représenter un pourcentage du débit réseau.

La liste possédée utilise la session du compte ; les détails publics utilisent un client anonyme, selon le comportement observé de l’API. Un listing retiré peut rester possédé et téléchargeable ; une taille absente est inconnue, pas nulle. L’inspection du manifeste permet séparément de connaître les tailles Unreal.

Les téléchargements récupèrent les chunks en parallèle mais assemblent les fichiers avec un writer ordonné, calculant SHA1 pendant l’écriture. Les fichiers terminés et vérifiés composent l’état de reprise ; l’identité du manifeste évite de mélanger des builds. Les fichiers quittent le répertoire partiel après achèvement.

Les chunks réutilisés disposent d’un cache mémoire borné. Le plan connaissant l’ordre d’écriture, l’éviction retire le chunk dont la prochaine utilisation est la plus éloignée. Une récupération supplémentaire occasionnelle permet un plafond mémoire prévisible sans stocker deux fois l’asset entier sur disque.

L’écriture ordonnée simplifie la vérification et la reprise, mais peut attendre un chunk retardé alors que d’autres sont arrivés. La limite du cache peut imposer de récupérer à nouveau un chunk. Le choix privilégie intégrité et mémoire prévisible plutôt que le parallélisme maximal.

Les packs de contenu vont dans Content ; les projets complets peuvent être copiés comme projets ; les plugins suivent les chemins du manifeste. Dry run prévisualise l’action et les collisions exigent force explicite. Les copies sont préparées sur le volume de destination ; le staging moteur reste hors du scanner de plugins.

L’installation exige la racine exacte d’un moteur enregistré. Les fichiers précèdent les enregistrements du launcher : manifeste, item, liste des installations et EOSH sont maintenus. Sauvegardes et relecture protègent la liste. Le launcher doit être fermé car il peut réécrire ces fichiers depuis son état en mémoire.

Installer du contenu dans un projet et un plugin dans un moteur touche des structures différentes. Des commandes séparées rendent destination et effet explicites. Les registres du launcher sont l’intégration la plus sensible : copier un dossier ne suffit pas pour que l’outil Epic reconnaisse installation et suppression.

La configuration reste dans le profil itinérant ; identifiants OAuth, cache et audit dans le profil local. Le login utilise le navigateur et renvoie un code masqué dans l’audit selon l’identité de la commande. Les mots de passe du stockage sont fournis séparément de l’URL enregistrée.

L’état du launcher est en lecture seule pour consultation et synchronisation. install, uninstall et repair sont les exceptions explicites qui écrivent ses enregistrements. L’audit mensuel local conserve les opérations ; doctor expose les problèmes d’intégrité sans demander au développeur d’inventer des requêtes de diagnostic.