Posts by SchulterSack

Bin heute durch Luxemburg gefahren und dabei zufällig an dem "Retrobus Sommerfest" in Bettembourg vorbei gekommen.
Der auf den Plakaten abgebildete Routemaster, der mich am meisten interessiert hätte, war leider weit und breit nicht zu sehen, stattdessen standen nur zwei für meinen Geschmack eher langweilige Fahrzeuge herum.
Leider hat meine Kamera rumgezickt (wollte trotz vollem Akku nicht starten), sodass es nur für ein paar Smartphone-Schnappschüsse gereicht hat - und das auch nur von einem der zwei Wagen.

AX 0867 (ex. AVL/TVL Wagen 212), ein Magirus Deu(t)z 260 SH 110

Derselbe Wagen nochmal von hinten

Das zweite Fahrzeug war übrigens BU 0806 (ex. AVL/TVL Wagen 182), ein MAN A10.

Das von dir verlinkte "audacity.de" ist aber gerade nicht die offizielle Website. Wer weiß, was man sich da auf den Rechner holt.

Die offizielle Website ist hier zu finden.

Bis 5. Juli gibt es im Steam-Store 5€ Rabatt bei PayPal-Zahlung. Im Zusammenhang mit dem Summer Sale, der morgen startet, ist damit sicher das ein oder andere Schnäppchen möglich.

Link zur Aktionsseite: https://www.paypal.com/de/weba…ils&offerId=QB4YNANJE2RXW

In Zeile 51 erwartet OMSI den Materialindex zum "matl_change"-Kommando. Mit der Angabe, die er aktuell dort vorfindet, kann er nichts anfangen, daher der Fehler.

Die Globalstrings sollten theoretisch beliebig erweiterbar sein. Die Anzahl der Zeilen, die OMSI ausliest, kann ganz oben definiert werden (wie es auch z.B. bei den Routen der Fall ist).
Inwiefern das einfacher als meine ursprüngliche Lösung sein soll, kann ich aber nicht nachvollziehen.

Ich meinte auch nicht den ganzen von dir geposteten Abschnitt sondern nur den obersten, also diesen hier:

Der Rest muss so belassen werden.

Moin,

du löschst einfach den bisherigen Abschnitt und fügst den neuen an der Stelle ein.
Die Variable "doorTimer" muss zudem noch in die varlist eingetragen werden.

Dazu müsstest du einen Timer ins Skript einbauen, der das Schließen verzögert, etwa so:

Beachte aber, dass der Sound dann logischerweise auch erst abgespielt wird, wenn die Türen tatsächlich schließen, also nach der Verzögerung.
Um einen Sound auch während der Verzögerung hörbar zu machen, kannst du z.B. auf die doorTimer-Variable zurückgreifen, oder du fügst noch eine zusätzliche Variable nur für den Sound hinzu.

Moin,

also Soundtrigger fürs Öffnen sind in dem Skript nicht vorgesehen, es sollte aber möglich sein, das über die sound.cfg zu realisieren.
Die Volcurve für die Sounds sieht aktuell so aus:

Das bedeutet, dass der Sound sowohl bei positiven (Tür wird geöffnet) als auch negativen (Tür wird geschlossen) Werten der "doorSpeed"-Variable hörbar ist.
Wenn du nun den oberen [pnt]-Eintrag mit der "-1" entfernst, sollte der Sound nur noch beim Öffnen und nicht mehr beim Schließen hörbar sein.
Dann kannst du einen neuen Sound anlegen, bei dem du wiederum den Eintrag mit der "1" entfernst und die "-1" stehen lässt. Dieser wäre dann nur beim Schließen zu hören.

Am Ende könnte das also etwa so aussehen:

So zumindest die Theorie, dass es funktioniert kann ich dir nicht versprechen, da sound.cfg's nicht mein Fachgebiet sind.

Viele Grüße
SchulterSack

Quote from omsifan2k17

Anmerkung: Ich finde es etwas verwerflich das 3 mal Zigarettenwerbung in einem Payware Addon ist obwohl das auch Kinder spielen sehr schlechtes Vorbild!

Ich nehme an, du sperrst deine Kinder - wenn du mal welche hast - dann auch im Keller ein, damit sie draußen nicht die böse Zigarettenwerbung sehen können?

Mal ernsthaft: Werbeplakate für Zigaretten an gefühlt jeder zweiten Ecke gehören zum Stadtbild heute einfach dazu.
Das muss man nicht gut finden - tue ich auch nicht - aber es ist nun mal so, also wird es natürlich auch in der Simulation so umgesetzt.

Ich verabschiede mich dann auch schonmal für dieses Jahr mit einem bunten Mix an bisher noch nicht gezeigten Bildern aus meinem Archiv.

Nordbahn ET 6.01 in Hamburg-Altona

628 481 in Bad Dürkheim

FG-DD 880, ein O405GN2 der Firma Reisedienst Brückner in Dresden (weiß leider nicht mehr, wo genau das war...)

Der Handelshafen in Mannheim, ein nettes Örtchen wo man u.A. dieses schöne Motiv aufnehmen kann

Zum Abschluss noch ein Foto aus der Heimat: Saarbahn Tw 1022 sonnt sich dank einer Betriebsstörung auf dem Stumpfgleis am Römerkastell

Frohe Feiertage und 'nen guten Rutsch allerseits.

Quote from OS-S 9031

Hier hast du irdgendwat falsch gemacht :

Nein, in cfg-Dateien kann man reinschreiben, was man will, die relevanten Zeilen pickt sich OMSI anhand der Schlüsselwörter raus.

Der Grund, warum das bei rnvfan nicht funktioniert, ist schlichtweg, dass über [animparent] auf die Animation "fahrertuer" zugegriffen werden soll, bevor diese überhaupt definiert wird.
Einfach einmal die Reihenfolge ändern, dann sollte das auch klappen.

Du musst die Variablen "ziel_aktuell" und "ziel_neu" in eine varlist und die Variable "LW_req_linie" in eine stringvarlist eintragen.
Normalerweise stehen die in der (string)varlist von Darius' Matrix, da diese aber hier nicht geladen wird, fehlen sie natürlich und müssen anderswo definiert werden.

Den letzten Eintrag mit dem ungültigen Makro kann ich jetzt auf Anhieb nicht so recht deuten. Wenn es einen "ticketprinter_frame" gibt, sollte es eigentlich auch einen "ticketprinter_init" geben.
Es ist aber gut möglich, dass der im Gladbeck-Druckerskript anders heißt oder weggelassen wurde, dazu einfach mal das Skript öffnen und nach "init" suchen.

Wie FlofiX3291 schon richtig angemerkt hat, ist "LW_req_linie" natürlich eine String-Variable, daher auch der Eintrag in die stringvarlist. Ich hatte das im Beitrag oben übersehen.
Das Prinzip bleibt das selbe, aber das Skript muss etwas anders aussehen (siehe zwei Beitrage über diesem).

Quote from ACMG

AI_target_index dient nur zur Übergabe des Ziels für die KI von OMSI an das Script. Entsprechend ist die read-only (siehe Wiki unter Systemvariablen). Das sollte natürlich keine Auswirkung hier haben, aber solltest du wissen.

Ich hatte während meiner Tests einige komische Erlebnisse (trotz "Leerziel" wollten Leute einsteigen), da hab' ich die Variable testweise auch mal beschrieben. Wäre ja nicht das erste Mal, dass im Wiki falsche Infos zu finden sind.
Genützt hat es aber nichts. War wohl wieder eines dieser OMSI-Mysterien.

Quote from ACMG

Warum die bei dir nur hinten eingestiegen sind, ist mir allerdings auch unklar. Bei der NF6D ist der entsprechende Teil in den Global-Scripten drin (mal nach "Trick17" suchen). Offenbar für jeden Fahrzeugteil? Wenn Velocity 0 ist, wird das richtige Ziel gesetzt, sonst Ziel 2.

Wie meinst du das, "für jeden Fahrzeugteil"? Es sollte doch überall das selbe Skript genutzt werden.

Ich habe das AddOn ja nicht, kann also nicht selbst nachschauen. Wobei das Prinzip bei mir ja das selbe sein sollte.

Ich hatte das letztens mal mit dem AGG ausprobiert, weil es mich tierisch nervt, dass die Leute immer wie bekloppt nach vorne rennen.
Der Code dafür sah wie folgt aus (einfach in der main.osc platziert):

Das hat leider nicht wie gewünscht funktioniert, die Leute sind fortan zwar hinten eingestiegen, aber leider nur hinten (letzte Tür).
Mich würde ja mal interessieren, ob das bei der Straßenbahn funktioniert (habe das AddOn nicht). Steigen da tatsächlich an allen Wagenteilen Leute ein? Oder hat die Bahn nur zwei Teile?

Die Druckerskripte von Darius mit den Standard-Matrixskripten kompatibel zu machen ist allerdings nun wirklich kein Hexenwerk.

Standardmäßig sucht die Matrix nach dem Ziel-Index in der Variable "IBIS_TerminusIndex", Linie und Suffix werden unter "IBIS_Linie_Complex" (Linie und Suffix) und "IBIS_Linie_Suffix" (nur Suffix) gesucht.
Die Drucker von Darius schreiben das Ziel in "ziel_neu" und die Linie (ohne Suffix) in "LW_req_linie".

Was machen wir nun mit dieser Information? Richtig, wir packen die Werte aus den Drucker-Variablen in die entsprechenden Matrix-Variablen, etwa so:

Wohin damit? Zum Beispiel einfach in den "{frame}"-Abschnitt der main.osc.

Alternativ könnte man natürlich auch die Drucker- und/oder Matrixskripte bearbeiten, aber warum sollte man das, wenn es auch der gerade gezeigte Zweizeiler tut?

Hi,

most of your questions can be answered by reading the wiki article about the OMSI scripting system. You can find it here.
"Timegap" contains the time (in seconds) since the last frame, so by adding this up you can make a timer or countdown (which is why the variable was named "Timer" in my original script ;)).
"TrafficLightPhase" contains the index of the current traffic light phase of the linked crossing object.
These are both system variables, they are declared and set by OMSI itself. You can find a list and details about them here (in German, but it's mostly pretty self-explanatory).

To answer your main question:
In my opinion, the best way to do this would be to add one or multiple separate "blinking phases" in the traffic light editor.
If you own the Vienna add-on, you should have a look at their traffic lights, since they did exactly what you're trying to achieve.
You could also use a timer to count the duration of the green phase, but I'm not sure this will work properly.

Das Ergebnis der Rechnung muss genau null sein, damit deine if-Bedingung zutrifft, das wird sie aber nur im seltensten Fall sein, eher irgendwas krummes, z.B. 0.0001234.
Ich würde hier eher mit einer Variable arbeiten, in der die Stunde der letzten Aktualisierung zwischengespeichert wird:

Die Infos im Wiki sind hier scheinbar falsch und Sceneryobjects unterstützen gar keine Skripttexturen.
Da kann man als User leider nichts machen, das System wirst du anders umsetzen müssen.

Du hast in der AI-Gruppe des Doppeldeckers das abschließende "[end]" vergessen, dadurch interpretiert OMSI die folgenden Zeilen als Fahrzeugeinsätze und schickt (mangels Angabe von Nummer oder Repaint) irgendwelche Zufallsbusse auf die Straße.