📦 Importer et exporter un module

Au-delà de l'export final de votre application (déjà couvert dans la catégorie Export, Monétisation), Celestory permet d'exporter un module ou un graphe isolé dans un fichier, pour l'archiver ou le transférer vers un autre projet. Ce guide décrit ce que contient réellement ce fichier, comment l'importer ailleurs, et ce qui se passe en cas de conflit de nom.

🚪 Où trouver cette fonction

Ouvrez le menu du projet, entrée Projet, puis le bouton Importer / Exporter des modules au bas de l'écran. Une fenêtre dédiée s'ouvre, avec un arbre à cocher (modules, graphe de départ de chacun, et les autres graphes non rattachés à un module) et deux boutons : Importer et Exporter.

🗂️ Ce que contient le fichier exporté

Le bouton Exporter produit une archive ZIP, nommée d'après le nom du projet et l'horodatage du jour. À l'intérieur :

• un fichier data.json qui décrit tout ce qui a été coché : les modules, les graphes et leurs blocs, les variables liées, la configuration de chaque module, et le numéro de version de l'éditeur au moment de l'export ;
• un dossier files/ qui contient les fichiers binaires réellement utilisés par la sélection (images, notamment les portraits de personnages d'un module Chatbot).

🔺 Ce n'est donc pas que de la logique : les assets référencés (fichiers utilisés dans les blocs et dans la configuration du module) sont bien inclus dans le ZIP, pas seulement leurs noms. En revanche, seul ce qui est réellement référencé par votre sélection est emporté — rien d'inutilisé, et rien qui appartienne à un autre module non coché.

Cocher un module coche automatiquement son graphe de départ et récupère en cascade tout ce qui est branché dedans : variables, sous-graphes ouverts depuis un bloc, fichiers utilisés. Cocher un graphe isolé (hors module) fait l'inverse : s'il appartient à un module, ce module est coché avec lui.

📥 Importer un module exporté

Dans la même fenêtre, sur le projet de destination, cliquez sur Importer et choisissez le fichier ZIP. L'import :

1. crée un nouveau dossier de fichiers nommé Import-<nom du fichier> dans votre bibliothèque de fichiers, pour ne pas mélanger les assets importés à ceux déjà présents ;
2. y dépose tous les fichiers binaires du ZIP ;
3. recrée les ressources (graphes, blocs), les variables et les modules avec les mêmes identifiants internes qu'à l'export.

Un message confirme la réussite de l'import une fois l'opération terminée.

💥 Collision de nom : le piège silencieux

🔺 Si le projet de destination possède déjà un module portant exactement le même nom que celui que vous importez, ce module précis n'est pas importé — il est simplement ignoré. Aucune erreur ne s'affiche pour ce cas précis : le message de succès apparaît quand même, comme si tout s'était bien passé, même si un ou plusieurs modules de votre sélection ont été silencieusement écartés.

Ce qu'il faut faire : avant d'importer, vérifiez qu'aucun module du projet de destination ne porte déjà le nom exact d'un module que vous importez — au besoin, renommez l'un des deux au préalable. Après l'import, comptez les modules obtenus pour confirmer qu'ils sont tous là.

Deux autres cas plus rares, à connaître :

• Si une ressource importée partage déjà le même identifiant interne qu'une ressource existante (cas typique : vous réimportez deux fois le même fichier), la version importée remplace silencieusement l'existante.
• Les variables, elles, ne sont jamais dédupliquées : réimporter deux fois le même fichier peut créer des doublons.

→ Prochaine étape : avant un export destiné à être réimporté ailleurs, renommez vos modules pour qu'ils ne portent pas de nom générique (« Module 1 », « Nouveau module »…), qui multiplie le risque de collision silencieuse à l'arrivée.

Mis à jour le : 21/09/2026