gmd

ok, dann ist es meine wahrnehmung, ich habe kein "Siemens"-deutsch mehr seit vielen vielen jahren gelesen und erst recht kein IT-deutsch. So, wenn du das sagts dann ist das ja eine positive aussage, die ich dann danked annehme und lerne . Ich habe mein Lua Action Center jetzt mit den gleichen oberflaechen mechanismen in die main app integriert (Docking Panels) und mal ein bildschirm layout ausprobiert fuer die konstruktionsphase, nicht die betriebsphase. Ich will eine automatische fensteranordnung fuer verschiedene situation vorsehen, dann ist das weniger aufwand die fenster zu positionieren. Die fenster sind von oben links im uhrzeigersinn: Abschnitteditor, MbsAnlage in arbeit , GBS editor, Main App mit blockerkennung etc. , Zugdesigner und Lua Action Center. Das sind die hauptkomponenten mit ihren teilsichten. Jetzt geht es an die weitere verfeinerung der einzelnen funktionen und em runtime system fuer die scripts. Gruss Gmd

Das erkennen und das pflegen ist aufwending, wenn man nicht externe hilfe in anspruch nimmt(damit meine ich die schnittstelle). Das Mbs kennt ja alle schalternamen fuer jedes objekt, die koennte Neo ja zugaenglich machen, bleibt aber die konsolidierung der namen zu einheitlichen funktionen. Da gibt es natuerlich viele funktionen die nicht fuer viele modelle vorhanden sind aber das kann man auch regeln. Also hier die beschreibung meines vogehens: Ich erzeuge meine objekt seitenbilder in meiner app auf aehnliche weise, daher kommt die idee. Meine App hat den katalog aller modelle und kann sie automatisch auf einer testanlage plazieren und einzel selektieren. Das fuehrt dazu dass die schalter im steuerungsfenster angezeigt werden. Das steuerungsfenster wird an einer bestimmten stelle des bildschirms positioniert und es wird ein screenshot gemacht und unter dem modellnamen abgespeichert. Das geht vollautomatisch. Dann lade ich die benannten files in badges in den AI und der macht fuer mich die listen. Hier ein einzelner dialog, das habe ich weiter automatisiert. Damit erhalte ich listen wie diese: ('DH 500 Ca') ['01 Dach ausblenden'] ['02 Spitzenlicht vorne'] ['03 Spitzenlicht hinten'] ['04 Schlusslicht vorne'] ['05 Schlusslicht hinten'] ['06 Führerstandsbeleuchtung'] ['07 Tür rechts'] ['08 Tür links'] ('MAK1202-1205') ['Kabinenbeleuchtung'] ['Lifter'] ['Rotlicht-hinten'] ['Rotlicht-vorne'] ['Spitzenlicht-hinten'] ['Spitzenlicht-vorne'] ('V200') ['Frontlicht_rot'] ['Frontlicht_weiss'] ['Kabinenbeleuchtung hinten'] ['Kabinenbeleuchtung vorne'] ['Maschinenbelüftung'] ['Maschinenraum_Beleuchtung'] ['Rücklicht_rot'] ['Rücklicht_weiss'] ['x- Info'] Die wird in die Db geladen. Das habe ich als vorbereitung fuer mein konzept getestet, habe die anforderungen und das konzept beschrieben und wollte anfangen zu programmieren, habe aber zuerst den post gemacht der dann in diesem thread gelandet ist. Der naechste schritt ist eine groessere schnittmenge an animationen zu ermitteln, die standardisierte liste zu erstellen und dann die animationen zuzuordnen. Das geschieht mit hilfe eines grids. Der AI erkennt die zusammenhaenge recht gut und liefert 90%-95% der zuordnungen. Das programm speichert diese und in dem grid kann man das kontrollieren,. Ich habe auch eine testfunktion geplant in der man ein objekt auswaehlt(in meinem katalog), das wird auf der anlage positioniert und die animationen werden automatisch durchgespielt. Alles das ist nur ueber die schnittstelle sinnvoll zu loesen und funktioniert nicht im Mbs direkt, dazu sind einfach nicht genuegend funktionen vorhanden und das uebersteigt auch die zielsetzung, da persistenz (datenspeicherung) gebraucht wird und wesentlich mehr funktionalitaet (user interface) als Lua breitstellt. Viele funktionen werden immer nur sinnvoll ueber externe programme machbar sein. Hier noch ein beispiel: Ich habe mich ein paar stunden mit fahrstrassen beschaeftigt, aber auch hier sind ausgefeilte steuerungen nur extern machbar. Fahrstrassen sind eine gute idee und ein sehr effizientes konzept fuer die EV schnell, komplexere strecken zu schalten, aber blocksicherung und effektive nutzung eines verzweigten netzes sind muehsam. Je laenger die fahrstrasse, um so mehr wird blockiert. Ich kann halt eine fahrstrasse bestehend aus 5 bloecken nicht von 3 zuegen befahren lassen. Eine komplexe steuerung ist auch hier nur extern moeglich, deshalb schreibe ich ja mein programm. Gruss Gmd

Es gibt einen schleichweg den ich nutze {"jsonrpc": "2.0", "method": "layout.invokeUserEvent", "params": {"event": {"_class": "event", "name": "Benutzerdefiniert"}, "params":{"guid":"F38B36A9-E8A0-4943-B3D8-00D78185EDA9"}}, "id": 1} Man kann ein responder plugin bauen das auf eine variable reagiert und einen namen bekommt, ueber eine liste von namen und guids verfuegt und die guid in einer variablen ablegt, was ueber eine benutzerdefiniertes ereignis erfolgt. Die schnittstelle liefert die guids und das plugin kann die sammeln. So kann ich mir das vorstellen, ich mache das in meiner app fuer andere zwecke. Gruss Gmd

Hallo nochmal heute, Ich habe ueber weitere Lua ansteuerung nachgedacht und bin dabi auf folgenden sachverhalt gestossen. Beispiel: habe einen zug mit Railjet 4xx Bmpz und einen anderen mit DE Bvmz 185 das sind 4 achs wagen mit reichlich animationen Will man nun in einem bahnhof die tueren oeffnen muss ich die animationen gemaess den einzelnen modellen ansteuern. Sie sind ja nicht standardisiert und ich finde das hoechst aufwendig. Ich habe einen weg gebaut die animationsmoeglichkeiten der einzelnen fahrzeuge automatisch zu ermitteln und erzeuge folgende listen. Beispiel fuer Loks: Da werden natuerlich auch verschiedene namen fuer die gleich sache verwendet ('DH 500 Ca') ['01 Dach ausblenden'] ['02 Spitzenlicht vorne'] ['03 Spitzenlicht hinten'] ['04 Schlusslicht vorne'] ['05 Schlusslicht hinten'] ['06 Führerstandsbeleuchtung'] ['07 Tür rechts'] ['08 Tür links'] ('MAK1202-1205') ['Kabinenbeleuchtung'] ['Lifter'] ['Rotlicht-hinten'] ['Rotlicht-vorne'] ['Spitzenlicht-hinten'] ['Spitzenlicht-vorne'] ('V200') ['Frontlicht_rot'] ['Frontlicht_weiss'] ['Kabinenbeleuchtung hinten'] ['Kabinenbeleuchtung vorne'] ['Maschinenbelüftung'] ['Maschinenraum_Beleuchtung'] ['Rücklicht_rot'] ['Rücklicht_weiss'] ['x- Info'] Ich moechte nun eine standardisierung der animationen durchfuehren und habe eine problembeschreibung und loesungsentwurf gemacht, allerdings in englisch. Bevor ich nun losprogrammiere hier die frage ob sich jemand schon mal gedanken gemacht hat das zu generalisiren. Waere ja auch was fuer das Mbs das zu standardisieren. Ich moechte also aktionen ausloesen wie: Front beleuchtung gemaess fahrtrichtung Tueren auf/zu in fahrtrichtung Tueren auf/zu in gegenrichtung Innenbeleuchtung an/aus usw. Zu jedem dieser aktionen koennen dann auch mehrere animationen gehoeren und sind fuer alle gleich. Wenn einzelne funktion nicht vorhanden sind dann passiert halt nichts. Hat jemand irgendetwas in dieser richting getan oder angedacht ? Gruss Gmd

Nochmal Hi, anbei ein kleines benutzerhandbuch fuer mein Lua Action Center. Ich habe generell begonnen programmdokumentation mit dem AI zu machen. Das funktioniert gut, fuer code sowohl fuer handbuch, nicht perfect aber gut genug fuer mein schwaches gedaechtnis :).. Ich diktiere ein paar schlagworte mit spracheingabe und der AI macht daraus ein handbuch in jeder sprache, ich fuege ein paar bilder hinzu und done !. Was auch hilft sind die posts hier, ich mache sie teil der eingabe und sie bereichern die ausgabe. Das deutsch klingt etwas geschwollen, aber das liegt vielleciht an meiner wahrnehmung da ich eigentlich sehr wenig deutsch lese oder schreibe ausser hier. Gruss Gmd LuaActionCenter_Manual_Deutsch.pdf

Hallo, Heute mal etwas ueber die schnittstelle. Habe mich eine weile damit beschaeftigt, allerdings noch nicht mit der neuen funktion von kuerzeln. Jedenfalls ist einiges an vorbereitung noetig die neue schnittstelle bequem zu bedienen. Mit der alten ist es ja einfach ein kommando per telnet abzusetzen, man tippt es einfach ein und das parsing war auch wesentlich einfacher. Die neue schnittstelle ist geschwaetzig (zu viele zeichen werden uebertragen fuer das was wirklich passiert), aber das ist halt die konsequenz wenn man Json strukturen baut, die auch noch lesbar sein sollen. Ich bin kein freund von json als protokoll format, ok zum abspeichern und laden von strukturdaten aber als schnittstellenprotokoll nicht geeignet, wenn man hohen durchsatz erreichen will. Nun ja das ist halt meine meinung. Da ich das nun mal nicht aendern kann und die alte schnittstelle ja irgendwann verschwinden soll, habe ich mir erst mal eine umgebung gebastelt mit der ich die schnittstelle etwas bequemer bedienen und testen kann, auch als vorbeitung aines laufzeitsystems fuer die ereignisauswertung und steuerung die dem AI als schnittstelle dienen soll. Hier ein fenster, das ich Lua Action Centre nenne. Es dient verschiedenen zwecken. Begonnen hat alles mit dem problem lua scripte ueber die schnittstelle zu schicken. Das ist muehsam, mit einem editor die nachricht erstellen, ok man kann copy und paste benutzen, und dann per telnet zu senden und als antwort einen nicht so aussagefaehigen parameter error zu bekommen. Das kann nerven .. Also erster schritt: Lua zu installieren und scripte zu erstellen mit syntax check, und wenn wir schon dabei sind mit komplettierungsfunktion fuer syntax , funktionen und objekte. Dann eine funktion das script zur uebertragung vorzubereiten ( kommentare entfernen und zue pruefen dass konventionen eingehalten werden), die nachricht zu erzeugen, zu schicken und die antwort anzuzeigen. Ausserdem zum test von steuerungen is es ja gut die protokollierung zu haben, hier natuerlich ueber die schnittstelle, und verdichtete darstellung oder original nachricht zu sehen und zu filtern nach event und auch nach objekt or mehrfach fuer mehrere objekte, und die gefunden nachrichtenteile auch hervorzuheben, zur leichteren erkennung. Das hilft alles beim testen von komplexeren steuerungen. Und weil das alles so gut geht dann noch eine bibliothek an scripten die dann fuer verschiedene zwecke verwendet werden koenen, zur laufzeit dynamisch parametrisiert werden, oder auch einfach in den editor geladen werden koennen um tiparbeit zu sparen. Damit ist erst mal das muehsal der schnittstelle drastisch reduziert und ich kann mich der tatsaechlichen steuerung widmen. Ich kann Lua innerhalb meines programms ablaufen lassen, d.h. die steuerscripte kann ich in Lua schreiben oder generieren, allerdings mit erweiterter funktionalitatet. Das Mbs implementiert funktionen fuer fahrstrassen, die ja auf einer "hoeheren" ebene ablaufen als ein signal or gleis event. Ich habe funktionen definiert die auf bloecke wirken und kann sie direct in Lua ansprechen. Dies wird durch einen preprozessor realisiert, der dann die entsprechende laufzeitfunktion aufruft, da das kommando nicht direkt von Lua in meiner app verarbeitet werden kann. Das gilt ja auch fuer alle funktionen die das Mbs betreffen und ueber die schnittstelle gesteuert werden. Dafuer sind die script snippets gemacht die dann vom laufzeitsystem verwendet werden um diese Lua funktionen auszufuehren, indem ein script ueber die schnittstelle geschickt wird und die antwort and Lua zurueckgegeben wird. Im grunde kann ich die gesamte event behandlung des Mbs damit nachbilden und in meiner app verwenden und ablaufen lassen, und natuerlich weitere komplexere funktionen anstossen. Ich habe noch keine entgueltiges bild vor augen, wie die aufteilung zwischen Lua im Mbs und Lua innerhalb der app aussehen wird. Wenn ich kann werde ich viele generische scripte im Mbs hinterlegen, die dann zur laufzeit verwendet werden. Dies sind allerdings nicht objekt oder evnet gebunden, sondern sind generisch, typgebunden und werden zur laufzeit parametriesiert. Gruesse und frohes schaffen. Gmd

Neo, Danke fuer die schnelle antwort und bestaetigung. Gruss 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