r4mir3zx

Hi Phrontistes Yes, indeed, I have to agree with you, the naming of the function is logical, probably I would have also defined it this way on my own. On the other hand, the driving axis of a train and the drivingDirection property together defines a direction in which that train will start moving once someone starts it and gives it a target speed - from this point of view, though it is standing and not moving anywhere, it is determined by those properties to go in a certain direction - hence heading somewhere. Hm, well... Or maybe then better to say that it's "facing" towards something? isFacingToward() ? Oh, my bad. Indeed, you are right, it's not the physical concept of acceleration but only a property that defines with what speed a train's speed will change to achieve its target speed ... Thanks for the code review ! So, the code correctly is then: local vehicleIsHeadingTowardSignal = vehicle:isHeadingToward(currentSignal) if vehicle.drivingDirection == -1 and vehicle.speed == 0 then vehicleIsHeadingTowardSignal = not vehicleIsHeadingTowardSignal end Kind Regards, r4mir3zx --- Hallo Phrontistes Ja, da muss ich dir zustimmen, die Benennung der Funktion ist logisch, wahrscheinlich hätte ich sie auch selbst so definiert. Andererseits definieren die Antriebsachse eines Zuges und die Eigenschaft drivingDirection zusammen eine Richtung, in die sich der Zug bewegt, sobald ihn jemand startet und ihm eine Zielgeschwindigkeit gibt – aus dieser Sicht ist er, obwohl er steht und sich nirgendwohin bewegt, durch diese Eigenschaften dazu bestimmt, in eine bestimmte Richtung zu fahren – also irgendwohin zu steuern. Hm, also... Oder ist es dann vielleicht besser zu sagen, dass er auf etwas „zugewandt“ ist? isFacingToward() ? Vor 2 Stunden sagte Phrontistes: "Allerdings verstehe ich die Bedingung vehicle.acceleration == 0 nicht. Das ist die Eigenschaft „Beschleunigung in m/s²“. Dieser Wert ist normalerweise nicht 0." Oh, mein Fehler. Da hast du Recht, es ist nicht das physikalische Konzept der Beschleunigung, sondern nur eine Eigenschaft, die definiert, mit welcher Geschwindigkeit sich die Geschwindigkeit eines Zuges ändert, um seine Zielgeschwindigkeit zu erreichen ... Danke für die Codeüberprüfung! Der Code lautet also korrekt: Code hier Mit freundlichen Grüßen, r4mir3zx

Wow, thanks! Exactly, and I could reproduce it: Which is a bit of head-scratching, since then how could it be decided whether after starting a motionless train it would head toward a certain signal or not? Also desctiption of the isHeadingToward() does not mention that the train should be moving when it's called: Well, after thinking a bit: if in case of a motionless train the isHeadingToward() decides based on the positive driving axis (let it be either X or Y) direction consistently, then it can be figured out using the vehicle's .drivingDirection. Something like: local vehicleIsHeadingTowardSignal = vehicle:isHeadingToward(currentSignal) if vehicle.drivingDirection == -1 and vehicle.acceleration == 0 and vehicle.speed == 0 then vehicleIsHeadingTowardSignal = not vehicleIsHeadingTowardSignal end Looks a bit weird, though, all those checks to make sure it does not move ... However on this layout as well as on the Versuchstadt layout my original method has had no such problems with deciding train direction since the last change in... I don't know maybe mid-November. So I think - at least for now - I keep it rather than using isHeadingToward(). Regards --- Wow, danke! Genau, und ich konnte es reproduzieren: Bild 1 Das ist ein bisschen rätselhaft, denn wie könnte dann entschieden werden, ob ein stehender Zug nach dem Losfahren auf ein bestimmtes Signal zufährt oder nicht? Außerdem erwähnt die Beschreibung von isHeadingToward() nicht, dass der Zug fahren sollte, wenn es aufgerufen wird: Bild 2 Nun, nach kurzem Nachdenken: Wenn im Falle eines stehenden Zuges isHeadingToward() konsequent basierend auf der positiven Richtung der Fahrachse (sei es X oder Y) entscheidet, dann kann es mithilfe der .drivingDirection des Fahrzeugs herausgefunden werden. So etwas wie: Code hier Sieht allerdings ein bisschen komisch aus, all diese Prüfungen, um sicherzustellen, dass es sich nicht bewegt ... Auf dieser Anlage sowie auf der Versuchstadt-Anlage hatte meine ursprüngliche Methode jedoch seit der letzten Änderung in ... ich weiß nicht, vielleicht Mitte November, keine derartigen Probleme mit der Entscheidung über die Zugrichtung. Ich denke also – zumindest vorerst –, dass ich es behalte, anstatt isHeadingToward() zu verwenden. Grüße

Well, though however, now I see isHeadingToward() returns true even when the train direction is set to point away from the signal. Does it not take into account the vehicle direction? Seemingly it doesn't: I really go to bed now, good night! --- Nun, jetzt sehe ich jedoch, dass isHeadingToward() „true“ zurückgibt, auch wenn die Zugrichtung so eingestellt ist, dass sie vom Signal weg zeigt. Berücksichtigt es nicht die Fahrzeugrichtung? Anscheinend tut es das nicht: Bild 1 Ich gehe jetzt wirklich ins Bett, gute Nacht!

So conclsion: adding "or engine:isLocatedOn(currentSignal)" to the condition can help Have a good night, I go to sleep. --- Fazit: Das Hinzufügen von „or engine:isLocatedOn(current Signal)“ zur Bedingung kann hilfreich sein. Gute Nacht, ich gehe jetzt schlafen.

Aaand I figured it out: when the locomotive stands exactly on the signal's contact, the isHeadingToward() returns false. Actually it works well in the curves, too. In case when the signal is not set to auto-accelerate on setting it free, like in case of signal 'R01-01_Enter' the train does not start because then neither the signal nor the script can start it. Actually it's logical, it's not isHeadingToward it is already on the contact. -- Uuund ich habe es herausgefunden: wenn die Lokomotive genau auf dem Kontakt des Signals steht, gibt isHeadingToward() false zurück. Tatsächlich funktioniert es auch in den Kurven gut. Wenn das Signal nicht so eingestellt ist, dass es beim Loslassen automatisch beschleunigt, wie im Fall des Signals „R01-01_Enter“, fährt der Zug nicht los, weil dann weder das Signal noch das Skript ihn starten können. Eigentlich ist es logisch, es ist nicht isHeadingToward, es steht bereits auf dem Kontakt.

What I did in my method - you can see them in the commented out lines - was to find the track on which the locomotive was standing and then calculated a vector from the center of that track to the center of the next one (the _previous_ starter track in the StarterTrack list of the signal*) pointing towards the signal. Then compared the angle between this vector and the locomotive's own one heading forward and if the angle is below a certain value (that is hardcoded to 30 degrees now but can be smaller actually) then the train was considered as "startable". This also has the benefit of working in curves, even when the locomotive's vector is still pointing significantly away from the signal. Of course I took into account the direction of the train, too. * In the StarterTracks list the closest track to the signal is the first and so on. --- Was ich in meiner Methode gemacht habe - Sie können es in den auskommentierten Zeilen sehen - war, das Gleis zu finden, auf dem die Lokomotive stand, und dann einen Vektor von der Mitte dieses Gleises zur Mitte des nächsten (des _vorherigen_ Startgleises in der StarterTrack-Liste des Signals*) zu berechnen, das auf das Signal zeigt. Dann habe ich den Winkel zwischen diesem Vektor und dem der Lokomotive in Vorwärtsrichtung verglichen, und wenn der Winkel unter einem bestimmten Wert liegt (der jetzt fest auf 30 Grad codiert ist, aber tatsächlich kleiner sein kann), wurde der Zug als „startfähig“ betrachtet. Dies hat auch den Vorteil, dass es in Kurven funktioniert, selbst wenn der Vektor der Lokomotive noch deutlich vom Signal weg zeigt. Natürlich habe ich auch die Richtung des Zuges berücksichtigt. * In der StarterTracks-Liste ist das dem Signal am nächsten gelegene Gleis das erste und so weiter. edit: grammar

Oh, OK, I just figured it out why it started still the engines at the curve when I set that R01-05_R04-04_Enter free: it stopped at the contact point and the signal had been set to automatically accelerate it. If it stops way before the contact point on any of the starter tracks, it cannot be started, because the isHeadingToward() returns false then. I just don't understand why then it returns also false in the straight track? (BTW in the straight track the signal R01-01_Enter is not set to accelerate trains automatically. ) --- Oh, ok, ich habe gerade herausgefunden, warum die Motoren in der Kurve noch gestartet wurden, als ich R01-05_R04-04_Enter freigab: Es hielt am Kontaktpunkt an und das Signal war so eingestellt, dass es automatisch beschleunigte. Wenn es auf einer der Startstrecken weit vor dem Kontaktpunkt anhält, kann es nicht gestartet werden, weil isHeadingToward() dann false zurückgibt. Ich verstehe nur nicht, warum es dann auch auf der geraden Strecke false zurückgibt? (Übrigens ist das Signal R01-01_Enter auf dem geraden Gleis nicht so eingestellt, dass es Züge automatisch beschleunigt.)

Hm, at least I am able to reproduce it now consistently with stopping first at the curve and then continuing. Whenever it stops at the curve at R01-05_R04-04_Enter and I set the signal free there it returns 'false' but still starts the engine, and then it fails eventually at R01-01_Enter. Strange. So this is why I went with my solution on the Vorsuchstadt layout. --- Hm, zumindest kann ich es jetzt konsistent reproduzieren, indem ich erst an der Kurve anhalte und dann weiterfahre. Immer wenn es an der Kurve bei R01-05_R04-04_Enter anhält und ich dort das Signal freigebe, gibt es „false“ zurück, startet aber trotzdem den Motor, und dann versagt es schließlich bei R01-01_Enter. Seltsam. Deshalb habe ich mich für meine Lösung auf dem Vorsuchstadt-Layout entschieden.

Yeah, you are right Goetz! That's what I've just done Here is the changed script (btw I changed it on my test layout to see things clearly, the script is exactly the same as on the Vorsuchstadt layout): And the effect: Initially the BR 86 refused to be started, saying that it was not heading toward the signal R01-01_Enter. Unfortunately I didn't create a screenshot from that. Then I swapped it with BR 81 which happily started running around, so it was definitely found by the isHeadingToward. So I thought it's actually the way around and the sideways X local coordinate setup is the correct for the train. Proof that it worked, you can see the happy huffs and puffs of the train there: Now I changed back to BR 86 and to my greatest surprise it worked, I did some runs around but isHeadingToward returned "true" for that at the R01-01_Enter signal. I changed to another engine, BR 144, just to see what's going on, it has again X coordinate in the direction of travel, contrary to BR 81. And it again worked. At this point I got confused as it didn't work initially with BR 86. Now after some rounds with BR 144 I stopped it at a signal in a curve, at signal R01-05_R04-04_Enter. Then I allowed it to enter the "station", and when I wanted to restart it I got this: I think the reason is deeper than I can see currently. It's like some heisenbug or mandelbug. Regards, r4mir3zx --- Ja, du hast recht, Götz! Das habe ich gerade gemacht. Hier ist das geänderte Skript (ich habe es übrigens auf meiner Testanlage geändert, um die Dinge klarer zu sehen, das Skript ist genau dasselbe wie auf der Vorsuchstadt-Anlage): Bild 1 Und die Wirkung: Zunächst weigerte sich die BR 86, gestartet zu werden, mit der Begründung, sie fahre nicht auf das Signal R01-01_Enter zu. Leider habe ich davon keinen Screenshot gemacht. Dann habe ich sie mit der BR 81 vertauscht, die fröhlich losfuhr, also wurde sie definitiv von isHeadingToward gefunden. Also dachte ich, es ist eigentlich umgekehrt und die seitliche lokale X-Koordinateneinstellung ist die richtige für den Zug. Als Beweis dafür, dass es funktioniert hat, können Sie das fröhliche Schnaufen und Pusten des Zuges hier sehen: Bild 2 Nun bin ich wieder auf BR 86 umgestiegen und zu meiner größten Überraschung hat es funktioniert. Ich habe ein paar Runden gedreht, aber isHeadingToward hat dafür am Signal R01-01_Enter „true“ zurückgegeben. Ich habe auf eine andere Lokomotive, BR 144, um zu sehen, was los ist, gewechselt. Sie hat wieder die X-Koordinate in Fahrtrichtung, im Gegensatz zu BR 81. Und es hat wieder funktioniert. An diesem Punkt war ich verwirrt, weil es anfangs mit BR 86 nicht funktioniert hat. Nun, nach einigen Runden mit BR 144, habe ich sie an einem Signal in einer Kurve angehalten, am Signal R01-05_R04-04_Enter. Dann habe ich sie in den „Bahnhof“ einfahren lassen und als ich sie neu starten wollte, bekam ich dies: Bild 3 Ich glaube, der Grund liegt tiefer, als ich derzeit erkennen kann. Es ist wie ein Heisenbug oder Mandelbug. Grüße, r4mir3zx

Yes, I think that was the method I tried. And as I remember - it was a month ago or so - initially it looked like working, but then for some reason it just didn't. And since I had already written my own version, instead of debugging I think I just decided to go with my one. Now I don't know whether I broke something in my script when I applied the isHeadingToward() or something else was the cause of the confusion. There's a chance that it was just before I found those vehicles with the different local coordinate setup (like BR 81 or DB 212 - their local X axis is pointed sideways and the Y axis is what points to their vector of motion) ... But I'll try out again that method and will see what caused the issue. Maybe it was just me confusing things --- Ja, ich glaube, das war die Methode, die ich ausprobiert habe. Und soweit ich mich erinnere – es war vor etwa einem Monat – sah es zunächst so aus, als würde es funktionieren, aber dann hat es aus irgendeinem Grund einfach nicht funktioniert. Und da ich bereits meine eigene Version geschrieben hatte, habe ich mich, glaube ich, einfach für meine eigene entschieden, anstatt sie zu debuggen. Ich weiß jetzt nicht, ob ich etwas in meinem Skript kaputt gemacht habe, als ich isHeadingToward() angewendet habe, oder ob etwas anderes die Ursache für die Verwirrung war. Es besteht die Möglichkeit, dass es kurz bevor ich diese Fahrzeuge mit den unterschiedlichen lokalen Koordinateneinstellungen gefunden habe (wie BR 81 oder DB 212 – ihre lokale X-Achse zeigt seitwärts und die Y-Achse zeigt auf ihren Bewegungsvektor) ... Aber ich werde diese Methode noch einmal ausprobieren und sehen, was das Problem verursacht hat. Vielleicht habe ich einfach nur Dinge verwechselt.

Thanks much! It wouldn't be super without the hundreds of models you guys all created and shared and I learnt much also from the layouts that you all had submitted before. Playing with this is like being in a shop with full of model trains that are just all mine to play with... and there's nothing to break, no short circuit, etc Endless possibilities here. --- Vielen Dank! Es wäre nicht so toll ohne die Hunderte von Modellen, die ihr alle erstellt und geteilt habt, und ich habe auch viel von den Layouts gelernt, die ihr alle zuvor eingereicht habt. Damit zu spielen ist wie in einem Laden voller Modelleisenbahnen zu sein, mit denen ich einfach spielen kann ... und nichts kann kaputtgehen, es gibt keinen Kurzschluss usw. Endlose Möglichkeiten.

Ah, and I almost forgot it again to mention something about routes and train activation: the trains don't have to be at the signal contact to be started. For all the starter signals there's a sequence of tracks defined as "StarterTracks". On any signal or route activation any trains with engine (hasEngine) on those starter tracks will be started. I tried to set up starter tracks up to a distance where the train driver still can "see" the signal. That's usually the 5 or 6 tracks before the signal, well, depending also on length and such. Usually turnouts are not included, but sometimes they are. This is a small layout... There are special cases however: Certain locomotives, like e.g. BR 81 has a different local coordinate system setup than those of the rest. For that case a "RotationOffset" number should be added to the locomotive variables with the rotation with which the train coordinate system is offset to that of the world's. E.g. in case of BR 81 it is 90 degrees, so "RotationOffset" should be 90. This is because when I worked with the scripts I had some problems with the methods that determine train direction, so I wrote my own that decides whether train stands in the direction of the signal or not (currently there's a hardcoded 30 degrees tolerance, can maybe be even less...). ------- Translated by Google Translate: -------- Ah, und ich hätte fast wieder vergessen, etwas über Fahrstraßen und Zugaktivierung zu erwähnen: Die Züge müssen nicht am Signalkontakt sein, um loszufahren. Für alle Startsignale gibt es eine Reihe von Gleisen, die als „StarterTracks“ definiert sind. Bei jeder Signal- oder Fahrstraßenaktivierung werden alle Züge mit Lokomotive (hasEngine) auf diesen Startgleisen losgefahren. Ich habe versucht, Startgleise bis zu einer Entfernung einzurichten, in der der Lokführer das Signal noch „sehen“ kann. Das sind normalerweise die 5 oder 6 Gleise vor dem Signal, na ja, je nach Länge und so. Normalerweise sind Weichen nicht enthalten, aber manchmal schon. Dies ist ein kleines Layout … Es gibt jedoch Sonderfälle: Bestimmte Lokomotiven, wie z. B. BR 81, haben ein anderes lokales Koordinatensystem als die anderen. Für diesen Fall sollte den Lokomotivvariablen eine „RotationOffset“-Nummer mit der Rotation hinzugefügt werden, mit der das Zugkoordinatensystem gegenüber dem der Welt verschoben ist. Z. B. bei BR 81 sind es 90 Grad, also sollte „RotationOffset“ 90 sein. Das liegt daran, dass ich beim Arbeiten mit den Skripten einige Probleme mit den Methoden hatte, die die Zugrichtung bestimmen, also habe ich meine eigenen geschrieben, die entscheiden, ob der Zug in Richtung des Signals steht oder nicht (derzeit gibt es eine fest codierte Toleranz von 30 Grad, kann vielleicht sogar noch weniger sein...).

Ah, yes, forgot to mention the predefined cameras from 0 to 6, some of my favourite views. Some of those screenshots above are from them. I hope you'll also like it. Kind Regards --- Google Translate: --- Ach ja, ich habe vergessen, die vordefinierten Kameras von 0 bis 6 zu erwähnen, einige meiner Lieblingsansichten. Einige der Screenshots oben stammen von ihnen. Ich hoffe, es gefällt Ihnen auch. Mit freundlichen Grüßen

Hi, good evening everyone, Happy New Year! I played a bit with the layout and noticed some issues here and there, with the grounds, or with the bus line and I decided to fix them. After fixing them I thought it would also be nice to have some quick buttons to access train cameras. I had set up cameras originally to see how they handle the curves and such, so they had already been there. What I just needed were some buttons and a quick script to handle them - you can find the new camera buttons under the bus line automation button. Afyer setting up a camera I also recalled how other people used buttons on their GBS lines to activate routes. So I decided to do something similar: I again dropped in a quick script and parametrized buttons to quickly activate (or deactivate) some pre-defined routes. Those buttons can be found on the middle GBS control group. When you activate it it will highlight the selected - and activated - route on the GBS controls. While the button stays in an active state the routes will be activated again and again. Toggling the buttons off will turn off the pre-defined route sequence, too. CW buttons are for clockwise routes, CCW are for counter-clockwise routes. Please note: not all the possible route sequences are handled by those buttons - some routes have to be selected manually! Also added some train drivers, at least to the two green electric locomotives. Finally, I decided to add a new signal house next to the western level crossings - that part was so empty, it needed something and comparing my layout with the original 12-year one plan I found there a signal box placed. So I put one here, too. I hope I won't find more issues. ------- Translated by Google Translate: -------- Hallo, guten Abend allerseits, frohes neues Jahr! Ich habe ein bisschen mit dem Layout gespielt und hier und da ein paar Probleme bemerkt, mit dem Gelände oder mit der Buslinie, und ich habe beschlossen, sie zu beheben. Nachdem ich sie behoben hatte, dachte ich, es wäre auch schön, ein paar Schnelltasten zu haben, um auf Zugkameras zuzugreifen. Ich hatte Kameras ursprünglich eingerichtet, um zu sehen, wie sie mit Kurven und dergleichen umgehen, also waren sie schon da. Was ich nur brauchte, waren ein paar Tasten und ein schnelles Skript, um sie zu handhaben – Sie finden die neuen Kameratasten unter der Buslinienautomatisierungstaste. Nach dem Einrichten einer Kamera erinnerte ich mich auch daran, wie andere Leute Tasten auf ihren GBS-Linien verwendeten, um Routen zu aktivieren. Also beschloss ich, etwas Ähnliches zu tun: Ich fügte wieder ein schnelles Skript ein und parametrisierte Tasten, um einige vordefinierte Routen schnell zu aktivieren (oder zu deaktivieren). Diese Tasten finden Sie in der mittleren GBS-Steuerungsgruppe. Wenn Sie sie aktivieren, wird die ausgewählte – und aktivierte – Route auf den GBS-Steuerungen hervorgehoben. Solange die Taste in einem aktiven Zustand bleibt, werden die Routen immer wieder aktiviert. Wenn Sie die Schaltflächen ausschalten, wird auch die vordefinierte Routensequenz deaktiviert. CW-Schaltflächen sind für Routen im Uhrzeigersinn, CCW für Routen gegen den Uhrzeigersinn. Bitte beachten: Nicht alle möglichen Routensequenzen werden von diesen Schaltflächen verwaltet – einige Routen müssen manuell ausgewählt werden! Außerdem wurden einige Lokführer hinzugefügt, zumindest für die beiden grünen Elektrolokomotiven. Schließlich habe ich beschlossen, neben den westlichen Bahnübergängen ein neues Stellwerk hinzuzufügen – dieser Teil war so leer, dass etwas fehlte. Als ich mein Layout mit dem ursprünglichen 12-Jahres-Plan verglich, stellte ich fest, dass dort ein Stellwerk platziert war. Also habe ich auch hier eines platziert. Ich hoffe, ich werde keine weiteren Probleme finden.

Thanks much. It looked the most user-friendly this way. The alternative would have been to turn on and off layers - and actually it can still be done, season layers are labelled with "SUMMER" and "WINTER" prefixes, all others with no prefix should be visible all the time (except which should not, e.g. road control signals, though as I see they cannot be seen in simulation mode). Initially the toggle was also used to set up the keyword parameters for the script: e.g. I turned on the visibility for all winter objects only and toggled the switch, and with that the script set up all the visible objects with the "winterObject" keyword. Then did the same with the summer only ones and then I just had to comment out the setup code and write the one that turns visibility on/off based on the toggle switch state and that was all, it changes between summer and winter swiftly. There are less figures on the winter layout, because most characters wear inappropriate clothes for winter time (e.g. the girl called "Clara" , she reminds me Clara Oswald from Doctor Who) Also storks had to leave to the south and I thought the cows and the horse would not enjoy the winter cold, so just removed them, too ... At one point I looked for a polar bear in the dictionary but found no one unfortunately ... as well as also no mammoth nor penguins could be found... Also the summer background had to disappear. Though I found a winter background and it's quite nice, but for this layout I found its blue sky too bright ... I wanted something more cloudy, maybe with snow. And I tried out putting snow particles in the layout, too, but with some 2500 snow particles even my PC struggled to render it with an appropriate FPS, and such so eventually I decided not to include it. If any of you has a power PC with some high end graphics card then don't hesitate to put in a snowbox and let it snow, I bet it would look nice. --- Translated by google: Vielen Dank. So sah es am benutzerfreundlichsten aus. Die Alternative wäre gewesen, Ebenen ein- und auszuschalten – und das geht eigentlich immer noch, Jahreszeitenebenen sind mit den Präfixen „SOMMER“ und „WINTER“ gekennzeichnet, alle anderen ohne Präfix sollten immer sichtbar sein (außer denen, die es nicht sein sollten, z. B. Straßenkontrollsignale, obwohl diese, wie ich sehe, im Simulationsmodus nicht sichtbar sind). Ursprünglich wurde der Umschalter auch verwendet, um die Schlüsselwortparameter für das Skript einzurichten: z. B. schaltete ich die Sichtbarkeit nur für alle Winterobjekte ein und schaltete den Schalter um, und damit richtete das Skript alle sichtbaren Objekte mit dem Schlüsselwort „winterObject“ ein. Dann machte ich dasselbe mit den reinen Sommerobjekten und dann musste ich nur noch den Setup-Code auskommentieren und den Code schreiben, der die Sichtbarkeit basierend auf dem Zustand des Umschalters ein-/ausschaltet, und das war alles, es wechselt schnell zwischen Sommer und Winter. Es gibt weniger Figuren im Winterlayout, da die meisten Charaktere für den Winter unpassende Kleidung tragen (z. B. das Mädchen namens „Clara“, sie erinnert mich an Clara Oswald aus Doctor Who). Auch die Störche mussten in den Süden ziehen und ich dachte, die Kühe und das Pferd würden die Winterkälte nicht mögen, also habe ich sie auch entfernt ... Einmal habe ich im Wörterbuch nach einem Eisbären gesucht, aber leider niemanden gefunden ... und auch Mammuts und Pinguine waren nicht zu finden ... Auch der Sommerhintergrund musste verschwinden. Ich habe zwar einen Winterhintergrund gefunden und er ist ganz nett, aber für dieses Layout fand ich seinen blauen Himmel zu hell ... ich wollte etwas Bewölkteres, vielleicht mit Schnee. Und ich habe auch versucht, Schneepartikel in das Layout zu setzen, aber mit etwa 2500 Schneepartikeln hatte sogar mein PC Probleme, es mit einer angemessenen FPS darzustellen, und so habe ich mich letztendlich dazu entschieden, es nicht aufzunehmen. Wenn jemand von euch einen Power-PC mit einer High-End-Grafikkarte hat, dann zögert nicht, eine Schneebox hineinzustellen und es schneien zu lassen, ich wette, das würde gut aussehen.