gmd

Wenn einer erfolg hat damit werden andere folgen.. nur so kann man neu konzepte verbreiten.. es muss mal einer anfangen, das versuchskaninchen zu spielen. Gruss gmd

ok jungs, lasst es mich mal so sagen.. Ich erwarte nicht das ihr da sofort draufspringt, das kann ich alles verstehen geht mir auch so. Und zweitens, ich bin mir darueber im klaren, dass das Lua hier fuer viele zu umfangreich ist. ABER: Das ziel ist es ein komplettmodul mit code zu erstellen, dass transportabel ist, und KEINE tiefen Lua kenntnisse erfordert, und sofern man nicht mehrere module davon will muss man auch nichts umbenenen, also PLUG and PLAY. Warum ich frage: Wenn ich ein modul abschliesse dann optimiere ich die scripte fuer meine zwecke. Nachdem ich das gemacht habe ist es mehr aufwand eine alleinstehende version zu erzeugen, es sei denn man schleppt allen code im globalen script mit.. deswegen die frage .. ausserdem wuerde ich auch eine "user dokumentation" erstellen solange noch alles frisch im kopf ist, was ich nicht tue wenn das nur fuer mich ist. Mir geht es nur darum, ob am thema generelles interesse besteht, dann tue ich das gerne und stelle einzelne isolierte module zur verfuegung. Ich frage nicht danach wer das morgen testen will. Hoffe das hilft und danke fuer die antworten, sodass ich das hier klarstellen konnte. Die motivation is nicht allein mein steuerprogramm, das ist der antrieb. Aber wenn ich lese wieviele benutzer sich qualen verkehrsfluss zu regeln mit variationsmoeglichkeiten, dann denke ich dass der ein oder andere vielleicht mal lust hat das auszuprobieren und zu verwenden, OHNE EIN STUECK CODE ANZUFASSEN., was der eigentliche sinn ist. Gruss Gmd

Hallo, ich warte noch einen tag, wenn niemandd interesse bekundet hat, dann wird keine standalone version entstehen, die muehe mache ich mir dann nicht. Letzte chance .. Gruss Gmd

Ja hatte das gelesen, deswegen ja die rueckmeldung.. als entwickler is es ja wichtig auch mal rueckmeldung zu bekommen wenn etwas besser funktioniert und nicht nur fehler. gruss Gmd

Haha, ja genau das, dachte es koennte dich interessieren .. frueher hatte ich immer abbruch, mit VPN, ohne VPN und das war sogar mit besserer verbindung als ich im augenblick habe. Gruss Gmd

Neo, FYI .. the first time I managed to download the catalogue .. up to V9 it never worked despite multiple attempts. Oops, sorry, gerade gemerkt dass das english war... hatte mit dem AI geschwaetzt und dann war der download gerade fertig. gruss Gmd

Hallo, mal ne frage and die leser dieses threads ... wenn das parkmodul fertig ist, ist irgendjemand an einem alleinstehenden modul interessiert ? Warum ich frage ist dies: Ich habe drei ebenen von scripts, module uebergreifend, modul generell und modul spezifisch Ich versuche soviel wie moeglich modul uebergreifend zu definieren, was fuer eine alleinstehende version nicht unbedingt nuetzlich ist; erzeugt ballast. Wenn ein modul funktional fertig is, dann pruefe ich ob ich weitere allgemeingueltige funktionen finde und lege die nach global. Falls also jemand interesse hat das modul zu verwenden um parkplaetze zu betreiben, dann mache ich eine version mit den erforderlichen scripten und nicht allen. Kann auch eine benutzeranleitung generieren falls gewuenscht. Ich baue die scripte derzeit weiter um, von direkter geschwindigkeitssteuerung auf kontaktsteuerung zum weichen bremsen und anfahren. Der code is weiter abstrahiert, d.h. alle spezifischen zugriffe (definitionen und variablen) sind in settern und gettern verpackt. Das macht das lesen zum einen einfacher da jetzt alle debug lines in the settern und gettern stecken, zum anderen ist das in vorbeitung der integration mit meinem schnittstellenprogramm. Die fertige loesung wird auch bremslichter und blinker betatetigen, sofern vorhanden. Ein tueren oeffnen und ein/austeigen von personen mit fussgaengerspur ist auch geplant, dafuer brauche ich aber noch ein anderes modul. Also lasst es mich wissen, ob ernsthaftes interesse and einer "plug and play" loesing besteht oder nicht. Fuer mich brauche ich das nicht. Im uebrigen gilt das nicht nur fuer die park loesung .. auch andere module kann ich alleinstehend definieren falls gewuenscht. Gruss Gmd

haha , ja, da hatte ich geschaut .. waere aber nie auf diese kombination gekommen.. mein zeit in the EV ist ziemlich nahe an zilch gruss Gmd

wow, danke Goetz, waere ich nie drauf gekommen .. der .prompt fuer kontakte sagt nichts von trackContact prima jetzt kann ich weitermachen .. ich stelle alles um von currentSpeed=0 fuer vehicles auf ausnutzen der kontaktfunktionen.. its etwas andere logik, aber nicht zu schlimm die aenderung. dann laeuft das alles weicher und nicht so abrupt. Nochmals danke fuer die hilfe Gruss Gmd

Hallo, was mache ich hier falsch ?? print ("Schalte kontakt bremsung") local contact = $("PB_1_Entry_Wait") print ("Contact " , contact.name) print ("Deceleration speed is ", contact.autoDecelerationSpeed) contact.autoDeceleration = false print ("Auto deceleration is ", contact.autoDeceleration) [1:07:22 PM] Schalter wird betätigt -> test_contact, 0 [1:07:22 PM] Schalter wird betätigt [1:07:22 PM] Schalte kontakt bremsung [1:07:22 PM] Contact PB_1_Entry_Wait [1:07:22 PM] Unknown method or property name autoDecelerationSpeed (Zeile 4) Danke Gmd

Neo, das ist mir klar aber maximal geschwindigkleit ist fuer mich typgebunden, nicht situationsgebunden, so wie es fuer mich auch logisch ist. Maximalgeschwindigkeit verwalten ist noch mehr aufwand, als ab ein und auschalten, ist fuer mich aber auch nicht logisch, und benoetigt zusaetzlichen aufwand. Gruss Gmd

Neo, nicht sicher ob das der platz fuer die frage/aussage ist. Ist aber mehr eine feststellung als alles andere. Ich habe immer wieder das problem bei meiner verkehrssteuerung, dass die eigenschaft automatisch beschleunigen nicht immer hilfreich ist. Sie muss gesetzt sein, damit ein fahrzeug nach dem halt wieder anfaehrt, aber wenn ein schnelleres fahrzeug einbiegt, im richtigen abstand, dann wird das nachfolgende fahrzeug "mitgezogen", logisch natuerlich wenn man das "automatisch beschleunigen" woertlich nimmt. Ich behebe das problem auf mehreren wegen: 1. wenn ich einbiege vor einem ankommenden fahrzeug und weiss das ich schneller bin als das ankommende, dann schalte ich automatisches beschleunigen fuer den nachfolger aus. 2. wenn ein fahrzeug "auf strecke geht" also nicht angehalten wird, dann ist "ab" aus. 3. vor strecken mit ampeln, wo sich der vehrkehr staut, habe ich kontakte die ab einschalten. Ich habe eine weiteres konzept "Assertion Contacts", die fuer definierte fahrzeuge bestimmte eigenschaften garantieren (setzen falls sie abweichen), bis hin zum abstand zwischen zwei fahrzeugen. Fuehrt mich dann doch vielleicht zu einem feature request: Automatisches Beschleunigen zu trennen in automatisches anfahren mit zielgeschwindigkeit und automatisches beschleunigen wie bisher Fuer mich ist das fast egal, da meine module es beruecksichtigen, aber fuer andere vielleicht nicht die damit kaempfen dass die geschwindigkeit nicht konstant bleibt. Es gibt ja beitraege dies sich mit dem thema beschaeftigen aber bisher nicht das automatische beschleunigen betrachtet haben. Dies als anregung und hinweis. Gruss Gmd

Hallo, mal wieder ein update A775BDC8-4700-4C67-A3D2-F89CDF55DA19 1. ein und ausfahrt modi implementiert und teilweise getestet 2. Route modus definiert, noch nicht complett 3. Init button, da braucht man nicht immer IsInitialised loieschen 4. Mehr safety functions fuer geblockte variablen, dient dazu ueberall fahrzeuge wegnehmen und setzen zu koenne, die sich einfuegen, noch nicht komplett 5. Ausfahrt und einfaedeln noch nicht verbessert, wenn das gemacht is habe ich auch gleich das modul fuer die ungesicherte kreuzung 6. Fehler beseitigt und noch mehr dokumentation in the ereignis scripten. 7. Komponentenuebersicht .. siehe bild Gruss Gmd

Hallo, dachte es koennte fuer einige interessant sein ...fuer die interaktion mit einem AI Request - mit geladenem source code aus meinen CS-Code files und die antwort: (copy and paste nach Word als tabelle und etwas manuellen zeilehintergrund zum bessere lesen Di aktionen sind aus meinen kommentaren abgeleitet. Damit kann ich die bedingungen und reaktionen des moduls besser testn und diagnostizieren. Gruss Gmd

Hallo, nochmal schnell ein update C830E17B-1C8F-4FBB-8D17-9176AF7A47AA Habe ein fahrzeugprofil "Sportwagen" im VM modul implementiert und das wird fuer das VP modul weitergegeben, ueber the QU (Query) kontakt. Man kann das unterschiedliche fahrverhalten erkennen. Mit den profilen werden dann auch die spezifischen strings fuer die animationen (Blinker, Bremslicht usw. ) uebergeben. Mein programm normalisiert die animationsnamen und stellt die spezifischen in die fahrzeugprofile. Damit koennen die verkehrsmodule standardisiert auf die animationen zugreifen. Habe auch nochmal im code aufgeraeumt und die regions fuer die bessere uebersicht in VS-Code definiert und die funktionen besser gruppiert. Damit ist eine einfacher ueberblick des scripts zu erlangen. Im MBS editor ist das ziemlich unmoeglich. Habe noch nicht entschieden was ich als naechstes angehe, das passiert meist spontan. Das 'bigger picture' habe ich ja vor mir, sind halt noch ein paar hundert schritte noetig. Gruss Gmd

Hallo nochmal, habe erst mal meine doku erstellt .. ist kein user manual, nur eine gedankenstuetze und navigationshilfe fuer spaeter, wenn nicht mehr alles so frisch ist. Hier das PDF fuer die die es interessiert. Werde diese dokumente nicht mehr posten in der zukunft, hier nur als beispiel, und wer in den code einsteigen moechte kann die jeweiligen sheets bei mir anfordern. Der AI hielft dabei die strukturen zu erstellen, das waere von hand sehr sehr muehsam. Auch wird die code generierung immer besser. Ich schreibe meist nur bruchstueckhaften pseudocode und der lua code kommt innerhalb sekunden. Ich verwende eine kommerzielle version, die nicht zum training verwendet wird (so ist das zumindest angezeigt). Wer fragen hat bitte melden. Falls interesse besteht kann ich mal eine demo der AI ausgaben machen .. manchmal liegt er daneben, aber im grossen und ganzen ist das mit "Handarbeit" nicht mehr zu vergleichen. Insebesondere wenn man kommentierten code moechte. Das Positive beim codieren ist ja, dass der code entweder laeuft oder nicht.. es gibt hier keine halbwahrheiten oder geruechte . Gruesse Gmd

Hallo, update 4BB94C1B-87D6-43F8-812B-D371358BB33F Im wesentlichen fehlerbeseitigung, ausfahrverhalten gefixt, laengere fahrwege fuer ausfahrt und belegt meldungen verbessert. Noch einige safety routinen fuer self repair .. plazieren fahrzeug in parkplatz noch nicht ganz fertig .. immer noch ein paar luecken im verhalten, ist aber schon recht stabil .. hatte noch problem mit den spuren, manchmal findet das MBS keine route per Lua, einsetzen einer stueck spur hilft dann meist. Als naechstes erweitere ich den manager mit werten zum fahrverhalten .. dann wird das etwas flexibler und belebter und zeight wahrscheinlich noch ein paar fehler . Ein problem habe ich noch mit ein und ausfahrt .. verbundene spuren erzeugen noch auffahrunfaelle wenn das fahrzeug auf der ein/ausfahrspur eingeholt wird von einem schnelleren fahrzeug aber schon auf der abbiegenden spur iist, dann erkennt das MBS nicht das vorausfahrende fahrzeug und knallt drauf. Da muss ich noch etwas ueberlegen. Werde noch etwas dokumentation verbessern damit ich in einem jahr immer noch durchsteige .. Gruss Gmd

Hallo, habe neue demo hochgeladen 4BB94C1B-87D6-43F8-812B-D371358BB33F strassenanbindung der zufahrt ... streckenlaengen muss man gemaess fahrzeugen waehlen.. hier nur als test Habe bugs gefixt, weitere sonderfaelle behandelt und die ausfahrt geregelt, muss noch weiter testen. Will soweit kommen, dass ich fahrzeuge von hand auf den parkplatz setzen kann, die dann automatisch akzeptiert und eingebunden werden. Noch nicht ganz der fall. Der naechste schritt is dann dem manager beizubringen die fahrzeuge mit individuellen daten zu versorgen, zb. die verschiedenen geschwindigkeiten, rueckwarts, ausfahrt, einfahrt usw. Das kann individuell fuers fahrzeug gesetzt werden, je nach typ oder nach name. In jedem fall muessen alle namen eindeutig sein. Damit is VP erst mal abgeschlossen. Man kann damit auch grossere einheiten bauen. Die version zwei wird dann dichteren verkehr ermoeglichen. Derzeit lasse ich nur ein fahrzeug einfahren, aber man kann regeln finden mit denen mehrer farhrzeuge gleichzeitig ein und ausfahren koennen, deshalb habe ich die viererbloecke definiert, die als kleinste einheit fungieren.. im extremfall kann man das modul auch fuer einen einzelnen park- oder halteplatz verwenden. Gruss Gmd

Hallo, mal wieder ein update, C075E815-63EE-41BA-B503-F3C45168E7F9 Das VP (Vehicle park) is in der grundversion fertig.. mit kurzen parkzeiten als test. Es ist integriert mit dem vehicle manager, der den QU kontakt bedient worueber das fahrzeug seine parkdauer bekommt. Hat es keine parkdauer faehrt es durch. Habe keine rampen eingebaut fuer die vituellen spuren, also keine kommentare bitte der aestheten . Der vehicle manager ist in der einfachst moeglichen form gehalten, falls jemand das konzept studieren moechte. Da wird noch einiges hizukommen. Das parkmodul ist nicht mit dem strassenmodul integriert, deswegen kommte es bei der ausfahrt noch zu konflikten. Das park modul veranschaulicht recht gut, was es bedeutet wenn man eine fehlertolerante steuerung bauen will. Ich habe 2000+ zeilen code und immer noch nicht alle moeglichkeiten abgefangen. Damit meine ich, wenn man einfach ein fahrzeug manuell umsetzt, wegnimmt oder hinzufuegt, mitten in dem park modul. Die automatische korrektur von statusvariablen usw. Wenn man das auf instanzebene bauen will und das fuer mehrere situationen, dann wird das aufwendig. Deshalb sind ja steuerungen auf instanzebene meist nur fuer die "richtigen" faelle gemacht. Verwendet man generische scripte braucht man das problem ja nur einmal zu loesen. Wie weit ich das mit allen modulen treibe weiss ich noch nicht. Bin erst mal an den grundversionen und deren verdrahtung interessiert, und natuerlich an dem anschluss an mein steuerprogramm. Wenn das mal laeuft dann kommt die feinabstimmung der module und erweiterung mit verschiedenen nettigkeiten wie, blinker, fahrer ein und austeigen, und was einem so einfaellt. Zur uebersicht wenn ihr lua code anschauen wollt, dann kopiert das script nach VS-Code, da kann man wesentlich besser navigieren. Die event module habe ich so klein wie moeglich gehalten (noch nicht in allen faellen), da diese ja fuer mehrere instanzen kopiert werden. Die scripte auf modulebene sind ja nur einmal vorhanden und der aufbau is fuer alle module gleich, mehr oder weniger. Viel spass beim stoebern. Gruss gmd Noch ein nachtrag. Habe meine spezifikation fuer die manager module erweitert und mal "einen maximalen unfall" dokumentiert. Das wird mir ueber jahre als fundus fuer weitere funktionen dienen Anbei als PDF Manager Module Concept.pdf

Hallo, hier nochmal zur verdeutlichung wie die module logisch verbunden sind. VS,VO und SR sind layout module und definieren content. SC (Signal Crossing), VP (Vehicle Parking) sind aktionsmodule wo etwas geschieht. R sind return kontakte die vom SR modul gesetzt sind. Q sind query kontakte, die fahrzeug parameter setzen bevor ein aktionsmodul erreicht wird. Das kann, muss aber nicht. Soweit mal eine minimale konfiguration. Weitere module werden entsprechend eingebunden. Das gleich wird dann auf die bahn uebertragen. Die regeln sind etwas anders aber die mechanismen die gleichen. SR entspricht einer blocksteuerung, VP entspricht bahnhoefen ... usw. Gleiche architektur. Gruss Gmd

Hallo, mal wieder ein update, komme nur langsam voran, habe nur 1-2 stunden pro tag am abend fuer ein "Hobby". Das parkmodul laeuft in der grundfunktion, habe die spuren noch etwas umgebaut (verschiedene gruende). Der naechste schritt ist die nuetzliche einbindung in den verkehr wie zb. parkdauer setzen, urspruengliches ziel erhalten, blinker setzen usw. hierzu muss man eine menge variablen setzen und das kann muehsam sein. Die konsequenz is ein Vehicle Manager, der alle noetigen informationen enthaelt und abgefragt werden kann. Abfrage ueber einen kontakt, und die info kann auch spaeter dynamisch ueber die schnittstelle geladen werden. Damit vermeide ich statische definitionen, die sich immer wiederholen. Hier meine definition und das feature summary VM “Vehicle Manager” is a logical module that contains information about vehicle behaviour when using various physical modules such as VP, VO, VS, and others. It is intended for PKW. It can be queried for attributes to be stored in the vehicle and used as module parameters — for example, the park duration for a specific VP module. Parameters can be loaded via dedicated contacts and may be defined for individual vehicles or vehicle groups. VM also holds information about vehicle animations, including indicators, lights, and similar behaviours. und hier das feature summary VM – Feature Summary “Vehicle Manager” provides a unified data-lookup system that supplies behavioural parameters to all modules that require vehicle-specific information. It centralises configuration for vehicle types, individual vehicle overrides, route-dependent settings, module-specific values, and contact-driven behaviour queries. Core Purpose VM acts as the central data provider for all modules. Modules request information via Query Contacts, and VM returns the correct data set for the current vehicle, context, and module. How It Works • Centralised Data Tables VM stores structured data tables grouped by: Purpose (e.g., indicators, door behaviour, speed rules) Target module (VP, SR, SS, VO, FD, etc.) Vehicle type (PKW, Bus, Taxi, LKW…) Specific vehicle name (with number suffix extraction) If a specific vehicle name is not defined, VM automatically falls back to the generic vehicle type. • Query Contacts A Query Contact determines what information is requested: The contact name defines the category of data needed. Contact variables can optionally define: Target module or list of modules, Variable names that should be loaded. If no variables are provided, VM returns the entire data group associated with the query type. • Context-Sensitive Lookup VM supports multiple identifiers to determine which data applies: Vehicle identifiers Vehicle Name — including number suffix handling. Vehicle Type — from vehicle.variables["VehicleType"]. Destination identifiers Destination name from vehicle.variables["DestName"]. Contact identifiers Full contact name (with numeric postfix). Generic contact type (e.g. “SR_Query” vs “SR_Query_3”). Key variables Specific behavioural flags (e.g., LeftDoor, Indicators). Module-specific keys (e.g. VP_1, SR_2). Module-type keys (e.g. VP, SS, FD). This allows VM to return precisely the right dataset depending on vehicle, route, module, and contact type. Data Delivery When triggered by a Query Contact: VM determines the required info class. It locates matching entries for: Vehicle name → highest priority Vehicle type → fallback VM loads: Specific variable names requested by the contact or The entire associated table. Resulting values are written into the vehicle’s variables, using the variable names defined inside the data table. Use Cases • Dynamic Behaviour Control Modules can ask for: Indicator settings Door operations Acceleration profiles Dwell times Speed limits Route-dependent parameters • Module Integration VM works as a shared backbone for: VP (Parking & allocation) SR (Sequential routing) SS (Smart signals) VO (Vehicle Outflow) FD (Forked drivethrough) VW (Vehicle Wait) • Scenario-Dependent Configuration Different settings based on: Vehicle destination Contact type Specific stop Assigned module Benefits Eliminates duplicated config across modules Enables fully dynamic vehicle behaviour Centralises all vehicle-related logic Allows simple extension by adding new keys Supports both high-level configs (vehicle type) and precise overrides (vehicle name) Das werde ich jetzt erstmal als naechstes implementieren, dann kann ich auch die timerfunktionen des parkmoduls testen und auch dynamisch entscheiden welche fahrzeuge tatsechlich parken sollen oder nicht, dann braucht man das nicht in jedes fahrzeug legen. VM ist fuer PKW VT fuer transport .. kleine LKW und TAXI VF fuer freight, Semi trailer VB fuer Busse VE fuer emergency vehicles Damit lassen sich dann die spezifischen verhaltensweisen der fahrzeuge in bestimmten streckenabschnitten definieren, zb. langsam fahrt der Semi Trailer bergab usw. Da gibt es keine grenzen und kann einfach per tabelle geladen werden. Wenn ich das am laufen habe (erste version fuer parkdauer) dann poste ich wieder eine anlage mit der integrierten parkbucht . Gruss Gmd

Hallo, hatte gestern und heute noch ein paar stunden und habe weitere specs, elemente und software gebaut. 1) Autobahn mit ueberholverkehr (dynamisch und geschwindigkeitsabhaengig) 2) Bus depot mit routenangabe und fahrplanvergabe 3) Parkbuchten mit dynamischer zuweisund und vielen features fuer verschiedene fahrzeugtypen mit verschiednen kriterien. Die Parkbuchten sind fast fertig .. mit bypass oder drivethrough wenn voll, oder fahrzeugtyp nicht passt, mit kontrollierter parkzeit, und vieles mehr. Auch voellig generisch mit beliebig vielen buchten, einfache oder mehrfache zu- und abfahrt. Beispieldefinition fuer 4 parkbuchten local slotTemplates = { { index = "1-4", entryTarget = {"PB_1_Entry" }, bypass = {"PB_1_Bypass" }, driveThrough = {"PB_1_Exit_Alternative" }, allowedTypes = {"PKW"}, -- Contacts used to drive INTO the slot (sequence of contacts) routeToSlot = {"PB_1_TSlot_*" }, -- slot target -- Track that represents the actual parking location slotTrack = "PB_1_SSlot_*", -- Contacts used to create target for reversing OUT of the slot routeToReverse = { "PB_1_Exit_2", "PB_1_Exit_3", }, -- Track used to detect “backed out far enough” reverseTrack = "PB_1_RSlot_*", -- Forward Exit finalExitTarget = {"PB_1_Exit"}, alternateExitTarget = {"PB_1_Exit_Alternative"}, }, Wildcard * wird fuer namesexpansion verwendet, dann braucht man nicht soviel zu tippen. Verwende dieses modul auch fuer LKW parken in speditionen usw. Die anbindung and die anderen module ist vorhanden, dh. ein fahrzeug kann auf einer route zwischendurch an verschiedenen punkten parken ohne dass das gesamtziel verlorengeht. Alle module koennen daten aus den fahrzeugen auswerten, die den fahrzeugen vom VS modul mitgegeben werden koennen oder auch dynamisch von der schnittstelle gesetzt werden. Das hier nur mal als grober ueberblick. Viele kombinationen denkbar. Gruss Gmd

Hallo, habe weiter an den specs gearbeitet und mal ein data sheet mit gebrauchsanleitung fuer das VS modul gemacht. Anbei das PDF, die mbp datei fuer das beispiel element und als zip die lua datei fuer VS-Code wie im PDF beschrieben. I habe, bzw. mache data sheets fuer alle module fuer meine entwicklung. Benutzeranleitungen aber nur wenn wirkliches interesse besteht, da fuer die anderen module mehr beschreibung fuer die konfiguration noetig waere. Die vorgehensweise bei der installation ist fuer alle gleich und ide lua files fuer VS-Code habe ich ohnehin. Also wer moechte, sagt bescheid. VS hat noch nicht alle funktionen die in der spec erwaehnt sind und falls es ein problem gibt, oder ich etwas vergessen oder uebersehen habe, dann meldet euch. Vielleicht kann ich ja den ein oder anderen motivieren mehr Lua zu benutzen. Jedes modul laesst sich ja anpassen und erweitern allein durch definition, ohne viel programmierung. Von hand ist die namenspflege natuerlich etwas muehsamer als wenn man das automatisiert. Gruss Gmd VS_module.zip VS_Element.mbp MBS_datasheet_VS.pdf

Hallo, hier die uebersicht ueber die derzeit geplanten / implementierten module. Das ist ausschliesslich verkehr, also keine kraene, baustellen, schiffsverladung usw. Vehicle Traffic - Generic Software Modules Module List VEHICLE RELATED VS - Vehicle Source VO - Vehicle Origin VP - Vehicle Parking VW – Vehicle Wait CROSSINGS SC – Signal Crossing UC – Unsecured Crossing RC – Rail Crossing RO - Roundabout ROUTE RELATED SR – Street Routes SS – Segmented Street Routes FD – Forked Drive Through FE – Forked Dead End MISCELANEOUS RO – RoLa VL – Vehicle Load / Unload Module Purpose / Application VEHICLE RELATED VS “Vehicle Source” is responsible for loading vehicles from categorised vehicle groups—typically located on park tracks—into selectable depots. The park track defines the vehicle type, and during loading, type-specific vehicle parameters are automatically applied. VO “Vehicle Origin” defines a vehicle storage system based on depots. Vehicles can be released using different criteria and route-determination modes. The module determines destination, forward target, and return target, and stores these values on the vehicle for use by connected modules. VP “Vehicle Parking” manages complex parking areas implemented with virtual tracks and contacts. It supports large-scale parking logic with criteria for entry control, release ordering, park duration, and other advanced features. It can also be used for transport logistics and other parking-related applications. VW “Vehicle Wait” provides queue management for temporary vehicle stoppage. It is ideal for bus lanes, taxi queues, drop-off points, and similar scenarios, and can be combined with “Forked Drivethrough” (FD) for more advanced flow control. CROSSINGS SC “Signal Crossing” manages signal-controlled road intersections. It supports complex multi-arm layouts, pedestrian phases, turn-specific signals, and coordinated phase timing for consistent traffic flow. UC “Unsecured Crossing” handles non-signalised junctions using right-of-way rules, priority logic, and yield behaviour. Ideal for simple or low-traffic intersections. RC “Rail Crossing” controls road–rail intersections, managing barriers, warning lights, approach triggers, and safety logic to prevent road traffic from entering when trains are present. RO “Roundabout” provides traffic flow management for circular junctions, including priority handling, entry gap detection, and smooth merging for continuous movement. ROUTE RELATED SR “Street Routes” determines full vehicle paths using sequential contacts. Supports direct and indirect routing, speed control, animations, and integration with vehicle origin and depot systems. SS “Segmented Street Routes” define single stretches of road where vehicles wait in specific positions before progressing. Segments can operate as single-lane or multi-lane sections and allow controlled, ordered movement through defined waiting points. Signal controlled or not. FD “Forked Drivethrough” provides a siding or lay-by for vehicles such as buses or taxis to queue for loading and unloading. It represents a separate lane parallel to the main road, with defined entry and exit points, and can be configured with or without a passing lane so through traffic can remain unaffected. FE “Forked Dead End” supports branching street layouts where one or more paths terminate, enabling turning loops, reversing logic, and service operations for taxis, delivery vehicles, and shuttles. MISCELANEOUS RO “RoLa” (Rollende Landstrasse) handles loading lorries onto rail wagons, coordinating rail departure, unloading, and transfer between road and rail for intermodal transport systems. VL “Vehicle Load / Unload” manages areas where vehicles exchange cargo or passengers, including stall assignment, queuing, timed loading operations, and integration with logistics workflows. und in Deutsch: Vehicle Traffic – Generische SoftwaremoduleModullisteFAHRZEUGBEZOGENVS – Vehicle Source VO – Vehicle Origin VP – Vehicle Parking VW – Vehicle Wait KREUZUNGENSC – Signal Crossing UC – Unsecured Crossing RC – Rail Crossing RO – Roundabout ROUTENBEZOGENSR – Street Routes SS – Segmented Street Routes FD – Forked Drive Through FE – Forked Dead End SONSTIGESRO – RoLa VL – Vehicle Load / Unload Modulzweck / Anwendung FAHRZEUGBEZOGENVS „Vehicle Source“ ist verantwortlich für das Laden von Fahrzeugen aus kategorisierten Fahrzeuggruppen – typischerweise auf Abstellgleisen – in auswählbare Depots. Das Abstellgleis definiert den Fahrzeugtyp, und beim Laden werden automatisch typspezifische Fahrzeugparameter gesetzt. VO „Vehicle Origin“ definiert ein fahrzeugbasiertes Lagersystem auf Grundlage von Depots. Fahrzeuge können nach verschiedenen Kriterien und Routenermittlungsmodi freigegeben werden. Das Modul bestimmt Ziel, Vorwärtsziel und Rückgabeziel und speichert diese Werte am Fahrzeug zur Nutzung in angeschlossenen Modulen. VP „Vehicle Parking“ verwaltet komplexe Parkbereiche, die mit virtuellen Gleisen und Kontakten umgesetzt sind. Es unterstützt großflächige Parklogik mit Kriterien für Einfahrtskontrolle, Ausfahrtreihenfolge, Parkdauer und weiteren Funktionen. Es kann auch für Transportlogistik und andere parkbezogene Szenarien genutzt werden. VW „Vehicle Wait“ stellt Warteschlangenmanagement für temporäre Fahrzeugstopps bereit. Ideal für Busspuren, Taxiwarteschlangen, Kurzhaltebereiche und ähnliche Szenarien. Kann mit „Forked Drivethrough“ (FD) kombiniert werden, um erweiterten Fluss zu steuern. KREUZUNGENSC „Signal Crossing“ steuert signalgesteuerte Straßenkreuzungen. Unterstützt komplexe mehrarmige Layouts, Fußgängerphasen, Abbiegesignale und koordinierte Phasenabläufe für einen gleichmäßigen Verkehrsfluss. UC „Unsecured Crossing“ behandelt ungesicherte Kreuzungen ohne Signale mittels Vorfahrtsregeln, Prioritätslogik und Vorsichtshalten. Geeignet für einfache oder wenig befahrene Kreuzungen. RC „Rail Crossing“ kontrolliert Bahnübergänge im Straßenverkehr, inklusive Schranken, Warnlichtern, Annäherungstriggern und Sicherheitslogik, um Straßenfahrzeuge bei Zugverkehr zu stoppen. RO „Roundabout“ steuert Verkehrsflüsse auf Kreisverkehren, inklusive Vorfahrtregelung, Einfahrtslückenerkennung und kontinuierlichem Kreisbetrieb. ROUTENBEZOGENSR „Street Routes“ bestimmt vollständige Fahrzeugrouten anhand sequenzieller Kontakte. Unterstützt direkte und indirekte Routen, Geschwindigkeitssteuerung, Animationen und die Integration mit Fahrzeugdepots und Ursprungssystemen. SS „Segmented Street Routes“ definieren einzelne Straßenabschnitte, in denen Fahrzeuge an festgelegten Positionen warten, bevor sie weiterfahren. Die Segmente können ein- oder mehrspurig betrieben werden und ermöglichen kontrollierte, geordnete Bewegungen durch definierte Wartepunkte – signalgesteuert oder ungesteuert. FD „Forked Drivethrough“ stellt eine Ausweichspur oder Haltebucht für Fahrzeuge wie Busse oder Taxis bereit, um zu laden oder zu entladen. Es handelt sich um eine parallel zur Hauptstraße verlaufende Spur mit definierten Ein- und Ausfahrten, optional mit Überholspur, sodass der Durchgangsverkehr ungestört bleibt. FE „Forked Dead End“ unterstützt verzweigte Straßenlayouts, bei denen ein oder mehrere Pfade enden. Ermöglicht Wendeschleifen, Rückfahrlogik und Serviceabläufe für Taxis, Lieferfahrzeuge oder Shuttlefahrzeuge. SONSTIGESRO „RoLa“ (Rollende Landstrasse) steuert das Aufladen von LKWs auf Bahnwagen, koordiniert Abfahrten, Entladevorgänge und den Übergang zwischen Straßen- und Schienenbetrieb in intermodalen Transportsystemen. VL „Vehicle Load / Unload“ verwaltet Bereiche, in denen Fahrzeuge Güter oder Passagiere aufnehmen oder abgeben. Beinhaltet Stellplatzzuweisung, Warteschlangen, zeitgesteuerte Ladeprozesse und Einbindung in logistische Abläufe. Gruss Gmd

Hallo, mal wieder ein update 904C5AD0-127E-4B96-943A-5596AEE8E457 etwas mehr fehlertoleranz eingebaut und das VO Vehicle Origin kann jetzt auch direct oder indirect setzen fuer die nachfolgende routenauswahl. Das SR Street Route modul kann jetzt indirekte routen ausfuehren, habe eine definiert.. Werde jetzt erst mal meine specs fuer die module erneuern und ueberdenken, nach den ersten erfahrungen. Was wirklich nervt ist der Lua editor, ist halt viel zu basic fuer das was ich tue, also verwende ich VS Code aber das bedeuted immer kopieren.. Ich habe all meine script module in VS Code und aendere auch dort und nur zum test kopiere ich die jeweiligen teile erneut in das MBS. Ein besserer editor oder direkter anschluss eines externen hilft auch nur bedingt, da die scripte ja verteilt sind. Waere nur nuetzlich mit globalen suchfunktionen und besseren strukturierungsmoeglichkeiten. Naja, vielleicht kommt ja mal ein library konzept mit einer IDE (Integrated Development Environment), aber ich denke solange nur wenige benutzer Lua verwenden und noch weniger wirklich intensiv, passiert da nichts auf der front. Gruss Gmd