Eléments de bibliothèque en double ...

Salut à tous

Je suis sûr que certains connaissent déjà ce message par cœur. En gros, j'ai regroupé ma bibliothèques d'objets et textures perso dans un dossier nommé "Bibliothèque ArchiCad complémentaire". Il y a en effet 4 doublons à l'intérieur de cette bibliothèque (textures nécessaires pour certains objets dans le cas où je ne charge pas l'ensemble de mon dossier) mais lorsque je charge mon dossier :



Pourtant j'ai identifié les doublons, j'ai ensuite lancé une recherche pour les trouver dans la biblio standard, et je ne les retrouve pas ! Alors pourquoi cet avertissement ?

Merci d'avance

Bonsoir

Tu as 4 textures en doublons qui existe dans la bibliothèque de base ?
Elles sont complètement identiques ? Si elles ne le sont pas il faut que tu renomme les unes ou les autres pour qu'elle puisse cohabiter.
Je ne comprends pas bien ton problème.
Par principe je conserve la bibliothèque ArchiCAD dans son intégralité non modifiée.
J'aurai tendance à sortir les 4 textures fautives de la bibliothèque complémentaire.

Après pour répondre à ta question toutes les formats de bibliothèque ne laissent pas les objets "en clair", comme le lcf par exemple si tes textures sont intégrées dans un lcf tu ne les verra pas en tant que fichier.

En fait les 4 textures se trouvent en deux exemplaires dans 2 dossiers différents de ma bibliothèque complémentaire. Je peux d'ailleurs les retrouver facilement en utilisant spotlight. Je ne supprime pas ces doublons car il se pourrait qu'un jour je ne charge qu'une partie de ma bibliothèque complémentaire, avec des objets éparpillés dans plusieurs dossiers qui font référence à ces textures. C'est entre autres pour éviter de me retrouver avec le message d'erreur GDL comme quoi il manque la texture, etc...

Ce que je ne comprends pas, c'est ce message d'erreur qui me parle de doublons par rapport à la bibliothèque standard ArchiCad à laquelle je n'ai pas touché et je suis certain qu'il n'y a aucune texture qui a le même nom vu que les 4 textures fautives de ma biblio ont des noms en anglais : "darkoak, pine, ..." et que ma biblio standard est en français.

Bonjour

Ton problème mérite étude.

Deux points :
1— Stratégiquement (et personnellement…) je me ferai quand même une version de ta bibliothèque complémentaire sans doublons, et je me l'enregistrerai en lcf histoire de différencier avec ta complémentaire de base.

2— Est ce que tes doublons franco-anglais sont la même texture ou pas ? Si c'est le cas je ferai le test de les sortir de ta bibliothèque complémentaire et je testerai les objets de ta bibliothèque complémentaire qui font appel à ses textures pour voir si j'ai des messages d'erreurs ou pas.

Merci Fred pour tes réponses toujours aussi rapides et efficaces

Fmr a écrit:1— Stratégiquement (et personnellement…) je me ferai quand même une version de ta bibliothèque complémentaire sans doublons, et je me l'enregistrerai en lcf histoire de différencier avec ta complémentaire de base.

Ma stratégie actuelle est la suivante :

Toutes les bibliothèques utilisées par l'agence sont situées dans la base de données du serveur.
- je charge la bibliothèque ArchiCad 16 (copie conforme du conteneur .lcf qui se trouvait dans le dossier application)
- je charge la bibliothèque complémentaire ArchiCad (biblio générale avec plus d'objets que j'ai créées / pêchés sur le net)
- en fonction du type de projet, je charge parfois une bibliothèque spécifique (par exemple : matériel de cuisine professionnel, matériel médical, ...)

Je sépare les bibliothèques spécifiques pour éviter de devoir charger une bibliothèque énorme pour des projets qui n'en ont pas besoin.

Je n'enregistre pas les biblios complémentaires en conteneur .lcf car je les complète et je les modifie régulièrement en fonction des besoins de l'agence.

Est-ce qu'il y a d'après toi une meilleure façon de fonctionner ?

Fmr a écrit:2— Est ce que tes doublons franco-anglais sont la même texture ou pas ? Si c'est le cas je ferai le test de les sortir de ta bibliothèque complémentaire et je testerai les objets de ta bibliothèque complémentaire qui font appel à ses textures pour voir si j'ai des messages d'erreurs ou pas.

J'ai fait un test en dupliquant mes bibliothèques et en supprimant tous les doublons, et, comme par magie, plus de message par rapport à la bibliothèque standard

Bon... si ce n'était que ça, pour moi le sujet est résolu.

pour ma part, je ne fonctionne qu'avec mes bibli perso.. je ne travaille quavec celles qui sont sur mon DD externe (que je me trimballe entre bureau et chez moi)
c'est à dire les bibli officielles AC + Bibli perso
Une fois que le projet est terminé j'en fais un pla. et mise en pages en pdf.. et supprime les différentes versions anciennes ou ayant évoluées..
de cette manière pour le bur, qui que ce soit ayant besoin d'ouvrir le fichier n'a besoin de rien d'autre comme bibli, tout est dedans, pas de doublons, etc...
ce qui implique certe un dd externe.. mais bon. moi j'ai ma manière, comme tout un chacun, de bosser, et bibli etc...

Bonjour Farkas

Pour moi ta stratégie est bonne, la seule chose à bien surveiller sont les histoires de doublons de macros et de textures.
L'idéal étant d'avoir la complémentaire la plus compacte et opérationnelle possible, et l'idée d'avoir des spécifiques en fonction des cas est bien, tu ménages ainsi ta mémoire vive.

PS
+1 pour le pla et les pdf de Freroil en fin de phase, la vie d'objet n'est pas toujours un long fleuve tranquille…

Puisqu'on en est arrivé à l'archivage des dossiers terminés, on s'éloigne du sujet mais j'en profite

Je fonctionne également ± de la même manière avec une petite nuance :

Prenons un exemple : un nouveau projet d'extension de concessionnaire Volvo. Je copie mon fichier archiCad modèle et je le renomme "1325 Extension Volvo Kain 1_00"
Le 1_00 veut dire qu'il s'agit de la toute première mouture, de l'esquisse. Au fur et à mesure que le projet évolue, à intervalle régulier, je fais une copie 1_01, puis 1_02 ... jusqu'au moment où on passe à l'avant-projet 2_00, etc...

En gros, j'augmente le premier nombre :
- si je passe une étape importante dans le projet
- si le MO décide de faire des modifications conséquentes
- en cas de changement de version ArchiCad

Le deuxième chiffre est un backup à intervalle régulier dont le but est de pouvoir revenir en arrière de plusieurs sauvegardes en cas de problème. (le fichier .pbn ne permet de revenir que 1 sauvegarde en arrière)

Lorsque le dossier est (théoriquement) terminé, j'archive la dernière version en .pla et je supprime tous les backups intermédiaires pour ne garder que les 1_00, 2_00, 3_00, ... Il nous est déjà arrivé qu'un client nous demande des documents relatifs à l'évolution du projet et il est parfois nécessaire de pouvoir réouvrir les anciens pln pour publier les documents adéquats.

Rien à redire.

Fmr a écrit:Rien à redire.

vi +1..


pour ma part de la manière suivante.; qui est quasi identique..

fichier archive de base
enregistrement : ESQ - A (pour Indice, version) - Nom dossier - 01-05-13
APS - A (pour Indice, version) - Nom dossier - 01-05-13
APD / PC (suivant ..) - A (pour Indice, version) - Nom dossier - 01-05-13
en général le A (version) évolue fonction si changement de direction / projet), surf, volumetrie, etc..
la date permet d'une part de trouver plus rapidement car souvent les client ne connaisse pas forcément la phase, ou ne la retienne pas forcément.. et donc à chaque étape ou modificat je change l'indice

Pas mal du tout ton système freroil, je pense que je vais faire évoluer notre nomenclature dans ce sens

merci..
bon après.. faut juste pensé à supprimer une fois fini une parties des fichiers.. enfoin comme dans ton cas.. sinon on se retrouve vite avec juste un dossier de ficheri archicad de qq Go.

Je fait aussi comme Freroil, sauf que je met la date en prem's & à l'américaine aaaa-mm-jj.
Comme ça Windows me classe automatiquement les dossiers par ordre croissant/décroissant.

& pareil pour le principe APS EXE etc ... & les indices A B ...

Ça donne par exemple un dossier "2013-05-06_EXE_iA"

Coulou a écrit:Je fait aussi comme Freroil, sauf que je met la date en prem's & à l'américaine aaaa-mm-jj.
Comme ça Windows me classe automatiquement les dossiers par ordre croissant/décroissant.

& pareil pour le principe APS EXE etc ... & les indices A B ...

Ça donne par exemple un dossier "2013-05-06_EXE_iA"

.. moi le classement est fait dans les fenêtres par date. mais effectivement tu as raison.. la date en prem est certainement plus adéquate..

Bonjour

J'utilise aussi la notation américaine pour les dates des noms de fichiers en utilisant dans l'ordre "Code du projet"/ "Phase" / "Date "Américaine"".
L'avantage est qu'avec juste un tri alphabétique tu peux différencier les projets (ce qui permet de repérer facilement les fichiers égarés…) la phase (de plus en plus les phases sont imbriquées), la date américaine met en phase ordre alphabétique et chronologique et après les différentes "annotations" permettant de "renseigner" le fichier (placés là ils ne perturbent pas l'ordre.

Intéressant post.

Pour ma part, je classe presque de la même manière que FMR.

Après mûre réflexions, nous avons décidé d'opter pour la logique suivante :

XXXX Nom du projet Y_YY (ZZZ)

où
XXXX = référence du dossier
Y_YY = version du projet (comme expliqué précédemment)
(ZZZ) = Etape / informations

Exemple :

1224 Home Myosotis 3_05 (APD b)


Je n'ai pas introduit la date car elle apparaît automatiquement dans le finder / explorateur windows. C'est le numéro de version qui détermine le classement chronologique des fichiers PLN.

Farkas a écrit:Je n'ai pas introduit la date car elle apparaît automatiquement dans le finder / explorateur windows. C'est le numéro de version qui détermine le classement chronologique des fichiers PLN.

Pour moi la date n'est pas la date d'enregistrement du fichier mais celle de l'édition de fin de phase (ou de "sortie" d'indice), ce qui n'est pas toujours la même chose…