Jump to content

Empfohlene Beiträge

Geschrieben (bearbeitet)

Hallo,
hier der naechste schritt in meiner definition the animationen/schalter wie auch immer man das nennt.

 

action_sequence.thumb.jpg.5efa4a7028cb713f0ac844c310c9c364.jpg

Ich definiere scenarien in meiner app, die als folge von aktionen (Animationen/Schaltern) ablaufen.
Scenarien sind zb. Aufruesten, Halt Bahnhof, Abfahrt Bahnhof, Rangieren, Wartung, Notfall Strecke, usw.
Die Aktionsnamen sind generisch und fuer alle modelle gleich. Ich verwende nicht nur An/Aus sondern unterscheide aktionstypen (Licht,Tuer etc.)
Auswahl einer aktion kann betriebsabhaengig sein, je nachdem in welcher richtung eine lok auf dem gleis steht ist es unterschiedlich welches licht
bei vorwaertsfahrt einzuschalten ist. Meine app weiss in welcher richtung fuer die lok vorne oder hinten ist. Ich habe zu jeder lok die info wie sie steht
wenn die koordinaten 0,0,0 und die drehung 0,0,0 ist. Loks werden meist 90 grad gedreht zu gleisen aufgesetzt, es gibt aber ausnahmen, -90 ist
dann gegenrichtung. Die App weis das , ich muss das nicht in scripten unterscheiden und auch nicht aufpassen wie ich die lok aufgesetzt habe.

Fuer jedes modell generiere ich einen mapper der meine "virtuelle" aktion/animation in den tatsaechlichen string umwandelt und in einem script als
parameter einsetzt.
Nicht alle aktionen sind fuer alle modelle vorhanden oder auch nicht unbedingt integriert (Zuglauschilder). Manche aktionen werden durch scripte
simuliert, oder durch eigene modellanimationen  ersetzt (weite zukunft).

Zu beachten ist: Diese aktionen laufen nur ab wenn eine kamera auf das objekt focusiert ist. Ansonsten ist das ja verschwendung von rechnerleistung.

Die Aktionsnamen stellen eine art standardisierten schalternamen dar, und ich bin gerne bereit meine liste fuer die verschiedenen typen zur diskussion zu stellen, und auch meine namen and einen konsensus anzupassen, aber bis so etwas existiert, werde ich weiter mein mapping benutzen.
Werde von zeit zu zeit weitere sequnzen posten, derzeit implementiere ich weitere anzeige funktionen die mir helfen vollstaendigkeit zu ueberpruefen und die mapper zu erzeugen, fuer die ersten beispiele.

Gruss
Gmd

 

 

 

Bearbeitet von gmd
Geschrieben
vor 7 Stunden schrieb gmd:

Diese aktionen laufen nur ab wenn eine kamera auf das objekt focusiert ist

Gute Idee. Das muss ich bei meiner (konventionellen) Programmierung auch noch einbauen.

Geschrieben
51 minutes ago, HaNNoveraNer said:

Wie willst du denn rausfinden, ob das Objekt irgendwo am Bildschirm mit angezeigt wird? :)  Das wäre ja eine LOD Stufe für Animationen. 

die aussage bezog sich auf scenarien, nicht einzelne animationen.. die app controlliert die camera views.
gruss
Gmd

Geschrieben
vor 1 Stunde schrieb HaNNoveraNer:

Wie willst du denn rausfinden, ob das Objekt irgendwo am Bildschirm mit angezeigt wird?

Ich programmiere wie gesagt konventionell - und weiß auch ganz genau, wo "die" Kamera (es gibt natürlich viele zwischen denen umgeschaltet wird) gerade hinschaut. Mit einer konventionellen Programmierung kann man aber bestenfalls ein größeres Diorama mit einer begrenzten Zahl von Zügen steuern. @gmds Ziel ist es, eine Anlage beliebiger Größe mit beliebig aufzusetzenden Zügen in den Griff zu bekommen.

Geschrieben (bearbeitet)

Das thema visualisierung von ablaeufen is noch ein anders. Ich arbeite nicht nur mit den Mbs kameras.
Die maus controlliert das viewport (sicht auf die anlage). Nun stellt euch mal vor ihr habt zwei joysticks, wie bei der steuerung fuer eine drone und zwei einstellraeder fuer zoom und gimbal position (kamera hoch und runter) und damit steuerst du die sicht auf die anlage unabhaengig von kameras. Damit kann das programm auch jederzeit jeden beliebigen blickwinkel reproduzieren. Grundfunktionen dieses knozepts verwende ich zur position von objekten auf weissem hintergrund zur erstellung der seitenbilder oder auch die screenshots fuer die animationen (steuerungsfenster).
Der phantasie sind da keine grenzen gesetzt.
Gruss
Gmd

Edit: Hier ein beispiel joystick_driver

Bearbeitet von gmd
Geschrieben (bearbeitet)

Hallo,
heute mal wieder ein filmchen. Habe mir ein testbett gebaut, um die schlaternamen besser vergleichen zu koennen falls irgendwo problem enstehen. Ausserdem ist so eine einrichtung auch geeignet alle moeglich scripte zu testen, nicht nur schalter.

testBett_Animations.thumb.jpg.34c3a94effa3680b82e366aef74bfa01.jpg

Hier zunaechst das statische bild. unter dem mbs, mein Lua center mit allen verfuegbaren lua snippets (gruppiert bei objekttyp/funktion).
Die scripte sind direct als beispiel ausfuehrbar enthalten aber parameter definitionen die von meinem preprozessor ausgewertet werden.
Im film kann man sehen wie im script editor das eigentliche script aussieht bevor es als json message verschickt wird.
Rechts die objektauswahl, die viele zwecken dient, unter anderem seitenphotos zu erstellen oder die schalterliste zu photografieren, und
vieles mehr, ist auch die grundlage fuer meinen zugdesigner.
Nun hier ist der film, ich denke der sagt noch mehr was dies bedeutet. nur noch eines, hier wurde auch eine geteilte verarbeitung zwischen
Mbs und app eingesetzt. Das Mbs hat grundscripte geladen, die dann auch von der app angesprochen werden, also zum beispiel das
rotierende gleis ist mit Mbs Lua gemacht, waere ueber die schnittstelle einfach nicht performant genug.

Animation/Schalter Testing

Gruss
Gmd

 

Bearbeitet von gmd
Geschrieben

Hallo,
hier mal wieder ein update. Ein forummitglied hat die letzte version bekommen und erfolgrecih installiert und zum laufen gebracht, im wesentlichen als studienobjekt fuer seine eigene entwicklung zu steuerung einer echtanlage und Mbs als simulation. Die posts hier dienen auch als eine art dokumentation.

Zwei themen heute, Animationen/Schalter und blockerkennung oder allgemeiner, spurenerkennung.

Zunaechst Animationen

schalter_sort.thumb.jpg.98c8331b398bbed3ac066b31b3c3ee6c.jpg

Habe meine funktionen zur ordnung der animationen/schalter fertig. Kann gruppiere, sortieren, filtern und meine eigenen keywords hinzufuegen (gruppenweise) die dann als basis einer einheitlichen benennung dienen. Daraus wird dann ein mapper erzeugt der die "virtuellen einheitlichen" schalter auf die physisch vorhandenen schalter umlenkt, und vielleicht ist diese liste ja mal irgendwann leer, ich halte aber nicht den atem an :)

Nun zu blockerkennung. Weiter oben hatte ich ja schon beschrieben wie ich eine Tracer lok auf der anlage fahren lasse und ueber events das layout rekonstruiere. Das hat soweit auch funktioniert, ist mir aber einfach zu langsam und hat auch einen haken, es is nicht wirklich fuer strassen und auch nicht fuer isolierte spuren geeignet. Der gedanke kam in erster linie auch weil mein hirn nicht mehr so frisch ist wie es mal war :) .. und mein mathe kopf noch weniger. Nun habe ich mich aber doch durchgerungen mich wieder mit 3d geometrie zu beschaeftigen und lese die koordinaten,rotationen und geometrie informationen aus und errechne die verbundenen elemente. Und damit ich auch sehe was das passiert habe ich ein paar simple 3d klassen gesucht, die in meiner umgebung helfen ein 3d layout anzuzeigen, und zwar nur spuren, keine gleise, oder strassen etc. Lediglich zu dem zweck blockstrecken, unschuetzbare verbindungen usw zu identifizieren  und schliessendlich auch kontakte und signale automatisch zu positionieren.
Ich habe die routinen fuer gebogene und gerade spuren fertig und baue jetzt an den weichen (ist ja nur eine kombination der fertigen funktionen) und dann noch das flexgleis mit wer weis wievielen segmenten. Ist aber auch nur eine kombination schon vorhandener logik. Jetzt kann ich kuerzester zeit layouts einlesen und darstellen und konfigurieren und muss nicht mehr endlos lange auf die tracer lok warten, die sowiso nicht ueberall hinkommt. Wird interessant wenn ich das auf strassen mit x fahrspuren anwende, aber das ist noch zukunft .

spur_erkennung.thumb.jpg.c2ba3b436f9c5a0b99ff817d887521db.jpg
Hier ein beipiel der ausgabe, noch ganz elementar mit gleisnamen als label und mittelpunkte und endpunkte markiert.  Aus der moeglichkeit jetzt jedes gleis und jede strecke genau zu kennen, lassen sich natuerlich auch weitere funktionen ableiten, wie anzeige von streckenlaengen, berechnen von bremsbereichen usw.
Das ist ein wesentlicher schritt zur schnelleren streckenerkennung und verwertung.
Gruss aus dem warmen Australien. Im Nordosten hatten wir in 3 tagen einen meter regen .. nicht schnee aber regen. Weiss gar nicht was das in schnee waere , sowas wie 10m ? So wie derzeit in Japan.  -
Gmd

 



 

Geschrieben

Hallo,

ein update bezueglich des gleisplans.
gleisplan_mbs.thumb.jpg.297cb5483cd49b84f059fbbf90bc868f.jpg
Hier eine kleine testanlage .. Ist ein teil meine gesamtanlage 
gleisplan.thumb.jpg.3f5199c768861f4e2de777e9ad07ea73.jpg

und hier der ausgelesene 3d spur plan.
Die alte schnittstelle hat ein paar macken die man umschiffen muss.. mal sehen wie das alles mit der neuen geht.
Wird aber noch dauern bis ich das umgestellt habe, da ich ja jetzt erst mal diese neuen daten verarbeiten kann
und meine blockerkennung vorantreibe.
Einige weichen werden noch nicht richtig gezeichnet, aber das werde ich auch noch beseitigen. Der plan is auch
interaktiv, d.h. ich kann jedes spur segment selektieren und dann spaeter alle moeglichen funktionen dranhaengen.
es sind strassen mit gezeichnet, da die schnittstelle sie als gleise meldet, wie auch die spuntwaende und tunnelroehre,
aber das werde ich noch ausblenden, da ich ja alle guids kenne und mein katalog auch die typen kennt. Dann wird
das auch schneller, weil ich nicht immer das MBS fragen muss.
So ganz allmaehlich bekommt das ganze mehr form :), allerdings immer noch eine menge zu tun.
Gruss
Gmd


 

Geschrieben

Hallo,
mal wieder ein zwischenbericht. Ich arbeite ja an verschiedenen baustellen gleichzeitig, je nach lust und laune. Die letzten tage habe ich allerdings auschliesslich mit blockerkennung verbracht. Wie oben berichtet habe ich den gleisplan ausgelesen und gezeichnet, zur kontrolle im wesentlichen.
Dann habe ich funktionen gebaut und mit consolausgaben getestet, was aber nur bis zu einem gewissen mass funktioniert. Dann habe ich erstmal weitere
anzeigenfunktionen gebaut, mit denen ich ergebnisse der analysenfunktionen besser pruefen kann, und auch interaktive elemente auf dem modell direkt auswaehlen kann.
GleisplanUebersicht.thumb.jpg.c225b1a348e455a436ebbbd5106ef8b0.jpg

Alle gleise eingelesen mit eindeutigen namen und allen eigenschaften.

BlockUebersicht.thumb.jpg.2f29dd440ebf4ba69e694e01be6c206c.jpg

Gleisstrecken und temporaere bloecke ermittelt. Hierauf aufbauend werden die steuerungselemente zugewiesen,
signale, bremskontakte, einfahr- und ausfahrkontakte, usw.

Blockverbindungen.thumb.jpg.8a4433ead2b0c0b853745b0f3a174ade.jpg

Blockverbindungen ueber weichen... und da ist noch ein fehler drin .. Diese info wird zur dynamischen
fahrstrassensteuerung verwendet.
Diese anzeigen werden spaeter nicht mehr wirklich gebraucht, wenn dann nur zur fehlersuche.

Ich habe weitere funktionen erstellt, die aber noch keine eigene anzeige haben, das kommt als naechstes.
Diese funktionen sind:
Erkennen isolierter weichen, d.h. weichen die nur mit weichen verbunden sind, die bekommen sonderbehandlung.
Doppelte gleise: erkennen wenn gleise uebereinanderliegen, kommt vor, ist ein abfallprodukt.
Erkennen parallele gleise und daraus parallele bloecke ableiten.  Daran arbeite ich derzeit.

Unde wenn ich parallele bloecke erkannt habe, dann folgt logischerweise:
Erkennen bestimmter gleismuster wie, ausweich gleis auf strecke, bahnhof harfe mit durchfahrt usw.
Aus dem erkennen der gleismuster werden dann die signale und kontakte abgeleitet, groessere bloecke werden je nach
laenge in unterabschnitte geteilt (parameter maximale zuglaenge).

Gruss
Gmd







 

Geschrieben

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)
Bild001.thumb.jpg.a61e660a781c5d009d27254c25f86b6f.jpg

Bild002.thumb.jpg.1ed2b7c339f1be5ad0e3fea47b2bd677.jpg

... vielleicht als Test, ob Dein Programm diese auch erkennt?

... und das "vergessene" Gleis...
Bild003.jpg.2f59c6fab8db2067339cb01ee872f934.jpg

... auch noch9_9

Gruß
EASY

Geschrieben

Ja Danke Easy

13 minutes ago, EASY said:

Hallo @gmd,

es ist zwar nicht ganz passend zu diesem Thema... aber vielleicht doch...

 

Passt schon :)
Ich baue nichts mit der anlage derzeit und habe sie in dem zustand belassen weil ich damit auch gut eine nicht perfekte anlage testen kann.
Bin noch nicht so weit das monster einzulesen, backe noch etwas kleinere broetchen :) .. aber die 2d sicht is gut, habe das ja gelernt. 
Habe auch festgestellt das gleise einen abstand haben koennen den man in 2D auch sieht und die Lok nicht stoppt. Solche abweichungen
verwende ich derzeit fuer meine geometrie tests.
Habe jetzt blockbeschriftungen gesetzt, kann gleiskontakte beliebig setzen und bin and the signalen mit der berechnung von punktverschiebungen entlang einer kurve 
fuer die positionierung von signale in beliebigen positionen einer kurve. Das gleiche wird dann fuer die oberleitungsmasten verwendet. 


Nochmals auf dein problem mit der schnittstelle zurueckzukommen. Ich habe die ersten generischen lua functionen als globale scripte im Mbs abgelegt und meine json strings dadurch dramatisch gekuerzt. Also zum beispiel die positionierung und transformierung passiert alles im Mbs, soweit das geht. Gleisgeometrie und andere funktionen gibt es ja nicht in Lua, das bleibt dann alles bei der schnittstelle, alt und neu.
Gruss
Gmd

 

Geschrieben

Hallo,
mal wieder ein kleiner zwischenbericht.

elemente_Plazieren.thumb.jpg.3cb76f67ec9548aef855da58e63c18ad.jpg

Nachdem ich den gleisplan einlesen und darstellen kann, hatte ich begonnen das layout zu analysieren. Ueberlappte gleise, nah aber nicht verbunden (in allen dimensionen), bloecke als strecken von gleisen zwischen weichen, weichen mit den angeschlossen bloecken pro spur und parallele bloecke. Das war der stand.
Der naechste schritt war meine geometrieberechnungen fuer das layout zu erweitern und objekte plazieren und verschieben zu koennen. Dazu habe ich testfunktionen in meiner gleisplananzeige gebaut, die visualisieren ob die berechnungen auch funktionieren. Die rote kugel bewegt sich entlang eines ausgewahlten gleises von anfang bis ende. 
Damit kann ich jetzt jedes objekt plazieren und dem gleisverlauf and jedem punkt anpassen.

 

Das war die voraussetzung fuer den naechsten schritt: Textfelder fuer blockbeschriftung (alle objekte koennen beschriftet werden - mit aus und einblenden fuer alle, bzw gruppen), Kontakte plazieren und verschieben (z.B. zwischen endpunkt und mittelpunkt des gleises), und signale plazieren und verschieben.  Das ist soweit alles fertig.
 

Naechster schritt ist, fuer bloecke einer gewissen mindestlaenge, einfahr-, brems-,halte- und ausfahrkontakte festzulegen. Die entsprechenden gleise zu beschriften und in meinem gleisplan farblich zu markieren. Waere schoen wenn das in Lua auch fuer das Mbs ginge. Weiterhin, ausfahr- und einfahrvorsignale automatisch zu setzen und verknuepfen und bei parallelen bloecken, die nebeneinander liegen die moeglichen gemeinsamen signalpositionen ermitteln fuer die ausfahrsignale. Habe immer noch keine idee wie ich die fahrtrichtung ermitteln kann ohne jeden block einzeln anzufassen, was die rueckfallstrategie waere uber eine funktion in meinem gleisplan.

Naechster schritt wird wohl etwas langer dauern, bin wieder oefter mit meinem motorrad hier in unserem schoenen suedwesten unterwegs. Viele tracks und waldstrecken zu erkunden und deswegen bin ich ja eigentlich hier. In Perth (nordoestlich)  hatten wir einen Tornado vor zwei tagen, einiges an schaden. Bei der tochter is ein baum runtergekommen (nur einer von vielen) und wartet auf mich zerlegt zu werden, neben anderen reparaturen.

Wuensche euch allen einen guten wahlsonntag und schaue gespannt auf Deutschlands zukunft.
Gruss
Gmd

 

 

 

Geschrieben (bearbeitet)

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)

10-Ergebnis.thumb.jpg.0b733ae89265cd344d0391d742ed250e.jpg

  ... ist allerdings schon etwas lange her (2016)...

... vielleicht hilft Dir das ja etwas weiter mit Deinem Fahrtrichtungsproblem...

Gruß
EASY

Bearbeitet von EASY
Geschrieben

Danke Easy,

Eine richtung, gegenrichtung moeglich, welcher block von zwei parallelen bloecken is hin oder rueck, oder beide hin. Ich weiss, ob parallele bloecke ueber weichen verbunden sind usw., aber all dies legt nicht wirklich fest in welcher richtung die zuege auf den unterschiedlichen bloecken wirklich fahren sollen ohne dass man irgendwo einmal die fahrtrichtung in einzelnen oder vielen bloecken festlegt und die anderen sich daraus ergeben. Was ich meinte ist wie ich die bevorzugte richtung in einem block fuer das programm erkenntlich mache, ohne dass ich alle gleise ausrichten muss. Das ist zwar auch automatisierbar, braucht aber auch wie du beschrieben hast die definition eines startgleises. Also ich muesste dann eine liste von startgleisen in verschiedenen bloecken haben um darauf aufbauend die richtungen aller bloecke bestimmen, was aber immer noch nicht moegliche gegenrichtungen erkennbar macht. Es geht ja hauptsaechlich auch um anlagen mit vielen weichenstrassen, wo das nicht immer so eundeutig ist.
Habe ich das jetzt besser erklaert oder klingt es immer nocht konfus. :)
Gruss
Gmd

   

Geschrieben

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

Geschrieben

Easy,

Ah wir reden aneinader vorbei .. Du hast es aber besser ausgedrueckt .. es geht ja darum wie der erbauer die bloecke nutzen moechte und nicht wie ich ohne jede angaben die richtung ermittle. Das ist ja nicht moeglich wie wir beide festgestellt haben nur verschieden ausgedrueckt. Bleiben wir also mal bei deiner erklaerung .. erster schritt ist nicht gueter oder fernverkehr , das kommt spaeter bei den blockeigenschaften, die erste angabe ist in welcher richtung der block befahren werden soll. Da wie du sagst viele wege nach Rom fuehren muss also irgendwo ein hinweis angebracht werden der definiert in welcher richtung ein block befahrbar sein soll oder auch in beiden ..
Kommen wir der sache naeher ?
Gruss
Gmd

 

Geschrieben

Hallo,

vor 8 Stunden schrieb gmd:

Kommen wir der sache naeher ?

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.
 

vor 10 Stunden schrieb gmd:

Was ich meinte ist wie ich die bevorzugte richtung in einem block fuer das programm erkenntlich mache, ohne dass ich alle gleise ausrichten muss.

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.

vor 8 Stunden schrieb gmd:

Ah wir reden aneinader vorbei ..

... hoffentlich nicht... und wir kommen der Sache näher...

Gruß
EASY

Geschrieben (bearbeitet)

Danke,
lass uns mal ein beispiel betrachten.
testcase.thumb.jpg.25db0caaa3aca6885cb01291ed3d4a09.jpg
Ob dieses beispiel sinn macht fuer "vernuenftigen" betrieb oder nicht sollte nicht das programm entscheiden. Wie du ja sagst, dass ist sache des anwenders. Festlegen durch fahrziele erscheint mir nicht praktisch zu beginn. Das programm soll ja nicht nur neue anlagen bearbeiten koennen, aber bei neuen ist das mit den zielen nicht immer eindeutig, janachdem wie man an die planung herangeht.
Theoretisch koennen in diesm beispiel alle strecken in gegenrichtung befahren werden. Ich habe zwar keine wendeschleife eingebaut aber der erbauer koennte ja zwei zuege in gegenrichtung aufsetzen wollen.
Die parallelen bloecke, nebeneinader, koennten ausweiche sein oder auch kleine bahnhoefe. Das programm kann das nicht entscheiden ohne weitere hinweise.

ausrichtung.thumb.jpg.1837a562b2f7209e58404ca052e38bb0.jpg
 Wenn ich dann meine blocklabels anschaue kommt dann die verbindung zu deinem vorschlag gemaess ausrichtung der gleise (oder eines gleises) zu entscheiden. Wie man erkennen kann sind die labels in der parallelen strecke entgegengesetzt ausgerichtet. Ich folge der ausrichtung des gleises (labels sind 90 grad verschoben gegenueber gleisen) und dadurch sind sie anders herum.

Wenn ich deinen vorschlag aufgreife koennte man nach der beschriftungsphase, die markierten gleise drehen, die labels folgen, und dadurch die richtung des blocks festlegen. Das ist einfach genug.

Jetzt fehlt noch eine markierung .. "Gegenrichtung moeglich", damit auch an beiden enden des blocks signale gesetzt werden.
Oder ich kann einfach sagen, "In der ersten version wird keine gegenrichtung ermoeglicht" ..

Die lables sind immer auf dem mittelpunkt des mittelgleises des blocks gesetzt. Die blocknamen sind temporaer zu diesem zeitpunkt, weil noch keine "Gebietsdefinition" stattgefunden hat. Generell moechte ich ja die bedingungen und regeln moeglichst einfach halten, damit sie nachvollziehbar bleiben.

Man koennte natuerlich weitergehen und aus einem grundmodell mehrere scenarien berechnen und anzeigbar machen und der ersteller kann dann eines auswaehlen und verfeinern. Das klingt aber nach viel mehr aufwand und geht wohl fuer eine erste version zu weit. Ich will ja erst einmal alle funktionen einmal durchgaenging angewendet haben. 

Dieser letzte satz bringt mich dann eigentlich zu der entscheidung, keine gegenrichtung zuzulassen und die markierten gleise als richtungsanzeige zu verwenden, damit erst mal eine entscheidung getroffen ist und ich mit der naechsten phase beginnen kann.

Was meinst du dazu ?

Gruss
Gmd



 

Bearbeitet von gmd
Geschrieben (bearbeitet)

Hallo,

vor 9 Stunden schrieb gmd:

Wenn ich deinen vorschlag aufgreife koennte man nach der beschriftungsphase, die markierten gleise drehen, die labels folgen, und dadurch die richtung des blocks festlegen. Das ist einfach genug.

... 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...
Bild001.jpg.bf4d2f3a0239dd96c87aa6b34e26b296.jpg
"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"
Bild002.thumb.jpg.9c504fded54317fc73bad235ac99bb91.jpg

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)

Bild003.jpg.52c9802c4b6a61f41aff2f871ed541bb.jpg

Bild004.jpg.5faba9de1e46ad0bb74451e92726f2ae.jpg

... 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

 

Bearbeitet von EASY
Geschrieben

Vielen, vielen dank fuer deine zeit und muehe.
Jetzt muss ich erst mal nachdenken, auf jedenfall genug anregung.
Gruss  und schoenen Sonntag
Gmd

Geschrieben

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

Geschrieben
6 minutes ago, EASY said:

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

Ja das habe ich verstanden, und wenn wuerde ich mit Neo auch nur ueber wichtigere dingen verhandeln wollen, z.B. die erweiterte gleisgeometrie in der neuen schnittstelle, oder funktionen zur positionierung vom objekten, die ja alle im Mbs vorhanden sind. Wuerde viel platz und aufwand in den scripten sparen ..
zum beispiel eine funktion wie "Signal snap onto gleis at (-)xxx offset from midpoint", oder create object:Guid:VariationName oder nummer.
Gruss
Gmd
 

Geschrieben

Hallo,

vor 34 Minuten schrieb gmd:

zum beispiel eine funktion wie "Signal snap onto gleis at (-)xxx offset from midpoint", oder create object:Guid:VariationName oder nummer

... 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

Geschrieben
4 minutes ago, EASY said:

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

Ja mache ich, wenn ich genau weiss was mir wirklich fehlt, hatte ich ja schon angefangen, und dann versuche ich ja auch nur wirklich dinge zu listen, die nicht nur fuer mich sinn machen wuerden.
Gruss
Gmd
 

Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren

Du musst ein Benutzerkonto besitzen, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen.

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde dich hier an.

Jetzt anmelden
×
×
  • Neu erstellen...