gmd

Hallo, wuerde gerne fahrstrassen per lua anlegen und entfernen koennen. Oder geht das schon ? Gruss Gmd

wow, da hast du viel zeit reingesteckt , in die analge und die videos, sehr gut gelungen. gruss Gmd

wuerde ich eh nicht kaufen, viel zu teuer fuer mich. Vielen dank an euch beide , das hilft weiter. Ist einfach mal interessant einen vergleich zu haben. Meine gpu ist halt nicht die kraeftigste .. Hatte bisher andere prioritaeten. Gruss Gmd

Danke fuer die muehe, das macht mir mut .. wenn ich bedenke dass ich einen schnellen prozessor habe und du eine bessere gpu dann ist das ein sprung. Kannst du mir bitte mal ein bild machen von einem ausschnitt, bei dem du diese fps bekommst ? Dann habe ich eine bessere vorstellung. Eine 5090 will ich, und kann ich mir nicht leisten. Meine frau wuerde mich koepfen . Gruss Gmd

Ok, danke, werde mal in mich gehen.. Allein fuer das MBS kann ich ja keine 5080 rechtfertigen .. gruss gmd

Danke fuer die rueckmeldung, das erwarte ich auch nicht. Diese anlage is auch nur ein test um das mal auszureizen. 15-20 fps in allen ansichten wuerden mir damit auch schon reichen. Ist das deiner meinung nach mit mehr hardware erreichbar oder eine geldverschwendung ? Wenn mein programm einmal die steuerung uebernimmt werden in der regel nur teilsichten relevant. Da geht es dabei nicht so sehr um groesse als um vielfalt. Gruss Gmd

Neo, dies ist meine grosse testanlage C8C0F123-2017-42AC-9234-EC4F1814261A ist als entwurf hochgeladen, ist einfach fuer dich und noch etwas groesser als rotties. Wuerde mich interessieren was du dazu sagts. Einfach zu gross oder mit mehr CPU und GPU zu beschleunigen. Gruss Gmd

Neo, Nur kurzer hinweis. Gelaende anpassen unter prellbock, spur zu ende .. damm zu ende .. 6016 Fleischmann aber ich denke das ist nicht wirklich relevant. Gruss Gmd

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

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

Hallo, zum einen elegante loesung von Hawkeye ! Fahrstrasse vs Block ist immer die frage. Neo hat fahrstrassen implementiert um mit einer einfachen zieldefinition alle notwendigen weichen etc. automatisch zu schalten um den erstellungsaufwand zu verringern. Wenn man nun eine feinere aufteilung moechte (so wie ich), dann denkt man in bloecken und die werden nicht mit fahrzielen definiert, die sind definiert durch signale und zwischen the signalen befindet sich ein zug oder nicht. Man muss eine "Blockverwaltung" implementieren und die ist nicht unbedingt kompatibel zu dem konzept der fahrstrassen wie es das Mbs definiert. Das naechste problem in der diskussion ist fuer mich die verbindung zum GBS. In meiner welt ist die visualisierung gekoppelt zunaechst an den block und wenn man will auch an das fahrziel. Die belegung ist alleine blocksache. Das GBS kann nur eine anzeige pro baustein und man muss sich entscheiden ob man eine blockstruktur order eine fahrzielanzeige darstellen will. Wenn ich schreibe - in meiner welt - dann meine ich damit, meine eigene sicht auf die dinge, hat nichts mit meinem programm zu tun und auch nicht notwendigerweise mit dem realen sachverhalt. Hawkeye hat in seiner welt eine loesung gebaut und jeder muss fuer sich entscheiden wie er die gegebenheiten nutzt oder auch nicht. Auf jeden fall sollte man erst einmal klar die zielsetzung definieren - Block oder Fahrstrasse oder - fuer mich ist eine fahrstrasse eine folge von bloecken, die nicht alle auf einmal gesperrt werden muessen, sondern nur vorausschauend gemaess dem fahrziel und fahrplan eines zuges. Gruss Gmd

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

Danke, lass uns mal ein beispiel betrachten. 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. 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

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

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