gmd

das hast du misverstanden .. es geht nicht ums abdecken des fensters .. die gruene (orange) spur ueberdeckt die kontakte auf den spuren .. Siehe Beispiel.. es ist hilfreich die kontakte zu sehen wenn man tested ob das MBS das ziel noch erreicht und die kontaktpositionen optimiert. gruss Gmd

Neo, ich verwende die fahrstrassen und zielanzeige regelmaessig um virtuelle spuren zu testen und zu verlegen. Da ja ein limit besteht (7) muss ich kontakte einfuegen. Es waere schoen wenn die braune bzw. gruene anzeige etwas transparent ware um die kontakte durchscheinen zu lassen. Gruss Gmd Edit: Anbei ein beispiel .. waere schoen die kontakte noch zu sehen

Wow,toll,danke gruss Gmd

Wozu dienen die kleinen teile unterhalb der auslegersignale ? Gruss Gmd

Greetings from Australia, Have given this subject a thought and timetables have been a major part of my programming. Few basic assumptions for my thinking: 1. I have a ratio of 1:120 in my clock, 30 seconds real time is 1 hour in the model for long distance views, and 1:1 for local views 2. Everything happens in "normal" speed, only the clock is fast 3. I am not interested in overviews of the whole set, I only use different camera perspectives, with 4 active views (windows) tracking trains. 4. I want to follow trains while passing through different landscapes, but only for a short time, kinda simulating long distance travel using the fast clock 5. I want to see trains arriving, waiting and leaving at stations using the normal time. So in consequence different time zones, depending on the view. 6. I can define schedules for trains between locations and trains will leave a view port (window) and when not appearing in a "travel" view, they will disappear until the time is right for them to appear at the right time before entering a station (other window). This allows some kind of realistic "travel" experience and you can simulate that with the EV and the current tools of the Mbs. You don't have to have a program like what I am writing at the moment. I build my sets the way that a train disappears into a tunnel or makes a turn and vanishes behind a hill or a building from an active view. This gives you the most realistic experience. The whole set in an overview does not have to look consistent or complete, because you look only onto certain aspects of it. This allows you to concentrate on your favourite themes of a model set, like a big station with lots of incoming and outgoing traffic, but where the traffic actually goes at the end of the view port does not really matter .. then you build your favourite landscapes and let the trains pass through to your liking or as per your schedule, and so on. The key here is moving away from the typical model train set thinking to create a "whole thing", which looks complete. This is not required in a virtual world and Neo has created the tools for it. Regards Gmd

Ja da hast du recht, auch wenn ich erweiterungen an einer bestehenden anlage mache (Kontakte,Signale, Zuege etc), ich habe einfach mehr vorarbeit zu leisten fuer meine funktionen, was ueber ein plugin hinausgeht und der erste schritt is einfach ALLES eindeutig zu benennen. das @-# ist nur ein temporaerer name, bevor ich die entscheidenden elemente umbenenne in ihre entgueltigen funktionalen namen. Das hat natuerlich den nachteil dass es da kein zurueck gibt ohne meine datenbank, die die temporareren namen und die fertigen namen kennt. Du hast voellig recht mit dem ziel an den standards des Mbs zu bleiben fuer ein Plugin. Ich nehme mir da mehr freiheiten. Gruss Gmd

Easy, warum willst du unbedingt ueber den index zugreifen ? Eine funktion die alle namen (auch doppelte) sendet und als original oder variation markiert, fuer eine gegebene Guid, ware viel praktischer, dann kannst du tun damit was du willst. Du findest doppelte, vergebene indices, erkennst variationen, usw. Damit braucht Neo nur wenige fuer ihn simple selektionen zu machen und wir gewinnen jede menge moeglichkeiten. Du bist dann auch nicht auf den Mbs index angewiesen. Das waere jedenfalls mein wunsch. Unda da wir gerade dabei sind .. Erzeugen eines objektes in variation, als Guid + Variation waere gut. Gruss Gmd

Hawkeye Haha.. Danke, ich sollte oefter mal in die grafische EV schauen Bin einfach zu sehr auf die syntax vervollstaendigung des VS2022 fixiert und habe zu wenig geduld mit Lua Danke Gruss Gmd

Hallo, local particles = $("Dampflok (blau)").particlesEnabled gibt mir den derzeitigen zustand .. Wie kann ich aus/einschalten mit Lua ? Gruss Gmd

Landstrasse einspurig, auswahl variation "einfach" im eigenschaftsfenster. Hat die breite der einspurigen stadtstrasse, geringfuegig andere textur. Gruss 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