gmd

Also das mit den portalen ist halbgar. Ich habe mir eine reihe von hilfsfunktionen gebaut, unter anderem positionieren portale an gleisenden (werde mal wieder ein filmchen machen), aber verbinden ist wohl nicht das gleiche wie verknuepfen und geht wohl nur im aufbau und nicht zur laufzeit ueber steuerung. Also keine dynamische steuerung der teleporterstrecke bis jetzt. Naja, es wird ja hoffentlich V9 und V10 und V11 geben und vielleicht kommt ja der weihnachtsmann und baut das ein. Also wenn ich in meinem programm einen blockabschnitt als "Beamer" definiere, dann kann ich wohl alles plazieren bis auf das "Verbinden" zur anderen seite. Naja irgendetwas muss man ja noch von hand machen . Ich habe die elementaren plazierungsfunktionen fuer signale, kontakte, depots und portale soweit fertig und dabei ist aufgefallen, dass die objekte aus dem katalog in unterschiedlichen richtungen plaziert werden, d.h. der/die modellbauer haben keine einheitlichen ansatz in der plazierungsrichtung der objekte. Ist schon bei wagen aufgefallen. Wenigsten scheinen signale innerhalb der gruppen konsistent zu sein. Lichtsignale habe andere position wie formsignale und auch sperrsignale, aber innerhalb der gruppen sind sie gleich; habe nicht alle signale getestet. Beim manuellen aufbau faellt das nicht weiter auf, beim automatischen plazieren aber wohl. Ich merke mir jetzt fuer jedes objekt die ausrichtung bei der erstplazierung und drehe entsprechend der verwendung. Das funktioniert soweit. Jetzt kann ich die blockerkennung weitermachen und dann alle kontakte und signale, entlang der abgefahrenen strecke, automatisch plazieren und benennen. Das ist ja erst mal das eigentliche ziel. Die gesamte streckenfuehrung abzufahren und zu definieren und hoffentlich verwendbare einheiten eines GBS zu erzeugen, die dann manuell nachbearbeitet werden koennen um sie zu verdichten. Aber vielleicht gelingt mir da auch ein konzept. Ich habe vor urzeiten mal einen platinenrouter geschrieben und ein gbs ist ja eine vereinfachte form eines platinen layouts. Mal sehen, kommt aber sicher erst nach der fahrplanerstellung mit string diagrammen. Filmchen kommt noch. Gruss Gmd Noch eine ergaenzung: Das mit dem gleisende fuer portale und der deaktivierung einer moeglichen weiterfuehrenden spur funktioniert. Man hat also die moeglichkeit einen zug durch das portal weiter auf dem gleis fahren zu lassen oder bei deaktiviertem nachfolgegleis den zug ins verbundene portal zu schicken. Das ermoeglicht ja auch noch einige variationen. Und dann war da noch die sache mit der gleislaenge; anscheinend werden die gleise in der breite aneinandergelegt Das informationsfenster zeigt breite statt das was man intuitiv als laenge sehen wuerde.

Habe damit experimentiert, bin noch dabei mit scripten dynamische zuweisungen zu realisieren. Denke schon dass ich das hinbekomme. Ist sicher einfacher als das ueber scripte zu loesen. Ein problem allerdings ist, dass es ein endpunkt sein muss sonst faehrt der zug einfach durch das portal weiter (ist vom ansatz ja logisch). Ich test das temporaere deaktivieren von fahrspuren hinter dem portal wenn ein fahrzeug kommt dass gebeamt werden soll und danach wieder aktivieren fuer durchfahrt. Werde weiter berichten. gruss gmd

Heute das filmchen zu dem gestrigen bild. https://teutanic.com/Startposition.mp4 Die bildanordnung habe ich vorher gemacht. Im letzten film hat man ja gesehen wie das passiert. Ich habe "Bequemlichkeitsfunktionen" eingebaut, wie das automatische benennen der komponenten des zuges, die vorbelegung der namen der wesentlichen komponeneten eines "Startblocks", zielzuordnung usw. Die beschriftungen koennen erzeugt und entfernt werden und dienen zur besseren orientierung und kontrolle. Zuege plazieren und wieder entfernen, beschriftung entfernen, definitionen belassen um eine neue konmfiguration zusammenzustellen ohne nochmals alles einzugeben usw. Etliche dinge, die ich hier gar nicht gezeigt habe. Einiges von dem gesehenen ist durch Lua scripte gemacht, die von der externen schnittstelle gestartet werden. Ziel ist es mit moeglichst wenig eingaben, moeglichst viele notwendigen definitionen zu erschlagen. Derzeit werden die entscheidenden komponenten (startgleis, richtungskontakt usw. noch manuell benannt und muessen stimmen. Der naechste schritt wird jetzt sein die blockerkennung zu erweitern und die sogenannten "StartBloecke" automatisch zu erkennen und benennen, sowie die kontakte und signale zu plazieren. Die beschriftung ist dann die kontrolle ob alles passt. Ok, wozu ist das gut .. zum Beispiel: Ich moechte reale depots haben mit vielen zuegen drin, die ich genau spezifizieren und zusammenstellen kann. Diese depots koennen als schattenbahnhof (kopf oder harfe) aufgebaut sein und verdeckt sein, sie koennen in der luft liegen und unsichtbar sein oder auch real auf der anlage, vielleicht auch in einem groesseren gebirge. Die anzahl the startgleise ist nicht wirklich begrenzt und es muessen auch keine wirklichen ausfahrten zusammenfuehren wenn man nicht will (im verborgenen natuerlich), und ein "Transfer" kontakt "beamt" einen zug dann an einen punkt an dem er sichtbar werden soll, wagen fuer wagen. Ein anderes Beispiel ist, wenn eine anlage immer zu einem ausgangszustand gesetzt werden soll und man 50 oder mehr zuege nicht von hand programmieren will. Startbloecke koennen irgendwo auf der anlage liegen, die einzige bedingung es sollte relativ gerade sein und ausreichend lang um den laengsten gewuenschten zug aufzunehmen. Bei kurven muss ich mein verfahren erweitern. Also bahnhoefe sind das typische beispiel fuer reale startdepots. Ein weiterer anwendungsfall den ich dann angehe sind rangierkonfigurationen, wagenkolonnen vor und hinter einem abrollberg, usw. Also ueberall wo rollmaterial positioniert werden soll und man das nicht alles haendisch machen will oder auf grund der anzahl einfach nicht sinnvoll kann. Das wars fuer heute. Der naechste schritt ist hoffentlich die automatische konfiguration eines startdepots. Frohe Ostern. gruss Gmd

Heute ein bildchen. Bin einiges weiter mit der Lua anbindung. Vom programm kann ich die beschriftungen erzeugen und mit einem Lua script positioniere ich sie an die richtige stelle. Koennte das auch ueber die schnittstelle machen, aber mit dem script bin ich glaube ich naeher an moeglichen zukuenftigen funktionen. Zugziele koennen gesetzt werden, was ich verwenden werde um dies jeweils bis zum blockende zu tun. Fahrstrassen werde ich nicht verwenden, sie bieten mir keine wirklichen vorteile ueber meine eigenen ideen hinaus. Sie sind gut fuer kleinere manuelle anlagen, aber wenn es wirklich zur sache geht ist die definition zu muehsam und ich habe keinen weg gefunden fahrstrassen mit Lua anzulegen. Vielleicht habe ich etwas uebersehen, aber Neo hat einmal gesagt dass Lua fuer die steuerung da ist und die fahrstrassendefinition ist bauphase und nicht ablauf, also gehe ich davon aus dass es keinen weg gibt diese ueber ein script zu definieren. Anders ist es ja mit dem zugziel. Das kann ich ja mit einem script setzen. Ich werde nun einige kommandos fuer die schnittstelle definieren und mit Lua scripten auf der MBS-seite realisieren. Bin gespannt ob es da mal zu einem flaschenhals kommt. Ich habe drei wege mit denen ich die kommndoverarbeitung auf der MBS seite starten kann. Ein taster, der nur asynchrone aktionen abarbeitet, einen langsamen und einen schnellen timer, die bei bedarf angeworfen werden (ueber ein taster kommando). Je nach bedarf werden dann kommandos unterschiedlich uebertragen und verarbeitet. Rueckmeldung findet ueber variablen statt, die mit Event 60 von der schnittstelle gemeldet werden. Parameter uebergebe ich an objektvariablen ueber die externe schnittstelle. Das funktioniert soweit hervorragend, interessant wird es erst wenn da mal richtig durchsatz verlangt wird. Jedenfalls lassen sich so alle prinzipiellen funktionen realisieren, die ich derzeit im sinn habe mit einigen wenigen einschraenkungen. Wie erwaehnt die fahrstrassen und auch die variationen, die ich nicht erzeugen und erkennen kann, sondern die manuell nachgebessert werden muessen. Aber das stoert mich derzeit nicht in meinem denken. Wenn ich einige weitere scripte fertig habe, werde ich mal ein paar zur durchsicht posten. Vielleicht hat der ein oder andere ein paar ideen, wie man sie verbessern kann. gruss Gmd

Mal wieder ein update. https://teutanic.com/zug_positionieren.mp4 Zeigt mehrere dinge. Einzelne fenster aus dem rahmen loesen und anordnen wenn man platznot hat. Mit groesserem oder mehreren monitoren ist das ja kein problem. Zusammenstellen eines zuges, musste natuerlich der BigBoy sein .. Benennen der komponenten,kann man natuerlich auch einzeln tun. Eingeben des gleisnamens fuer den anfang der plazierung und die anfangsdrehung der lok (haengt vom modell und drehung ab. Werde daran noch arbeiten. Das plazieren und die tatsache dass ich keine variationen automatisch plazieren kann, deswegen stimmt das bild im programm nicht mit dem bild auf der anlage ueberein. Da muss man mit hand nacharbeiten wenn die variationen gewuenscht sind. Ein weiterer punkt ist nicht offensichtlich. Ich habe die ersten schritte zur eigenen kommunikation mit dem MBS gemacht. Ich kann kommandos senden, die dann lua scripte aktivieren und all die dinge tun die ich nicht ueber die schnittstelle tun kann oder will. Die lua scripte sind generisch und universell verwendbar, d.h. ist habe eine basisanlage, die alle komponenten enhaelt die benoetigt werden. Die kann mann kopieren und dann darauf aufbauen. Alles andere wird zur laufzeit parametrisiert. Die zuege koenen gespeichert, ausgeblendet, geloescht oder auch auf den anfangspunkt zurueckgesetzt werden. Die kleinen roten tabs ueber dem erstellten zug stellen die kupplungen dar. Die koennen als loesbar oder fest definiert werden. Wenn fest ist kein roter tab zu sehen. Dann kann speter beim rangieren die konfiguration nur dort getrennt werden wo ein roter tab dies erlaubt. Genug fuer heute. Wird jetzt eine weile dauern bis ich wieder poste, da ich jetzt erst mal eine ganze menge mit dem MBS testen muss und Lua scripte schreibe, fuer alle moeglichen situationen. Ich muss sehen ob ich die MBS fahrstrassen verwende oder nicht und kontakt und signal plazierung muss ich auch noch automatisieren. Aber es geht voran. Gruss Gmd

Ist wirklich gute arbeit, hat viel geduld gebraucht die unglaublich vielen elemente zu verwalten und zu testen. Hat mich weiter motiviert mein steuerungsprogramm zu bauen und ablaeufe wie du sie gezeigt hast zu automatisieren. gruss Gmd

ok guys, danke fuer die antworten. Wie gesagt ich kann damit leben, war nur etwas irritiert zu beginn. gruss Gmd

102;(6001)@G114; 1;-61.89042;-178.1079;2.980232E-8 104;(6001)@G114; 1;0;0;-29.85089 Das ist das startgleis auf dessen koordinaten ich aufbaue. die z rotation ist positiv im Positionierungsfenster und ich bekomme einen negativen wert. Mit Putty getestet und mit dem programm. Wird spaet, ich gehe ins bett, bis morgen. gruss Gmd

Neo, es sieht so aus dass bei der rotation (kommando 104,105) ueber die schnittstelle das vorzeichen vertauscht wird. Die anzeige im positionierungsfenster ist -1 mal was ich ueber die schnittstelle bekomme und umgekehrt. Eine neu position zu berechnen ist wie folgt: ( MBS_Drehung * -1 + weitere_Drehung) * -1 Das funktioniert und liefert auch das gewuenschte ergebniss. Ich verwende 41 und 43 in einer kommandogruppe mit allen anderen kommandos. double porZ = (-1 * RotZ + (double)_zugKonfiguration.StartPositionRotation) * -1; command = "10;\n43;0;\n41;0;\n"; command += "134;" + ((RollingStockNamen)anItem).Guid + ";" + ((RollingStockNamen)anItem).BetriebsName + "\n"; command += "103;" + ((RollingStockNamen)anItem).BetriebsName + ";" + posX + ";"+ posY + ";" + posZ + ";\n"; command += "105;" + ((RollingStockNamen)anItem).BetriebsName + ";" + porX + ";" + porY + ";" + porZ + ";\n"; command += "11;\n"; Hier ein auszug aus dem code. Eine situation die ich loesen musste ist die tatsache, dass einige modelle um 90 grad gedreht sind wenn sie plaziert werden. Ich muss mir das merken welches modell zusaetzlich gedreht werden muss. Das gleiche habe ich aber auch mit einem endwagen, da muss ich auch die gewuenschte drehung merken. Das nur als hinweis, ich kann damit derzeit leben, oder mache ich etwas falsch ? gruss gmd

Sehr schoen, gutes verhaeltnis zwischen strassen, schienen und gelaende. Wirkt sehr ausgewogen und gelungene details. War ein verknuegen anzuschen. Gruss Gmd

Oh, wow, wow, wow ... da haette ich besser hinschauen sollen. Vielen, vielen dank ... this made my day .. Jetzt muss ich eine Ami Anlage bauen .. regards Gmd

Ich hoffe. Wie man ja sehen kann mag ich grosse projekte es muss immer eine herausforderung sein, oder challenge wie man hier sagt. Wenn ich das steuerprogramm fertig habe, dann habe ich ein anderes "Riesenprojekt" im Auge. Ich bewundere die Modellbauer hier, mit welcher liebe zum detail und motivation gebaut wird. Tolle sache, braucht auch viel geduld und ausdauer. Mein lieblingsmodell waere ein Challenger oder BigBoy, das waere (wird) mein naechstes projekt, wenn es bis dann noch niemand angegangen hat. Danke fuer den post. gruss Gmd

Hier mal wieder ein Filmchen. https://teutanic.com/ZugDesign.mp4 Die konfiguration von zuegen. Hatte ich ja schon in der alten version, ist aber jetzt mehr ausbaufaehig implementiert. Zuege werden abgespeichert und sind dann im depot (kommt als naechstes) verfuegbar und koennen dann auf designierte bloecke automatisch plaziert werden. Die seitenansichten der modelle erstellt das proramm auch automatisch. Alle komponenten eines zuges sind eindeutig benannt und alle zuege koennen dann jederzeit an einen ausgangspunkt zurueckgesetzt werden, entweder automatisch oder auf anforderung. Dann muss ich die blockbehandlung noch ausfeilen, signal und kontakt plazierung fertigstellen und dann kann es so allmaehlich an die generierung von LUA scripten und variablenlisten gehen, damit dann etwas betrieb entsteht. Danach kommt dann Fahrplan und Ablaufsteuerung. gruss gmd

Hallo Dieter, nichts falsch mit der Vorstellung. Mal jemand der sich fuer die Schnittstelle interessiert. Solltest du Fragen haben, dann kannst du mir jederzeit eine Message schicken oder auch auf dem Forum unter Extensions posten. Viel Spass, Gruesse aus Australien Gmd

Haha, gibt doch immer wieder leute, die was zu meckern haben. Nur zur klarstellung: Programmieren ist ein hobby fuer mich, hat nichts mit experte zu tun. Henry hat recht, MBS ist flexibel einsetzbar. Ich habe uber 7 Jahre einen grossen caravan gebaut (von grund auf) und das war auch nur hobby. Was ich tue ist open source und jeder der interesse hat kann das programm mit source bekommen. Also keine vermutungen dass ich irgend etwas anderes vorhabe. gruss Gmd

Ein weiterer kleiner schritt. https://teutanic.com/BaumDiagramm.mp4 Habe eine diagrammkomponente eingebaut und eine erste testanwendung implementiert. Einen einfachen baum, der die lokale katalogstruktur zeigt. Diagramme werden ein wesentliches planungswerkzeug werden mit dem man auf graphische weise strukturen und ablaeufe definieren kann. Mit dem baum ist gedacht fuer jeden knoten zum beispiel die menge der gespeicherten objekte anzuzeigen oder knoten zu unterdruecken, die keine objekte referenzieren. Damit bekommt man einen schnellen ueberblick. Ebenfalls moeglich ist die erweiterung oder verkleinerung der lokalen katalogstruktur pro anlage. Damit kann man overheads verringern und eine kompaktere verwaltung erreichen. Blaetter des baumes koennen zu aggregierten eintraegen zusammengefasst werden und vereinfachen die baumstruktur, wenn eine feinere aufteilung nicht benoetigt wird, aber mehr oder weniger in jeder kategorie ein eintrag vorhanden ist. Ein wichtigeres werkzeug ist die einfache zuordnung von katalogkategorien zu layern. Das programm hat eine netzstruktur fuer layer (mehr als nur eine hierarchie pder liste) und man kann katalogkategorien zu layern zuweisen. Mehrer kategorien koennen auf einen oder mehrere layer zugewiesen werden (graphisch). Damit is gewaehrleistet dass beim plazieren von objekten das programm automatisch eine layerzuordnung erzeugt, wenn man die anlage von zeit zu zeit scanned. Eine layerzuordnung kann typeorientiert und auch geographisch sein. Dies bedeutet ich kann alle fahrzeuge in einem segment auf einen oder mehrer layer legen und alle selektieren, ausblenden, loeschen, zurecksetzen, usw. ohne beim plazieren immer peinlich genau auf den aktiven layer zu achten. gruss gmd

Hier der naechste kleine video. https://teutanic.com/ObjektErkennung.mp4 Gibt einen eindruck wie die objekterkennung/umbenennung funktioniert. Ist ein kleines beispiel um das prinzip zu zeigen, funktioniert auch mit tausend und mehr objekten. Man kann auch die dokumentation sehen, die ich im programm integriert habe. Das ist fuer mich eine gedankenstuetze fuer die zeiten wenn ich mal eine laengere pause habe. Ist aber auch nuetzlich wenn ich mal eine weile nicht mehr an einem programmteil gearbeitet habe. Ausserdem macht das dokumentieren auch ablaeufe klarer und man merkt wenn etwas nicht so logisch oder effektiv ist. Sind noch einige punkte die mir nicht gefallen. Kleine displayfehler (man sieht im video dass manche buttons erst blank sind), aber auch die klarheit der symbolik (icons und deren anordnung). Die identifikation und klassifizierung von plazierten objekten hat viele moeglichen anwendungen. Eine der einfachsten ist das zuruecksetzen einer grossen anlage auf einen ausgangspunkt, d.h. alle beweglichen objekte werden an ihren startpunkt zurueckgesetzt, oder auch nur eine teilmenge. Erst mit der erstellung von grundfunktionen und der verwaltung werden komplexere aktionen moeglich. Wahrend ich diese grundfunktionen erstelle oder erweitere denke ich ueber die anwendungen nach in denen sie verwendet werden sollen. Aber auch umgekehrt, wenn ich eine anwendung im sinn habe, muss ich bestimmte grundfunktionen bereitstellen. Ich wurde gefragt warum ich das alles tue. Ich hatte vor langer zeit mal den TrainSimulator, war aber ziemlich schnell gelangweilt. Mir macht es keinen spass eine e-lok aufzuruesten und stundenlang durch irgendwelche landschaften zu fahren. Zu viel widerholung. Dann habe ich das MBS gefunden (V3 oder so - kann mich nicht mehr genau erinnern). Ich fand es einen guten ansatz und inzwischen ist es ja weiter gewachsen. Es macht schon spass eine schoene anlage zu bauen und ein bisschen betrieb zu machen, ich habe aber nur bedingt lust neue anlagen zu bauen oder eine anlage bis ins kleinste auszufeilen und steuerung auf dem niedrigsten level zu programmieren. Der ansatz des MBS ist sicherlich fuer die mehrheit geeignet, insbesondere die verpackung von Lua in eine grafische oberflaeche, ist mir aber zu muehsam. Ich hatte ja schon mal erwaehnt, dass ich eine groessere anlage vollstaendig mit fahrplanbetrieb automatisieren moechte und dann einen zug manuell durch die gesamte anlage fahren zu koennen, mit der kamera im cockpit. Einen streckenplan zu erstellen, vom streckenleiter freigaben zu beantragen und auf zufallsereignisse zu reagieren. Um das zu realisieren muss man ziemlich viel ueber die anlage wissen, insbesondere mit der derzeitigen externen schnittstelle. Allerdings ist sie ausreichend fuer das was ich vorhabe, auch wenn einige aspekte umstaendlich sind, wie zum beispiel das eindeutige benennen von objekten, da das MBS keine eindeutigen namen erzwingt, was ich ja verstehen kann. Es ist fuer die meisten funktionen nicht erforderlich. Ich habe aber fuer solche situationen ersatzloesungen geschaffen. Mal sehen wie weit ich komme. Gruss Gmd

Hier mal wieder ein update. Das video im vorigen Post zeigt das alte programm. Habe die meisten funktionen in dem neue rahmen eingebaut. Habe viele grundleistungen erweitert und dokumentation integriert. Alle fensterteile lassen sich herausloesen und neu andocken oder auch nicht, je nach situation. https://teutanic.com/BlockMonitorDemo.mp4 Hier ein video von der neuen oberflaeche mit den gleichen funktion wie bisher allerdings koennen jetzt beliebige bloecke gleichzeitig ueberwacht werden und auch andere funktionen sind erweitert. Alles ist multi threaded und ich arbeite jetzt and der Routen Erkennung und Fahrplan definition. Danach kommt die ablaufsteuerung mit der ausfuehrung des fahrplans. Ein stellpult kommt erst danach fuer manuellen eingriff. Der fahrplan wird mit einem regelkonzept (Json RuleEngine) implementiert und die ablaufsteuerung mache ich mit einem Actor/Message konzept ( Akka.Net) falls das jemanden interessiert. Werde nach und nach noch von anderen teilen kleine videos machen. gruss Gmd

Neo, habe weiter getestet und die info mit dem index hat geholfen, dass ich zumindest erkenne das ein objekt variationen hat. Ich teste einmal ob mehrere bilder vorhanden sind und merke mir das mit dem Objekt. Ich habe auch einen weg gefunden die variationen zu plazieren. Das funktioniert bis 4 wie du ja gesagt hast. Ist fuer viele faelle schon ausreichend. Wenn es mehr als 4 sind mache ich das einmal manuell. Ich muss eben einmal fuer eine anlage die verwendeten variationen benennen und dann kann ich durch duplizieren neue variationen anlegen und positionieren. Nur wenn eine variation noch nicht vorhanden ist kann ich sie nicht automatisch plazieren. Das ist aber nicht so wichtig da ich ja die anlagen nicht baue sondern nur vorhandene analysiere und verwalte. Ich kann auch durch einen bildvergleich fuer alle guid mit mehreren thumbs feststellen welche variation vorliegt und das objekt entsprechend benennen. Ich habe ja ohnehin alle images auch von der seite fuer meinen zug designer und kann dann durch farbvergleich die variation ermitteln. Ist schon wieder ein stueck weiter .. gruss gmd PS: Inzwischen ist mir die Idee gekommen, dass ich ja eine platte vorbereiten kann die alle variationen die ich haben will enthaelt, mit den richtigen namen und dann kann ich diese ja einfach "reinziehen" fuer die identifikation. Ist die anlage dann identifiziert kann man diese platte ja wieder loeschen. Das ist ausreichend fuer eine weile.

Zunaechst mal danke fuer die Antwort. Ich bin weiter an meinem Verwaltungs/Betriebsplanung/Steuerungsprogramm. Habe einiges ueberarbeitet. Ziel ist es eine sehr grosse anlage in allen aspekten verwalten zu koennen. Ich brauche dazu nicht viele grundfunktionen, muss nur darauf achten dass alle namen eindeutig sind. Ich kann damit verschiedene dinge erreichen, z.b. ganze anlagenteile austauschen, wenn sie "genau passen", anlagenteile ausblenden um auf verdeckte teile zuzugreifen und vieles mehr. Man koennte ja mit layern arbeiten wirst du sagen fuer diese beispiele, aber das erfordert dass man total konsequent mit der plazierung ist und die eindimensionale layerliste hat eben grenzen fuer komplexe anlagen. Ich habe die moeglichkeit objektreferenzen aufzubauen und sie eigenen layern und layergruppen zuzuordnen, die wiederum an gebiete und segmente gehaengt werden. Ich habe die moeglichkeit vorhandene anlage automatisch zu strukturieren und alle objekte aufzuteilen. Das geht alles prima mit den vorhandenen kommandos bis zu dem punkt dass ich information verliere (variationen), wenn ich objekte nur ueber guid und einen namen ansprechen kann, aber das objekt nicht mit einer variation plazieren kann oder erkennen kann dass es eine variation ist. Dies kann ich verhindern wenn ich manuell variationen den variationsnamen vergebe (im MBS) und selbst eine liste pflege mit guid und variationsnamen. Mehrere objekte des gleichen namens machen mir dabei keine probleme. Der erste schritt ist den manuellen aufwand im MBS zu verringern wenn die variationsbezeichnungen als name eingetragen werden. Das spart aufwand. Der zweite punkt ist es ein objekt als variation ueber schnittstelle erzeugen zu koennen oder als variation zu identifizieren, dann brauche ich keine zuordnungsliste zu pflegen. Das gilt auch fuer zugkonfigurationen mit vielen wagenvariationen. Diese punkte sind weder eilig noch extrem wichtig, es behindert mich nicht in meinem vorhaben, waere aber schoen wenn ich dann doch eine vollstaendige loesung hinbekomme. Ist eine anregung fuer die zukunft. Manche werden sich fragen was das ziel ist: Eine sehr grosse anlage automatisiert zu analysieren, vorgefertigte ablaufe anzuwenden und einen fahrplanbetrieb zu ermoeglichen und irgendwann vielleicht multiplayer. Was mich am meisten antreibt ist das ziel einen zug manuell in einer vollautomatisierten anlage zu fahren. Alle ablaefe muessen dynamisch korrigierbar sein, vielleicht (wahrscheinlich) regelbasiert und nicht algoriythmisch. Du hattest ja angedeutet die schnittstelle zu veraendern/erweitern/verbreitern (was auch immer), damit werden natuerlich meine moeglichkeiten verbessert, aber derzeit bin ich noch mit grundfunktionen beschaeftigt. Eine schoene funktion ware eine tauschtextur spezifizieren zu koennen zur temporaeren visualisierung bestimmter abschnitte, ich behelfe mir derzeit aber mit beschriftungsobjekten die ich automatisch plaziere und dann ein und ausblenden kann. Mein derzeitiger stand ist: Ich kann bloecke mit allen komponenten automatisch erkennen durch abfahren mit einem benannten fahrzeug. Gilt fuer schienen und strassen. Kann signal, kontakt, weichen und gleiszustaende fuer mehrer bloecke optisch anzeigen zur betriebskontrolle (wird dann das stellpult treiben). Ich kann signale und kontakte automatisch plazieren wenn in einer abgefahrenen strecke keine erkannt wurden, die strecke aber gesichert werden soll. Ich kann Fahrwege (bloecke mit geschalteten weichen) zu fahrstrassen kombinieren. Das beinhaltet rangierwege etc. Fahrstrassen koennen zu routen kombiniert werden, fuer die dann ein fahrplan erstellt werden kann. Ich kann Wagen/Zug konfigurationen erstellen und automatisch auf startgleise positionieren (hier schlaegt das variationsproblem zu). Fuer jeden erkannten block generiere ich automatisch einen schaltpultzweig (ausserhalb MBS) den ich in ein gesamtbild oder teilbild einsetzen und anpassen kann. (das ist noch nicht ganz fertig). Schaltpulte sind nach segmenten unterteilbar. Bei allem genannten natuerlich automatische eindeutige benennung aller teile. Depotverwaltung, fahrplaene und steuerungsablauf kommen dann. Wird etwa so laufen wie meine blockdemo mit generischen, vorgefertigten scripts die manuell eingebracht werden und dann ueber variablen von extern gesteuert werden. Es ist eine andere art von Rockrail mit tieferer integration mit dem MBS. Das programm hat sehr viele "Hilfsfunktionen" und ich war in letzter zeit beschaeftigt einen neuen rahmen fuer die programme zu schaffen und besser zu dokumentieren, da ich ja immer wieder pausen mache und leichter wieder reinfinden moechte. Die vorige version hat eine zweistufige struktur (Gebiet,Block) unterstuetzt, das habe ich erweitert auf (Gebiet, Segment und Block). Das nur mal als ueberblick. Gruss Gmd

Neo, in meinem verwaltungsprogramm bin ich jetzt etwas weiter und an einem punkt wo ich mehr informationen brauche. Ueber das api bekomme ich ja die thumb images aber nicht die variationen, da sie die gleiche guid haben. Was ist die URI fuer die variations images (thumbs). Desweiteren waere es toll wenn das MBS die namen der variationen automatisch uebernehmen koennte statt immer nur den namen der grundversion einzusetzen. Um die variationen zu identifizieren brauche ich mehr als nur die guid. Ueber info have ich die anzahl der polygone, die fuer variationen unterschiedlich ist. Komme ich ueber LUA and diese info ? Kann ich uber LUA den variationsnamen abfragen ? Dann kann ich das in eine variable stellen und abholen. Waere toll wenn du mir da auf die spruenge helfen koenntest. Danke Gmd

Neo, ich kann mich nicht erinnern ob ich das schon mal erwaehnt habe. Suche ware ohne ergebnis. In der liste der ereignisse fehlt die 152 Kontakt erreicht/verlassen. Nur zu info. Gruss Gmd

Das laesst sich alles ueber namen der elemente und variablen machen und mit generic scripts. Neo hat ja angedeutet dass die schnittstelle erneuert werden soll und im grunde "alles" ermoeglicht was das studio kann. Allerdings fehlen mir nur ein paar wenige Kommandos, das meiste mache ich ueber namen. Gruss aus Australien Gmd

Das einzige was mir als frage in den sinn kommt ist, warum du keine quertragewerke fuer die oberleitung benutzt hast. Ansonsten, toll, viele schoene details, sehr gut gelungen, tolle begruenung, sehr gefaelliges gesamtbild. Macht spass anzuschauen. Gruss aus Australien Gmd

Prima, das ist doch schon mal ein Ansatz. Danke fuer die Antwort. Ich bin am pruefen was fuer mich ausreichend ist, eine 4080 oder mehr. Das MBS als hobby ist sicher kein grund fuer eine 4090, waere aber ein nettes abfallprodukt. Das video rendering ist ja auch stark from inhalt abhaengig, ob viele 3d elemente ueberlagert sind oder nicht. Ich werde mal probieren ob ich deine aussagen an meinem monster anwenden kann. Gruss Gmd