Directives techniques - Scripts Dynamo

Instructions techniques pour la soumission de scripts Dynamo

Ces directives définissent les normes techniques, structurelles et de qualité pour la soumission de scripts Dynamo au programme RD Studio Creator. Notre objectif est simple : publier des solutions d’automatisation fiables et prêtes pour la production, que les professionnels peuvent exécuter en toute sécurité dans des projets réels.

Le respect de ces directives ne garantit pas une approbation automatique. Chaque soumission est évaluée selon des critères de qualité, d'ergonomie, de performance et d'originalité. Notre objectif n'est pas de créer des formalités administratives supplémentaires ; nous avons besoin de normes uniformes pour pouvoir tester, accompagner et publier votre travail de manière responsable.

Navigation rapide

✅ Ce que nous recherchons

Nous privilégions la qualité à la quantité. Les candidatures les plus performantes pour Dynamo présentent généralement les caractéristiques suivantes.

✅ Autorisé - Scripts autonomes (s'ils sont complets)
Un script unique peut être accepté s'il apporte une valeur ajoutée claire, possède une expérience utilisateur propre et inclut la documentation requise ainsi que la liste des dépendances.

✅ Requis - Automatisation professionnelle et prête à l'emploi
Les scripts doivent être pratiques pour une utilisation concrète dans un projet : des entrées claires, des résultats prévisibles et une configuration minimale. Si un script oblige l’utilisateur à deviner les entrées, à modifier des nœuds ou à résoudre des problèmes liés à des étapes manquantes, il n’est pas prêt à être publié.

✅ Requis - Œuvre originale
Veuillez soumettre uniquement vos propres scénarios originaux. Les scénarios republiés, légèrement modifiés ou réutilisés d'autres auteurs ne sont pas acceptés.

Raisons courantes de rejet (Échec rapide)

  • ❌ Le script ne s'exécute pas sur la version de Revit/Dynamo déclarée.
  • ❌ Chemins de fichiers codés en dur, noms d'utilisateur, répertoires spécifiques à la machine ou fichiers externes manquants
  • ❌ Utilise des dépendances de paquets payantes, privées ou peu claires sans autorisation ni documentation.
  • ❌ Absence d'entrées/sorties claires, d'instructions ou graphique illisible
  • ❌ Comportement risqué sans avertissement (supprime des éléments, écrase des paramètres, modifie silencieusement de grandes sélections)
  • ❌ Aucun fichier d'exemple n'est fourni lorsqu'un tel fichier est requis pour comprendre ou tester le flux de travail.
  • ❌ Aucun fichier vidéo n'est autorisé lorsqu'il est nécessaire de comprendre ou de tester le flux de travail.

Compatibilité et configuration

Nous avons besoin de détails de compatibilité afin de pouvoir tester votre script de manière fiable et réduire les problèmes d'assistance après sa publication.

  • Déclaration de compatibilité : Indiquez clairement la ou les versions de Revit prises en charge par le script.
  • Environnement : Indiquez si le script est destiné à Dynamo dans Revit ou à Dynamo Player.
  • Préférence Python (recommandée) : Dans la mesure du possible, nous privilégions les nœuds Python personnalisés aux dépendances de packages externes. Cela contribue à garantir la stabilité à long terme en cas de dépréciation, de suppression ou de modification importante de packages.

Structure et lisibilité du graphique

exigences strictes

  • Utilisez une mise en page claire et lisible, avec un espacement et un alignement réguliers.
  • Regroupez les nœuds liés (utilisez des groupes avec des titres clairs)
  • Supprimez le code mort, les nœuds inutilisés et les branches expérimentales

Fortement recommandé

  • Ajoutez de brèves notes pour expliquer la logique non évidente et les décisions clés.
  • Évitez autant que possible les fils trop longs traversant toute la toile.
  • Nommez clairement les nœuds personnalisés (le cas échéant) et veillez à leur organisation.

Entrées, sorties et expérience utilisateur

exigences strictes

  • Les entrées doivent être évidentes et centralisées (une seule zone de saisie est préférable).
  • Utilisez des étiquettes d'entrée claires (exemple : « Catégorie cible », « Nom du paramètre », « Texte préfixe »)
  • Les résultats doivent être visibles et compréhensibles (exemple : liste de résultats, nombre ou message d’état).
  • Si le script modifie le modèle, veuillez inclure un avertissement clair à proximité de la zone d'exécution.

Fortement recommandé

  • Fournissez des valeurs par défaut sûres lorsque cela est possible.
  • Ajoutez un court bloc « Mode d’emploi » à l’intérieur du graphique à l’aide de Notes.
  • Incluez des messages clairs de succès/échec (exemple : « 0 élément trouvé », « Terminé », « Paramètre manquant »).

Paquets et dépendances

Les paquets sont autorisés. Nous avons simplement besoin de transparence pour que les utilisateurs puissent exécuter votre script sans avoir à deviner, et pour que nous puissions assurer son support à long terme.

exigences strictes

  • Liste de tous les paquets utilisés (nom du paquet + version)
  • Évitez les dépendances payantes, privées ou sur invitation uniquement, sauf accord explicite préalable.

Fortement recommandé

  • Privilégiez les nœuds prêts à l'emploi (OOTB) lorsque cela est possible.
  • Les paquets communautaires populaires sont généralement acceptables à condition qu'ils soient stables et documentés.
  • Évitez les dépendances susceptibles de rompre la compatibilité entre les versions.

Qualité, sécurité et performance

exigences strictes

  • Pas de chemins codés en dur (utiliser la sélection de l'utilisateur, la logique relative ou des étapes de configuration clairement documentées).
  • Gérer élégamment les sélections vides et les paramètres manquants
  • N’exigez pas que l’utilisateur modifie le script pour l’exécuter (sauf indication contraire claire et justifiée).
  • Évitez les actions destructives sans avertissement explicite (suppression, écrasement, modification en masse).

Fortement recommandé

  • Réduisez au minimum les opérations géométriques lourdes lorsque cela est possible.
  • Filtrez en amont, réduisez la taille des listes et évitez les conversions inutiles.
  • Fournissez un fichier d'exemple léger si le flux de travail nécessite un contexte.

Nœuds Python (le cas échéant)

  • Les nœuds Python sont autorisés
  • Incluez de courts commentaires dans le code pour expliquer les entrées, les sorties et la logique principale.
  • Évitez les dépendances obscures que les utilisateurs ne peuvent pas installer facilement.

Exigences de soumission

  • fichier .dyn
  • Enregistrement vidéo montrant le fonctionnement du script sur le fichier .rvt d'exemple
  • Exemple de fichier .rvt (requis lorsque le script nécessite une configuration spécifique pour être testé)
  • Brève description expliquant le fonctionnement du script et son utilité.
  • Environnement : Dynamo ou Dynamo Player
  • Liste des dépendances (packages utilisés, le cas échéant)

Toutes les soumissions sont examinées manuellement. Les commentaires ou les demandes de révision font partie intégrante du processus.

Prêt à soumettre ?

Soumettez votre travail via notre formulaire. En cas de doute sur la pertinence de votre scénario, veuillez joindre une brève note ; nous l’examinerons.

Soumettez votre travail

Des questions ?
Envoyez-nous un e-mail à support@rdstudio.co

Retour en haut de page