Support Forum

Momentan bietet VS nicht viele Möglichkeiten den Ablauf besser zu organisieren, insbesondere wenn mehrere Nodes eine Anwender-Interaktion benötigen. Wir haben zwar schon eine Idee, wie wir in Zukunft es lösen können/möchten. Aber es könnte vermutlich nicht zeitnah implementiert werden.

Der Einsatz vom Node Pause ist schon korrekt, um solche Fehlermeldung zu vermeiden. Ein Bug war uns leider bekannt, dass Änderungen auf einem bereits abgesetzten PythonPart, in dem Node Pause verwendet wird, kein Objekt am Ende erzeugt können. Ein Fix wird voraussichtlich mit 2021-1-6 ausgeliefert.

Hallo Xinling,

ich habe gerade ein ganz ähnliches Problem in einem Scrip:

Am Anfang des Script soll mittels des Nodes SelectObjectsByAreaInput eine 3D Fläche selektiert werden, welche die Grundlage für das
zu erstellende Python-Part darstellt.
Das PP wird in weiterer Folge entsprechend dem Script sauber erstellt.

Versucht man jedoch später das PP nochmals zu bearbeiten öffnet sich die Palette gar nicht und das PP verschwindet komplett aus der Darstellung bzw. allen Fenstern. Wechselt man anschließend zw. 2 Teilbildern hin und her, wird das PP wieder angezeigt.

Ich habe dann ebenfalls den Node "Pause" nach dem Node SelectObjectsByAreaInput eingefügt.
Dadurch öffnet sich beim Versuch das PP zu bearbeiten zumindest die Palette. Jedoch erhält man keinen Zugriff auf die konfigurierten Paletteninhalte des PP.
Man hat lediglich die Möglichkeit den "Start" Button für die erneute Objektselektion zu wählen, wodurch das bestehende PP neu erzeugt und faktisch auf die im Script hinterlegten Werte resettet wird...

Das ist echt ein Problem, weil ich mit dem Script zwar ein funktionierendes, parametrisches Objekt erzeuge, welches ich aber nachträglich nicht mehr bearbeiten kann bzw. nur mehr resetten und komplett neu konfigurieren muss.

Gibt es vielleicht eine Möglichkeit Anwender-Interaktionen bei bestehenden PP zu unterdrücken, bzw. so zu konfigurieren, dass diese nur dann nochmal ausgeführt werden wenn der Anwender diese aktiv anstößt?

Wurde der von dir im Posting vom 08.07.2021 beschriebene Fix bereits mit 2021-1-6 ausgeliefert oder kommt der erst?

Grüße,
Mario

Vielleicht 3 Verbesserungsvorschläge an die Entwickler von Visual Scripting:

1. Wenn ein Node keinen Eingangswert hat <empty> sollte das nicht zum Abbruch der Scriptbearbeitung bzw. zu einem Fehler führen.
Alle anderen Visusl-Scripting Tools (Grasshopper, Dynamo, Marionette ...) akzeptieren einen "freien" Eingang bzw. einen dortigen NULL-Wert. Der Ausgang ist dann zwangsläufig auch <empty>, was aber kein Problem darstellt, wenn die damit verbundenen Eingänge kein Problem damit haben!
Schön wäre es, wenn der Node optisch z.B. durch eine Farbe anzeigt, ob er gültige Werte produziert hat. Auch das ist mittlerweile in allen andere VS-Tools implementiert. Die rote Farbe bei einem nicht belegten, aber obligatorischen Eingang ist zwar hilfreich, sagt aber noch nichts aus, ob die Node-Funktion erfolgreich ausgeführt wurde. (s. node_colors.mp4)
Und wann kommt endlich ein Panel-Node zum Anzeigen der Datenströme? Die kryptischen Angaben im Tooltip reichen da leider nicht aus.

2. Wenn eine bestimmte Eingabereihenfolge notwendig ist, kann man diese doch anhand der Y-Lage des Nodes auf der Diagrammfläche ermitteln. Die Eingabe-Nodes werden dann einfach von oben nach unten abgearbeitet. Diese Reihenfolge ist ja nur bei der "Erst-Eingabe" von Belang. Beim Modifizieren nimmt man dann die Controls in der Palette...

3. Wenn ein Script durch einen Fehler nicht ausführbar ist oder keine geometrische Objekte produziert, sollte ein Hilfs-Körper erstellt werden, und nicht das PythonPart komplett gelöscht werden. (siehe SmartParts)

Und: Könnte mal jemand den Sinn des Pause-Nodes erklären? Den habe ich bisher nicht verstanden.
Scheinbar soll es den Datenfluss in einem bestimmten Punkt des Diagramms unterbrechen. Aber wo fliessen die Daten dann weiter?
An anderen Nodes? Dazu müßte man erst mal wissen, wo der Datenfluss (die Evaluierung der Nodes) startet, wenn mehrere Nodes ganz links stehen, und/oder keine weiteren Eingangsverbindungen haben, und wie/wo die Auswertung der Nodes dann weiter verläuft...

Aufgrund der Zurückziehung von beiden Hotfixes 2021-1-5 und 2021-1-7 wird ein Fix wieder nach hinten verschoben. Momentan versuchen wir das Problem mit dem Node Pause mit dem nächsten Hotfix 2021-1-9 zu fixen. In der neuen Version muss man das „weiter“ drücken, um die Objekte erneut zu erzeugen. Aber alle Parameter werden übernommen.

Danke für den Vorschlag. Theoretisch wird Benutzer-Eingabe bei bestehenden PythonPart gespeichert. Es kann sein, bei einige Nodes diese Funktion noch fehlt. Mit dem Nodes SelectGeometryObject funktioniert es. Wir werden aber noch prüfen, ob es bei anderen Nodes zu der Auswahl von $ModelObject genauso.

Danke Nemo für alle Verbesserungsvorschläge. Ein derartiges in-place Warnungssystem steht auf unserer To-Do-Liste, wir wissen es für eine bessere Bearbeitung sehr wichtig. Genauso ist ein Panel-Node. Der muss wegen einigen technischen Schwierigkeiten leider verschoben werden. Aber wir sind gerade dabei eine ähnliche Lösung zu entwickeln, sodass Benutzer Inhalte von Nodes sehen kann.

Eingagbereihenfolge mit der Y-Lage des Nodes ist unsere Meinung nach später schwer zu kontrollieren. Benutzer wird sie dann unbemerkt durch Ausbau des Skripts verändern. Wir werden deinen Vorschlag aber noch intern diskutieren.

Wir werden den Vorschlag prüfen, wie wir es implementieren können. Aber ist er schon ein guter Vorschlag.

In Grasshopper gibt es ein ähnlicher Node Data Dam. Er versucht den Datenfluss zu stoppen, um unnötige aufwendige Berechnung hinter dem Node zu vermeiden. Erst wenn das Ergebnis vor dem Node korrekt / geprüft ist, kann Benutzer den Datenfluss durchfließen lassen.
Bei Visual Scripting dient der Node Pause hauptsächlich zum folgenden zwei Zwecken.

• Einige Node verändert bestehende Allplan Objekte direkt. Um unbemerkte Änderungen zu vermeiden ist der Node Pause schon hilfreich. Es kann sein, dass wir kein Node erlauben sollten, vorhandene Objekte ohne Benutzer-Interaktion zu verändern. Aber nicht alle Nodes sind bereits angepasst worden.
  
• Da Visual Scripting behandelt momentan Fehlern nicht so gut wie Ihr alle schon wisst. Pause kann hier helfen, um Fehlern umzugehen. Wenn wir das Problem für die Fehlernbehandlung lösen würden, wäre der Pause nicht nötig hier.
  

Ich weiß, dass beide wie Zwischenlösungen klingen. Aber wir verbessern VS Schritt für Schritt.