[rdc] stümpert Szenarien zusammen

Grüße!

Da ich ja irgendwann auch mal meinen "Neueinsteiger" Status loswerden möchte, fange ich nun auch Beiträge hier im Forum zu schreiben. Das wird für uns alle nicht einfach, daher vorab schon mal ein dickes "sorry"!

Und getreu dem Titel bin ich gerade dabei eine Art von Szenario zusammen zu pfuschen, welche mir eigentlich gar nicht liegt. Es wird.... tada... Ein Szenario mit einem Personenzug.

Es ist aber nicht irgendein Zug, sondern das Ergebnis eines Projektes, in das einige Leute sehr viel Zeit investiert haben und ich mich schon lange auf diesen Zug freue.

Das reine "Fahren" und der KI Verkehr sind zwar fertig, aber es fehlen noch einige Dinge. Die Ansagen muss ich noch aufnehmen und schneiden. Die Anzeiger an Bahnsteigen müssen noch erstellt und platziert werden, das Skript muss noch geschrieben und die Trigger gesetzt werden.

Wenn es gut läuft, werde ich damit aber in den nächsten Tagen fertig.

Und dann geht es im RE 3 - Umleiter nach Dresden.

Das ist dann auch ein Stück "Vergangenheitsbewältigung", da ich in 2016 oder 2017 tatsächlich mal in Chemnitz in einen RE 3 nach Dresden gestiegen bin, der dann über Riesa nach Dresden umgeleitet wurde, da in Tharandt die Oberleitung im Dreck lag.

An dieser Stelle schon mal ein dickes Lob an Dijon-Senf und alle anderen Beteiligten, denen wir den Umbau von der BR 440 auf die 1440 zu verdanken haben (werden).

Ich erstelle ja auch weiter Szenarien. Aber manchmal stoße ich dabei auch auf Herausforderungen, mit denen ich nicht gerechnet habe.

Beispiel: Für eines der nächsten Szenarien habe ich mir einen hübschen Güterzug erstellt. Bedingung für mich war, dass alle Wagen mit 120 km/h lauffähig sein sollten.

Also habe ich einen Zugverband erstellt

und natürlich die Fahrzeugdaten erfasst, damit ich die BRH berechnen kann

Mit den Grunddaten war ich auch zufrieden. Also ging es auf die Strecke um das Fahr- und Bremsverhalten zu testen.

Wie mache ich das? Ich beschleunige auf Fahrplangeschwindigkeit und an einem Vorsignal suche ich die Schnellbremsstellung auf. Im besten Fall kommt der Zug dann weit vor dem Hauptsignal zum Stehen.

Ende vom Lied: Der Zug bremst wie ne feuchte Brotdose auf Fliesen. Halt erst weit hinter dem HS.

Also kann ich diesen Zugverband so nicht benutzen. Mein Ziel, einen abwechslungsreichen Zug zu haben, der trotzdem bis 120 fahren darf, habe ich nicht aufgegeben. Nur der Weg dahin ist etwas aufwendiger. Ich brauche also mehr Wagen, von denen ich weiß, dass diese vernünftig fahren und bremsen. Da wird es dann aber mit den verfügbaren Repaints etwas dünn. Ich möchte aber einen "bunten" Güterzug haben. Also hilft am Ende nur: selber machen.

Problem dabei: Meine quasi nicht vorhandenen Fähigkeiten im Umgang mit Grafikprogrammen.

Darum dauert es dann auch entsprechend lange, eh ich bis an diesem Punkt angekommen bin.

Ganz fertig bin ich mit den Wagen auch noch nicht. Und das ist ja auch erst eine Variante. Am Ende muss der Spaß noch dokumentiert (ReadMe) und nicht zu vergessen, die Freigabe bei vR angefragt werden.

Bei meinen letzten Objekten war das etwas einfacher. Die habe ich in Blender konstruiert und mit eigenen Fotos texturiert.

Und bei all dem Aufwand ist der Zug im Szenario noch keinen Meter gefahren

Zum Glück habe ich nicht immer solche blöden Ideen und komme meistens mit dem verfügbaren Rollmaterial und den Repaints aus. Wenn sich aber so eine Idee erstmal in meinem Kopf festgesetzt hat, dauert es dann eben länger, bis wieder ein Szenario fertig wird.

Hallo ChemistryHC ,

ich denke, ich kann durchaus mit beiden Loks umgehen

Aber nein, getestet habe ich mir einer 185 von vR. Auch die Lok kenne ich im TS gut. Die Repaints bastle ich trotzdem weiter. Wenn alles klappt, haben wir alle wieder ein bißchen mehr Abwechslung im TS. Und gerade die Vielfalt ist das, was den TS für mich so besonders macht. Und eben die Möglichkeiten unheimlich viel durch das Auslesen und Setzen von Controllern der Loks via LUA-Skript beeinflussen zu können.

VG Ronald

ChemistryHC hab's auch nicht als "böse" aufgefasst

So, dieser Beitrag hat zwar nur bedingt etwas mit Szenariobau zu tun. Da ich den ganzen Spaß aber nur mache, da ich ein Szenario mit bestimmten Wagen erstellen möchte, sind wir doch wieder beim Szenariobau

Ab und an komme ich ja auf die Idee ein Szenario mit bestimmten Wagen zu bauen. Also gehe ich auf die Suche nach den passenden Repaints. Nur leider findet man nicht immer das was man sucht. Da hilft dann nur selber ein Repaint zu erstellen.

Nun hab ich von Repaints und dem Umgang mit Grafikwerkzeugen keine Ahnung. Das hält mich aber nicht davon ab es trotzdem zu versuchen.

Gesagt, getan oder besser, immer noch dabei...

Zuerst habe ich die BIN-Dateien an meine Bedürfnisse angepasst und mich dann den Texturen gewidmet. Ziel ist es, die Wagen frisch aus der Revision darzustellen.

Von Weitem sah das auch gar nicht so schlecht aus. Da ich aber einige Details direkt in die Textur gepackt habe, war das Ergebnis beim genaueren Hinsehen dann nicht mehr so toll.

Man kann deutlich die Unschärfen an den Symbolen und Schriftzeichen erkennen. Also mache ich nun doch das, was ich eigentlich vermeiden wollte. Ich arbeite mit Child-Objekten und füge diese den Wagen hinzu.

Zuerst habe ich dafür eine grobe Form des Wagens erstellt...

Dazu eine passende Textur mit den Anschriften und Symbolen, die ich gern zusätzlich an die Wagen anbringen möchte.

Und dann heißt es eben Faces am Objekt anzurichten und diese mit den Symbolen und Schriften zu befüllen

Und mit dem Ergebnis bin ich deutlich zufriedener als zuvor

Was jetzt noch fehlt? Ein paar weiteren Stunden basteln und natürlich die Freigabe von vR. Wenn es gut läuft, gibt es dann die Sggmrss-Wagen von vR in zwei neuen Farbvarianten.

Eh das nächste Szenario kommt, wird es also noch ein bißchen dauern. Mir ist aber schon die ein oder andere "Gemeinheit" eingefallen um das Fahren etwas interessanter zu machen.

Guten Tag,

in diesem Beitrag soll es um das Thema Scripting gehen. Die Grundlagen dazu wurden schon an verschiedenen anderen Stellen hier im Forum beschrieben. Daher möchte ich mich auf die Dinge beschränken, die mir in den Jahren so aufgefallen sind.

Bevor wir beginnen, müssen wir uns aber ein paar Dinge in Erinnerung rufen.

1. Bereiche des Skriptes

Auch wenn das gesamte Skript "nur" aus Funktionen (functions) besteht, lässt sich das Skript grob in zwei Bereiche einteilen. Einen Bereich der die im Szenario ausgelösten Ereignisse (events) verarbeitet und einen Bereich, der Bedingungen testen kann (testconditions).

2. Gültigkeit von Variablen

Variablen sind immer jeweils in dem Bereich gültig, in dem sie deklariert werden. Wird eine Variable also innerhalb eines Events deklariert, ist diese nur innerhalb des Events gültig. Auf den Wert dieser Variablen kann also nicht in anderen Funktionen zugegriffen werden.

GVAR1 = "ich gelte im gesamten Skript";
-- diese Variable gilt immer und überall
OnEvent = function(event)
    if event == "Test1" then
        VAR2 = "ich gelte nur im Event Test1";
        -- diese Variable gilt nur in diesem Event 
    end
end

function TestCondition(condition)
    if condition == "CheckHLL" then
        currentBPP = SysCall("PlayerEngine:GetControlValue", "HLL", 0);
        -- die Variable 'currentBPP' gilt nur in dieser TestCondition
        if currentBPP >= 5.3 then
            SysCall("ScenarioManager:TriggerDeferredEvent", "PressureReached",0);
        end
    end
end

Was an dieser Stelle auch noch erwähnenswert ist, ist der Umstand, dass die innerhalb von Funktionen deklarierten Variablen nach dem Durchlauf der jeweiligen Funktion "vergessen" werden. Sie sind also nur zur Laufzeit innerhalb der Funktion vorhanden und können auch nur dann Werte aufnahmen bzw. Werte ausgeben.

3. Laufzeit

Ganz wichtiges Thema. Hier muss man wissen, dass der Bereich der Events und der TestConditions bei jedem Frame komplett durchlaufen werden. Ihr habt 30 FPS im Spiel? Super, dann wird das Skript 30 Mal pro Sekunde durchlaufen. Bei 50 FPS wäre das dann eben 50 Mal.

Warum das wichtig ist? Einmal sollte man daran denken, TestConditions auch wieder zu beenden. Es kann sonst nämlich zu unerwünschten Ergebnissen kommen. Zum Anderen sollte man die Anzahl der Durchläufe nicht für die Berechnung von Zeiten benutzen. Warum das weniger klug ist, soll folgendes Beispiel zeigen:

-- Start- und Randbedingungen
-- - es wird das Event 'Start' ausgelöst
-- - 10 Sekunden danach soll ein zweites Event 'Weiter' ausgelöst werden
-- - der TS läuft mit 30 FPS

if event == "Start" then
    -- Überlegung: 30 Durchläufe pro Sekunde -> 300 Durchläufe in Sekunden
    for i = 0, 300, 1 
        do
        if i == 300 then
            event = "Weiter";
        end
    end
end
if event == "Weiter" then
    -- do some nice things
end    

Das sollte so zwar funktionieren, aber eben nur bei den Start- und Randbedingungen. Bei 60 FPS ist die Bedingung schon nach 5 Sekunden erfüllt.

Die Anforderung so zu lösen ergibt also keinen Sinn, da es dafür einen eigenen Aufruf für den TS gibt.

-- Start- und Randbedingungen
-- - es wird das Event 'Start' ausgelöst
-- - 10 Sekunden danach soll ein zweites Event 'Weiter' ausgelöst werden
-- - der TS läuft mit 30 FPS

if event == "Start" then
    -- Aufruf "TriggerDeferendEvent"
    SysCall("ScenarioManager:TriggerDeferendEvent", "Weiter", 10);
end
if event == "Weiter" then
    -- do some nice things
end

Das ist weniger Aufwand und führt sicher zum gewünschten Ergebnis.

Soweit, so gut. Wir wollen aber spannende Dinge mit dem Skript tun. Das Beispiel mit den Ansagen werde ich daher hier nicht wiederholen.

Achso, kurzer Einschub an dieser Stelle: Das was ich hier niederschreibe ist sicherlich nicht der einzige Weg um an Ziel zu kommen. Es gibt mit Sicherheit auch einfacherer oder elegantere Wege. Aber so wie ich das hier wiedergebe funktioniert es für mich.

Die große Frage, die sich stellt, ist dann natürlich: Woher soll ich denn wissen, wie die Dinger heißen, die ich per Skript steuern möchte?

Und diese Frage ist mehr als berechtigt. Die "Dinger" heißen Controller und haben selbst eigene Bezeichnungen. Ein paar wenige Standard-Controller heißen (fast) immer gleich. Die Anzahl und die Bezeichnung der Controller unterscheidet sich aber von Entwickler zu Entwickler. Selbst bei Fahrzeuges eines Entwicklers kann es unterschiedliche Bezeichnungen geben.

Ich habe bisher drei Möglichkeiten gefunden, um an die gewünschten Controllerbezeichnungen zu kommen.

- Logmate

Ja, das soll irgendwie gehen. Aber ich bin zu blöd dafür

- Fahrzeugdatei

Man kann sich die bin-Datei mit der serz.exe in eine mehr oder weniger lesbare XML-Datei umwandeln. In dieser sind die Bezeichnungen der Controller enthalten.

Das Image zeigt beispielhaft den Controller "HLL" einer BR185 von vR. Aber auch das ist mir zu mühsam.

- TS-MFD

Es gibt auf https://www.ts-mfd.de/ das wundervolle gleichnamige Programm. Dieses wurde wohl primär dafür entwickelt einen EBuLa abbilden zu können aber ich nutze die darin ebenfalls enthaltene Funktion zur Anzeige der Controller.

Vorteil des Programms: Ich sehe alle verfügbaren Controller und auch die Werte in "Echtzeit" während das Szenario läuft.

Ab hier habe ich also alle Informationen zusammen, um damit ein Skript basteln zu können, dass das Verhalten meines Fahrzeuges beeinflussen oder eben bestimmte Werte abfragen kann. Was man alles machen kann überlasse ich aber eurer Fantasie.

Damit diejenigen, die den Text bis hier hin gelesen haben auch etwas davon haben, hier ein erstes kleines Beispiel.

Ich fahre ja selbst unheimlich gern mit EBuLa-Fahrplänen. Darum erstelle ich bei meinen Szenarien auch immer Fahrpläne, sofern die Fahrzeuge diese auch anzeigen können. Außerdem fahre ich gern mit Fahrzeugen von virtual Railroads. Einziger Nachteil, die vR-Loks schalten nicht automatisch die einzelnen Seiten des Fahrplans durch. Zu erklären, warum das so ist, würde hier zu weit führen. Aber es ist eben so.

Man kann aber die Seiten am EBuLa im Fahrzeug selbst während des Szenarios durchblättern. Also muss es dafür einen Controller geben, der auf die Interaktion im Szenario reagiert. Die Controller heißt "EbulaPageUp" und muss von unserem Skript angesprochen werden.

Bevor wir das aber tun, sollten wir uns die Bedienhandlung als solche vor Augen führen. Also was passiert beim manuellen Umschalten des Fahrplans wirklich?

Man "drückt" auf den entsprechenden Knopf und lässt ihn auch wieder los. Die eine Aktion, also das Umschalten des Fahrplans, besteht aus zwei einzelnen Aktionen. Und diese beiden Aktionen müssen dann auch im Skript umgesetzt werden. Die große Erklärung, wie Schalter und Taster funktionieren und was es da für Unterschiede gibt, möchte ich mir und euch an dieser Stelle ersparen. Nur kurz so viel: Es gibt Schaltelemente, die auf eine ansteigende Flanke des Signals reagieren - also dem Wechsel von 0 auf 1 - und es gibt Elemente die auf einen abfallenden Flankenwechsel - also von 1 auf 0 - reagieren. Wer mehr dazu wissen möchte, möge die Suchmaschine seines Vertrauens nach Flipflops, NAND-Gatter und dergleichen befragen.

Für unsere konkrete Anforderung ist wichtig zu wissen, dass das Engine-Script auf einen negativen Flankenwechsel reagiert.

Der Controller hat im Grundzustand den Wert 0 und beim bestätigen des Buttons den Wert 1. Wird der Button losgelassen, nimmt der Controller wieder den Wert 0 an.

Im Skript kann es dann so aussehen:

-- -----------------------------------------------------------------------------------
-- EBuLa umschalten 
-- dazu Trigger von Scarlet im Szenario verbauen
if event == "EBULANEXTPAGE" then
    -- Controller auf den Wert 1 setzen
    SysCall ( "PlayerEngine:SetControlTargetValue", "EbulaPageUp" , 0 , 1);
    -- 'kurz' abwarten, und dann den Knopf wieder loslassen
    SysCall ( "ScenarioManager:TriggerDeferredEvent" , "EBuLaNextPage_null" , 0.5 );
    return TRUE;
end
if event == "EBuLaNextPage_null" then
    -- loslassen --> Controller auf 0 setzen
    SysCall ( "PlayerEngine:SetControlTargetValue", "EbulaPageUp" , 0 , 0);
    return TRUE;
end
-- -----------------------------------------------------------------------------------

Das ganze zur einfacheren Lesbarkeit noch als Image mit Syntax-Highlighting

Für das einfache Drücken von Knöpfen kommen wir auch ganz ohne Testconditions aus. Wichtig ist aus meiner Sicht wirklich nur, dass man alle Interaktionen genau betrachtet und diese Aktionen in ihre einzelnen Schritte zerlegt. Diese einzelnen Schritte kann man dann je nach Fahrzeug mehr oder weiniger einfach in einem Skript abbilden.

Nachtrag: Zum Auslösen des Events muss dieses natürlich im Szenario getriggert werden. Ich nutze dazu meist die Scripttrigger von Scarlet

Trigger platzieren, Bezeichnung des Events im Skript eintragen bzw per Copy&Paste einfügen und fertig.

Wenn ich noch weitere Themen niederschreiben soll, dann lasst es mich wissen. Aber als Denkanstoß kann dieser Beitrag sicher schon dienen.

Danke für das Lesen des Beitrages.

VG Ronald

Guten Tag,

für den Abschluss meiner aktuellen Szenario-Reihe (Kisten an die Küste) hab ich mir mal eine neue Herausforderung gesucht. Nicht beim Szenario selbst, aber bei der Umgebung.

Auch wenn ich nicht mehr ganz so jung bin, so bin ich trotzdem noch ein Spielkind. Ich probiere gern Dinge aus. Und so habe ich meine TS-Installation mal in eine Nicht-Windows-Umgebung verfrachtet.

Ja, ich bin tatsächlich unter Linux unterwegs.

Es funktioniert auch alles und man kann sich ganz normal im TS bewegen.

Ich hab zwar alles in Lutris importiert, aber der TS läuft über die Proton-Engine von Steam selbst.

Jetzt wird sich sicher der ein oder andere fragen, was das soll und warum ich das mache. Diese Frage lässt sich recht einfach beantworten:

1. weil

2. ich's

3. kann

Aber Spaß bei Seite. Auf meinem Notebook läuft schon seit geraumer Zeit ein Linux. Auf dem PC bisher nur Windows. Eben wegen der Spiele. Aber ich möchte eben mal ausprobieren und schauen, ob ich meinen "Workflow" unter Linux auch so leben kann wie unter Windows.

Grundsätzlich komme ich mit allen drei Betriebssystemarten (Kommerz / Hipster / Hippie (ihr wisst, welches was ist)) zurecht. Auch die Software, die ich außerhalb des TS benötige, gibt es als native Anwendung unter Linux oder eben eine passende Alternative.

Folgende Tools benötige ich außerhalb des TS für ein "normales" Szenario

Es ist also alles da, was ich brauche.

So viel dazu. Mich würde ja interessieren, ob noch weitere Linux-Nutzer hier vertreten sind und welche Erfahrungen gemacht wurden.

Ich bin jetzt wieder im TS. Die Szenarien bauen sich ja nicht von alleine

VG Ronald

Zitat von faber2311

Da hatte ich auch schon dran gedacht, aber sag mal, wie sieht es denn mit der Performance des TS unter Linux aus?.

Ich habe ein ähnliches Setup wie du. Rayzen 5600 (ohne X) und eine 4070. Bisher sind mir keine gravierenden Unterschiede aufgefallen. Eine "richtige" Messung habe ich aber auch noch nicht gemacht. Ich kann nur sagen, das der TS, TSW4 und ZuSi ohne Probleme laufen.

Hallo train:bird

Endeavour ist doch eine Arch-Distro, oder? Nicht schlecht. Linux im Heimanwenderbereich begleitet mich seit Anfang der 2000er Jahre. Aber meist nie als Daily-Driver, sondern immer nur nebenher. Der große Vorteil und zugleich der große Nachteil von Linux ist ja die unheimliche Vielfalt. So habe ich immer wieder unterschiedliche Distributionen ausprobiert, bin aber nie lange bei einer geblieben, da es ja immer neue Dinge zu entdecken gab.

Auf meinem Notebook läuft seit Anfang des Jahres Mint mit dem Cinamon Desktop und erfüllt im Moment all meine Ansprüche. Da ich meinen PC ausschließlich zum Spielen nutze, sah ich da bisher keine Notwendigkeit für einen Wechsel des Betriebssystems.

Auf meinem PC läuft derzeit alles noch parallel. Also alles was unter Windows läuft liegt auf eigenen Festplatten (also nvme und SSD) und was unter Linux läuft ebenso. Das ist zwar derzeit eine ziemlich "Platzverschwendung" aber ich möchte die Systeme getrennt halten. Was Gaming und Linux angeht bin ich ja noch in der Findungsphase. Nobara hatte ich ausprobiert, bin damit aber fulminant gescheitert. Derzeit werkelt dort also auch ein Mint.

So lieber train:bird , vielen Dank für deinen ausführlichen Beschreibungen. Ich freue mich, dass es noch weitere Linux-Nutzer hier im Forum gibt. Wobei jeder hier im Forum auf die eine oder andere Art und Weise ein Linux-Nutzer ist. Nur weiß das in der Regel niemand.

Eine Anmerkung vielleicht noch: Einen Wechsel des Betriebssystems muss man wollen. Egal von und auf welche Plattform man kommt und wechselt. Alles ist ein bißchen gleich und doch wieder anders. Auch würde ich nicht pauschal behaupten, dass das eine System besser oder schlechter ist als das andere. Es ist anders.

Heute mal wieder etwas aus der Rubrik "Was tut man nicht alles für ein Szenario"

Wie ihr evtl. mitbekommen habt, arbeiten FortyCS und ich an einem Repaint-Paket für die Sdggmrss-Wagen der WaggonWerkstatt. Einen kurzen Zwischenstand unserer Bemühungen könnt ihr euch hier ansehen:

Und wozu das alles? Nun, bei diesem Projekt fallen eben auch die Wagen ab, die ich für 1-n Szenarien benötige.

Ein paar Tage werden wir sicher noch benötigen, bevor wir die erste Version des veröffentlichen. Aber in den letzten Wochen haben wir schon eine ganze Menge geschafft.

Grüße!

Heute habe ich ein kleines Update zum Stand des Repaint-Paketes für euch.

Ja, wir arbeiten noch daran. Jetzt kann man natürlich fragen, warum das so lange dauert. Daher hier einige Erläuterungen.

Beladung vs. Quickdrive

In der ersten Version des Repaint wurde FortyCS darauf hingewiesen, dass das Paket nicht quickdrivefähig sei. Diese Kritik möchten wir vermeiden. Das bedingt aber, dass die Assets für die Ladung ebenfalls direkt im Repaint enthalten sein müssen. Von RailDesign & Friends haben wir die Erlaubnis, deren Trailer in unser Paket zu integrieren. Das ist natürlich super und wir sind unheimnlich dankbar dafür. Für alle weiteren Varianten müssen wir uns selbst kümmern. Wir haben zwar bei Anderen auch angefragt aber eben keine oder eine negative Antwort erhalten. Was übrigens auch nicht schlimm ist. Es ist schließlich deren Arbeit.

verfügbare Zeit

FortyCS und ich sind berufstätig. Und neben der Zeit, die für die Arbeit drauf geht, gibt es ja auch noch andere familiere Verpflichtungen die man so hat. Also ist Zeit der limitierende Faktor. Über Weihnachten und Neujahr ging alles noch gut voran, da zumindest ich Urlaub hatte und wirklich viel Zeit in das Projekt stecken konnte. Und neben dem TS habe ich auch noch andere Hobbys (Volleyball, Klemmbausteine, ...). Daher kann ich hier nur um Geduld bitten. Mindestens ein Ladungsobjekt wollen wir noch realisieren, bevor die erste Version des Paketes veröffentlicht wird.

Wo stehen wir jetzt?

Fahrzeuge bzw. Wageneinheiten mit Trailern

Dank RDF sind diese (fast) fertig. Hier haben wir neben den "normalen" kranbaren Varianten auch einige nicht kranbare Auflieger die dann zusätzlich in einem Transportgestell (R2L) stehen. Hier ist uns nur bei einigen Trailern ein Unstimmigkeit aufgefallen. Da wird FortyCS die Texturen nochmal überarbeiten.

Fahrzeuge mit Wechselbrücken

Auch hier haben wir schon ein paar Varianten fertig. Ich hatte zwar für ein früheres Projekt einen Wechselbehälter gebaut, welchen wir aber so nicht verwenden konnten. Also hab ich einen neuen gebaut, den wir nun universeller verwenden können.

Allein durch diese Varianten kommen wir bisher auf gut 84 Fahrzeuge (also 42 Wageneinheiten). Und das pro Einsteller (HUPAC, KOMBI, WASCO) und jeweils zwei Varianten der Wagen.

Für einen kleinen Einblick in den Entstehungsprozess und den aktuellen Stand habe ich ein weiteres Vorschauvideo erstellt. Wer mag, kann sich das gern ansehen.

Viele Grüße und 42!

Ronald