gmd
-
Gesamte Inhalte
673 -
Benutzer seit
-
Letzter Besuch
Beiträge erstellt von gmd
-
-
Hallo,
habe die definitionsphase fuer das module "Vehicle Origin" soweit abgeschlossen.
Anbei der derzeitige stand der dokumentation und scripte.
Jetzt kommt das design der demo anlage und die verwwendung (test) der scripte.
Werde zwei module einrichten, dann sieht man gleich wie die scripte mehrfach verwendbar sind.
Diese demo ist dann auch fuer mich die basis fuer das design nachfolgender module. Bei meinem gedaechtnis brauche is so etwas inzwischen.
Die RoLa ist das beispiel der kombination mehrerer teilmodule zu einer groesseren anwendung.
Wenn das abgeschlossen ist gehe ich wieder an die gleise und baue aehnliche generische module fuer gleise.Gruss
Gmd
-
Hallo,
heute eine weitere version der dokumentation mit einem grossen teil der scripte fuer die erste komponente der RoLa "Vehicle Origin".
Noch nicht ganz vollstaendig, ohne die tatsaechliche anbindung an ein MBS modul, das kommt noch mit einer demo anlage, wenn ich
dann tatsaechlich die scripte teste.
Ich habe die dokumentation inclusive der scripte in word geschrieben. Nachdem ich die tests mit RoLa gemacht habe, bin ich einigermassen fliessend in Lua und kann die scripte schreiben ohne syntax check. Teilweise copy/paste, teilweise neue strukturierung, jedenfalls eine etwas bessere ordnung als in meinen testscripts.
Jede der abstrahierten komponenten wird dann separat getestet und zum schluss werden die einzelteile zur RoLa zusammegefuegt.
Die scripte dienen dazu die teilweise cryptischen zugriffe auf tabellen in leichter lesbare, "sprechende" begriffe zu verpacken und einfacher ablaeufe zusammenzustellen. Zugriffe auf 3 oder 4 dimensionale listen, koennen leicht unuebersichtlich werden, wenn man keine spezifischen zugriffsmethoden baut.
Bitte beachten: Die scripte sind noch nicht getestet. Wenn der entwurf vollstaendig ist, dann kann ich die scripte so wie sie sind vom word text in VS Code kopieren und syntax pruefen, und dann nach MBS in ein globales script uebernehmen und das anwendungsbeispiel zusammenbauen.
Gruss
Gmd
Edit:
Updated the pdf with a revison, added scripts and a depot return definition, scripts not completely tested, but partially syntax checked !
It has proven useful to rethink the functions and start fresh top down, including documentation. Some generic scripts will be added as an appendix.
Next step is to create the event module and event handlers in the studio for a demo. -
Hallo,
unser sommer geht langsam zu ende und die grosse hitze in Perth ist langsam vorbei. Wir sind immer noch in unserem sommerdomizil, fahren aber naechste woche wieder nach hause. Ich dachte ich schreibe mal wieder einen update, ueber das was ich in der letzten zeit mit dem MBS gemacht habe.
Ich habe ein pause von der codierung fuer meine gleissteuerung eingelegt, um die verhaeltnisse mit strassenfahrzeugen besser kennenzulernen und moegliche parallelen zu erkennen. Ich habe mir drei scenarien ueberlegt, eine RoLa, eine grosse spedition und einen grossen bahnhofsparkplatz, die ich automatisieren moechte mit weitestgehend wiederverwendbaren scripten.
Das bauen von umfangreichen, virtuellen strecken mit vielen verzweigung kann muehsam sein, aber nach einer weile bekommt man uebung. Ich habe viele einzelne funktionen implementiert und stueck fuer stueck gelernt, wie ich abstrahierte funktionen mit Lua implementieren kann.
Die verallgemeinerung ist aber noch nicht vollstaendig abgeschlossen, jetz folgt eine "Ordnungsphase" die einzelnen funktionen in leicht wiederverwendbare einheiten zu verpacken.
Dazu habe ich angefangen eine dokumentation zu schreiben mit der RoLa als beispiel, die den entwurfsprozess mehr top down formalisiert und nun eine klare richtlinie wird, wie ich die scripte gruppiere und parametrisiere um die moeglichst beste wiederverwendbarkeit zu erreichen.
Anbei ist das dokument, welches erweitert wird und schliessendlich die gesamte beschreibung der verwendung der scripte enthaelt. Das dokument ist in English aber es gibt ja uebersetzer. Ich schreibe lieber in English. Ich bin nicht versiert in deutscher IT sprache.
Gruss
Gmd
-
Hallo,
Ich verwende keine kommentare um code zu deaktivieren, auch wenn ich damit microsekunden verschenke.
Ich vermisse mehr #region #endregion um code segmente zu kollabieren, da meine skripte sehr umfangreich sind
Fuer debug und test verwende ich
$("Ereignisse").variables["Debug"] = true $("Ereignisse").variables["ErrorPrint"] = true function IsPrintError () if $("Ereignisse").variables["ErrorPrint"] == true then return true else return false end end function IsDebug () if $("Ereignisse").variables["Debug"] == true then return true else return false end end -- use the debug variable instead of print in the main script (print not implemented yet in MBS) function debugMessage(msg) if IsDebug then $("Ereignisse").variables["DebugOutput"] = msg -- Store only the last message will be displayed in the Eventlist end end
Man kann das auch noch differenzieren fuer teile von skitpten mit anderen oder mehrfach bedingungen. Das finde ich wesentlich flexibler.
Am editor nerven mich andere dinge: zum beispiel dass der curser mit down nicht and das jeweilige ende der zeile springt, double click drag markiert nicht wortweise sondern nur das erste wort, usw.
Verglichen mit einem richtigen editor ist der studio editor ein absolutes spielzeug. Viele teile meine scriptes schreibe ich in
Visual Studio Code mit Lua by sumneko.
Ich verwende den editor nicht um kleinkram zu testen (zuviel copy und paste), ich konsolidiere meine scripte hier.
Da ich nur wenige event module verwende (meist nur globale scripte) is das copy und paste akzeptabel. Trotzdem
waere es schoen einen externen editor anschliessen zu koennen wie bei EEP, eines der wenigen features in EEP die ich
ok finde.
VS Code ist frei, so ist die Lua extension und kannWindows: Shift + Alt + A
Gruss
Gmd
Edit: Posted in the wrong thread -
On 2/25/2025 at 8:42 AM, Goetz said:
Fahrstraßen legt man vorher an, damit sie den Betrieb erleichtern..... und damit man ein performance problem umgeht. Im bild unten geht das anlegen einer langen fahrstrasse in den minutenbereich.
Nicht in allen situationen sind fahrstrassen eine erleichterung. Man kann sie auch fuer strassenfahrzeuge anlegen, aber zumindest fuer meine anwendungen ist das einfach nicht sinnvoll. Sobald eine anlage mehr "Bewegung" hat kommt man schnell an verwaltbare grenzen.
Hier ein beispiel and dem ich derzeit meine scriptkomponenten (erstellt fuer die RoLa und Spedition) teste und varianten einbaue. Fuer diese situation, fahrstrassen vor dem betrieb einzurichten ist nicht das was man machen will. Die zieldefinition ist hier voellig ausreichend bis auf die performance. Ich hangele mich von kontakt zu kontakt und das macht die kalkulation tragbar, allerdings haengt das auch stark davon ab wieviele fahrzeuge in solchen situationen unterwegs sind. Hier im beispiel parkplatz ist das ziel typisch zwischen 5 und 10 fahrzeuge gleichzeitig ein- und ausfahren zu lassen, mit ein- und ausparken.
Das ziel zumindest meiner scripte ist es, so viel wie moeglich bewegung und abwechslung auf einer anlage zu schaffen, die dann ueber entsprechende kamerafuehrung projektiert wird.
Es macht also durchaus sinn eine zieldefinition "aufzuheben", was ja einer "einfachen" fahrstrasse entspricht (ohne weichen). Abgespeicherte zieldefinitionen abzurufen macht das alles sehr viel effizienter. Wenn eine zieldefinition ungueltig wird dann bleibt das fahrzeug halt stehen.
Ich wuerde bei anlagen start eine initialisierung durchfuehren, die wichtige, lange zieldefinitionen einrichtet.
Wuensche wie, "Bessere Ubersicht fuer Fahrstrassen" etc. zeigen die grenzen der manuellen verwaltbarkeit.
Ich weiss, ich bin mal wieder ein "Einzelfall" aber auch andere werden mehr und mehr ueber automatisierung und "script bibliotheken" nachdenken.
Und noch ein weiterer gedanke: Ich habe auch kein problem 100 Euro im jahr fuer eine "Expert" version zu zahlen, die dann vielleicht nur auf einem etwas anspruchsvolleren rechner laeuft. Die hardware wird immer schneller und billiger.
Gruss
Gmd
-
6 minutes ago, guenter.strickmann said:
Vielen Dank erstmal für den Vorschlag. Das geht aber ein wenig am Kern meines Wunsches vorbei.
Wenn ein Zug auf Gleis 6 bis zum Einfahrsignal einfährt, könnte er theoretisch alle Gleise 1-6 belegen. Kommt jetzt zeitgleich ein Zug auf Gleis 2 angefahren und fährt in 6 ein, dann "schneidet" er alle Gleise für den Zug auf 6 ab, wenn ich nur einmal die Wdh-Funktion nutze. Durch den Timer schaue ich alle par Sekunden, ob wieder ein Gleis frei wird.
Das konntet ihr nicht wissen, aber wenn ich euren Ansatz wählen würde, bliebe der Zug auf 6 stehen, bis ein Zug von vielleicht Gleis 3 ausfahren würde. Dann würde 6 in 3 einfahren. Zeitgleich wären aber vielleicht, 1,2,4 und 5 schon frei gewesen. Ich hoffe, das war verständlich.
Durch die Timerabfrage habe ich also die Möglichkeit, ständig nach freien Gleisen "Ausschau" zu halten.
Wie gesagt, dass funktioniert auch. Aber geht das nicht auch anders?
Ich antworte mal ohne dein beispiel anzuschauen.
Ich wuerde keinen timer verwenden, der loest event aus auch wenn nichts zu tun ist und loest nicht gleich aus wenn was tun ist, jenachdem wie oft er eingestellt ist.
In meinen augen die bessere loesung ist, entweder einfahr- und ausfahrgleisen, oder kontakten das gleiche schlagwort zuweisen und einen event verwenden, der bei diesem schlagwort entweder fuer gleis oder kontakt ausloest. Damit weisst du ganz genau dass es lohnt etwas zu tun, und wenn du jetzt noch das gleis oder kontakt benennst und abfragst weist du auch welches gleis betroffen ist.
Mit diesem konzept vermeide ich timer generell.
gruss
Gmd
-
Hallo,
Ueber die schnittstelle habe ich ja editor.createEntity, was in lua nicht existiert.
Ich habe mehrfach die anwendung fahrzeuge aus einem depot zu holen, habe aber nicht die geringste lust fuer alle diese situationen die fahrzeuge manuell zu plazieren und in ein oder viele depots zu schicken.
Wuerde gerne in Lua fahrzeuge aus dem katalog direct ins depot schicken. Das depot kann ja einen fahrzeugverbund verwalten, das wuerde ich nicht mit einbeziehen. Einzelne fahrzeuge mit antrieb sind ausreichend und ist einfach zu realisieren., inclusive setzen der ausfahrgeschwindigkeit.
Ich kann das mit meinem programm erledigen, aber die Lua scripte die ich stueck fuer stueck erstelle und auch plane zu veroeffentlichen, wuerden von einer automatischen fahrzeugbereitstellung profitieren.
Verbund konfiguration koennte ueber "Meine modelle" abgewickelt werden, aber das nur um es zu erwaehnen.
Gruss
Gmd
-
siehe oben -- empty, check for keyword
if v == keyword
gruss
Gmd -
14 hours ago, EASY said:
Hallo,
... liefert zwar nicht für alle Variablentypen ein Ergebnis (v)... ich aber für einen Überblick ganz praktisch und ausbaufähig
Gruß
EASYfor k, v in pairs(contact.variables) do print("VAR: " .. tostring(k) .. " = " .. tostring(v)) if v == keyword then print("VAR is keyword") end end
Zum beispiel, empty v test fuer keyword.
Ich nutze das jetzt um keywords der beteiligten objekte abzufragen.
Gruss
Gmd
-
17 hours ago, EASY said:
Hallo,
... die Falle liegt allerdings bei Dir
Ha, und ich koennte schwoeren dass ich das probiert habe ..
Ist aber logisch, danke fuers finden.
Gruss
Gmd
-
Wen es interessiert - hier eine loesung die ich fuer mich ausgetueftelt habe ..
Ich verwende schlagworte fuer eine serie von objekten, kennzeichne aber einige mit zusaetzlichen merkmalen
wie "_Start" oder "_Ende" usw.
also zum Beispiel XYZ und XYZ_Start wenn nun XYZ ausloest (weil ich alle XYZ haben will) aber fuer _Start etwas anderes tun will
dann benutze ich
function GetStartKeywordPrefix(contact) for k, v in pairs(contact.variables) do local prefix = string.match(k, "^(.-)_Start$") if prefix then return prefix end end return nil -- Not found end
und bekomme das ausloesende schlagwort und gleichzeitig die information _Start. (_Start is bei mir immer nur einmal vorhanden)
Man kann natuerlich auch alle moeglichen anderen variationen verwenden und es muss auch nicht das ausloesende schlagwort sein.
Damit lassen sich auch kaskaden von filtern bauen.
Auf diese art und weise muss ich nirgendwo das schlagwort explizit angeben. Ich kann dann einen event "Alle Kontakte" oder was auch immer verwenden und trotzdem auf das schlagwort abfragen ohne durch meine gesamte liste durchgehen zu muessen.
Gruss
GmdNachtrag: Ich habe diese funktion auch fuer variable suffixes, die auch Lua special characters enthalten koennen.
function GetKeywordPrefixBySuffix(contact, suffix) -- Escape the suffix if needed for pattern matching local escapedSuffix = suffix:gsub("([%^%$%(%)%%%.%[%]%*%+%-%?])", "%%%1") local pattern = "^(.-)" .. escapedSuffix .. "$" for k, _ in pairs(contact.variables) do local prefix = string.match(k, pattern) if prefix then return prefix end end return nil end
-
1 minute ago, Goetz said:
care to explain?
Ja werde ich tun, ist aber nicht so einfach ohne das entsprechende beispiel fertig zu haben.
Hier eine beschreibung der zielsetzung.
Stell dir folgende anwendungen vor:
Ein Taxiplatz an dem fahrzeuge ein und ausfahren an halteplaetzen
Busse halten in reihe an einer umsteigestation
Die Einfahrt fuer LKW in meine RoLa
Das Auffahren von Fahrrzeugen auf die wagen ..
Eine warteschlange von personen vor einem point of interest
und was einem noch so alles einfaellt mit einer "segmentierten Einfahrt" mit oder ohne ampelsteuerung.
Das alles wird mit dem gleichen script reaslisiert und definitionstablellen mit minimalen (keinen) eintraegen von "Expliziten" werten.
Geht alles dynamisch und kann auf verschiedene events verteilt werden oder auch nicht.
Grund: Man muss nicht immer wieder ueber die gleiche logik nachdenken oder die gleichen fehler beseitigen und testen.
Es ist wie eine library die man einfach verwendet.
Die programmierung erfolgt auf der "Meta" ebene und nicht auf der logischen ebene der evenets, dort laeuft das programm nur ab.
Alles ist in parametrisierte funktionen gepackt.
Man kann die definitionstabellen von hand erstellen und in Lua bleiben, mein ziel ist es auch diese tabllen von meinem programm zu generieren.
Wenn ich meine RoLa fertig habe mit den verallgemeinerten scripten dann werde ich dir den entwurf zur durchsicht geben. Dann wird
das klarer und bedarf nicht so vieler worte.
Gruss
Gmd
-
1 hour ago, EASY said:
Hallo,
der einzige Umweg, der mir einfällt ist, den Schlagwortnamen (die Schlagwortnamen) in einer Objekt-Textvariablen (Liste Objekt-Textvariable) zu hinterlegen und diese dann abfragen. Dann hast Du eine (namentlich bekannte) Variable für weitere Verzweigungen... dies steht allerdings etwas entgegen zu dem eigentlichen Sinn von Schlagworten, da man so prinzipiell natürlich dann auch nur über die Variable arbeiten könnte.
Gruß
EASYEasy
koennte fuer dich auch interessant sein.
for k, v in pairs(contact.variables) do print("VAR: " .. tostring(k) .. " = " .. tostring(v)) end
probier es aus .. das ist ein teil der miete
Warum bin ich eigentlich nicht frueher darauf gekommen !!
gruss
Gmd
Edit: noch ein tip
hier weise ich ein keyword zu
entryObject.variables[keywordText.."_Start"] = keyword
hier frage ich ab
contact.variables[keywordText.."_Start"] == keyword
das funktioniert auch so weit .. aber wenn ich versuche diese abfrage in eine funktion zu legen
wie hier
function IsStartKontakt(keyword, kontakt)
if kontakt.variables[keyword .. "_Start"] == keyword then
return true
else
return false
end
end
dann ist das immer falseDiese funktion bringt true zurueck ..
function IsStartKontakt(keyword, kontakt)
if kontakt.variables[keyword .. "_Start"] then
return true
else
return false
end
end
Eine weitere coding falle
-
36 minutes ago, EASY said:
Hallo,
der einzige Umweg, der mir einfällt ist, den Schlagwortnamen (die Schlagwortnamen) in einer Objekt-Textvariablen (Liste Objekt-Textvariable) zu hinterlegen und diese dann abfragen. Dann hast Du eine (namentlich bekannte) Variable für weitere Verzweigungen... dies steht allerdings etwas entgegen zu dem eigentlichen Sinn von Schlagworten, da man so prinzipiell natürlich dann auch nur über die Variable arbeiten könnte.
Gruß
EASYJa das tue ich .. pflege eine liste aller schlagworte und gehe einfach alle durch zum entfernen und auch zum testen ob vorhanden.
Man muss ziemlich viel umwege gehen um eine library von generischen funktionen aufzubauen. So scheint hier niemand zu denken.
Gruss
Gmd
-
32 minutes ago, Goetz said:
Wenn ein Ereignis durch Objekte mit einem Schlagwort ausgelöst werden, dann reagieren sie nur auf ein einziges, explizites Schlagwort. Da ist nichts generisches an dieser Stelle. Also kannst du dasselbe Wort auch innerhalb des Ereignisses explizit angeben (und zum Beispiel als Argument an andere Funktionsaufrufe weiterreichen.)
sooo wrong .
Gruss
Gmd
-
Ja, aber in einem generischen script verwendest du keine "expliziten" werte.
Gruss
GmdEdit: fuer contact und vehicle brauche ich auch keine expliziten referenzen und kann voellig allgemeine funktionen bauen, die unabhaengig vom kontaktname sind und muss nicht jedesmal wenn ich den aufruf verwende die parameter explizit einfuellen.
Ich kann die verteilung auf ereignisse veraendern ohne jedesmal den code anfassen zu muessen.
Ein weiteres problem ist, dass man nicht die schlagworte zu einem objekt bekommt ohne die namen zu kennen. Zumindest kenne ich keinen weg. Lua ist nicht sehr geeignet um auf der Meta ebene zu programmieren. Da muss man einige umwege gehen.
-
Hallo,
Ereignis: Ein Gleiskontakt mit Schlagwort "XYZ" wird ausgeloest
Ich habe contact und vehicle als variablen im script.
Kann ich das schlagwort abfragen, welches ausgeloest hat ?
Gruss
Gmd
-
12 hours ago, EASY said:
t = $("Ereignisse").variables["SwNamen"] for _,v in ipairs(t) do local s=layout:getEntitiesByKeyword(v) for _,sw in ipairs(s) do sw.variables[v] = nil end end
... so werden beim Listendurchlauf nicht immer alle Objekte angesprochen sondern nur die, mit dem entsprechenden Schlagwort...
... etwas "einfacheres" ist mir [leider] nicht eingefallen... wäre aber vielleicht etwas für die "Wunschliste"
Gruß
EASY
Diesen gedanken werde ich verwenden.. Immer wenn ich ein objekt keyword setze, werde ich das keyword "marked" setzen. Dann bekomme ich alle objekte mit keywords und vermeide alle objekte abzurufen. Das erscheint mir am besten, mit den gegebenen moeglichkeiten.
Gruss
Gmd
-
Danke an euch beide.
Ich dachte mir so etwas. Ich habe eine funktion mit der ich alle aktuell verwendeten modul keywords loesche bevor ich ein neues setze.
Ich vergebe keywords grundsaetzlich durch code in einer initphase und dann auch waehrend des betriebs. Die meisten keywords
habe ich in einer tabelle, aber beim erstellen einse scriptes kommt es vor dass man keywords aendert und dann bleiben die
alten "haengen". Die muss ich dann halt alle manuell pflegen. Insbesondere fuer objektvariablen. Da werde ich dann eure vorschlaege nutzen.
Tabellen habe ich derzeit fuer "statische" Modulvariablen.
Ich poste mein beispiel hier fuer andere als beispiel. Dann hatte der thread wenigstens einen sinn mit euren beitraegen.
Zunaechst ein Beispiel einer definitionstabelle. Der erste eintrag is das keyword, danach folgen listen von kontakten.RouteIdentifikation = { { "RolaZufahrt", { ["RolaEntryRoute"] = 1 } }, { "RolaExit", { ["RolaExitRoute"] = 2 } }, { "RolaEinfahrt", { ["RolaEinfahrRouten"] = 3 } }, { "RolaAusfahrt", { ["RolaAusfahrRouten"] = 4 } }, { "RolaLoading", { ["RolaLadeRouten"] = 5 } }, { "RolaUnLoading", { ["RolaAlternativAusfahrt"] = 6 } }, { "RolaAltExit", { ["RolaAlternativAusfahrt"] = 7 } }, { "RolaWagenLaden", { ["RolaWagengruppe1Lkw"] = 8, ["RolaWagengruppe2Lkw"] = 9 } }, { "RolaWagenEntLaden", { ["RolaWagengruppe3Lkw"] = 10 } } }
Hier die funktion, die bei der initialisierung den kontakten ein statisches keyword zuweist. Wird ueberall fuer alle module verwendet.function InitialiseAllKeywords(Modul, RouteIdentifikation, clearExisting) for i, entry in ipairs(RouteIdentifikation) do local keywordText = entry[1] -- Extract keyword (e.g., "RolaZufahrt") local routeGroups = entry[2] -- Extract table of route lists for groupName, _ in pairs(routeGroups) do local KontaktListe = _G[groupName] -- Dynamically fetch global table by name if isListOfLists(KontaktListe) then for _, sublist in ipairs(KontaktListe) do ProcessKontaktListe(sublist, keywordText, clearExisting) end else ProcessKontaktListe(KontaktListe, keywordText, clearExisting) end end end end
Hier die funktion die einzelne listen verarbeitet
function ProcessKontaktListe(KontaktListe, keywordText, clearExisting) local lastIndex = #KontaktListe for i, entryName in ipairs(KontaktListe) do local entryObject = layout:getEntityByName(entryName) if entryObject ~= nil then if clearExisting then ClearKeywords(entryObject, RouteIdentifikation) -- Clear previous keywords before assigning end entryObject.variables[keywordText] = keyword -- Extra keyword for the first and last entry if i == 1 then entryObject.variables[keywordText.."_Start"] = keyword elseif i == lastIndex then entryObject.variables[keywordText .. "_End"] = keyword end end end end
und hier die funktion, die alle keywords loescht bevor eines gesetzt wird, manuell ergaenzt, damit keine leichen entstehen. Wird aufgerufen wenn clearExisting == true ist.
function ClearKeywords(entryObject, RouteIdentifikation) -- Loop through all possible keywords in RouteIdentifikation and clear them for _, eventData in pairs(RouteIdentifikation) do local oldKeyword = eventData[1] -- Extract stored keyword entryObject.variables[oldKeyword] = nil -- Clear the keyword if it exists entryObject.variables[oldKeyword.."_Start"] = nil entryObject.variables[oldKeyword.."_End"] = nil end entryObject.variables["Rola"] = nil entryObject.variables["Start"] = nil end
Ich dachte halt dass ich das einfacher haben kann, insbesondere fuer objektvariablen, die ich noch nicht erschlagen habe.
Nochmals vielen dank fuer eure muehe. Manchmal kann einem Lua schon auf den nerv gehen, wenn man eine "richtige" Entwicklungsumgebung gewohnt ist.
Gruss
Gmd
-
Hallo,
Wie kann ich auf einfache weise ALLE objekt schlagworte/variablen loeschen
$("").variables[""] = nil
$("").variables[""] = keyword
oder aehnlich ??
gruss
Gmd
-
Hallo,
ich denke ich kann das selbst beantworten, aber ich frage trotzdem, da ich ja so oft dinge uebersehe.
Ich moechte per Lua einen neuen ereigniseintrag innerhalb eines moduls anlegen, also z.B. Gleiskontakt mit schlagwort xy wird ausgeloest.
Ich kann ja variablen beliebig anlegen. Ich moechte ereignisse verteilen auf mehrere entry points, moechte die aber nicht manuell einrichten muessen.
Fuer generische scripts ist das kontraproduktiv.
Ich nehme mal an das geht nicht, aber wie gesagt ich frage trotzdem mal. Das waere was fuer den Wunschzettel.
Gruss
Gmd
-
3 hours ago, Neo said:
aber wenn ich mir ein neues Feature überlege, dann muss das so allgemeingültig sein wie möglich, keine Sonderlösung.
100% .. kein argument dagegen.. Ich habe nichts gegen einen snapshot der gesamten anlage.
2 hours ago, EASY said:Hallo gmd,
Bedenke bitte, daß es im MBS auch noch den Schienenverkehr gibt und da spielen für den Anfangszustand die Stellungen von z.B. Weichen und Signalen eine bedeutende Rolle (wenn diese im Test in ihrer Stellung verändert werden, sollten sie schon zurückgesetzt werden...)
In meinem beispiel hatte ich schienenverkehr angesprochen und da gilt fuer mich das gleiche. In einer "Einfahrtsituation mit Auftrag", wird ALLES auf einen definierten zustand gesetzt, IMMER. Ich versuche auch soweit wie moeglich variablen zu vermeiden, die nicht automatisch zurueckgesetzt werden koennen, aber das geht nicht immer.
Depots koennen hier eine besondere rolle spielen, das ist wohl ein gutes gegenbeispiel. OK, versteht mich nicht falsch, ich diskutiere hier nicht um recht zu behalten, weit entfernt davon, aber es ist manchmal einfach gut ideen austauschen.Viele demos haben das problem dass man sie nicht unterbrechen kann, sie muessen zu ende laufen etc. Man kann nur die anlage neu starten und wehen man hat sie gespeichert. Es ware halt schon zu einer demoanlage immer einen "Ursprungszustand" zu haben, der immer erhalten bleibt bis er neu gesetzt wird.
Und da gebe ich Neo absolut recht, das macht nur sinn mit allen zustaenden. Aber auch das waere fuer meine zwecke phantastisch und wuerde viel zeit sparen.Just an idea.
Gruss
Gmd -
8 hours ago, EASY said:
Hallo,
... in Deiner Antwort liegt liegt ein wichtiger Aspekt. Ich nehme an, daß Neo mit "Zuständen" wohl mehr auf den Zustand von z.B. Weichen, Signalen... angesprochen hat und das läßt sich nicht "mit einem einfachen loeschen aller temporarer variablen regeln" und da beginnt die Schwierigkeit für Neo, Deinen "Spezialfall" zu berücksichtigen bei dem dies (anscheinend) keine Rolle spielt.
Irgendetwas verstehe ich hier nicht, oder sehe ich nicht. Auch weichen und signale spielen nicht wirklich eine rolle wenn scripte robust programmiert sind. Lediglich einige variablen koennten da relevant werden, wenn ein test abgebrochen wird oder wegen fehlern nicht zu ende laeuft.
Beispiel Variable: Wenn ich zustaende in variablen in fahrzeugen speichere, dann so dass am ende eines zyklus (block etc. ) immer ein zustand verbleibt, der bei einem erneuten ausloesen eines kontaktes zurueckgesetzt wird, da er nur an einem "zielkontakt" existieren kann.
Beispiel Signale und Weichen: Am beginn eines scenarios (folge von fahrstrassen etc.) ist es in meinen scripten egal wie weichen und signale, oder auch animationen gesetzt sind. I sorge immer dafuer, dass alle benoetigten elemente aktiv geschaltet werden. Bei mir betritt ein fahrzeug ein gebiet mit einem "auftrag" und einem "ziel". Der auftrag haengt an einem keyword und nicht an einem bestimmten fahrzeug. Der auftrag legt fest ob zum beispiel ein bahnhofshalt erfolgt oder nicht. Wenn ein solches fahrzeug einen "eingangskontakt" ausloest, und die freigabe bekommt, (wo auch immer), dann werden alle element bis zum ausgang "reserviert" einschliesslich zustand, und aktiviert je nach bedingungen am jeweiligen abschnitt. Am ende des letzten abschnitts wird der auftrag geleoscht. Ich kann ein fahrzeug mit auftrag and den eingangspunkt zuruecksetzen ohne dass signale oder weichen gestetzt werden muessen, das geschieht automatisch. Natuerlich werde ich beim testen auftrage nicht immer loeschen vor dem zuruecksetzen.
Fuer mich ist das kein "Spezialfall", aber es ist wohl die art wie ich programmiere, dass das so ist. Wenn ich auch noch weichen und signale zuruecksetzen muesste um ein scenario immer wieder zu testen, wuerde ich verrueckt werden, bzw. dann mache ich was gruendlich falsch und meine steuerung ist nicht sehr robust.Gruss
Gmd
-
Goetz,
es kommt wirklich darauf an was zu testen ist. Ich halte versionen der gleichen Anlage fuer das testen von unterschiedlichen teilen und fuehre dann die scripte zusammen. Das problem ist wenn man einen teilaspekt tested, z.b. das einfahren von 12 lkw mit anhaenger ueber verschiedene spuren mit einer reihe von konfliktloesungen. Der test is relativ kurz, aber das ruecksetzen von 12 lkw mit anhaenger ist es nicht. Das laden der anlage dauert noch viel laenger also ist das speichern eines anfangszustandes hier auch nicht hilfreich. Ich habe mir in meinem programm eine loesung gebastelt, allerdings dachte ich dass auch andere in aehnlichen situation ein solches feature moegen wuerden. Ich habe mich ja auch vorsichtig ausgedrueckt und das nicht wirklich als featurewunsch definiert, bin aber einfach mal neugierig was andere dazu zu sagen haben oder ob nur ich dieses problem habe oder sehe.
Gruss
Gmd
MBS Companion V2
in Erweiterungen (Plugins)
Geschrieben
Hallo,
.
hier mal wieder ein update. Anbei eine erste version der demo fuer das "Vehicle Origin" modul.
Es passiert noch nicht viel, aber die struktur der scripte ist jetzt gut erkennbar und noch ueberschaubar.
Die einzige funktionalitaet, die derzeit implementiert ist, ist das setzen von release optionen fuer die fahrzeuge vom depot ueber schalter.
Der code ist generic und wird fuer alle VO module verwendet, egal wie viele. Die steuerung erfolgt ueber namen in den definitionstabellen.
In der demo vergebe ich die namen manuell, und auch die tabellen sind manuell erstellt. Spaeter wird mein programm solche tabellen generieren
und die objekte(hauptsaechlich kontakte) entsprechend automatisch benennen.
Ich verwende Ereignismodule zur strukturierung der scripte. Fuer das VO modul gibt es ein Ereignismodul VO, in dem nur die generischen scripte liegen.
Hier werden keine variablen abgelegt, jedenfalls keine die spezielle instanz daten enthalten.
Die anwendungen des VO moduls sind dann VO_1, VO_2 usw benannt, koennen aber auch anders heissen, ist nur eine tabelleneintrag.
Nachfolgend werde ich jetzt die tatsechlichen funktionen einrichten mit 3 instanzen des VO Moduls. Und dann das naechste modul "Segmentierte Strecke"
mit einbinden. Ich habe das dokumentationsdokument weiter ergaenzt. Ich bin mal gespannt wieviel tausend zeilen script das studio verkrafted.
Bisher ist noch keine kollisionskontrolle vorgesehen, wird interessant werden, wenn aus allen loechern die fahrzeuge ausgespuckt werden und wieder verschwinden
Hier ist die content ID 5CE8FC5C-BD36-48C3-9B23-566BF925A002 , ist als entwurf geladen.
Gruss
Gmd