Vielen Dank für alle Feedback.
Logisch ist Grasshopper ein geiles Tool, aber ist das wirklich die richtige Zielgruppe (Durchschnittliche Allplan User)?
Der Grasshopper oder Visual Scripting sowie die Python API zielen nicht auf normale Allplan-Benutzer ab, deshalb habe ich die Umfrage nur in diesen Forenbereichen gepostet.
Da unser Team hauptsächlich an API-bezogenen Themen arbeitet, habe ich diese Umfrage erstellt, um einige Einblicke von euch allen (einschließlich WIP-Teilnehmern) zu erhalten.
Wenn Ihr schon über Schnittstellen nachdenkt wäre der Multi-IFC Export sicher viel höher zu priorisieren. Sowas habt Ihr ja in eurem Entwicklungsteam ja via Phyton schon gemacht.
Das Thema Multi-IFC-Export wird von anderen Teams behandelt. Wir haben zwei PythonPart-Skripts erstellt, um IFCs und DWGs/DXFs ohne Benutzerinteraktionen zu exportieren. Es funktioniert sogar mit dem Windows Task Scheduler. Der Grund, warum wir es damals erstellt haben, ist die Verbesserung der API. Wir planen, es später als Plugin in einem neuen allep-Paket zu veröffentlichen, damit zumindest jeder Benutzer, der auf einen Multi-Export wartet, es als Zwischenlösung nutzen kann.
Ein anderes Projekt "Grafische Überschreibungen" ist bei mir seit Jahren zuoberst auf der Wunschliste.
Bezüglich der "Grafischen Überschreibungen" ist unser Team nicht zuständig. Was ich sagen kann, ist, dass andere Teams derzeit an einer Lösung arbeiten. Aber es gibt noch kein Release-Datum.
Meiner Meinung nach sollten die Ressourcen besser für die Weiterentwicklung von Visual Scripting eingesetzt werden. Mit der Implementierung von ein paar Dutzend zusätzlichen Nodes könnte Visual Scripting ohne großen Aufwand verbessert werden.
Wir werden die Entwicklung des Visual Scripting fortsetzen. Aber die Grasshopper-Verbindung könnte beeinflussen, welche Art von Aufgaben mit VS erledigt werden sollen, und den Rest für die GH-Verbindung lassen. Wir möchten auch sicherstellen, dass dieser Unterschied selbst fortgeschrittene Allplan-Power-User nicht verwirrt.
Das sind 3 Beispiele, die zeigen, wozu Visual-Scripting eben nicht geeignet ist!
Ja. VS ist derzeit nicht gut genug, um die von Ihnen genannten Anwendungsfälle auf einfache Weise zu erfüllen. Und niemand wird erweiterte professionelle Grasshopper-Plugins erneut für VS erstellen.
Aber das bedeutet nicht, dass VS bedeutungslos ist. Wenn Sie verfolgen, was ArchiCAD tut, führen sie auch den PARAM-O nach der Veröffentlichung ihrer GH-Verbindung ein. Der PARAM-O ist ihre einzige visuelle Programmierlösung, aber nur für benutzerdefinierte allgemeine parametrische Objekte. Dies wird wahrscheinlich auch in naher Zukunft der Schwerpunkt unseres VS sein, da native Objekte, die von GH erstellt wurden, ihre in GH definierten Constrains und Parameters in Allplan verlieren. Wir haben derzeit auch keine andere einfachere Möglichkeit, benutzerdefinierte parametrische Objekte schnell zu erstellen. Basierend auf dem aktuellen Umfragefeedback ist dies auch die Hauptaufgabe, die unsere Benutzer mit VS erledigen.
Product Owner API, Allplan GmbH
