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:

1. VM determines the required info class.

2. It locates matching entries for:

   • Vehicle name → highest priority

   • Vehicle type → fallback

3. VM loads:

   • Specific variable names requested by the contact
     or

   • The entire associated table.

4. 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,
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

Bearbeitet 27. November27. Nov von 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

Bearbeitet 28. November28. Nov von 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,

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

Bearbeitet 30. November30. Nov von 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,

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,
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,

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,
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

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

Am 7.12.2025 um 06:27 schrieb gmd:

Also lasst es mich wissen, ob ernsthaftes interesse and einer "plug and play" loesing besteht oder nicht.

Du stellst die Frage zu einem ungünstigen Zeitpunkt, jedenfalls für mich. Denn momentan erfordert die neue Version vom MBS meine volle Konzentration, und im realen Leben hält mich ein Räumungsverkauf voll auf Trab. Im Januar oder Februar sollte mehr Ruhe in meinem Leben sein, dann setze ich mich auch gern mit Deiner Arbeit auseinander.

Gruß nach down under

Walter

Ich entschuldige mich auch: Mir gefallen diese Module, aber im Moment sind sie zu kompliziert für mich.

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

Am 7.12.2025 um 06:27 schrieb gmd:

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.

Hallo @gmd ,

ich finde das schon echt "krass" was du da so hinzauberst. Für den Parkplatz wäre ich sehr interessiert. Passt zu meinem Projekt, aber ich denke auch für andere die etwas weniger von Lua verstehen. Ich schaue mir immer die Dateien an und probiere und lerne dadurch. Aber wegen einer Person die Arbeit zu machen musst du natürlich selbst entscheiden. Vielleicht melden sich ja noch einige "Parkplatzbauer"!

Gruß Sven

12 minutes ago, Chaosgrummi said:

.Aber wegen einer Person die Arbeit zu machen musst du natürlich selbst entscheiden. Vielleicht melden sich ja noch einige "Parkplatzbauer"!

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

Hallo,
heute mal was anderes .. ein kleines filmchen ..
habe noch zwei unschoenheiten, die ich beseitigen will und dann noch die blinker und bremslichter, dann is das parkmodul erst mal fertig.

Hier der link: Parken Movie

und hier der entwurf wen es interessiert: 4A12E79C-57D8-48F7-9EA9-CCA8305E34B5 wie gesagt, noch nicht ganz fertig
Gruss
gmd

vor 6 Minuten schrieb gmd:

4A12E79C-57D8-48F7-9EA9-CCA8305E34B5

Die ist super.
Eine sehr süße Szene

7 minutes ago, Goetz said:

Die ist super.
Eine sehr süße Szene

Danke fuer die blumen, ab und zu muss man ja auch was fuers auge tun. Ich arbeite derzeit 10-12 stunden and dieser riesigen kommerziellen app und zwischendurch wenn der AI mal besonders lange denkt baue ich an meinen lua modulen weiter, inzwischen auch sehr umfangreich mit dem AI.
Gruss
Gmd

Hallo,



Fast fertig, habe noch harte stops an zwei kontakten, die ich noch aendern moechte.
Blinker, Bremslicht und Fahrlicht implementiert. Licht schaltet aus beim parken. Kurze bremslichtperioden habe ich nicht implementiert da ich nur einen 10s timer verwende und nicht noch mehr belastung fuer das MBS shaffen will ... wenn ich alle meine module mal zusammen am laufen habe, erwate ich dass der rechner und das MBS das nicht mehr schafft. Ich sehe vor, dass man einzelne komponenten/module aktiviert wenn eine kamera darauf gerichtet ist und das vom gesamtablauf moeglich ist. Es werden keine
kompletten anlagen sein, teilstuecke (immer noch gross) aber dazwischen verzoegerunsgstellen fuer den verkehr in virtuellen depots, damit der sichtbare verkehr ueberschaubar bleibt. Schon jezt spuere ich das MBS aechzen mit den routenzuweisungen und script ausfuehrungen. Muss da noch nach optimierung suchen, und es ist nicht die grafik, es ist die scriptausfuehrung, die ja augenscheinlich nicht multithreaded laeuft.

Die scripte sind noch nicht vollstaendig aufgeraeumt, haben noch viele explizite zuweisungen und verwenden nicht setter und getter, die aber alle definiert sind.
Ich will dies scripte fuer dieses modul soweit bereinigen, dass sie als vorlage fuer weitere module dient. Bevor ich allerdings mit Lua intensiv weitermachen, gehe ich erst mal an mein C# programm zurueck und teste die integration.
Hauptgrund ist der folgende:

Das obige bild zeit die definitionen fuer ein fahrzeug, mit standardisierten animantionen, geschwindigkeitsverfielfachern, typdefinition und weitere.
Die typedefinition mit animation und geschwindigkeiten ist hier manuell definiert, das ist mir aber auf dauer zuviel arbeit und mein programm hat ja schon die voraussetzungen das zu automatisieren. Ich habe animationslisten pro fahrzeug, kenne den fahrzeugtyp und kann dies konfiguration beim plazieren automatisch mitgeben.
Ausserdem habe ich keine lust all komponenten eines solchen moduls manuell umzubenennen, wenn ich ein zweites plaziere. Ueber die schnittstelle kann ich das auch automatisieren. Ich denke damit wird jetzt mehr und mehr klar, warum ich das mache .. Ein solches parkmodul mit der EV zur beliebigen wiederverwendung zu bauen ? Also ich koennte das jedenfalls nicht, dazu haette ich nicht die nerven. Anyway, wie man hier sagt, jedem das seine.

update wen es interessiert: 4A12E79C-57D8-48F7-9EA9-CCA8305E34B5

Und falls ihr fehler findet oder unfaelle erzeugt, dann lasst es mich wissen. Habe noch nicht alle variationen von einstellungen getestet. Das kommt noch spaeter im betrieb. Mir war die erstellung des konzeptes erstmal wichtiger.

Alternative ausfahrt, mehrspurige ein- und ausfahrt, richtungsaenderung von ein und ausfahrt (parameter in definition) und vieles mehr ist allein fuer dieses modul denkbar. Aber das ist dann version ?? Das modul ist jedenfalls jetzt in einem zustand dass man es einfach wiederverwenden kann, wenn man sehr sehr vorsichtig ist und die spuren veraendern will. Ich rate es nicht zu tun, es ist sensitiv, und am besten nur die vorhandenen anschluesse verwenden. Dann geht das mit minimu aufwand.

gruss
Gmd

Hallo,


hier ist das modul CM_Park 77F4E85C-4252-4278-A8AC-4CA0384A76A3

Hier ist das datasheet/manual

und hier der absatz zur verwendung

Set name: CM_Park

The module is delivered as a complete sample set and can be run as a standalone installation. The simplest way to integrate it into another layout is to import the entire module first, confirm correct operation, and then customise only the visible elements (labels, signals, decorative objects, and other appearance-related components).

Portals may be replaced with connected tracks without affecting functionality, provided that the contact sequence and routing logic remain unchanged. When modifying or re-laying the module’s virtual tracks, proceed with caution: these tracks are sensitive to imprecise joints and small alignment errors, which can cause unreliable contact triggering or unexpected vehicle behaviour.

Das ist alles was man wissen muss ... UND jedes fahrzeug das parken soll braucht eine variable VehicleType = "PKW" sonst faehrt es vorbei.

Der rest des dokuments ist dockumentation des codes und der strukturen fuer die die es interessiert. Fuer mich ist es gedankenstuetze und vorlage fuer die naechsten module.

Es gibt noch den ein oder anderen kleinen fehler, denn ich noch nicht richtig identifizieren konnte. Falls ich das finde mach ich einen update im modul.

Gruss
Gmd

Hallo,

habe mal wieder an meinem steuerprogramm weitergebastelt. In vorbereitund fuer module wie das obige VP oder VS habe ich an meinem Ebenensieb gebasltet. Ebenensieb ist ein mechanismus mit dem ich filterkriterien definieren kann, die dann auf selektionen angewendet werden und die gelesenen objekte in die gruppen aufteilt. Damit kann man die unterschiedlichsten funktionen treiben, zum beispiel elemente einer gruppe selektieren und einer ebene zuweisen, oder schlagworte zuweisen, oder unsichtbar machen und gegen andere objekte einblenden, also ganze landschaftsteile auswechseln. Oder elektrifizierte strecken umwandeln durch einfaches ausblenden von oberleitungen, oder auch dynamisch gruppen bilden.. und und ..

Ich habe meine eigene katalogstruktur, die ich aufgeteilt habe wie es mir zweckmaessig erscheint. Also zum beispiel habe ich die vegetation feiner unterteilt, damit ich nicht so lange suchen muss oder auch eine kategorie als ganzes auf die anlage stelle (beliebige kopien) und dann einfach verteile. Eindeutige namensvergabe ist dabei immer gewaehrleistet. Es geht so wit, dass ich auch einzelne objekte als filterkriterium angeben kann, dass passiert im Ebenensieb "Manuell".
Der naechste schritt is dynamisch nach variableninhalten eines objektes zu filtern und zu gruppieren, nicht nur nach typ oder namesbestandteil, also auch nach schlagworten. Das wird ueber die neue schnittselle mit Lua scripten geloest.
Das sind alles infrastruktur massnahmen und funktionen bevor ich dann irgendwann wirklich and die steuerung herangehe.
The gruppen koennen wie die ebenen eingefaerbt werden und auch im kategoriebaum sieht man dann gleich die verwendeten farben. Ich kann jede ebene eines zweiges in die gruppe ziehen. Das ist jetzt soweit fertig. Der naechste schritt ist die anwendung ..
Ich hatte zuvor eine einfache version gebaut, die eine selektion auf die hauptgruppen verteilt, das war aber einfach nicht gut genug, zu grob fuer die meisten zwecke.


Als naechstes werden diese einfachen listen durch die gruppendefinitionen ersetzt und die selektierten objekte werden dann zugeordnet und dies aufteilungen koennen gespeichert und aktualisiert werden.

Gruss
Gmd

Hallo,

habe meine filterfunktionen noch erweitert und mit manuellen drag drop objekt additionen versehen. Damit kann ich jetzt beliebige filter und auch objekttypgruppen definitionen bilden fuer die verschiedensten anwendungen.
Ich erneuere meine todo- liste regelmaessig, da ja immer neue module fertig werden und auch neue ideen und anwendungen hizukommen.
Anbei das pdf mit dem derzeitigen stand der angedachten features. Bisher habe ich ja mehr oder weniger research gemacht, proof of concept wie man sagt, und jetzt fuege ich allmaehlich die teile zusammen.
Wen es interessiert, hier das pdf. Ist aber noch nicht sehr detailliert was den betrieb angeht. Auch bedenke man, die einzelnen punkte sind keine beschreibungen, sondern nur gedankenstuetzen.
Funktionmsumfang MBS Companion V2.pdf

Gruss
gmd

Hallo,
hier noch mal ein beispiel fuer die filterfunktion und ihre anwendung. Es gibt zwei ebenen der anwendung, einmal auf der objekttyp ebene und zum zweiten auf the auspraegungsebene. Typen sind die katalog elemente und auspraegungen sind ihre tatsaechlichen instanzen (auch mehrfach) auf einer anlage.
Mit den "erweiterten" filterfunktionen kann ich einzelne katalogobjekte dem filter zufuegen, auch ohne eine kategorie. Im unteren beispiel habe ich eine gruppe Begleitfahrzeuge und eine gruppe Loeschfahrzeuge. Dieser filter definiert einen Loeschzug der zu einem einsatz abgerufen werden kann.
Die definierten objekte werden mit eindeutigen namen abrufbar plaziert (mit Reihenfolge), der einsatzbefehl startet die einsatzfahrt an ein definiertes ziel.
Das ist das beispiel auf the typebene.
Wenn man jetzt eine oder auch mehrere gruppen auf der anlage positioniert und in betrieb hat, dann will man vielleicht eine gruppe oder auch alle identifizieren. Dann kann man die filterdefinition and das ebenensieb ausfuehrungsmodul uebergeben und erhaelt als antwort die liste der gefundenen einheiten mit position und variablen inhalt.
Nun kann man aktionen abrufen, wie zurueckfuehren auf ursprung, oder entfernen oder einfach animationen ein oder auschalten fuer alle oder einzelne fahrzeuge.
Ich standardisiere die aktionen ueber gruppen von objekten und fuehre sie aus mit solchen instanzgruppen als parameter. Damit wird auch oeffnen von tueren an haltestellen und ein/aussteigen von personen getriggert usw. Immer wenn man eine gruppe von objekten zu einer gemeinsamen gleichen oder zusammenhaengenden aktion verwenden moechte kommen filter zum einsatz. Ich versuche so viel wie moeglich zu abstrahieren, damit ich nicht jede kleinigkeit separat implementieren muss.
Zumindest ist das der plan.
Das klingt immer noch sehr abstrakt, aber viel einfacher kann ich das nicht erklaeren, solange ich noch keine echten beispiele zum vorfuehren habe.


Die einzelnen views lassen sich rausloesen und auch wieder andocken, sodass man sie anordnen kann wie es gerade zweckmaessig ist.
Gruss
gmd

Hallo,


Heute ein weiterer schritt in richtung automatisierung der konstruktion. Wir hatten ja versuche mit plugins und auch die mehrfach plazierung im MBS hilft etwas, aber es it immer noch sehr muehsam interessante sets von vegetation zu erstellen, insbesondere bei groesseren flaechen. Mich hat es genervt, dass die gruppierung nicht detailliert genug war um sinnvolle gruppen leicht zusammenzustellen und auch die favorites helfen da nur bedingt. Da ich ja nun die filter und andere mechanismen implementiert habe sind die naechsten schritte wirklich einfach.
Aus einem filter, mache ich ein aktives element und erzeuge ein definiertes set auch mit manueller erweiterung wie oben (voriger post) gezeigt, oder durch bilden eines subsets (kleine gruene punkte in den bildern im obigen image) und speichere als benannte palette ab. Jederzeit wieder aufrufbar. Ich plaziere einen peilstab, name ist im parameterfenster vergeben und mit der palette gespeichert. Jetzt kann ich nach den verschiedensten strategien gruppen bilden und plazieren. Die ergebnisse sowie die parameter werden ebenfalls gespeichert und sind jederzeit wieder abrufbar. Auch kann ein ganzer wald entfernt und wieder neu aufgebaut werden.
Sollten einzelne element von hand versetzt werden koennen alle positionen erneut eingelesen und aktualisiert werden, falls erforderlich.
Nachdem jetzt die architektur und navigation meiner anwendung steht, und die grundlagen gelegt sind, mit den schnittstellen funktionen und Lua integration, geht das fertigstellen von funktionen immer schneller. Der AI hilft natuerlich, ich kann in zwei stunden einige tausend lines of code erzeugen fuer die ich vorher tage gebraucht habe.
Wenn ich fuer den AI die vorgaben genauer machen kann, da ich ja jetzt beispiele fuer alle mechanismen bereit habe, sind auch die ergebnisse wesentlich genauer und naeher am endresultat.
Die peilstabmethode verwende ich auch fuer die segment berechnung, ortsbestimmungen und anderes. Ausserdem behalte ich alle peilstaebe die ich beim oberleitundsbau verwendet habe in der datenbank und kann sie jederzeit wieder abrufen und einsetzen.
So allmaehlich faengt das programmieren an spass zu machen, da mehr und mehr teile zusammenwachsen.
Mit den baeumen das ist ein beispile fuer "ungefuehrte" plazierung. Die "gefuehrte" plazierung kommt als naechstes, wobei bewegte objekte wie fahrzeuge und fussgaenger auf spuren plaziert werden. Fuer zuege habe ich bereits fertige funktionen zur aufgleisung auf bereitstellunsgstrecken.

Merry Christmas
Gruss
Gmd