EASY

Hallo @Chaosgrummi, ... noch ein kleiner Hinweis: Wenn Du im Simulationsmodus ein Fahrzeug markierst, dann wird mit einen animierten grünen Pfeil die aktuelle Fahrtrichtung des Fahrzeugs angezeigt (auch wenn es steht) [MBS V9]... ... Ziele können nur festgelegt werden, wenn sie in Fahrtrichtung liegen... deshalb: Gruß EASY

Hallo, einfach gar nicht ... die Variablen gehen über (eindeutige) Namen. Wildcards sind im MBS nicht vorgesehen. Prinzipiell geht es nur über eine Referenzliste als Variable z.B. "Variablennamen" mit allen Variablennamen, die in einer Schleife durchlaufen wird. Um auf alle Objekte zuzugreifen gibt es ... layout:enumEntities() Und so würde ein Listendurchlauf beispielsweise aussehen... local t = $("Ereignisse").variables["Variablennamen"] for _,v in ipairs(t) do layout:enumEntities(function (entity) entity.variables[v]=nil end) end ... dabei muß man allerdings bedenken, daß bei jedem Durchlauf allen Objekten die Variable zugewiesen wird und da "nil", diese jedoch nicht als solche gespeichert bzw. [wenn vorhanden] gelöscht wird (also nicht erschrecken beim Verfolgen in Ereignisprotokoll...). Für Schlagwörter gäbe es noch als Alternative eine Liste z.B. "SwNamen" mit den Namen aller Schlagwörter, die durchlaufen wird... t = $("Ereignisse").variables["SwNamen"] for _,v in ipairs(t) do local s=layout:getEntitiesByKeyword(v) for _,sw in ipairs(s) do sw.variables[v] = nil end end ... so werden beim Listendurchlauf nicht immer alle Objekte angesprochen sondern nur die, mit dem entsprechenden Schlagwort... ... etwas "einfacheres" ist mir [leider] nicht eingefallen... wäre aber vielleicht etwas für die "Wunschliste" Gruß EASY

Hallo @gmd, Neo hat es eigentlich schon beschrieben. Noch ergänzend dazu ein Wort zu "Spezialfall". Du hast eine Szene mit Straßenverkehr, bei dem es z.B. keine Weichen im eigentlichen Sinn gibt. Bedenke bitte, daß es im MBS auch noch den Schienenverkehr gibt und da spielen für den Anfangszustand die Stellungen von z.B. Weichen und Signalen eine bedeutende Rolle (wenn diese im Test in ihrer Stellung verändert werden, sollten sie schon zurückgesetzt werden...) Gruß EASY

Hallo, ... in Deiner Antwort liegt liegt ein wichtiger Aspekt. Ich nehme an, daß Neo mit "Zuständen" wohl mehr auf den Zustand von z.B. Weichen, Signalen... angesprochen hat und das läßt sich nicht "mit einem einfachen loeschen aller temporarer variablen regeln" und da beginnt die Schwierigkeit für @Neo, Deinen "Spezialfall" zu berücksichtigen bei dem dies (anscheinend) keine Rolle spielt. P.S. ... es ist zwar etwas mehr Aufwand aber mit STRG+C (markierte Objekte) und STRG+V läßt sich auch einfach eine Objektliste in einer z.B. Modulvariablen füllen. Dann bist Du unabhängig von eindeutigen Namen. Mit zwei Tastern und den dazugehörigen Ereignissen kannst Du dann die Anfangs-position / -rotation z.B. als Objektvariablen abspeichern und die Objekte wieder auf die Anfangs-position / -rotation bringen... so habe ich dieses "Problem" schon einmal für mich gelöst. Gruß EASY

Hallo, ... danke für den Hinweis. Ich habe noch etwas herumexperimentiert. Wie es aussieht liegt es tatsächlich an der Ausgabe im Visual Studio 2022 und die Newtonsoft Bibliothek arbeitet korrekt. Wenn da noch jemand einen Tipp hat, an welcher Stelle man da noch etwas an den Einstellungen drehen könnte... gerne! (... die Microsoft Hilfe dazu ist zwar interessant aber [wie gewohnt] mehr verwirrend als hilfreich...) Gruß EASY

Hallo, ... du denkst zu kompliziert... ... beides steht im Ereignisprotokoll (ein Ereignis [event] wurde ausgelöst... also muß es das auch geben) Gruß EASY

Hallo, ... Zeit für eine Pause? (... um aus dem Fokus des Programmierens zu kommen) Gruß EASY

Hallo, ... es gibt das event... ... mit den Rückgabe Parametern "depot" -> welches Depot, "vehicle" -> welches Fahrzeug, die Du auswerten kannst. Oder hat sich Deine Frage nur auf das Portal bezogen? @Neo wäre nach meiner Meinung logisch, wenn es auch ein event wäre, da eigentlich eine Verbindung zwischen zwei Gleisen (Spuren) darstellt und auch "betreten" und "verlassen" wird (wie ein Gleis / Straße). Gruß EASY

Hallo, ... ist das auch der Grund warum es mir nicht gelingen mag eine "print" Kommando über die JSON Schnittstelle zu senden? {"jsonrpc":"2.0","method":"layout.invokeScript","params":"print('Hallo Welt')","id":2} ... zeigt (bei mir) im Ereignisprotokoll nichts an. Gruß EASY

Hallo, aus den Versuchen von @Wopke und @Phrontistes ist immerhin ersichtlich, daß der KI folgende Informationen zur Verfügung stehen... Die Organisation von Gleisen über den Katalog erfolgt über IDs Es gibt unterschiedliche Gleissysteme Die Gleise lassen sich in ihrer Geometrie verändern Der prinzipielle geometrische Aufbau erfolgt über Segmente ... ich möchte wirklich niemand zu nahe treten, aber ich würde einmal behaupten, daß nicht jedem Anwender des MBS um alle Punkte weiß. Von der prinzipiellen Logik her, wären beide Skripte anwendbar [wenn auch etwas "kindlich naiv" betrachtet]. Was ich daran bemerkenswert finde, daß die KI lua Kommandos erfindet um ein Ergebnis präsentieren zu können... da würde mich sehr interessieren, wie das zustande kommt / woher diese "Informationen" stammen. Gruß EASY

Hallo, Da es mir geholfen hat Ereignisse über die JSON Schnittstelle auswerten zu können, anbei die JSON Struktur der einzelnen Ereignisse... (die Namen von Objekten oder Rückgabewerte sind beispielhaft...) { "jsonrpc": "2.0", "method": "layout.eventTriggered", "params": { "id": "{E5555398-A0B4-40FC-9752-D25D0F93DD3E}", "name": "Weiche schaltet", "params": { "track": { "_class": "entity", "name": "24620" }, "state": 1.0 } } } { "jsonrpc": "2.0", "method": "layout.eventTriggered", "params": { "id": "{3A3AC222-BE3D-40C0-AC6F-4FE760D61ACD}", "name": "Signal schaltet", "params": { "signal": { "_class": "entity", "name": "Hauptsignal Hp0/1" }, "state": 1.0 } } } { "jsonrpc": "2.0", "method": "layout.eventTriggered", "params": { "id": "{87089543-10D9-45C0-BD26-4A36CBFF68A4}", "name": "Schalter wird betätigt", "params": { "controller": { "_class": "entity", "name": "Schalter groß" }, "state": 0.0 } } } { "jsonrpc": "2.0", "method": "layout.eventTriggered", "params": { "id": "{2BB87EF8-698A-4001-80B1-50C77B5C5ED8}", "name": "Schalter wird betätigt (integriert)", "params": { "entity": { "_class": "entity", "name": "ADtranz DE-AC33C (BlueTiger)" }, "action": "02-Fahrlicht vorn rot", "state": 1.0 } } } { "jsonrpc": "2.0", "method": "layout.eventTriggered", "params": { "id": "{D2DE7F99-5258-49FD-9057-DF237BFC1BAF}", "name": "Gleiskontakt wird ausgelöst", "params": { "contact": { "_class": "entity", "name": "Beschleunigungskontakt" }, "vehicle": { "_class": "entity", "name": "DR-Baureihe 102.1 - Gartenlaube" }, "direction": 1.0 } } } { "jsonrpc": "2.0", "method": "layout.eventTriggered", "params": { "id": "{708C2FC0-4823-4ADC-B05A-A4CE65DE6C13}", "name": "Zug/Fahrzeug betritt ein Gleis/Straße", "params": { "track": { "_class": "entity", "name": "Gleis 2" }, "vehicle": { "_class": "entity", "name": "DR-Baureihe 102.1 - Gartenlaube" }, "oldTrack": { "_class": "entity", "name": "Gleis 1" } } } } { "jsonrpc": "2.0", "method": "layout.eventTriggered", "params": { "id": "{DA8B4A24-9D02-4000-9B3B-1E6A0C4540FD}", "name": "Zug/Fahrzeug verlässt ein Gleis/Straße", "params": { "track": { "_class": "entity", "name": "Gleis 1" }, "vehicle": { "_class": "entity", "name": "DR-Baureihe 102.1 - Gartenlaube" }, "newTrack": { "_class": "entity", "name": "Gleis 2" } } } } { "jsonrpc": "2.0", "method": "layout.eventTriggered", "params": { "id": "{4BCC10DE-ED83-4830-975D-E5B11B180018}", "name": "Zug/Fahrzeug erreicht sein Ziel", "params": { "vehicle": { "_class": "entity", "name": "DR-Baureihe 102.1 - Gartenlaube" }, "target": { "_class": "entity", "name": "Beschleunigungskontakt" } } } } { "jsonrpc": "2.0", "method": "layout.eventTriggered", "params": { "id": "{5DC268D6-F196-468B-99BD-9C26CC5D2266}", "name": "Zug/Fahrzeug stoppt", "params": { "vehicle": { "_class": "entity", "name": "DR-Baureihe 102.1 - Gartenlaube" } } } } { "jsonrpc": "2.0", "method": "layout.eventTriggered", "params": { "id": "{61B21003-1099-4C36-BD5E-118295EEC70C}", "name": "Zug/Fahrzeug betritt ein virtuelles Depot", "params": { "depot": { "_class": "entity", "name": "Depot" }, "vehicle": { "_class": "entity", "name": "DR-Baureihe 102.1 - Gartenlaube" } } } } { "jsonrpc": "2.0", "method": "layout.eventTriggered", "params": { "id": "{130999F3-5855-4CC3-8628-8E73E4D0DA35}", "name": "Zug/Fahrzeug verlässt ein virtuelles Depot", "params": { "depot": { "_class": "entity", "name": "Depot 1" }, "vehicle": { "_class": "entity", "name": "DR-Baureihe 102.1 - Gartenlaube" } } } } { "jsonrpc": "2.0", "method": "layout.eventTriggered", "params": { "id": "{ABCD8CA1-C844-45D0-BCF7-BCEB4683B751}", "name": "Fahrstraße wird aktiviert/deaktiviert", "params": { "route": { "_class": "route", "name": "TestFahrstraße" }, "state": true } } } { "jsonrpc": "2.0", "method": "layout.eventTriggered", "params": { "id": "{DA6A84C7-EAC6-41AB-B354-BEB42106D3BA}", "name": "Kran hat Transportgut aufgenommen/abgesetzt", "params": { "crane": { "_class": "entity", "name": "Portalkran Holzkontor" }, "target": { "_class": "entity", "name": "Objekt1" }, "state": 1.0 } } } { "jsonrpc": "2.0", "method": "layout.eventTriggered", "params": { "id": "{CD810070-811D-4B45-9D22-38B5180CF20A}", "name": "Kran wurde zurückgesetzt", "params": { "crane": { "_class": "entity", "name": "Portalkran Holzkontor" }, "standby": false } } } { "jsonrpc": "2.0", "method": "layout.eventTriggered", "params": { "id": "{357EA41F-8215-484D-AD2C-F0DEE25DD026}", "name": "Animation gestartet/gestoppt", "params": { "entity": { "_class": "entity", "name": "Windrad" }, "name": "_AnimUndefined", "running": true } } } { "jsonrpc": "2.0", "method": "layout.eventTriggered", "params": { "id": "{E520655B-BB24-4EF3-ACB8-FD37376ABC22}", "name": "Timer läuft ab", "params": { "eventModule": { "_class": "event", "name": "Ereignisse" }, "name": "Timer 1" } } } { "jsonrpc": "2.0", "method": "layout.eventTriggered", "params": { "id": "{7A3CA30D-037C-4DBB-B5B4-5F91483480B4}", "name": "Zeitpunkt erreicht", "params": { "time": { "_class": "time", "value": 0.65 } } } } { "jsonrpc": "2.0", "method": "layout.eventTriggered", "params": { "id": "{BD4C3F83-293F-4024-81B4-B17E1B37BE96}", "name": "Objekt-Variable wird gesetzt", "params": { "entity": { "_class": "entity", "name": "Pyramide" }, "name": "Objektvariable", "value": 10.0 } } } { "jsonrpc": "2.0", "method": "layout.eventTriggered", "params": { "id": "{F0096CC6-9C67-480C-A7B1-F7A637FB4D3A}", "name": "Modul-Variable wird gesetzt", "params": { "eventModule": { "_class": "event", "name": "Ereignisse" }, "name": "Modulvariable", "value": 20.0 } } } { "jsonrpc": "2.0", "method": "layout.eventTriggered", "params": { "id": "{50EE5CD0-1561-4571-B19E-D9A7398AD8D7}", "name": "Ereignis/Modul wird aktiviert/deaktiviert", "params": { "event": { "_class": "event", "name": "TestEvent" }, "state": true } } } { "jsonrpc": "2.0", "method": "layout.eventTriggered", "params": { "id": "{157AF46E-18AD-4087-A79A-7B564DD6D79C}", "name": "Tastenkürzel wird gedrückt", "params": { "shortcut": 9.0 } } } ... vielleicht hilft es ja jemand, der sich damit beschäftigen möchte... Gruß EASY

Hallo @Neo, nachdem es mir gelungen ist Ereignisse über die JSON Schnittstelle auszuwerten (Danke an @gmd für entscheidende Hinweise) habe ich die eine oder andere Frage: Gibt es einen (logischen) Grund weshalb "state" (Weiche, Gleiskontakt, Kran) oder "direction" (Gleiskontakt) mit Dezimalstelle (z.B. 1.0) zurückgegeben wird? Bei "Gleiskontakt wird ausgelöst" fehlt nach meiner Meinung ein Parameter, das Auskunft darüber gibt, ob "betreten", "betreten (Mitte)" oder "verlassen" (Auswahl in der EV möglich). Sonst erzeugt ein Fahrzeug das über den Gleiskontakt fährt drei mal das Ereignis ohne das man ausschließen kann, daß das Ereignis [meistens] zwei mal nichts tun sollte. Bei z.B. Taster "Taste ▲" (CD41F1D2-6ADF-4307-9964-66523248ABBA) und "Taste ▼" (43F18DCC-73EE-4F83-B9D5-B85E102980A7) habe ich ein Problem mit den Sonderzeichen. Eine Namensauswertung mit Newtonsoft.Json bringt in beiden Fällen "Taster ?" zurück. Hast Du noch einen Hinweis, wie man mit diesen Sonderzeichen umgehen kann? (da die Schnittstelle ja nur Namen kann)... Gruß EASY

Hallo, Gruß EASY

Hallo, noch einmal nachgefragt... bedeutet "zufällig", daß sich die Zeichenkombination innerhalb eines Ereignistyps ändern kann (es also [temporär] bezogen auf das Ereignis aber nicht auf den Ereignistyp eindeutig ist)? und man nur über die Auswertung von "name" auf den eigentlichen Ereignistyp schließen kann? Ich frage deshalb, weil unterschiedliche Ereignisse unterschiedliche Parameter zurückliefern und somit zur Gewinnung der Informationen aus dem Ereignis die Auswertung an den Typ angepasst werden muss. Gruß EASY

Hallo @Neo, bei der Auswertung von Ereignissen über die JSON Schnittstelle wird eine id (z.B. .... "id":"{3A3AC222-BE3D-40C0-AC6F-4FE760D61ACD}" ...) zurückgeliefert. Ich nehme an, daß diese id die Art des Ereignisses beschreibt (im Beispiel "Signal schaltet")... liege ich mit dieser Vermutung richtig? Wenn ja, gibt es eine Referenzliste welches Ereignis, welcher id entspricht? ... wenn nein, was bedeutet die id? Gruß EASY

Hallo, .... Du kannst das was @Neo geschrieben hat... local ReturnValue = $("Benutzerdefiniert"):invoke() $("Objekt").variables["Variable"] = ReturnValue auch in einem zusammenfassen... $("Objekt").variables["Variable"] = $("Benutzerdefiniert"):invoke() -- Variable = Benutzerdefinierte Funktion (... wenn das benutzerdefinierte Ereignis "Benutzerdefiniert" einen "return" - Wert besitzt.) P.S. was hinter einem "--" in lua steht gilt als Kommentar... ... dann entspricht es dem, was Du gedacht hast... Gruß EASY

Hallo, ... wenn es um das Auslesen / Setzen einer Objekteigenschaft geht, wie z.B. [momentan] Position, Rotation, Größe, Skalierung, das Setzen oder Auslesen von Objektvariablen. [weitere Beispiele] Schaltzustand, Geschwindigkeit... Das geht nur indem man über die Schnittstelle als lua-Skript das Objekt über den Namen anspricht "a=layout:getEntityByName('name') return a.Eigenschaft" bzw. "a=layout:getEntityByName('name') a.Eigenschaft=". Das große "Problem" beim Ansprechen von Objekten über die Schnittstelle gegenüber der EV ist, daß man nicht über die "Interne-ID" arbeiten kann. In der EV kann ich mit "$" und der Auswahl eines Objektes dieses eindeutig zuordnen, da dann der Name nur noch so etwas wie ein Pseudonym ist und sich dahinter die intern zugewiesene ID "versteckt" (ich hoffe ich habe dies richtig verstanden) und mit ($ "Quader").Eigenschaft kann es eben noch viele andere "Quader" geben. Ungünstiger würde es, wenn man über die Schnittstelle Ereignisse auswerten wollte... Bei z.B. "Gleiskontakt wird ausgelöst" kann man in der EV über "contact" und "vehicle" unabhängig vom Namen auf den richtigen Gleiskontakt und das auslösende Fahrzeug zugreifen. Die Schnittstelle liefert nur die beiden Namen zurück und man verliert somit den (absoluten) Bezug, der den eigentlichen Vorzug dieser Möglichkeit zunichte macht (was allerdings durch die Übermittlung der internen ID und der Möglichkeit derer weiteren Verarbeitung (theoretisch) ausgeglichen werden könnte (?)...) Soweit einmal meine ersten Gedanken zur Beantwortung Deiner Frage (ich sehe es einmal als Grundlage für eine weiterführende Diskussion...) Gruß EASY

Hallo, Es geht mir hauptsächlich darum einen "einfachen" Weg zu finden Objekte für die Schnittstelle eindeutig zu machen. Die Schnittstelle arbeitet ausschließlich mit Namen, ich bin also immer darauf angewiesen, daß die Namen eindeutig sind, damit ich ein Objekt ansprechen kann. Dein Vorschlag so etwas wie eine Vorselektion über die Guid zu machen, um nur die Objekte, die dieser Guid zugeordnet sind, eindeutig umzubenennen, bedingt, daß ich zusätzlich zu jedem einzelnen Namen, der zurückgegeben wurde, überprüfen muß ob dieser nur dieser einen Guid zugeordnet ist, was derzeit nicht möglich ist, "editor.getEntityContentID" liefert nur einen Wert zurück, auch wenn der Name in zwei unterschiedlichen Guids vorkommt. Natürlich kann man es als Haarspalterei betrachten (wer eine eine Pyramide in "Quader" umbenennt, ist selbst schuld, wenn es Probleme verursacht), aber das Prinzip der Uneindeutigkeit ist trotzdem gegeben und es ist ein Beispiel dafür, daß ich zuerst eindeutige Namen haben muß um (wie in diesem Fall) die Guid bestimmen zu können, oder allgemein um ein Objekt über die Schnittstelle anzusprechen... womit wir uns einmal im Kreis gedreht haben. Über einen Index bei der Vergabe von Namen von doppelt vorkommenden Objekten so zu vergeben, wie es den "Regeln" des MBS entspricht (Zusatz " (zahl)") erscheint mir deshalb sinnvoll, da das Programm (anscheinend) in der Lage ist, die nächste freie Zahl zu finden (so wie ich bisher gesehen habe machst Du es über "@Zahl")... P.S. wir verfolgen etwas unterschiedliche Ziele. Dein Projekt ist mehr darauf angelegt ein bestehendes Layout zu analysieren und mit bestimmten Funktionen zu belegen (also mehr ein statischer Zustand des Layout), mein Ziel ist es ein (wenn auch im Vergleich bescheidenes) Plugin zu machen, das zu jedem Zeitpunkt eingesetzt werden kann um z.B. eine Objektstapel zu erzeugen (dynamischer Zustand des Layout). Gruß EASY

Hallo @Neo, wenn ich z.B. über die JSON Schnittstelle die Position eines Objektes auslesen möchte, dann geht das ja nur über das Senden eines lua Skriptes... Dim script As String = String.Join("", "a=layout:getEntityByName('", name, "') return a.transformation.position") .. dabei bin ich darauf angewiesen, daß der Name im MBS einmalig ist. Wenn nun ein Name mehrfach vorkommt, muß ich zuerst alle gleichnamigen Objekte umbenennen und z.B. mit einem Index versehen. Wenn ich das JSON Kommando... {"jsonrpc": "2.0", "method": "editor.cloneEntity", "params": {"_class": "entity", "name": "Quader"}, "id": 1} ... versende, dann wird das so erzeugte Objekt der Namen vom MBS automatisch mit einen Index versehen. "Quader (2)" und wenn "Quader (2)" schon existiert mit "Quader (3)".... Dies führt mich zu der Annahme, daß es bei Dir im Programm eine Routine geben müßte, die den nächsten freien Index sucht. Mich würde hierzu interessieren, wie bei Dir dieser Index gefunden wird. Momentan habe ich 2 Methoden um den nächsten freien indes zu finden... Entweder lasse ich das Objekt klonen und lese mir den Index aus dem zurückgegebenen Namen aus, lösche den Klon, um dann dem doppelten Objekt den Namen mit dem Index zuzuweisen. (Nur mit dem Klon arbeiten und das "Original" löschen geht nicht, da ich nicht weiß ob das Objekt in der EV schon einen Bezug hat.) Oder ich erzeuge den neuen Namen mit dem Index, sehen nach, ob es schon ein Objekt mit diesem Namen gibt... Dim script As String = String.Join("", "return #layout:getEntitiesByName('", name, "')") und wenn ja, erhöhe ich den Index um 1 und spiele es so lange durch, bis ich einen freien Index finde. Beide Methoden haben den Nachteil, daß sie aus mehreren Kommandos bestehen um ein Resultat zu erhalten (Objekt mit eindeutigem Namen) und entsprechend langsam sind. Anmerkung: natürlich könnte ich auch stur alle gleichen Objekte mit einen Index versehen, hat aber den Nachteil, daß ich nie sicher sein kann, ob aus der Vergangenheit der Index nicht schon einmal vergeben wurde. Nun wären meine Fragen: Wäre es möglich auf Deine Routine über die Schnittstelle zuzugreifen? Siehst Du eine Möglichkeit, daß es so etwas wie ein Kommando "Object_ReanmeEqual" geben könnte? oder hast Du noch eine Alternative? Gruß EASY

Hallo @Neo, bei einem Versuch ist mir das Komma verrutscht. Dabei habe ich zufälligerweise festgestellt, daß ich kein Objekt auf eine Position setzen kann, die größer ist als 21750m (1:1) -> 250m (H0). Ich nutze dies bestimmt nie aus, aber da ich neugierig bin, gab es diese Grenze schon immer? Gruß EASY

Hallo, ... als kleiner Hinweis: mache doch unter "Feature Wünsche" ein neues Thema auf mit "Fehlende Kommandos JSON Schnittstelle" (oder so ähnlich)... Dies hätte zum einen der Vorteil der Bündelung (auch von anderen Anwendern [wie ich]) und zum anderen wird es von Neo besser wahrgenommen als im Forum unter anderen Themen verstreut... Gruß EASY

Hallo @gmd, manchmal braucht es etwas Zeit, bis man seine Ideen noch einmal überdacht hat... Eigentlich brauchst Du mit Neo nicht über "Text180" verhandeln. Ob man nun im Vorfeld im Modell den Text um 180° dreht oder das "normale" Textfeld um zusätzliche 180°, dürfte im Ergebnis keine Rolle spielen. Wichtig ist nur in beiden Fällen, daß erkannt wird, daß es notwendig ist (Benutzung oder zusätzliche Drehung)... Gruß EASY

Hallo, ... das ist nicht ganz so einfach. Bei geraden Gleisen geht es. Bei gebogenen Gleisen müßte man ja bei einer Drehung um 180° die Definition des Winkels im Vorzeichen umdrehen, was nur manuell gemacht werden kann. Noch schlimmer ist eine frei geformte Spline, die müßte manuell neu geformt werden. Es gäbe prinzipiell eine einfache Lösung... Es gibt 2 verschieden definierte Textfelder... "Text0" würde dem normalen Textfeld entsprechen, bei Text180 ist in der Definition des Textes, dieser doppelt gespiegelt. (Beide Darstellungen bei 0°) Wenn nun Dein Programm erkennen würde, daß das Referenzgleis um 180° gedreht ist, nimmt es für die Beschriftung "Text180" und ohne zusätzliche Drehung "Text0" Dies hätte den Vorteil, daß die Darstellung der Richtung z.B. durch das letzte Zeichen des Textes dargestellt werden könnte. ">" positive Richtung, "<" negative Richtung, "x" beide Richtungen. (Dies wäre durch den Anwender auch einfach editierbar) ... in beiden Fällen wäre die Richtung über die Beschriftung eindeutig feststellbar. (Auslesen des Textes über das mit dem Gleis verknüpften Textfeldes und Auswertung des letzten Zeichens) Das eigentliche Problem dabei ist nur, daß es "Text180" nicht im Katalog gibt. Ich habe es mir zwar selbst erstellt, hat allerdings den Nachteil, daß es eine fixe Größe hat und es bei längeren Texten Darstellungsprobleme gibt. Ob @Neo ein solches (dynamisches) Textfeld als eigenständiges Modell (Variante geht nicht, wenn Du das Textfeld über die ID in Deinem Programm aus dem Katalog einfügen möchtest) zur Verfügung stellen würde, müßtest Du mit ihm aushandeln. Gruß EASY

Hallo, noch ein Versuch der Interpretation: Ich (Anwender) möchte von A nach B. Im Idealfall sucht mir Dein Programm eine Strecke mit der ich einverstanden bin. Dann möchtest Du die beteiligen Blöcke dahingehend mit einem Hinweis versehen, in welche Richtung sie befahren werden (ist ja auch wichtig zu wissen, damit Signale auch so aufstellt werden, daß sie eventuell nicht von hinten "gelesen" werden). Aus weiteren Strecken würde sich ja dann ergeben, ob ein Block nur in einer oder beide Richtungen befahren wird. Du möchtest den Hinweis an einem Gleis innerhalb des Blockes "befestigen", so daß der Hinweis zwar der Orientierung des Gleises folgt, aber dies unabhängig davon ob das Gleis "normal" gedreht oder zusätzlich um 180° gedreht ist. ... hoffentlich nicht... und wir kommen der Sache näher... Gruß EASY

Hallo gmd, nach meiner Meinung mußt Du etwas differenzieren zwischen der Summe aller Möglichkeiten (alle Wege führen nach Rom) und den Möglichkeiten, die der Anwender dann nutzen möchte. Nehmen wir gedanklich einen 2-gleisigen Streckenabschnitt. Wenn man nur Ausgelegt ist auf einen schnellen Fernverkehr, dann kann man schon definieren, daß links bevorzugt von Nord nach Süd und rechts von Süd nach Nord gefahren wird. So kommt man sich nicht in die Quere und kann die Taktzahl erhöhen. Als Anwender könnte ich aber auch definieren, daß der rechte Abschnitt für den Güterverkehr "reserviert" ist ... kommt dem Fernverkehr nicht in die Quere (und es stört mich nicht, da der Fernverkehr sowieso eine geringe Taktzahl hat) dann wäre Deine "bevorzugte" Fahrtrichtung schon wieder hinfällig... was ich damit sagen will ist, daß bevor nicht festgelegt ist, wie die Strecke genutzt werden soll, eine Bevorzugung der Richtung nicht möglich ist. Vielleicht ein etwas einfaches Beispiel, aber ich hoffe Du verstehst wie es gemeint ist (und ich das was Du meinst, richtig interpretiert habe) Gruß EASY