Beiträge von ma7t3

Willkommen in der OMSI-WebDisk!
Als Gast kannst du nur Inhalte in deiner ausgewählten Sprache sehen. Registrierte Nutzer können die Sichtbarkeit anderer Sprachen in ihrem Kontrollzentrum aktivieren, weitere Infos hier.
Alle Themen sind in den Foren mit einer Sprachflagge gekennzeichnet: = Englisch [EN], = Deutsch [DE], = Französisch [FR]. Wenn du die angegebene Sprache nicht beherrschst, schreibe auf Englisch!

    Einen guten Tag zusammen,


    beim Werkeln und Scripten an meinem Nuntius-Drucker bin ich auf die Idee gekommen, dort auch eine Anzeige zu implementieren, die mir auf dem Bildschirm anzeigt, in wie vielen Metern die nächste Haltestelle kommt.

    Man kennt das ja heutzutage vom ein oder anderen, modernen Drucker, wenn die mit GPS ausgestattet sind, dass sie anzeigen, wie weit die nächste Haltestelle noch entfernt ist.

    Leider hat OMSI kein direktes Makro oder Variable, mit der es möglich ist, die Entfernung zur nächsten oder zwischen Haltestellen direkt abzufragen und anzuzeigen.

    Dennoch dürfte es mit einigen Tricks und etwas Gerechne möglich sein, diese zumindest angenähert zu bestimmen.

    Dieses Konzept möchte ich euch hier gerne kurz vorstellen. Ganz unten findet ihr dafür auch ein fertiges Script, was ihr gerne in euren Bussen und für eure Projekte verwenden dürft. Ich erhebe kein Copyright darauf. Feel free to do what you want. :)



    Die Theorie

    Für alle, die nicht einfach nur das fertige Script (ihr findet es unten) kopieren wollen, sondern auch tatsächlich verstehen wollen, warum und wie es funktioniert, hier die Erklärung, wie ich es mir überlegt habe und was der "Plot" ist:

    Es ist zuerst wichtig, die folgenden Informationen bzw. Konzepte notwendig zu kennen/verstehen.

    Wichtig ist noch, dass wir immer nur von einer Haltestelle zur nächsten denken. D.h. wir gehen immer davon aus, wir befinden uns gerade irgendwo zwischen zwei Haltestellen einer Route und wollen die Entfernung zur nächsten bestimmen.

    1. Mit den Makros (M.V.GetTTBusstopDep) und (M.V.GetTTBusstopArr) lassen sich die planmäßige Abfahrtszeit der letzten Haltestelle bzw. Ankunft an der nächsten abfragen.
    2. Über (M.V.GetTTDelay) lassen sich aus den planmäßigen Zeiten die tatsächlichen (bzw. prognostizierten für die nächste Haltestelle) errechnen.
    3. Vergleicht man diese nun mit der aktuellen Ingame-Uhrzeit ((L.S.Time)), kann man daraus einen relativen Wert bestimmen, wieviel Zeit bereits seit der letzten Haltestelle vergangen ist, bzw. wo auf der "Zeitachse" wir uns gerade zwischen Zeit Haltestellen befinden. Dazu ein Beispiel:

    Das bedeutet jetzt also, dass ein Viertel der Zeit zwischen beiden Haltestellen verstrichen ist. Wenn wir nun von einer konstanten Geschwindigkeit ausgehen, bedeutet das, dass auch ein Viertel der Strecke bereits zurückgelegt wurde und dementsprechend noch 3/4=0.75 fehlen.

    Wenn wir jetzt auch noch von einem konstanten Haltestellenabstand insgesamt ausgehen würden, könnten wir die übrige Entfernung bereits exakt berechnen. Gerade auf Überlandmaps, wo innerhalb von Ortschaften Haltestellen eng zusammenliegen können, zwischen Orten aber auch große Entfernungen haben, ist das jedoch etwas doof. Deshalb wollen wir das nun ändern. Dazu brauchen wir nur die Variablen kmcounter_km und kmcounter_m, welche zusammen den Kilometerstand repräsentieren.

    1. Beim Verlassen einer Haltestelle merken wir uns den aktuellen Kilometerstand in einer Variable.
    2. Nun können wir jederzeit den aktuellen Kilometerstand mit dem gespeicherten vergleichen und so die zurückgelegte Strecke seit der letzten Haltestelle ermitteln.
    3. Aus all diesen Daten lässt sich nun bereits eine Prognose erstellen. Wir haben nun unsere zurückgelegte Strecke auf z.B. 100m bestimmt.
    4. Wenn wir weiterhin von einer konstanten Fahrtgeschwindigkeit ausgehen, so ergibt sich:
    Code
    25% Zeit vergangen => 100m gefahren.
    100m / 25% = 400m => gesamte Entfernung zwischen den Haltestellen
    Bereits zurückgelegte Entfernung wieder subtrahieren:
    400m - 100m = 300m
                  ====

    Damit haben wir nun also die Entfernung zu nächsten Haltestelle auf 300m bestimmt.

    Wie bereits zum Anfang betont, ist das kein exakter Wert sondern nur eine Annäherung, da wir immer von einer konstanten Geschwindigkeit ausgehen müssen. Besser geht es leider nicht. Es ist und bleibt also immer eine "Prognose".

    Der Wert wird jedoch genauer, je weiter wir fortgeschritten sind. Nach 10% Strecke haben wir nur eine sehr kleine Stichprobe an bestehenden Daten und die 90% übrige Strecke werden aus dieser Stichprobe nur "hochgerechnet". Das ist natürlich nicht so genau, wie wenn schon 90% gefahren wurden und nur noch 10% errechnet werden müssen.

    Die Berechnung wird genauer, je dichter man die Zielhaltestelle erreicht.

    Damit das ganze aktuell bleibt, muss man natürlich diese ganze Berechnung regelmäßig (z.B. alle 10 Sekunden) neu durchführen.

    Wichtig ist, dass man nicht nur die Entfernungsberechnung ("2. Teil vom Beispiel") neu berechnet, sondern tatsächlich alles, da sich ja z.B. beim schnellen oder langsamen Fahren auch die Verspätung ändern kann, die man dann immer wieder neu einrechnen und daher auch die Haltestellenzeiten immer wieder neu berechnen sollte, um möglichst genaue Werte zu erhalten.



    ...und in OMSI

    Hier findet ihr nun meine Implementierung der Idee in OMSI. Es sind Kommentare vorhanden, die das meiste klären sollten. Baut euch den "Scriptschnippsel" gerne in eure Busse ein. :)


    Als erstes müsst ihr euch allerdings noch die folgenden Variblen in einer Varlist eintragen:

    Code: varlist.txt
    busstopDistance_timer
    busstopDistance_lastKmCounter_km
    busstopDistance_lastKmCounter_m
    busstopDistance_nextBusstopDistance
    busstopDistance_lastIndex

    Dies ist dann der Codeabschnitt für die Script-Datei.

    Den Bereich im Frame-Abschnitt solltet ihr euch am besten einfach in euren Bus- bzw. Drucker-Frame mit integrieren. Das Makro busstopDistance_recalculateDistance kann bzw. sollte also in jedem Frame ausgeführt werden.

    Das Makro busstopDistance_restartDistanceCalc muss immer dann ausgeführt werden, wenn die Abstandsmessung neu begonnen soll, d.h. wir z.B: eine Haltestelle erreicht haben und nun von dort den Abstand zur darauf folgenden bestimmen wollen. Darum kümmert sich der Frame-Abschnitt hier.

    Am Ende steht in der Variable busstopDistance_nextBusstopDistance immer die Entfernung zur nächsten Haltestelle in Metern bzw. "-1" falls der Wert nicht ermittelt werden kann. Diesen könnt ihr nun mit einem Textfeld verbinden oder z.B. auf eine Texttextur schreiben.

    Das war's soweit. Viel Freude damit.

    Wenn ihr weitere Fragen oder Anmerkungen habt, könnt ihr sie im Folgenden gerne posten. :thumbup:

    Wenn dein oben gepostetes Logfile vollständig ist (wovon ich mal ausgehe), dann stürzt OMSI bei dieser Aktion ab:

    Code
    293 14:11:35 -  -       Information: Try placing random bus: 

    D.h., OMSI versucht, einen KI-Bus auf der Map zu spawnen, kriegt es aber aus irgendeinem Grund nicht gebacken.

    Hast du mal dein AI-List kontrolliert? Ist da vielleicht irgendetwas komisch oder sind einige Busse, die du als KI verwendest, defekt, sodass OMSI diese nicht spawnen kann?

    Thomas U. Wir schicken jedes Jahr eine Rundmail automatisch an alle User los, dafür brauchst du nichts eingestellt zu haben.

    Es kann sein, dass die nur bei dir im Spam Ordner gelandet ist.

    Ich habe auch nie eine bekommen. Lag aber daran, dass ich (aus irgendeinem Grund) in den Einstellungen "Emails der Administration" deaktiviert hatte. Vielleicht ist das bei Thomas U. der gleiche Fall...

    Jetzt ist es aktiviert:

    Ich bin noch nie auf die Idee gekommen, OMSI von einer externen Festlatte aus zu starten.

    Da das für das OMSI-Dateisystem eigentlich keinen Unterschied macht, sollte es aber in der Theorie auch eigentlich egal sein.

    Was für eine externe Festplatte ist das denn? SSD oder HDD?

    Falls es sich um eine HDD handelt (und du möglicherweise sehr viel Content, also Busse und Maps) installiert hast, kann es sein, dass der Startvorgang einfach wesentlich länger dauert. HDDs sind per se langsamer und wenn deine externe Platte dann noch nur per USB 2.0 am PC hängt, kann es gut sein, das OMSI beim starten deutlich länger braucht, alles einzulesen als vorher.

    Falls du dieses Problem ausschließen kannst, gibt's noch weitere Gründe:

    • Hast du mal versucht, OMSI als Administrator zu starten?
    • Wenn nichts weiterhilft, kannst du auch versuchen, OMSI mit erweitertem Logging zu starten. (Verwende dazu den Startparameter -logall). Das erzeugt mehr Details im Logfile und gibt dann vielleicht mehr Informationen dazu, wo es hakt.

    Ich meinte damit nur, dass deine Karte, solange du sie nirgends hochgeladen/also veröffentlicht hast, ja (logischerweise) noch privat ist, da nur du sie besitzt.


    Wenn deine Karte fertig ist und die sie hier in der WebDisk hochladen und veröffentlichen möchtest, gehst du einfach auf die WebDisk-Startseite und klickst auf den "Hochladen"-Knopf rechts unten (bei mir ist die Oberfläche englisch):


    Auf dieser Seite kannst du dann ganz oben deine Map als Archiv-Datei hochladen und alle weiteren Daten, die wichtig sind, angeben

    (z.B. Name, Kateogrie, Versionsnummer, sowie natürlich Vorschaubild und eine Beschreibung).

    Scrolle einfach durch das Formular durch und fülle alles aus.


    Dann kannst du das ganze abschicken.

    Die Filebase-Prüfer checken dann, ob mit deiner Datei alles passt (dass die Ordnerstruktur stimmt, alles richtig angegeben ist und es keine Urheberrechtsverletzung gibt).

    Und dann wird es freigeschaltet und steht ab dem Zeitpunkt jedem öffentlich zum Download verfügbar. :)

    Den Haken setzt du in der Filebase, wenn du eine neue Datei hochlädst. Dort gibst du auch Name, Vorschaubild usw. alles an und kannst dort dann auch diesen Haken setzen.

    Deine Map kannst du da hochladen, wenn sie fertig ist. Wenn dann keine Copyright-Verstöße o.ä. vorliegen, wird sie auch von den Filebase-Prüfern freigeschaltet.

    Allerdings solltest du die Map erst hochladen/veröffentlichen, wenn sie wirklich fertig ist. Solange du noch daran arbeitest, ergibt das nicht so viel Sinn und (noch) private Maps wird Pedepe wahrscheinlich nicht bei sich aufnehmen.

    Das wird nichts bringen. Diese Gruppen müssen zusätzlich in der Datei unsched_vehgroups.txt hinterlegt werden.

    Alle dort eingetragenen Gruppen müssen zwar auch in der AI-List unter gleichem Namen vorhanden sein, diese Datei teilt OMSI aber mit, dass die dort ebenfalls hinterlegten Gruppen für den unfahrplanmäßigen Verkehr (also keine Busse/Züge etc.) bestimmt sind.

    Die Zahl darunter teilt OMSI mit, ob:

    1. diese Fahrzeuge überall standardmäßig fahren dürften und dementsprechend ggf. Pfade manuell zu sperren sind

    0. diese Fahrzeuge standardmäßig überall gesperrt sind (d.h. überall wo sie fahren dürfen, müssen die Pfade explizit freigeschaltet werden).


    Beispiel:

    Du meinst, wie "fein" du quasi malen kannst?

    Das hängt von der Auflösung ab, die du beim erstellen des Layers eingestellt hast.

    Das sind standardmäßig 64x64px, was relativ wenig ist.

    Je höher du es stellst um so genauer wird es - um so schlechter wird es allerdings auch. 256 oder 512 sind aber dennoch völlig okay.

    Ach und noch ne sache,bei mir dispawnen die Autos nach kurzer zeit auf meiner map wenn sie an mir vorbei gefahren sind, wieso?

    Das wird daran liegen, dass Pfade nicht richtig verbunden sind.

    Erstelle für das Problem aber am besten einen separaten Thread. :)

    Ansonsten ist eine gute und einfache Practice für die Dauer auch, dass man grundsätzlich niemals eigene OMSI-Mods etc. direkt bzw. ausschließlich direkt im Hauptverzeichnis erstellt.


    Ich habe separat auf einer anderen Festplatte einen OMSI-Projekte Ordner. Dort lege ich alles ab, was ich brauche, wenn ich in irgendeiner Form Content erstelle (sein es neue Objekte, Änderungen an Bussen oder was auch immer. Dort habe (und belasse) ich dann auch alle weiteren Dateien, die OMSI direkt eigentlich nicht braucht (z.B. blend- oder xcf-(GIMP)-Dateien)


    Wenn ich fertig bin, ziehe ich mir die Sachen in's OMSI Hauptverzeichnis rüber und nehme nur das mit, was OMSI tatsächlich braucht (also cfgs, Texturen, o3d-Dateien usw.).

    (bei komplexen Projekten mit vielen Dateien wo man häufig zum Testen Dinge "rüberziehen" muss, kann man sich auch mit wenig Programmierkenntnis eine einfache Batchdatei anlegen, die per Dopppelklick alles ins OMSI-Hauptverzeichnis synchronisiert).


    Durch dieses Vorgehen habe ich den großen Vorteil, dass mein OMSI-Ordner frei von unnötigen Dateiformaten (wie Blender, GIMP oder PowerPoint (nutze ich für Texturen)) bleibt und ich gleichzeitig automatisch eine Art "Backup" ja immernoch in meinem Projektordner habe. Wenn Steam nun anfängt, mein OMSI zu überprüfen, sind die Mods in OMSI zwar weg aber ich kann das, was ich brauche recht unkompliziert einfach wieder "reinziehen" und fertig.

    Zitat von logfile.txt

    71 13:22:30 - - Warning: Loading plugin plugins\OMSIPresentationTools.dll: procedure "AccessVariable" not found!

    72 13:22:30 - - Warning: Loading plugin plugins\OMSIPresentationTools.dll: procedure "AccessTrigger" not found!

    73 13:22:30 - - Warning: Loading plugin plugins\OMSIPresentationTools.dll: procedure "AccessSystemVariable" not found!

    74 13:22:30 - - Warning: Loading plugin plugins\OMSIPresentationTools.dll: procedure "AccessStringVariable" not found!

    Was hast du so an Plugins installiert?

    Kannst du diese mal testweise deaktivieren (am einfachsten, indem du die opl-Dateien in eine andere Dateiendung umbenennst)?


    Ansonsten hast du auch diverse Fehler mit anderen KI-Fahrzeugen, wie z.B. dem Mx200-C2:

    Zitat von logfile.txt

    164 13:40:41 - - Error: vehicles\MB_C2_EN_BVG\MB_C2_E6_Gn_trail.bus: Scriptshare-Command but no equal variable count!

    165 13:40:47 - - Information: Menu pos set

    166 13:40:48 - - Error: Fehler: im Befehl "(M.L.IVU_Ticketbox_frame)" (vehicles\MB_C2_EN_BVG\\script\C2_LE_main.osc) ist der Macroname ungültig!

    167 13:40:48 - - Error: Fehler: im Befehl "(M.L.IVU_Ticketbox_init)" (vehicles\MB_C2_EN_BVG\\script\C2_LE_main.osc) ist der Macroname ungültig!


    Tatsächlicher Auslöser für deine FPS-Einbrüche ist allerdings scheinbar ein DirectX-Fehler:

    Zitat von logfile.txt

    21810 14:57:12 - - Error: Draw Normal Mesh - Direct9 Error: D3DERR_INVALIDCALL (-2005530516)

    Eine Neuinstallation von DirectX könnte das Problem lösen. Probiere es mal auch. Für mich sieht es allerdings danach aus, dass bei dir irgendein Mesh eines Standardobjekts fehlerhaft ist, was zu den Fehlern führt, sobald das Objekt in deinem Blickfeld liegt.


    Du sagst, du hast das Problem auch auf Grundorf. Magst du das mal dort reproduzieren und erneut ein Logfile posten? Das würde es deutlich übersichtlicher machen.

    Moin,


    direkt ganz sauber aneinander legen kannst du Splines im Editor nicht.

    Der einzige Weg, über den sich Splines (und Objekte) aneinander ansnappen lassen, sind tatsächlich Pfade bzw. das Meter-Raster. Dabei kann man (standardmäßig mit der Strg+Taste gedrückt) die Splines an einem größeren Raster (von 1x1 Meter) platzieren. Das funktioniert aber auch nur solange die Splines irgendwie ganzzahlige breiten haben und eine Rotation, wie exakt 0, 90, 180 oder 270 grad haben.


    Ansonsten ist das tatsächlich einfach meist nach Augenmaß gearbeitet. Wenn du dir deshalb solche Maps mal ganz genau anschaust, siehst du daher auch oft, dass die Splines garnicht perfekt aneinander liegen, sondern kleine Lücken aufweisen oder sich (meist eher) minimal überlagern.


    Beim legen von Kurven ist es oft ratsam, die Länge eines Kurvensegments nicht über die Length-Box festzulegen, sondern über den Angel (Winkel) zu definieren. So können alle Teilsplines (z.B. Gehweg und Fahrbahn) gemeinsam den exakt gleichen Winkel haben, sodass auch die Folgesegmente noch genau parallel liegen.

    Mit dem Radius muss man dann ggf. etwas ausprobieren oder tatsächlich einfach rechnen, wenn man die Splinebreite kennt.


    Genauer bzw. sauberer geht es leider nicht.

    Die cleane Variante ist mMn. daher deshalb eher, halt einen Gesamtspline zu haben, bzw. bei komplexeren Verkehrsführungen (mit häufigen Einmündungen, Verkehrsinseln, was auch immer) ganze Straßenabschnitte in Blender zu modellieren und mit Pfaden auszustatten. Da kann man mMn., wenn man sich einmal in Blender reingefuchst hat, viel entspannter und vor allem sauberer bauen, da sich natürlich alles miteinander perfekt verbinden und ansnappen lässt.


    Ich hoffe, das hilft dir. :)

    Moin,

    Ich gehe mal davon aus, dass das mit deinem hier beschriebenen Problem zusammenhängt.

    Im dort angehangenen Logfile gibt es einige Auffälligkeiten:

    Code
    96 20:57:00 -  -     Warning:       load x File - Direct9 Error: DXFILEERR_FILENOTFOUND (-2005531815)
    97 20:57:00 -  -     Warning:       File Sceneryobjects\entrypoint_bus.sco: texture filename entrypoint.bmp not found in mesh file Sceneryobjects\model\entrypoint_bus.x!
    105 20:57:01 -  -     Warning:       load x File - Direct9 Error: DXFILEERR_FILENOTFOUND (-2005531815)
    106 20:57:01 -  -     Warning:       load x File - Direct9 Error: DXFILEERR_FILENOTFOUND (-2005531815)
    107 20:57:01 -  -     Warning:       load x File - Direct9 Error: DXFILEERR_FILENOTFOUND (-2005531815)

    Da sind scheinbar irgendwelche Model-Dateien vom Spandau-Content kaputt. Wenn du kein Backup davon hast, wirst du warscheinlich um eine OMSI-Reperatur/Neuinstallation via Steam nicht drum herum kommen. Was dabei zu beachten ist, kannst du auch hier nachlesen: Articles and FAQ

    Beachte, dass bei einer einfachen Steam-Reperatur, Steam alle geänderten Dateien von OMSI selbst und Addons überschreibt und durch die Originale ersetzt. Hast du zum Beispiel an DLC-Dateien etwas gemoddet, solltest du deine Änderungen dort unbedingt vorher sichern.

    Richtig, dass dürfte sich aus Abfahrtszeit an der letzten Haltestelle, Ankunft an der nächsten, Verspätung und aktueller Uhrzeit zumindest grob berechnen lassen, das wird aber nicht sehr präzise funktionieren.

    Diese Busse schildern aber auch das richtige Ziel?

    Ich habe leider beide Addons nicht, daher kann ich nichts konkretes dazu sagen, aber falls es von den Bussen spezielle KI-Varianten gibt: Hast du auch diese in der AI-List eingetragen und nicht die "normalen"?

    Hier habe ich fix mal einen neuen Link hinterlegt. Hätte nicht gedacht, dass noch jemand sich für meine mittlerweile schon etwas in die Jahre gekommenen Repaints interessiert. VG :)

    Moin, leider ist der neue Link bereits nicht mehr verfügbar, da, die Datei zumindest im kostenlosen Plan laut des Upload-Dienstes nach dem ersten Download automatisch gelöscht wird.

    Vielleicht magst du es so hochladen, dass es dauerhaft verfügbar bleibt. Das geht auch direkt hier in der WebDisk. :)

    Ein paar Bilder von der Spätschicht:

    Map: Lemmental-Neuenbreid (WiP) von Sev99LC

    Bus: MB O530 Citaro Facelift mit Nuntius-Drucker (WiP, privat) und BUSE BS210-Matrix (Flip-LED) von Lenn (WiP, privat)

    Repaint: VVK

    Moin,

    die Haltestellenweiterschaltung kannst du nicht direkt beeinflussen, die ist in OMSI fest programmiert, ab welcher Distanz auf die nächste Haltestelle geschaltet wird.

    Was du allerdings im Drucker umsetzen kannst, ist eine Zeitverzögerung einzubauen, dass die Ansage also nicht sofort beim weiter schalten der Haltestelle abgespielt wird, sondern das Script beispielsweise noch 10 Sekunden wartet.

    Das jedoch tatsächlich von der gefahrenen Distanz abhängig zu machen, ist jedoch in OMSI nicht so ohne weiteres direkt möglich, da das Scriptsystem dir nicht die Möglichkeit gibt, die Distanz zur vorherigen oder nächsten Haltestelle abzufragen.

    Der Atron im Mx200-C2 schafft das zwar, allerdings wird das dort relativ kompliziert berechnet, indem die Fahrplanzeiten der letzten und nächsten Haltestelle (die man per Script abfragen kann), sowie aktuelle Uhrzeit und derzeitige Verspätung miteinander verglichen werden. Dadurch lässt sich ungefähr bestimmen, wo genau der Bus sich zwischen zwei Haltestellen gerade befindet (also wieviel "Prozent der Strecke") von A nach B abgeschlossen wurden. Wenn man das dann mit einem durchschnittlichen Haltestellenabstand multipliziert, kann man ungefähr berechnen, wieviele Meter die nächste Haltestelle entfernt ist. Damit bekomme ich aber auch nur einen ganz grob angenäherten Wert, der gerade bei sehr kleinen oder großen Haltestellenabständen auch ganz schön daneben liegen kann.


    Ganz theoretisch: Wollte man es exakt machen, könnte man alle Haltestellenabstände im Druckerscript hardcoden. So würden tatsächlich alle Abstände exakt berechnet werden können, allerdings ist das natürlich 1.) ein extremer Aufwand und 2.) vermutlich auch nicht gerade performancefreundlich, wenn ein massiver Scriptblock, der eigentlich nur Daten speichert, geladen und ausgeführt werden muss.

    Moin,

    ich würde mal davon ausgehen, dass der Download leider nicht mehr so ohne weiteres auffindbar ist.

    Zumindest habe ich durch Googeln auf die Schnelle auch keinen anderen gefunden.

    Auf der Seite im MOF steht auch nichts weiteres zum Copyright der Repaints, eventuell steht in der Readme mehr. Im Zweifelsfall ist das erneute hochladen oder weiterschicken natürlich dennoch nicht erlaubt.

    Mit viel Glück findet sich hier vielleicht jemand, der es noch auf der Platte rumliegen hat und einen Blick in die Readme werfen kann. Wenn das Copyright es erlaubt, könnte man es hier natürlich erneut teilen.