Jump to content

EASY

Mitglieder
  • Gesamte Inhalte

    3318
  • Benutzer seit

  • Letzter Besuch

13 User folgen diesem Benutzer

Alle anzeigen

Letzte Besucher des Profils

Der "Letzte Profil-Besucher"-Block ist deaktiviert und wird anderen Benutzern nicht angezeigt.

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. Hallo @gmd, ich hatte mir mal eine Streckenverfolgung programmiert, die allerdings darauf basierte, daß die Gleise als solches zur Darstellung genommen wurden und farblich über die Zuweisung einer Tauschtextur farblich gekennzeichnet wurden. Mein Lösungsansatz für die Erkennung der Richtung war folgender: Ich habe mich (mit mir) darauf geeinigt, was die "positive" Fahrtrichtung ist. Bei meinem Startgleis habe ich dann nachgesehen, ob diese Richtung in Richtung Gleisanfang oder Gleisende zeigt. Wenn z.B. die Fahrtrichtung in Richtung Gleisende gezeigt hat dann war die Vorgehensweis folgende. Da das Anfangsgleis und das nachfolgende Gleis einen gemeinsamen Punkt haben (Gleisverbindung), mußte ich dann nur noch überprüfen ob das Ende des Anfangsgleises mit eine Anfang des nachfolgendem Gleis zusammentrifft (->Gleise haben gleiche Orientierung) oder ob das Ende des Anfangsgleises mit dem Ende des nachfolgendem Gleis zusammentrifft (-> nachfolgendes Gleis ist um 180° gedreht ). Somit konnte ich für jedes Gleis die "richtige" Richtung bestimmen... (Setzt allerdings "saubere" Gleisverbindungen voraus) ... ist allerdings schon etwas lange her (2016)... ... vielleicht hilft Dir das ja etwas weiter mit Deinem Fahrtrichtungsproblem... Gruß EASY
  12. Hallo gmd, ... es gibt immer wieder Diskussionen über die geringe fps beim MBS (im Vergleich zu anderen grafikintensiven Programmen). Da ich nicht so viel Ahnung dazu habe, möchte ich mir allerdings kein Urteil darüber erlauben... Gruß EASY
  13. Hallo @gmd, es ist zwar nicht ganz passend zu diesem Thema... aber vielleicht doch... Du hast hier deine "große Anlage" vorgestellt. Bei der Ansicht sind mir einige nicht ganz gute Gleisverbindungen aufgefallen (2D technische Zeichnung) ... vielleicht als Test, ob Dein Programm diese auch erkennt? ... und das "vergessene" Gleis... ... auch noch Gruß EASY
  14. Hallo, ... meine onboard grafikkarte (Itel UHD Graphics 730) schafft es immerhin in der totalen Ansicht noch mit 7 fps / 5 fps (Intel i5-11400 @2.6 GHz) P.S. da ich keine Anlagen baue, reicht mir das um mal in andere Anlagen rein zu sehen... Gruß EASY
  15. Hallo @Neo, das mit in der z-Drehung falsch angezeigte Gleis hat eine interessante "Eigenschaft"... ... wenn man Duplikate so aufreiht... ... ist deutlich eine Steigung zu erkennen. Ein Duplikat... ... mit dem Manipulator y in die Länge gezogen zeigt dann auch die Steigung an... und die entsprechende Verdrehung in der x-Achse... ... wobei sich die Drehung in der z-Achse wieder (fast) normalisiert (-90°). (Das Gleis ist in seiner Grundorientierung 0° wieder y-orientiert) ... vielleicht hilft Dir das ja bei der Analyse des Problems... Gruß EASY
×
×
  • Neu erstellen...