gmd

Neo, habe noch ein paar fragen zur behandlung von scripten die ueber die schnittstelle uebertragen werden. Bisher habe ich die erfahrung gemacht, dass die scripte sofort ausgefuehrt werden. Kann ich scripte an ereignissen festmachen ? Das folgende script is wirkungslos wenn das Fahrzeug nicht auf dem genannten gleis steht. local v = layout:getEntityByName('ABC') local g = layout:getEntityByName('haltegleis') if v:isLocatedOn(g) then v.currentSpeed = 0 end Ich meine, das ist ja zunaechst logisch, da hier keinerlei ereignis verknuepft ist wie in der EV und das MBS ja nicht alle scripte aktiviert sondern erst das ereignis und dann das script ausfuehrt. Ist folgende annahme richtig: Wenn ich ereignisgetriebene ablaeufe abbilden will, dann geht das nur ueber die ereignisnachrichten der schnittstelle. Alternative kann ich ja variableen versorgen (aus der EV) die ich mir scripten auslese, das ist eine art asynchrone kommunikation. Ich kann ueber die schnittstelle nur scripte absetzen die unmittelbare bedingungen prueft und/oder aktionen ausloest, ist das so richtig ? Was genau bedeutet die id am ende the Json message ? Waere toll wenn ich scripte laden koennte, die mit ereignissen oder modulen verknuepft sind, optimal natuerlich wenn ich die dann auch in der lokalen EV sehen koennte. Aber das ist wohl ein "pipe dream" oder ? Ich habe Lua fuer meine app implementiert und kann scripte erstellen, syntax checken und dann als Json message schicken. Habe eine bibliothek von templates mit denen ich die ereignisse, die ich von der schnittstelle bekomme nachbilde und dann schaltaktionen verschicke. Waere halt toll wenn ich die verarbeitung zwischen meinem steuerteil und der EV aufteilen koennte. Gruss Gmd Edit: Hier noch ein bildchen von meinem kleinen Lua tool

Neo, Bin ein ganzes stueck weiter mit der neuen schnittstelle. Habe Lua in meinem programm installiert und kann beliebige scripte erzeugen, syntax checken und per message uebertragen und ausfuehren. Du hast gefragt was mir fehlt .. das wichtigste was ich vermisse ist ein rename Ich koennte das quellobjekt loeschen und ein neues and die stelle setzen, wenn ich einen namen angeben koennte. Derzeit sehe ich keine moeglichkeit per script ein objekt umzubenennen. Transformationen, selektion, etc. alles ok so wie ich das derzeit beurteilen kann. Es reduziert sich also zu einem "Umbenennen" {"jsonrpc": "2.0", "method": "editor.createEntity", "params": "F38B36A9-E8A0-4943-B3D8-00D78185EDA9", "id": 1} {"jsonrpc": "2.0", "method": "editor.deleteEntity", "params": {"_class": "entity", "name": "Gleis 1"}, "id": 1} Gruss Gmd Edit: Hatte gerade eine idee .. local v = getEntityByName("ABC").name v.name="EBC" das sollte ja gehen. Werde ich gleich mal testen. Edit2: ja das geht so .. also, das bedeutet dass ich alle meine funktionen mit der neuen schnittstelle erledigen kann. Waere trotzdem schoen hier einen namen angeben zu koennen {"jsonrpc": "2.0", "method": "editor.createEntity", "params": "F38B36A9-E8A0-4943-B3D8-00D78185EDA9", "id": 1} Es waere hilfreich ist aber nicht entscheidend, objekte auf ebenen zu legen oder zwischen ebenen umzusortieren. Ist einfach hilfreich automatisiert groessere anlagen zu strukturieren und dies struktur dann auch lokal im MBS zur verfuegung zu haben. Ok, das wars, damit ist dieses kapitel ziemlich abgeschlossen.

tue was du moechtest mit den dateien, kein problem. Das urheberrecht hat Neo fuer den inhalt sowieso. Erstellt mit saxon-he java command line app. Download here Der AI kann dir helfen das einzurichten, wenn du dich ueberwinden kannst. Den frame fuer das XSLT file hat der AI gemacht die styles und tabelle etc. habe ich ergaenzt. Wie du sagst, geschmacksache. Gruss Gmd

ja die habe ich ja auch formatiert -- siehe den anderen post. ah ich glaube ich habe verstanden : Die aktionen in der ev wie Toggle Turnout -- sind einfach auf elementare funktionen wie state zurueckgefuehrt und die sind ja in der xml beschrieben. Ist das richtig so ? grudss Gmd

Neo, gibt es noch andere editor methods ausser denen im Wiki zur neuen externen schnittstelle ? Bin dabei die neuen funktionen vorzubereiten, die event transformation ist so gut wie fertig, bin dabei die anderen funktionen anzupassen. Noch eine frage zum verstaendnis: Zum beispiel die aktion geschwindigkeit setzen gibt es nicht mehr als method, sondern nur als lua script ueber layout.invokeScript; ist das richtig so ? oder habe ich etwas nicht verstanden. Hast du eine xml datei mit allen Aktionen der EV ? die script datei hat keine aktionen oder editor methods gruss Gmd

Nochmal Hi, sorry fuer die mehrfachen posts aber ich dachte es koennte nuetzlich sein. Habe deutsch und english mit inhaltsverzeichnis gemacht.. nur html Falls gewuenscht kann ich auch das stylesheet posten. gruss Gmd Lua_Toc.zip

Hi again, und hier die pdf files, falls das bevorzugt wird. Gruss Gmd Lua_PDF.zip

Hi everyone, anbei drei files. Formatierte datei = English und Deutsch und stylesheet fuer xslt falls jemand spielen moechte Gmd Lua_Formatted.zip

Hi everyone, Being home for a week and not having my desktop (it's in the caravan down south), was playing on a laptop with some layout variations. Two things came up, which always were a bit of an annoyance to me over the years: 1. It would be really nice to be able to apply ramp modifications to group of splines (tracks). One has to release the group to do that and then group again. 2. When using terrain features it would be nice if each function (up, down, smooth etc.) could remember the settings individually. Building terrain requires a lot of switching between the functions and usually the settings for size and strength, and maybe even form of brush is different. Would be great that settings remain for each function separately. Oops, sorry just realised that I wrote in English, wasn't intentional. I am back next week on my desktop and will give XLST a go, unless somebody else has already done the formatting of Neo's command list. Still kinda embarrassed about the plunder with the AI. Regards Gmd

Haha, da hast du wohl recht .. Aber ein fundus an ideen .. gruss Gmd

Da hast du wohl recht. Ich verwende den AI zum programmieren und das ist ein 100% factcheck, entweder es geht oder es geht nicht .. und zum texten fuer webseiten.. das kann man ja auch selbts korrigierenn .. der rest ist fragwuerdig gruss Gmd

Ich habe den AI nochmals befragt woher das dokument kommt das er ausgespuckt hat als formatierung fue das XML. Hier ist die Antwort .. Ich glaube wir haben aus versehen die dokumentation der EEP implementierung bekommen. Hmmm... ich denke das alleine ist eine diskussion wert ueber sinn und unsinn eines AI. Dann habe ich die Frage gestellt: How does that compare with 3D Modellbahn Studio und die antwort is unten angeheftet Und falls das zuviel fremdwerbung ist, kann Neo den thread ja loeschen, fuer mich ist allerdings weder EEP noch RocRail wirklich konkurrenz. Wow, wieder was gelernt ... und fakten sorgfaeltiger checken gruss Gmd The provided Table of Contents (TOC) has some overlap with both EEP (Eisenbahn-Experten-Programm) and Rocrail, but the overall structure aligns more closely with EEP Lua scripting. Here’s a comparison: 1. EEP (Eisenbahn-Experten-Programm) Key Indicators: EEP uses onStart, onStop, onObjectAdded, and other event-driven Lua functions. Extensive use of layout objects like Vehicle, Signal, Track, Switch, and Block. Lua scripting with defer(), toTime(), and playSound() is characteristic of EEP's simulation scripting environment. EEP has UI-related functions such as showPopup, playEffect, and safety-related controls (enableEmergencyBrake). Matching Sections: Event Parameters, Global Variables/Functions, Events, Layout Objects, Vehicle Properties, Signal Settings, Functions for Event Scripts, and Animation Control are all common in EEP. Depot-related and contact settings (e.g., triggeredBy, isActive) also appear frequently in EEP. 2. Rocrail Key Indicators: Rocrail supports Lua scripting for automation but is more focused on integration with MQTT, network communication, and event-based commands for train control. Rocrail typically emphasizes train schedules and actions but may not have as many animation functions (e.g., playEffect, setCamera) as listed in your TOC. Rocrail tends to focus more on track feedback, occupancy detection, and external control using scripts. Matching Sections: Network-related commands, event registrations, and vehicle tracking (trackVehicle, stopTrackingVehicle) do align with Rocrail. Functions like getConnectedBlocks, sendCommandToVehicle, and external communication (connectToServer) match Rocrail's architecture. Conclusion: Based on the structure and variety of features like UI effects, signal and contact functions, and the animation controls listed in your document, this TOC matches EEP's Lua scripting environment more closely. If you’re using EEP, this makes sense. Rocrail’s scripting is more focused on command-based control rather than UI animations and vehicle properties in such detail. Let me know if you’d like a detailed example comparison, or if I should extract additional details to confirm! -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Comparison with 3D Modellbahn Studio Lua Scripting: 3D Modellbahn Studio is a sophisticated 3D model railway simulation software that supports Lua scripting for layout automation, similar to EEP and Rocrail. Here’s how the features in your table of contents compare with 3D Modellbahn Studio's capabilities: Similarities: Event System: 3D Modellbahn Studio supports event-based triggers like onSimulationStart, onObjectAdded, and onObjectRemoved, similar to your "Events" section (3.1 OnStart, 3.3 OnObjectAdded). Lua scripts in 3D Modellbahn Studio can listen to events related to vehicles, signals, contacts, and switches, matching the types in your "Layout Objects" (5.x) section. Object References and Properties: Your TOC mentions Vehicle, Signal, Track, Switch, Camera, Depot, etc., which are also core simulation elements in 3D Modellbahn Studio. Properties like currentSpeed, maxSpeed, and stateCount (sections 7.x and 8.x) are typical in both 3D Modellbahn Studio and EEP for controlling vehicle behaviors and signal states. Functions for Event Scripts: Functions like print(), math.random(), and wait() are standard Lua functions used in 3D Modellbahn Studio for script debugging, randomness, and delays (sections 6.x). The ability to control objects (playSound, setSignalState, spawnVehicle, etc.) appears in both environments. UI and Animation Controls: Both EEP and 3D Modellbahn Studio support animations (playAnimation, setCamera, showPopup), indicating that visual storytelling and camera effects are part of the simulation scripting. Differences: Focus on 3D Visualization: 3D Modellbahn Studio emphasizes immersive 3D layout visualization and has detailed animation controls (startAnimation, stopAnimation), which are noted in your document. Some UI controls like showMessage, showAlert, and resetCamera may be more relevant to interactive user interfaces rather than purely automation-focused scripting like Rocrail. Network and External Communication: The "Network Communication" and "External Communication" sections in your TOC align more with Rocrail’s network-centric approach but may have some support in 3D Modellbahn Studio for cloud-based layout sharing rather than MQTT communication. Schedule and Depot Management: The sections on schedules (12.x) and depots (10.x) indicate a system with train management logic, which 3D Modellbahn Studio supports in simpler form but may not be as extensive as EEP’s detailed timetable and depot functions. Conclusion: Your TOC is highly aligned with 3D Modellbahn Studio, especially for event-based control, animations, vehicle properties, and user-defined variables. Some parts, such as detailed network synchronization (35.x) and statistics export (30.x), may indicate additional features beyond 3D Modellbahn Studio's primary focus, pointing more toward EEP or Rocrail. If your simulation includes detailed schedules and train operations, EEP remains a strong contender. Would you like me to dig deeper into specific sections or assist with more detailed examples from 3D Modellbahn Studio?

Ich wuerde mal sagen das hat der AI getraeumt. Ich habe den inhalt nicht geprueft ob er wirklich dem original entspricht, h atte mich nur ueber die lanege gewundert aber nicht weiter darueber nachgedacht. Deckt sich mit den anderen erfahrungen mit dem AI , man braucht manchmal viele anlaeufe bis was vernueftiges rauskommt. Also wahrscheinlich doch besser mit XLST. Danke Easy das du das aufgedeckt hast ... Und entschuldigung dass ich da nicht sorgfaeltiger war. gruss Gmd

Und hier die englische version Wenn jemand lust hat selbst einen versuch zu machen, ich habe das mi ChatGpt 4o gemacht .. die freie version ist 4omini, habe keine ahnung was die version macht. Jedenfalls 4o kommt nach etwas insistieren zu einem halbwegs brauchbaren ergebnis. Gruss Gmd Script Definitions_LUA_English.zip

Hier eine etwas bessere version. Habe 3 file formate im zip mht fuer browser use ohne page breaks, docx zum nachbearbeiten wenn jemand lust hat die table of contents aktiv zu machen (word hat automatische TOC, die header sind ja gesetzt), und ein pdf mit page breaks. Ich bevorzuge die mht version da sie am besten zu lesen ist und compakt. Ich habe den AI noch etwas gekitzelt mir ein besseres ergebnis abzuliefern, aber zu mehr habe ich viel zeit (lust) muss ich sagen. Dieses ergebnis is ok, meiner meinung gemessen an der zeit die ich damit verbracht habe .. Werde noch die englische version machen .. Fuers Wiki muesste es noch etwas huebscher werden, aber vielleicht findet sich ja jemand .. Gruss Gmd Script Definitions_LUA_Deutsch.zip

2 html files, simple formatting hoffe das gefaellt Gruss Gmd ScriptDefinitionsFullFormatted_EN.zip

Nun macht mal halblang. Hier denkt jeder mal wieder nur an sich selbst. Neo und das MBS braucht verbreitung und je mehr benutzer es gibt um so mehr kann das MBS wachsen. Fuer mich ist es mehr als 5 oder 14.50 wert NICHT mit Steam zu dealen. Es ist "invasive" und annoying. Ein einfuehrungsangebot in Steam ist hoffentlich eine erfolgreiche sache fuer Neo, dann kann er oefter upgrades verkaufen. Leute die Steam benutzen sind ja gewoeht fuer jeden furz zu zahlen. Ihr solltet mal den wert des MBS schaetzen und nicht ueber ein paar euro gackern. Das MBS ist meiner meinung mit abstand das beste produkt in seinem segment. Ich habe EEP und auch Scarm getestet, Scarm hat die Lizenz refunded bei rueckgabe, EEP nicht. Was zahlt man denn fuer ein regelmaessiges upgrade bei EEP und mal ganz abgesehen von den modellen. EEP hat so eine fuerterliche oberflaeche und anlagen sind schwerfaellig zu bauen ... Der 3D MBS editor ist convenient und macht spass zu bauen. Ich bin kein freund von 2d plaenen etc. Interactiv die anlage bauen is genausogut wie die anlage benutzen wenn sie fertig ist. Der ganze prozess macht spass und das ist bei anderen programmen nicht der fall. Ihr koennt ja nach Steam wechseln, ich jedenfalls verzichte gerne auf einen Kaffee pro jahr um davon fern zu bleiben. Das sinf halt mein 2c. gruss Gmd

Hallo mal wieder, habe an meinem abschnitteditor weitergebastelt. Zu jedem abschnitt koennen teilabschnitte und eigenschaften zugeordnet werden (die bilder unten an der gruppe). Teilabschnitte sind separate sichten auf teile des gbs fuer diesen abschnitt. Ein bahnhof oder ein haltepunkt kann zugeordnet werden (oben rechts), und auch ein stellwerk (oben links). Alle anderen symbole sind plan- und steuerbare ablaeufe. Jedes bild representiert eine darstellung von daten mit moeglicher eingabe. Fuer jeden ablauf wird eine schablone vorgeneriert (templates) die vom "GBS pult" abgerufen werden koennen, mit hilfe der gleichen symbole wie hier im diagramm. Ist einem Abschnitt ein bahnhof oder haltepunkt zugeordnet, steht er fuer einen fahrplan zur verfuegung. Die linke gruppe stellt den derzeit maximalen umfang and definitionen dar. Mit funktionen wie schliessen und oeffnen koennen die gruppen verkleinert werden. Das diagramm kann beliebig gross werden. Die anordnung der komponenten ist vollautomatisch, man braucht also nicht lange mit "ordnen" verbringen. Fuer die meisten abschnitte werden natuerlich nicht alle variationen verwendet, die anordnung wird dann automatisch angepasst, man kann aber immer auf die grundanordnung zurueckgehen. Damit lassen sich grafisch sehr schnell die strukturen festlegen mit denen das GBS verwaltet werden soll. Ist ein stellwerk zugeordnet dann wird die steuerung aktiv moeglich. Ist kein stellwerk zugeordnet ist nur eine ueberwachung gedacht. Dies alles gehoert zu den strukturen auf denen der AI einmal arbeiten soll. Fuer das AI-Modell braucht man ja eine gute abbildung der "welt" in der die entscheidungen getroffen werden sollen und alles soll ja in einem wohl definierten rahmen ablaufen. Zugeordnete funktionen koennen jederzeit wieder weggenommen oder hinzugefuegt werden. Es folgen noch weitere details zu den bahnhoefen, wodurch einzelne gleise bestimmten aktivitaeten zugeordent werden koennen. Ich brauche dazu keine kontakte, nur eindeutige gleisnamen in den bloecken. Auf bestimmten gleisen sind dann nur bestimmte aktivitaeten moeglich, wie anhalten eines personenzuges, oder durchfahrt eines gueterzuges. Wenn keine zugliste fracht zugeordnet ist, kann kein gueterzug in dem abschnitt fahren. Damit is das automatisch definiert.. und so weiter. Es lassen sich noch eine vielzahl von eigenschaften oder funktionen denken, deshalb sind die einzelnen digrammelement auch nicht fest definiert, sondern koennen erweitert werden. Die editierungsfunktionen sind jetzt soweit fertig, jetzt kommt noch das abspeichern und laden des diagramms. Dann gehts mit einer anderen komponente weiter. Ich muss ja noch die blockerkennung weitermachen und die automatische generierung der bloecke im Gbs fertigstellen. Ein solches diagramm mach natuerlich mehr aufwand bei der programmerstellung als eine einfache texttabelle, ist aber in der anwendung unvergleichlich schneller und uebersichtlicher. Mit der neuen schnittstelle kann ich ja sogar lua code hinter solchen symbolen verbergen und bei bedarf laden. Damit kann ich schneller auf einzelnen script komponenten zugreifen und diese nach meinen kriterien ordnen. Gruss Gmd

Ich misch mich mal kurz hier ein. Aus dem was ich gelesen habe schliesse ich daraus dass ein plugin zur ansteuerung und "Short Cuts" die bessere Loesung waere, wesentlich flexible, wie Neo ja schon sagte. Was ich fuer die erweiterung von steuerungsmoeglichkeiten in der EV machen wuerde und dann aufrufbar, unter anderem, durch simples plugin sind Macros, wurde ja oben schon angedeutet. Macros sind eine methode das MBS lernen zu lassen (in elementarem umfang). Macros wuerden erstellt durch schaltaktionen, die ueber gbs, direct am objekt oder ueber steuerfenster ausgefuehrt werden und das MBS zeichnet die einzelnen aktionen auf und man gibt dem macro einen namen und natuerlich auch schlagworte. Dann kann das jederzeit ausgefuehrt werden. Es koennen gruppen gebildet werden (schlagworte) und die macros koennen auf tasten im gbs gelegt werden. Die einfachste form eines Macros waere dann ein "short cut", ausgeloest ueber ev, taste, oder auch externe schnittstelle. Es laesst sich auch in der graphischen EV darstellen und noch manipulieren, zb. zeitverzoegerungen einbauen etc. Das gilt dann auch fuer animationen. Das waere fuer mich ein konzept dass sich gut in die jetzige logik einfuegt. Damit lassen sich externe geraet leicht anschliessen und benoetigen nicht eine "tiefe" programmierung. Die logik der macros wird dann durch ausfuehrungsbefehle ("short cuts") "durchgereicht". Damit sind externe gearete leicht auswechselbar und die logik verbleibt im MBS. Die grafische EV ist sehr gut geeignet die macros darzustellen und zu manipulieren. Durch diese mechanismen haette man auch eine einfache eingabemoeglichkeit fuer steuerungskomponenten die keine macros werden sollen, die man dann verfeinern kann. Ich habe die ersten elemente davon in meinem steuerprogram, so lege ich routen an. Im MBS setzt man start und ziel und die fahrstrasse wird geschaltet. Das ist ok und einfach zu definieren, ist aber ein sonderfall. Ich definiere routen, das sind wege die ein zug nimmt um einen fahrplan abzufahren und nicht die kuerzeste strecke zwischen punkten, also eigentlich viele fahrstrassen verbinden. Dafuer verwende ich macros, die die flexible definition von beliebigen fahrstrecken ermoeglicht und dabei auch alle moeglichen aktionen startet oder beendet, inclusive tuere oeffnen und schliessen, lautsprecher ansagen starten usw. Ich waehle allerdings nur bloecke aus, signale und weichen steuert das programm automatisch. Man kann das auch mit automatisch ermittelten fahrstrassen zwischen haltepunkten machen, aber die manuelle definition von macros erlaubt mehr variationen. Das bedeutet man kann mit der kirche ums dorf fahren bevor man am naechsten bahnhof ankommt . Gruss Gmd

DoppelDepot natuerlich, sorry... war ein langer tag regards Gmd

Prima, wieder was gelernt.. das doppelportal ist "close enough". Danke Gmd

Mehr ein vorschlag als ein request. Bei der liste von features fuer mein steuerprogramm habe ich unter anderem features wie eingleisigem schattenbahnhof mit ein und ausfahrt, oder auch einer zeitverzoegerung im berg nachgedacht. Mit meinem programm kann ich das alles machen aber ich denke es kommt allen zugute wenn das depot eine variante bekommt. Einfahrt an einer seite, ausfahrt an der anderen. Damit lassen sich lange fahrstrecken simulieren, zweiseitige schattenbahnhoefe und anderes. Vielleicht weiss ich ja etwas nicht und das deport kann das schon, dann lass ich mich gerne belehren. Gruss Gmd

Hallo, Ich habe ja nichts inhaltliches beizutragen zu diesem thread kann mich aber einfach nicht zurueckhalten mal einen post hier abzusetzen. Ueber die jahre habe ich etliches in Solidworks (3dCad) modelliert und danach in realitaet gebaut. Solidworks ist auch nicht gerade simple, aber blender "intimidated' mich immer noch. Weiss gar nicht mehr was das auf deutsch heisst. Ich muss einfach sagen dass ich eure geduld und ausdauer mit diesem modellbau total bewundere. Irgendwann werde ich vielleicht mal die motivation aufbringen da weiter hineinzuschauen. Ich habe mit interesse alle 16 seiten dieses threads gelesen, und man kann da eine menge lernen und die reise beginnen in der Klartexter schon weit fortgeschritten ist. Well done. Und noch ein wort zu den unglaublich detaillierten beitraegen von unermuedlichen unterstuetzern, insbesondere BahnLand. Maechtig beeindruckt von der grosszuegigkeit und ausdauer mit der ihr neueinsteigern helft. Vielen dank fuer die vielen guten informationen. Gruss Gmd

Neujahrsgruesse fuer alle auch aus Australien, alles Gute fuer 2025 und auch von unseren derzeitigen Nachbarn . Gmd

Vielen Dank fuer die vielen schoenen modelle. Gruss Gmd