Hallo

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.
Der Programmcode der meisten Nodes besteht ja nur aus wenigen Zeilen.
Generell sollte zunächst die von Visual Scripting verwendete Python-Schnittstelle für alle Allplan-Elemente erweitert werden.

Gruss

Ich sehe das wie meine Vorschreiber!
Grafische Überschreibung wäre schon cool!

Schöne Idee - wenn deswegen nicht alles andere liegen bleibt. Es gibt wirklich eine lange Liste an Punkten, die der Qualität von Allplan gut tun würde. Das Kontzept des Werkzeugkastens ist irgendwie auch nicht schlecht, fordert aber den Nutzer. Trotzdem, wenn Zeit dafür da ist - dann los.

Nun ja, es war eine Frage der Zeit, bis man bei Allplan realisiert, daß eine "Insellösung" Allplan-Visual-Scripting nicht so gut funktionieren wird. Warum mußte man das "Fahrrad auch nochmal erfinden"?
Grasshopper war zum Start von Visual-Scripting in Allplan längst "Marktführer" und hatte einen enormen Vorsprung! Diesen hat nicht mal die übermächtige AutoDesk mit dem Visual-Scripting-Tool Dynamo einholen können. Graphisoft hat das richtig erkannt, und sofort eine Schnitstelle zu Grashopper implementiert, statt noch eine Eigen-Lösung zu bauen. Mittlerweile gibt es sehr leistungfähige Tools für Grasshopper , z.B. LadyBug für Simulationen und Optimierungen. Wer implementiert sowas für Allplan-Visual-Scritping?

Nun muss man ehrlicherweise sagen, dass Allplan versucht hat, statt der geometrischen Formerzeugung andere Aufgaben mit Visual-Scripting zu lösen, z.B. automatisierte Bewehrung und Attribut-Verwaltung!

Die Fortschritte bei den Reinforcement Components (zu sehen wieder im letzten WIP-6) zeigen, daß man so etwas nicht in Allplan-Visual-Scripting versucht hat und auch nicht versuchen sollte.
Auch mit der neuen Information-Palette ist eine Attribut-Verwaltung sehr viel einfacher und effektiver, als es in Visual-Scripting jemals möglich wäre!
Es gab mal eine Präsentation von Modell einer Brücke in Allplan-Visual-Scripting. Spätestens bei
der Wartezeit von mehreren Minuten bei der Aktualisierung sollte auch dem letzten klar geworden sein,
dass man so etwas nicht in Visual-Scripting machen sollte, und schon gar nicht mit Python-Unterbau!
Zum Glück hat das auch Allplan eingesehen, und ein eigenes Brücken-Modul in nativem Code gemacht.

Das sind 3 Beispiele, die zeigen, wozu Visual-Scripting eben nicht geeignet ist!

Mich würde tatsächlich mal interessieren, wie viele wirklich brauchbare "Visual-Scripts" es so bei den Anwendern gibt, die diese auch täglich einsetzen. Ich meine damit wirklich so welche mit "Wow-Effekt", wo man sagt, das kann ich NUR mit Visual-Scripting machen, nicht mit Allplan, nicht mit SmartPArts, nicht mit PythonParts! Möglicherweise wäre das auch für Allplan von Interesse, bevor man jetzt wieder mit viel Aufwand wieder etwas macht, was keiner braucht und von begrenztem Nutzen ist.

Für mich ist Visual-Scripting genauso ein "Hype" GEWESEN, wie es derzeit große Sprachmodelle (ich weigere mich das als KI zu bezeichnen) sind. Nach ein paar Jahren wird man herausgefunden haben, wofür man das gut einsetzen kann, und wofür es nicht taugt. Diese Zeit ist für Visul-Scripting schon um, und man sollte es als das sehen, was es ist: Ein weiteres Tool, was aber nicht alles kann!

Grafische Überschreibung ist etwas, was hier im Forum schon mehrfach diskutiert wurde. Das würde allen Nutzern helfen, da jeder Planer der Pläne auf die Baustelle liefern muss, farbige angelegte Übersichtspläne aus Attribut-Werten der Elemente erstellen können muss, und zwar am besten auf "Knopfdruck"!

Man bzw. ich kann Deinen Link "Grafische Überschreibung" nicht öffnen. Obwohl ich angemeldet bin kommt die folgende Meldung?!

Moin,

wie Xinling schon geschrieben hat richtet sich die Umfrage eher an PythonPart- Entwickler, weniger an "Durchschnitts-ALLPLAN- Benutzer".
Das wird meiner Einschätzung nach mit der Grasshopper- Anbindung genauso sein.

Da aber alle Anwender von möglicherweise besseren, einfacheren und/ oder günstigeren parametrischen Objekten profitieren würden ist die Überlegung auch von daher grundsätzlich schon berechtigt und genaugenommen schon lange überfällig.
Ob Grasshopper für diesen Anwendungsbereich besser ist als Visual Scripting oder ob Visual Scripting in die Grasshopper- Richtung aufgebohrt werden kann vermag ich nicht einschätzen.
Wenn dadurch allerdings z.B. mit vergleichsweise wenig Aufwand bestehende Grasshopper- Scripts in ALLPLAN verwendet werden könnten (keine Ahnung ob das realistisch ist...) wäre die daraus möglicherweise resultierende höhere Vielfalt an parametrischen Objekten schon ein Vorteil, auch für den "Otto Normalanwender".

Interessant zu wissen wäre ob damit langfristig auch parametrische Gebäudemodellierungen (wie man sie an den Unis immer so hübsch präsentiert bekommt) möglich werden oder ob ALLPLAN da an seine Grenzen kommt.

Insgesamt ist das sicher auch eine produktstrategische Frage/ Entscheidung.

Ohne Zweifel dürfen die hier bereits genannten und noch so einige andere "Großbaustellen" in ALLPLAN dafür nicht vernachlässigt werden.

BG
Jens Maneke
AAP Sommerfeld

Der link verweist auf ein WIP-Forum. Dazu musst Du Beta-Tester sein.

Aber eine Suche im Forum nach "Grafische Überschreibung" findet die anderen Beiträge...