Tool "Treppe" für Treppen im Außenbereich

[linosphere]

Im GaLa-Bau ist es ja üblich, Treppen mit ca. 1 cm Höhenunterschied von Stufenhinter- zu Vorderkante einzubauen, um die Entwässerung sicherzustellen.

 

Sehe ich das richtig, dass ich das mit dem Tool "Treppe" aus der Werkzeugpalette Architektur so nicht konstruieren kann?

 

[Stefan Bender]

Derzeit ist das nicht vorgesehen. Ist aber sicherlich ein interessanter Verbesserungsvorschlag @Michael Gass@Marc Wittwer. Wäre aber leider sehr aufwändig umzusetzen.

[pitter]

Hallo linosphere,

da gibts ein Marionette Objekt aus dem US Forum.

Vieleicht hilft das ja weiter??

Marionette_Landscape stairs Marionette.vwx

Schöne Grüße

Pitter

[linosphere]

Cool, das sieht schon mal ganz gut aus! Werde es mal in der Praxis testen.

Das "echte" Treppen-Tool kann natürlich noch mehr, unterschiedliche Bauweisen und Handläufe usw. - Das einzige, was dem fehlt, ist ja eigentlich die Stufenneigung (und vielleicht Fundamentierung).

[linosphere]

Dann wird das jetzt ein Marionette-Thread:

Dachte, ich übersetze die Inputs gleich mal, für die Kollegen im Büro. Manche der Nodes kann ich umbennenen, bei anderen wirft es Fehler:

 

"Einbindung Unterstufe" macht keine Probleme, aber wenn ich "Number of steps" umbenenne in "Anzahl Steigungen", bekomme ich diesen Fehler:

 

Wie debuggt man Marionettes denn am besten? Kann ich mir die Marionette als fertiges Script anzeigen lassen? Damit wäre ich etwas vertrauter, wenn es um suchen/ersetzen von Variablen-Namen ginge.

[L00S]

vor 19 Stunden schrieb Stefan Bender:

Derzeit ist das nicht vorgesehen. Ist aber sicherlich ein interessanter Verbesserungsvorschlag @Michael Gass@Marc Wittwer. Wäre aber leider sehr aufwändig umzusetzen.

Man kann auch 3D Symbole, zB Fahrzeuge aus der Bibliothek nicht in die Neigung drehen, was bei Rampen oder Geländeplanungen aber schon mal vorkommt. Ein Sattelschlepper auf 2% Neigung schwebt dann gerne mal sichtbar in der Luft. Wenn das Grundsätzlich gelöst wird, ist es vllt. im Gesamten nicht mehr so aufwendig.

[HebHeb]

Marionette Objects sind m.E. die beste Wahl!

Haben uns schon einige Freiraum-spezifische Tools gebaut. Seit Marionette die Objektstile im Zubehör verwendet leidet auch die Datei-Performance nicht mehr und sie funktionieren so geschmeidig wie die "original"PIOs
Bisher hat sich jede investierte Stunde gelohnt!

Debugging ist so eine Sache... Am besten scriptet man von 0... und noch besser nur mit Nodes aus der Originalbibliothek (so ist man bei Versionsupdates etwas "sicherer")
Im englischen Forum wird einem bezüglich Marionette immer sehr gut geholfen (hier sind auch Vectorworks-Angestellte unterwegs, die sehr prompt antworten und kompetent weiterhelfen)

Den größten Vorteil das ganze selbst von 0 aufzubauen sehe ich darin:
1. "die Kontrolle" über das Script bewahren (ich habe es aufgegeben bestehende Scripte umzubauen)
2. das Ganze in seinen Büro ifc/BIM workflow (Tabellen, Datenbanken, Attribute etc…) einbinden kann

Auf jeden Fall muss man so etwas langfristig denken, die Entwicklung solcher Tools ist aufwendig, muss daher reproduzierbar und der Mehrwert skalierbar sein.
Insgeheim hoffe ich aber natürlich auch auf gute Vectorworks-PIOs die die Landschaftsarchitektur BIM technisch revolutionieren! Bis dato heißt es einfach selbst machen ;D

[Antonio Landsberger]

Am 25.5.2023 um 17:08 schrieb linosphere:

 

 

Diese Fehlermeldung solltest Du eigentlich nicht in diesem Szenario erhalten.

 

Ich habe mal kurz Nodes so zusammengestellt, dass genau diese Meldung kommt.

Hier wirft der Werteingang für iCount den Fehler, weil hier ganze Zahlen erwartet werden.

 

Ich werde es den Entwicklern melden. Danke für den Hinweis!

 

Ach ja, nachdem ich das Node umbenannt und den Stil verlassen und die Fehlermeldung weggeklickt und den Anzahl-Wert von 0 wieder auf 3-9 gesetzt habe, hat das Marionette-Objekt bei mir wieder seinen Dienst getan.

[linosphere]

vor 25 Minuten schrieb Antonio Landsberger:

Diese Fehlermeldung solltest Du eigentlich nicht in diesem Szenario erhalten.

Hatte mich auch gewundert, dass die Umbenennung zu einem Mathe-Fehler führt. Lag also nur daran, dass beim Bearbeiten der Marionette die Werte zurückgesetzt wurden, und das hat dann den Fehler produziert.

 

vor 26 Minuten schrieb Antonio Landsberger:

Ach ja, nachdem ich das Node umbenannt und den Stil verlassen und die Fehlermeldung weggeklickt und den Anzahl-Wert von 0 wieder auf 3-9 gesetzt habe, hat das Marionette-Objekt bei mir wieder seinen Dienst getan.

Super, besten Dank! Konnte jetzt alle sichtbaren Werte umbenennen (mit Ausnahme des Wrappers, der ist immer noch auf schwedisch - keine Ahnung, wo man an den rankommt?).

 

Habe die übersetzte Version hier noch mal angehängt.

Treppe Landschaft Marionette.vwx

[Apfelbeere]

Hallo,

ich habe mir ein Blockstufensymbol aus einem Belag Weg erstellt. Damit kann ich das Gefälle gut einstellen und im Plan entsprechend stapeln.

[Antonio Landsberger]

Die aktuelle Situation mit den Input Nodes in Wrappern/Marionette-Objekten muss von den Entwicklern gelöst werden.

Die Umbenennung von Input Nodes innerhalb eines Wrappers hat zur Folge, dass sich die Position des Datenfeldes in der Infopalette (alphabetisch sortiert) automatisch auch ändert. Leider bleiben aber die korrespondierenden Werte an der Stelle und werden nicht mit dem Feldnamen verschoben bzw. synchron gehalten.

 

Beim Umbenennen also bitte auf die Feldnamen und Werte in der Infopalette achten.