gmd

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

Hallo, mal wieder ein kleiner zwischenbericht. 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

Ja Danke Easy 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

Da koennte man doch fast daraus schliessen dass die gpu nicht genug effizient eingesetzt wird, sonst muesste bei mir die anlage schneller sein. Also eine bessere gpu bringt dann nicht endlos viel mehr power. Habe allerdings keinen vergleich zwischen the Intel 730 und the Nvidia GTX 2060 .. ist vielleciht nicht mal viel unterschied. 2060 ist ja das low end der serie. Gruss Gmd

Hallo, ich bin auch auf der suche nach aussagen bezueglich CPU vs GPU power .. Habe die testanlage mal geladen da ich mal sehen wollte wie die sich gegenueber meinem monster verhaelt. Habe eine anlage die noch groesser ist und mehr objekte hat. Bei all diesen angaben bezueglich frames per second ist zu beachten welchen auschnitt man waehlt und wie gross auf dem bildschirm mit welcher aufloesung. Da sind die belastungen der CPU vs der GPU unterschiedlich. Ich kann die test anlage mit 16 f/s oder mit 7 f/s laufen lassen, je nach groesse the verwendeten flaeche oder des auschnitts. Habe keine high end grafikkarte nur eine alte 2060, aber eine schnelle cpu I9 mit 4.8 Ghz takt. Mein schwerpunkt war nicht gaming Der bildschirm is ein 5K monitor mit 5120x2160 native resolution 36". In meinem falls ist kein wirklicher unterschied in der frame rate bei stop oder laufender animation, schwankt bei 15-17 oder bei anderem ausschnitt zwischen 8 und 7 in beiden modi. Ich brauche eine schnellere gpu fuer davinci resolve und bin daran interessiert wie sich das auf das Mbs auswirken wuerde. Mein gefuehl sagt mir derzeit, dass da noch luft drin ist bei der nutzung der neuesten technologien fuer das Mbs. Neo mag mir da widersprechen, aber ich denke er reitzt die neuesten grafikkarten noch nicht wirklich voll aus. Natuerlich bring eine super gpu auch nicht viel wenn nicht der entsprechen prozessor dahinter steckt und der auf moeglichst vielen cores verwendet wird. Vergessen duerft ihr nicht dass typische games sehr viel weniger einzelne objekte zu berechnen haben mit hoher frame rate, auch wenn die grafiken oft sehr detailliert und plastisch aussehen, aber die anzahl der zu berechnenden schatten etc. ist drastisch geringer. Bin kein 3D spezialist und kann das nicht wirklich beurteilen, ist nur mein eindruck. Mein videoprogramm (davinci resolve) ist jedenfalls bei der erzeugung der ausgabe mit schneller gpu und viel speicher in der gpu sehr viel schneller, aber das rendern von movie frames mit einigen overlays ist dramatisch einfacher als das was das Mbs zu bewaeltigen hat. Man muss sich schon fragen wo the sweetspot liegt zwischen groesse und performance. Anbei ein kleiner movie eines auschnitts der anlage mit gestoppter und laufender lok. gruss Gmd Edit: Wen es interessiert findet mein grosse anlage hier C8C0F123-2017-42AC-9234-EC4F1814261A . Sie ist der grund warum ich mein prgramm baue diese anlage mal automatiche zu steuern mit allen moeglichen facetten, und wenn es sein muss auf drei rechnern laufen lasse, wenn einer nicht schnell genug ist. fs.zip

Danke , verstanden Gruss Gmd

good catch .. werde noch etwas testen, aber auf den ersten blick haette ich keine idee warum die rotation ein resize macht .. Mal sehen Gruss Gmd

das ist das ergebnis eines scriptes .. hatte es erst in json uber die schnittstelle und dachte es koennte daran liegen aber local ist es das gleiche local paramName='Textfeld' --["Name"] local paramBlock='Block# 1' --["Block"] local paramGleis='(6030)@-054' --["Gleis"] local t=layout:getEntityByName(paramName) t.text=paramBlock local g=layout:getEntityByName(paramGleis) local pos = g.transformation.position pos.z = pos.z+0.2 t.transformation.position = pos local rot = g.transformation .rotation rot.z = (rot.z + 90)%360 t.transformation.rotation = rot stoer dich nicht and den lokalen variablen, das sind nur anweisungen an meinen preprozessor habe das script an weiche schaltet gehaengt und wenn du das ausloest stehts du im dunkeln die entscheidende anweisung ist die letzte , ohne die zuweisung der rotation geht es irgendwie muss ich wohl gesaved haben, also nach dem laden ist sie immer noch dunkel. gruss Gmd dunkle_analge.zip

Die trefferquote by autos is wesentlich hoeher als bei loks und wagen. Bei loks gibt es wesentlich mehr funktionen, zumindest bei einigen, und nicht allzuviele gemeinsamkeiten bei der benennung der front, rueck, rot,weiss usw. Man muss schon einige keywords verwenden um da einiges rauszuholen, mal ganz abgesehen von vielen tippfehlern. Ich habe alle schalter fuer loks und alle wagen zugeordnet und immer dann wenn ich mal keine lust mehr habe an einer anderen sache zu arbeiten sortiere ich ein paar weitere keywords ein und naehere mich einem "Mapper" fuer alle schalter. Wird aber noch eine weile dauern bis ich da eine standardisierte liste habe. Ich bleibe aber zunaechst mal bei rolling stock, strassen sind noch viel weiter hinten auf meiner liste. Gruss Gmd

Sorry, folge da nicht.. ich sehe nicht die modelle ich sehe spuren .. wenn eine spur auf beiden seiten belegt ist sollte keine weitere andockbar sein, und dabei spielt es keine rolle zu welchem modell die spur gehoert oder auch nur virtuell. Ich habe Andreas so verstanden und nicht auschliesslich gleis an gleis. Jede spur hat eigene geometrie und anschluesse, auch bei weichen. gruss gmd

Hallo Neo, folgendes problem .. zwei gleise 6002 gleiche richtung , eines wird mit yaw 0 und das andere mit yaw -90 angezeigt. 0 ist falsch, 0 richtig ist perdendicular zu dem gezeigten gleis. Schnittstelle berichtet das gleiche. Mbs zeichnet korrekt auch nach neuem laden, falsche anzeige bleibt bestehen. Mein program hat damit natuerlich ein problem .. Anlage ist angeheftet. Das gleis mit dem falschen wert is durch ALT drag entstanden, ich konnte das aber nicht reproduzieren, habe es mehrfach versucht. Ist das erste mal dass mir das untergekommen ist. Kein wirkliches problem, gleis geloescht und neu erzeugt, done .. aber ich dachte vielleicht steckt mehr dahinter und es waere gut fuer dich das zu checken. Don't we hate this sort of thing as a programmer ! Gruss Gmd yaw_anomalie.zip

Neo hat ja schon angeboten den buffer zu vergroessern.. Gruss Gmd

In ettlichen jahren seit ich Mbs verwende habe ich da nie reingeschaut .. .. Mein gehirn arbeitet nicht 2D.. waere aber eine idee .. lol Danke fuer den tip .. Gruss Gmd

Ja, das waere wohl die beste loesung. Gruss Gmd

Nur als anregung gedacht, wenn Neo mal nichts zu tun hat .. lol Als abfallproduct meiner gleis- und blockerkennung habe ich funktionen, die eine anlage zunaechst einmal untersuchen ob doppelte oder ueberlappte gleise vorhanden sind. Diese bringen die kalkulation durcheinander. Es war erstaunlich wieviele doppelte gleise ich in meinen anlagen hatte und auch ueberllappende enden. Da bleiben die loks stehen, aber wenn das im tunnel oder schattenbahnhof passiert dann ist man am suchen. Doppelte gleise, also direkt uebereinander halten die loks ja nicht an, koennen aber bei oberleitungen und steuerungen probleme machen. Ich habe ueberlegt daraus einen plugin zu machen, ist aber einiges an arbeit, die ich eigentlich derzeit nicht investieren will, im MBS aber ist das sicherlich unendlich viel einfacher in der elementuebersicht eine warnung eizublenden. Einfach mal ein gedanke, kommt ja hin und wieder vor dass man in eine solche falle faelllt. Gruss Gmd

Neo, Easy, Testergebnis: String - nur teilweise zur veranschaulichung [{"jsonrpc": "2.0", "method": "editor.getEntityContentID", "params": {"_class": "entity", "name": "(6001)@-001"}, "id": 1},{"jsonrpc": "2.0", "method": "editor.getEntityContentID", "params": {"_class": "entity", "name": "(6003)@-002"}, "id": 2},{"jsonrpc": "2.0", "method": "editor.getEntityContentID", "params": {"_class": "entity", "name": "(6030)@-003"}, "id": 3},{"jsonrpc": "2.0", "method": "editor.getEntityContentID", "params": {"_class": "entity", "name": "(6003)@-008"}, "id": 4},{"jsonrpc": "2.0", "method": "editor.getEntityContentID", "params": {"_class": "entity", "name": "(6003)@-009"}, "id": 5},{"jsonrpc": "2.0", "method": "editor.getEntityContentID", "params": {"_class": "entity", "name": "(6030)@-010"}, "id": 6},{"jsonrpc": "2.0", "method": "editor.getEntityContentID", "params": {"_class": "entity", "name": "(6001)@-011"}, "id": 7},{"jsonrpc": "2.0", "method": "editor.getEntityContentID", "params": {"_class": "entity", "name": "(6001)@-012"}, "id": 8},{"jsonrpc": "2.0", "method": "editor.getEntityContentID", "params": {"_class": "entity", "name": "(6030)@-013"}, "id": 9},{"jsonrpc": "2.0", "method": "editor.getEntityContentID", "params": {"_class": "entity", "name": "(6036)@-004"}, "id": 10},{"jsonrpc": "2.0", "method": "editor.getEntityContentID", "params .......} ] habe 120 dieser commands erfolgreich versendet - getestet mit Putty Bei 160 macht die verbindung die kraetsche ... Verbindung abgebrochen durch server .. Habe nicht genau die grenze getest, wahrscheinlich buffergroesse .. 120 commands ist erstmal ok fuer mich .. alte schnittstelle benutze ich mehr aber mit der groesse kann ich zunaechst einmal leben. Langfristig waere groesserer batch laenge gut. Gruss Gmd

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. Alle gleise eingelesen mit eindeutigen namen und allen eigenschaften. Gleisstrecken und temporaere bloecke ermittelt. Hierauf aufbauend werden die steuerungselemente zugewiesen, signale, bremskontakte, einfahr- und ausfahrkontakte, usw. 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

Kann das jemand bitte fixen ? {19A4C617-603E-4066-A5FD-D49FA2BD54EF} - Anknickende Vorfahrtstraße rechts Bin nicht kleinlich was tipfehler angeht, aber hier macht es mir technische probleme beim migrieren von anlagen, wenn es frueher richtig war und jetzt nicht mehr. Auch haben viele strassen den name geaendert zu Stadtstrassen (mit sz natuerlich), das ist ok, aber tippfehler sind hinderlich. Gruss Gmd

Neo, danke, wie sieht das mit den return werten aus, ich nehme an die kommen als json zurueck und in der reihenfolge der kommandos, correct ? Werde das ausprobieren. Ich bin nicht mehr weit davon entfernt die blockstrukturen automatisch zu erkennen und alle benoetigten steuereinrichtungen automatisch zu plazieren. Werde weiter berichten, koennte ein plugin daraus werden. Auslesen des gleisplans mit allen informationen und zeichnen des plans in rund 30 sekunden, da sind noch einige einzelaufrufe drin. Habe noch keine zeiten fuer die plazierung von signalen und kontakten. Ich muss noch scripte bauen fuer die objektverknuepfungen. Aber alles in allem geht es vorran. Habe auch schon mit ueber 10,000 gleisen getestet, welches der ausloeser war zu optimieren wo ich konnte. Das beispiel oben hat 750 gleiselemente, ist also vergleichsweise klein. Sagen wir mal eine rohanlage mit 2000 gleiselementen mit allen signalen und kontakten zu versehen und die signifikanten gleise alle mit blockkennungen versehen in unter 3 minuten, das waere so mein naechstes ziel. Gruss Gmd

Neo, Ich bleibe mal bei diesem thread mit den rueckmeldungen bezueglich der neuen schnittstelle. Ein ganz wesentliches problem, abgesehen von einzelnen funktionen, ist die performance beim anlysieren von gleisplaenen und orgnisieren groesserer objektmengen, bedingt durch die abwesenheit der kommandogruppen. Ich kann natuerlich alle kommandos einzeln schicken, es funktioniert grundsaetzlich, aber der unterschied ist faktor 100 in der laufzeit. Ich habe limits festgestellt in der anzahl der kommandos pro gruppe abhaengig vom typ des kommandos und habe empirisch zuverlaessige werte ermittelt. Zum beispiel um fuer 500 objekte die koordinaten zu lesen brauche ich im gruppenmodus 103ms, transformationen lese ich in batches von 200, ebenenfalls um die 100ms. Das sind zeiten, die ich mit einzelkommandos niemals erreiche. Und das wird sich auch auf die steuerung auswirken, wenn eine entsprechende anzahl von operationen auszufuehren ist. Derzeit werde ich nur diejenigen funktionen umstellen die nicht zeitkritisch sind und die neue schnittstelle lediglich fuer scripte verwenden. Auch die verarbeitung von events ist durch das Json format langsamer geworden, wir reden hier zwar nur um wenige milisekunden, aber das addiert sich natuerlich bei tausenden von events. Meine app laeuft jetzt multicore und ich versuche zu optimieren wo ich kann. Eine weitere funktion, die ich vermisse, ist lesen objektypen, also die moeglichkeit alle gleise zu lesen und nicht nur uber die selektion. Die alte schnittstelle sendet zwar viele objekte die nicht typ 1 sind auch wenn ich nur nach typ 1 frage, und hat auch fehler bei denen falsche typen zurueckgegeben werden, aber das filtern ist immer noch schneller als bei einer gesamtselektion, da die anzahl der gleise in der regel deutlich geringer ist als die anzahl der nicht gleise. Es stellt sich halt die frage, wie du die verwendung der schnittstelle in zukunft wirklich siehst. Fuer mich ist die alte schnittstelle in vieler hinsicht einfach besser, und wie erwaehnt, das senden von scripten ist eine gute sache. Ich sehe die neue schnittstelle nicht wirklich als realzeitsteuerung fuer groessere anlagen. Die voraussetzung dafuer sind einfach kommandogruppen. Du wirst moeglicherweise auf die verwendung von scripten hinweisen, die zur laufzeit als eine art kommandogruppe verwendet werden koennen, und ich werde auch ausprobieren wo da die grenzen sind, fuer die kontruktionsphase ist die alte schnittstelle jedenfalls noch nicht ersetzbar. Du koenntest zum beispiel {"jsonrpc": "2.0", "method": "editor.getEntityContentID", "params": {"_class": "entity", "name": "BD_W3-E"}, "params": {"_class": "entity", "name": "BD-AG-B07"}, "id": 1} verarbeiten, wie bei gruppierung usw. Das kommando wird nicht zurueckgewiesen, liefert aber nur eine guid, was ja nicht ueberrascht, wenn man den namen der funktion betrachtet. In summe, mit alter und neuer schnittstelle habe ich alle funktionen, die ich fuer meine app brauche. Ich erwarte auch nicht dass du wegen mir funktionen einbaust, die nicht deinem langfrisitigen konzept entsprechen, aber wie schon gesagt, es kommt letztlich darauf an wozu die schnittstelle gut sein soll. Jedefalls bin ich dankbar, dass du die alte schnittstelle nicht gleich ersetzt hast, sondern dass ich beide parallel nutzen kann in der V9. Gruss Gmd

Es hat mich einfach mal interessiert ob ich vielleicht rocrail format benutzen kann um meine gleisplaene zu speichern, habe allerdings festgestellt dass das nicht viel bringt. Rocrail hat einen grundsaetzlichen designfehler in der datenstruktur und zwar sind layout und controllinformationen vermischt . Ich koennte einen gleisplan vom MBS exportieren und in Rocrail einlesen, aber ohne jeglichen weitern informationen und dabei gewinnt man nicht wirklich viel. Layout muss reduziert werden, bloecke definiert usw. . Man muesste fahrstrasseninformationen aus dem Mbs in rocrail kontrollstrukturen umwandeln und da fragt man sich dann warum .. Mbs ist wesentlich flexibler und hat ein GBS und Rocrail hat einfach eine andere zielsetzung und ursprung und meiner meinung nach ist es einfach voellig veraltet und ein undurchsichtiges sammelsurium von funktionen geworden im laufe der zeit. Jedenfalls sieht das fuer mich so aus, und was mich am meisten stoert ist dass es so wenig intuitiv ist. Man kann nicht viel sinnvolles tun ohne dokumentation zu lesen, und das stoert mich nun mal unendlich. Sorry for the rant.. Gruss Gmd

Neo, du hast mich mal gefragt was mir an der neuen schnittstelle fehlt und ich war noch nicht vollstaendig im bilde. Das bin ich zwar immer noch nicht , aber zumindest kann ich jetzt eine funktion nennen die mir in der neuen schnittstelle fehlt. 303;name;0;1 also extended geometrie mit allen segmenten aus der alten schnittstelle. Warum ? : wenn man ein Katalogkleis mit dem editor verbiegt und verlaengert, verkuerzt, etc. dann kann man das nicht erkennen. Ich kann keine flexibel verlegten gleise erkennen (selbe guid wie original, und auch nicht anders gekennzeichnet). Das ist fatal fuer meine blockerkennung und auch die plazierung von steuerobjekten, da kein durchgaengiger gleisplan errechnet werden kann. Damit wuerde mein konzept so wie die schnittstelle jetzt ausgelegt ist nicht mehr funktionieren, da luecken im gleisplan entstehen oder jegliche abweichung vom standardgleis vermieden wird, und das ist theorie. Weiterhin, und das ist halt eine schoenheitssache und nicht existentiell, waere es schoen bei erzeuge objekt auch eine variation angeben zu koennen. Mein programm kennt alle variationen und wenn du diese funktion implementierst, mache ich ein plugin mit dem man variationen eines modells zur auswahl auf dem board positionieren kann und nicht einzeln durchgehen muss. Wenn man natuerlich nocht die anzahl von variationen abfragen kann waere das noch besser. Gruss gmd

Das ist nun wirklich elegant, very nice. Gruss Gmd

Was mir noch dazu einfaellt ist, dass Neo ein feature einbauen koennte mit dem man die manuelle bedienung von weichen, signalen etc unterbinden kann, fuer einzelne objekte, gruppen, schlagworte oder alle eines typs (entweder Guid oder sammelbegriff wie Signale,Weichen etc. Damit kann man dann ungewuenschte oder zufaellige eingriffe verhindern. Ist im grunde das was auch meine steuerung tut. gruss Gmd

Was ich tue sollte Neo ueberhaupt nicht beeinflussen in seiner entwicklungsrichtung, zumindest fuer einige zeit. Was ich tue ist "einfach" ein riesiges plugin und eine experimentelle entwicklung. Weder wird es die kosten des MBS erhoehen noch verringern. Wenn durch dies entwicklung und die diskussionen ideen entstehen die unmittelbar fuer das Mbs nuetzlich sind, kann und wird Neo diese aufgreifen und umsetzen. Wird am ende meine vision wahr, wird das werbung fuer das MBS sein und ein modul welches kostenfrei von jedem verwendet werden kann, falls es jemals dazu kommt das ganze installierbar zu machen und mit weniger resourcen auszukommen als bisher. Fuer jetzt ist das ein versuch und wer moechte kann daran teilnehmen, die source ist offen. Ich hoffe ich habe das verstaendlich formuliert. Gruss Gmd