= Englisch [EN], 
= Deutsch [DE], 
= Französisch [FR]. Wenn du die angegebene Sprache nicht beherrschst, schreibe auf Englisch! Genau das sind so Sachen warum man so Tools eben begrüßt. Ja, OMSI wird nicht gepflegt, umso besser wenn es andere Abhilfe gibt.
Musste schon mal jemand die Umläufe zählen oder die verfügbaren Fahrzeuge in den Depots? War sicher ein Spaß;-D Erst recht mit Chrono und Abgängen und Zugängen. Wenn das bloß ein Tool könnte, einfach mit einem Klick die AI-Listen durchforsten und den Bestand zum Datum X ausspucken. Aber das wäre schon fast Träumerei das dieses Tool das kann;-D
Ich finde den OMSI-Fahrplaneditor unglaublich schwerfällig und lästig. Wenn mir hier ein Tool die Arbeit erleichtert finde ich das super. Vor allem wenn es Funktionen hätte auch zu überprüfen ob alles im Fahrtplan stimmt zum Beispiel dann durch einen Aufruf des Linienfahrplanes oder eines beliebigen Haltestellenfahrplanes, natürlich unter Berücksichtigung von Chronos. Zum Teil geht das mit OMSI-Bordmitteln, ist aber super lästig.
Gleiches mit den AI-Listen. Klar kann ich die editieren. Mit Chronos und Veränderungen ("ailist_#upd") über die Zeit wird das aber wieder unübersichtlich und man macht schnell Fehler. Außerdem verzeiht OMSI gewisse Fehler in den AI-Listen nicht (macht mal ein TAB oder ein Leerzeichen nach einem [end]...) und vielleicht kann man diese so einfacher vermeiden.
Ich weiss natürlich nicht in wie weit das Tool die erwähnten Sachen kann, aber ich finde eine prinzipielle Stimmung gegen solche Tools unangebracht.
Ein ähnliches "Problem" hab ich mit den Triggern im O405 beim IBIS und Eurofare-Drucker was die Weiterschaltung der Haltestellen betrifft.
Erstmal grundsätzlich: ich habe die ANNAX Matrix aktiv und den Eurofare, somit das IBIS- und das Eurofare-Script.
Das IBIS-Script schaltet die Haltestellen ganz nach OMSI_standard stumm weiter und zurück mit folgenden Triggern:
- IBIS_vor_stumm
- IBIS_rueck
Das Eurofare-Script kocht eigenes Süppchen und nutzt folgende:
- eurofare_vor
- eurofare_rueck
Ich habe IBIS_vor_stumm und IBIS-rueck auf das Rädchen am Lenkrad gelegt, hätte aber gerne dass wenn ich dieses benutze auch der Eurofare darauf reagiert und entsprechend schaltet. Über den Umweg G-Hub-Software ginge das mit Abfangen von Tastaturbefehlen, da hier Doppelbelegungen gehen. Würde das aber lieber Scriptseitig im Eurofare lösen, da manchmal die G-Hub-Software da zickig ist. Ich glaube aber dann behindern sich die Trigger gegenseitig zum, Beispiel wenn ich die entsprechend umbenenne oder das Drücken mit der Maus funktioniert dann nicht. Kann ich denn im Script nicht irgendwie einen Trigger basteln der dann auf den anderen reagiert? Also irgendwas a la wenn IBIS_vor_Stumm ausgelöst, dann tue so als wäre auch eurofare_vor ausgelöst. Geht das, und wenn dann wie? WÜrde mir vielleicht grundsätzlich bei den Triggern helfen, wie auch beim Rollband-Problem.
Macht irgendwie auch gar keinen Unterschied...
O405\o405_extglass.o3d scheint die Frontscheibe zu sein. Ändere ich da den Texturnamen auf einen der nicht existiert ist die Scheibe komplett durchsichtig als wäre sie nicht da.
Moin!
Mir gefallen im O405(G) Stadtbus-Addon die Spiegelungen in der Frontscheibe überhaupt nicht. Ich habe rausgefunden dass dazu die Datei o405_intenv.png verantwortlich. Wenn ich diese entferne ist auch die Spiegelung weg, aber ich möchte sie nur reduzieren, denn sonst sieht es aus als wäre gar keine Scheibe drin. In der Modelldatei kommt sie an zwei Stellen vor:
und
Wenn ich dort bei [matl_envmap] unter o405_intenv.png den Wert reduziere sehe ich aber keinen Unterschied. Gehe ich das ganz falsch vielleicht an?
Moin!
Ich wundere mich ein wenig dass bei Einsatz des Eurofare-Druckers keine Ansagen gehen. Ist das normal? In der Log krieg ich dann immer sowas:
245 17:39:57 - - Warning: Soundfile vehicles\O405\sound\..\..\Announcements\Grundorf\_#terminus.wav does not exist!
246 17:40:21 - - Warning: Soundfile vehicles\O405\sound\..\..\Announcements\Grundorf\_#terminus.wav does not exist!
247 17:40:38 - - Warning: Soundfile vehicles\O405\sound\..\..\Announcements\Grundorf\_#terminus.wav does not exist!
248 17:40:40 - - Warning: Soundfile vehicles\O405\sound\..\..\Announcements\Grundorf\_#terminus.wav does not exist!Beim Optima geht es, der ist mir aber für gewissen Einsätze in diesem Bus dann noch zu modern.
Oder kommt es auch auf die Kombi von Drucker + Matrix an? Bei mir ist es ANNAX mit dem Eurofare, also theoritisch 2x IBIS...
Edit: Hat sich erledigt, der Eurofare ist wohl tatsächlich nicht dafür ausgelegt. Hatte vorher in die falschen Scripte geschaut.
Wie ist denn die Haptik bei dem Teil? Also wie fühlt sich das ganze subjektiv an beim Spielen?
Und wie läuft das softwaremäßig? Simuliert der quasi das Drücken bestimmter Tasten?
Ich finde das Ding ziemlich interessant und überlege es zu holen. Ich würde gerne noch mehr auf die Tastatur verzichten, vor allem bei nicht universellen Funktionen, wo ich sonst zig Profile für Lenkrad- und LaWi-Konsole bräuchte.
Meine Spandau 1986er AI List (aus dem Map-Ordner):
Ende-1989er AI LIst mit der ich auch getestet habe (aus Chrono 0300):
Und hier der car_use Inhalt gezippt:
Da aber einige Fahrpläne bearbeitet sind gut möglich dass Du Fehlermeldungen in der Log bekommst weil z.B. irgendwelche Trips nicht existieren oder Fahrzeuggruppen. Zum Beispiel ist bei mir für die 54er und 94er KI ein Hof C drin.
Wie gesagt, habe immer aus dem car_use Ordner Dateien entfernt, getestet und hinzugefügt um mal zu schauen ob da was fehlerhaft ist. Im Spiel selbst waren die Zuweisungen gestern (Mai 1990) weitestgehend richtig, bis auf Linie 97 die irgendwie mit EN92 fuhr statt SDs. Aus der Beobachtung der letzten Tage weiss ich auch dass die speziellen Wochenend-Zuweisungen z.B. auf Linie 31 auch funktioniert haben. Da hatte ich gewisse Befürchtungen.
Edit:
Ich hab eine kleine Inventur gemacht und einerseits die Umläufe gezählt und dann die Fahrzeuge. Hier das Ergebnis:Fahrzeug-Inventur.txt
Da habe ich mich garantiert irgendwo verzählt und das ist auch mega unübersichtlich mit den Abgängen und Zugängen über die Jahre in den Chronos. Aber so in etwa müsste das hinhauen. Und eigentlich habe ich genügend Fahrzeuge für die Umläufe, zumal ich nur den Maximalbedarf ermittelt habe. Bei Types_Prefered können ja andere gewählt werden, und wo D und SD gleichermaßen eingesetzt werden ist ja auch Luft. Einzig bei den Eindeckern könnte es knapp werden, allerdings kommen bei mir 1990 3 bis 6 EN92 dazu, und dann passt es ja wieder. Eigentlich... 
Moin!
Das Mysterium car_use... Ich habe festgestellt dass unter bestimmten (aber schlecht zu identifizierenden) Konstellationen der car_use Dateien die Zufallsauswahl der Busse nicht oder nur eingeschränkt funktioniert. Auf Spandau habe ich ausgiebig car_use verwendet zur verteilung der Busse auf die Linien, was auf den meisten Linien gut funktioniert, auf anderen weniger. So weit so bekannt, und nervig wie immer. Aber nun noch was aufgefallen: wählte ich einen Bus zufällig aus, löschte ihn und wählte erneut einen zufälligen war es immer der gleiche: gleiche Nummer, gleiches Fahrzeug. Wenn ich dann bestimmte car_use Dateien gelöscht habe dann hatte ich die gewünschte Zufallsauswahl, oder zumindest eine Pseudo-Zufallsauswahl wo immer wieder gefühlt aus den gleichen etwa 4 Wagen gewählt wurde. Nun dachte ich da ist irgendwo ein Fehler in einer car_use Datei, aber fand da kein System dahinter. Mal die rausgenommen, dann andere, es liess sich aber nie auf eine bestimmte reduzieren. Hatte ich mal eine gefunden wo ich dachte die ist es nun, lief alles anstandslos wenn zum Beispiel nur diese drin war. Vielleicht ist ja einer von Euch dahinter gekommen woran es liegt? Ich schätze mal irgendeine Kleinigkeit wieder...
Auf Original_Spandau fällt das nicht auf, bei den wenigen Dateien im Car_use Verzeichnis. Aber so ab 10 bis 15 wird das kurios.
Und natürlich hatte ich zum Testen die Chrono abgeschaltet damit da nicht irgendwelche upgedateten AI-Listen reinpfuschen.
Hat ALU StationLinks? Da muss man schon aufpassen. Aber auch im alten System wo anscheinend nicht nur die ID sondern auch der Name zählt. Wenn dann in eibnem Chrono-Event ein anderer Name gefordert wird gibts eben Salat. Bei StationLinks muss man auch aufpassen, da ist es aber einfacher das wieder hin zu biegen.
Es ist ja auch nicht immer dass er irgendwo steht. Ich hab es erst ein mal gesehen, dachte aber die Ursache wäre eine ähnliche wie bei den HH-Bussen.
Da sind haufenweise fehlerhafte Trips in der Chrono. Möglicherweise findet er da die Haltestelle nicht, die Du berarbeitet hast. Zum BEispiel wenn Du sie umbenannt hast. oder sie aus versehen irgendwie für dieses Chronoevent ungültig gemacht hast.
Mich würd mal interessieren was Du beim AI-Bugfix bei den Hamburgern gemacht hast. Habe nämlich heute den O305G als BVG-Mod mit Vollgas im Leerlauf als KI den Verkehr blockieren gesehen, und das erinnerte mich doch arg an die Hamburger ohne Bugfix...
Nee das geht nicht, weil das eine Event nicht auf das andere anspringt. Entweder man belegt also das eine, oder das andere, und das jeweils andere geht nicht. Daher will ich das ja auf einem haben. So wie in allen Bussen der gleiche Abblendlicht-Trigger bei allen Lichtsystemen funktioniert, egal ob per Schlüssel, Schalter oder irgendein Drehding, so möchte ich es beim Rollband eben auch haben. Wie man sieht gehts ja im Prinzip, nur irgendwo ist da noch eine Kleinigkeit falsch.
Das Mausevent hat glaub ich nicht den gleichen Trigger, aber der Tastatur-Trigger aktiviert das Mausevent. So scheint es mir zumindest.
Bei der Tastatur hatte ich beide Events auf einer Taste, was sich nie behindert hat da entweder der eine oder der andere Trigger vom Bus benutzt wurde, nie beide. Bei anderen Eingabegeräten gehen aber solche Mehrfachbelegungen nicht.
Mit Maus geht, mit Maus kann ich sogar die gedrückten Knöpfe wieder rausdrücken;-)
Ja, denn der gleiche Trigger wird auch für die 3 Linienbänder benutzt, wenn die aktive Kurbel auf 1, 2 oder 3 ist. 4 Schaltet den Trigger aufs Zielrollband, im SD77 funktioniert er aber nicht weil es da eben den anderen Trigger ("_step") gibt.
Hallo!
Ich möchte die Trigger für das Ziel-Rollband vereinheitlichen, da ich für Rollband-Busse nicht zwei unterschiedliche Geräte gleichen Namens in den Inputs haben möchte. Fürs Zielrollband nutze ich die Saitek-Konsole, und wie bei Lenkrädern kann man nicht zwei Trigger auf eine Taste legen wie bei der Tastatur, und auch möchte ich vermeiden irgendwelche Umleitungssoftware des Signale zu nutzen. Anderen ist vielleicht das Problem bekannt durch die Vielzahl an Kneeling-Triggern, hier geht es ums Rollband.
In OMSI hat man prinzipiell hier zwei verschiedene Trigger:
bus_rollband_up_step und bus_rollband_dn_step wie beim SD77
und
bus_rollband_up und bus_rollband_dn wie bei O307
Letztere Variante ist die, die ich gerne universal verwenden möchte, auch beim SD77-Typ, da sie auch bei den Liniennummern zum Einsatz kommt.
Also hab ich im SD77 Rollband.-Skript folgendes modifiziert:
Ergebnis ist aber nicht zufriedenstellend, denn nach Betätigung der Taste rollt das Band dann durch, da die Taste im Bus am Steuergerät durchgedrückt wird. Es sollte sich aber so verhalten wie beim bus_rollband_dn_step und bus_rollband_up_step Trigger. Dort klappt es nämlich dass beim einmaligen Drücken der Taste das Band nur eine Position weiter rollt und beim gedrückt halten so lange rollt wie man gedrückt hält.
Was stimmt also in meiner Modifikation nicht?
In der envir.cfg gibt es ein Schlüsselwort, was regelt wann die Dämmerung startet bzw. endet. [twilight_start_end] heißt das. Eventuell könnte dort das Problem liegen. Bei mir habe ich da die Werte -7 und 7 als ganz passend herausgefunden, allerdings nutze ich selbst erstellte Himmel-Texturen. Da müsstest du mal ein bisschen herumprobieren was gute Werte für dich sind.
Ich habs mal ausprobiert mit einem Test-Save von vor paar Tagen. Es ist tatsächlich mit -7 und 7 viel besser, es wirkt aber für mich wie ein Turbo-Sonnenauf- oder Untergang. Zum Beispiel um 21 Uhr ist es noch Mittelhell, 15 Min später aber zappenduster. Beim Sonnenaufgang kurz nach 5 ähnlich. Das würde ich dann doch ein wenig glätten, aber ist schon mal deutlich realer. Also vielen Dank!
Bei mir ist das so:
Setzt die Texturen des Himmels, erst Tag, dann Dämmerung, dann Nacht:
[sky_textures]
Texture\skybox\day01.bmp
Texture\skybox\sunset01.bmp
Texture\skybox\night01.bmp
Setzt Start und Ende der Dämmerung als Höhenwinkel. Höhepunkt (letzte obige Textur
wird zu 100% dargstellt) ist dabei dann, wenn die Sonne gerade aufgeht (Höhenwinkel = 0).
Aus diesem Grunde muss der erste Wert kleiner Null, der zweite größer Null sein.
[twilight_start_end]
-18
10Da es aber wohl wie im Text steht Winkel sind sagt mir das so garnichts;-D Ich werde es aber mal mit -7 und 7 versuchen.
Ich vermute mal das regelt dann wann die 3 obigen Texturen sich überblenden, nur sagen mir die Werte garnix. Aber Uhrzeiten wären da ja auch nicht angebracht aufgrund unterschiedlicher Koordinaten.
Hab gestern gesehen dass im Code die Koordinaten gefehlt haben. Komisch, war ja Original-Spandau... Also hab ich die eingetragen und fand es dann noch schlimmer;-D Gegen Mitternacht okay, aber schon gegen 2:30 fängt es an heller zu werden. Tiefe Nacht also etwa nur 23-2 Uhr doch ein wenig kurz...
Jetzt vielleicht checken ob die entsprechende Sky Textur vielleicht zu hell ist. Das wäre zumindest eine Idee. Es ist die vom Enviroment Pack, tagsüber find ich die ja gut. Es macht aber auch einen Unterschied ob ich OMSI das Wetter herunterladen lasse oder AUXI. AUXI ist da Nachts einen Tick heller als wenn das aus ist, ein großer Unterschied ist es aber nicht und löst das grundsätzliche Problem nicht.