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!
-
Auch nach dem heutigen Update leuchten die Beschriftungen am Heck des Gelenkwagens mit dem Innenlicht:


Das ganze ist unabhängig vom Repaint und tritt nicht bei den Solos auf. In meinem Beispiel dürfte nur "Air Conditioned" leuchten, nicht aber Citaro, Sippel und Mercedes Benz.
-
Ich hab beim Rheinhausen-Repaint gemerkt dass die Setvar vis_CTI_Front beim 12C irgendwie nicht funktioniert. Sie müsste beim Wert 0 oder beim Weglassen eine schwarze Front darstellen, sie zeigt aber das Repaint, so wie es beim Wert 1 sein müsste. Bei vielen Repaints fällt es nicht auf, da sie an dieser Stelle eh schwarz sind, im Falle von RHeinhausen ist dies aber nicht so. Übrigens auch ein Umstellen im Setvar-Monitor ändert da nix. Im 18C funktioniert das ganze einwandfrei, egal ob per CTI Datei oder mit dem Boardgerät. Für 10C und 19C nicht getestet.
-
Informationen zur Entwicklung über Discord zu verbreiten ist, als hätte er es bei OMSI damals in einer ICQ-Gruppe getan... wozu hat man ein offizielles Forum?
Bei OMSI damals gabs keine Informationen. OMSI war irgendwann da, und vorher gab es einfach nur 2 Videos. Das war's.
-
Ja, die Funktion kenne ich. Die Wahrscheinlichkeit ist aber die gleiche für alle Gruppen und abhängig von den Einstellungen in den Optionen und (vermutlich) der Tageszeit. Allerdings für alle Gruppen gleich. Und ich brauche Dummys um diese Wahrscheinlichkeit dann optisch zu reduzieren. Es würde also eine weitere Parkgruppe angelegt werden die dann parkende Autos enthält und eine gewisse Anzahl an Dummys. Ich stelle mir das so vor dass wenn ich genauso viele Dummys da reinschreibe wie Autos dann hätte ich die Wahrscheinlichkeit um die hälfte reduziert.
Eine weitere Sache die ich als nächstes dann angehen würde sind verscriptete Parking Slots. Damit würde ich gerne zum Beispiel Supermarkt-Parkplätze Sonntags, Abends und Nachts ausdünnen. Sowas in der Art gab es von Zane in Rheinhausen für die Falschparker, ich habe aber leider den Eindruck dass das Script da nicht so funktioniert wie er es sich gedacht hat.
-
Moin!
Ich würde gerne eine parked cars Gruppe anlegen, die mit deutlich geringerer Wahrscheinlichkeit parkende Autos spawnt als in den Optionen festgelegt. Dazu bräuchte ich einen unsichtbaren, kollisionsfreien Dummy, am Besten mit fast keinen Polygonen als .sco Objekt um damit die parklist zu füllen. Zunächst habe ich da fOcUs04 seinen Dummy eingefügt, aber der funktioniert anscheinend nur in der ailist. Die Folge waren diverse Fehler wie abgeschaltete Ampeln etc. Also würde ich das mit einer Alternative versuchen. Gibt es da was? Ich könnte mir transparente Würfel oder Flächen bauen und die entsprechend konfigurieren, aber vielleicht gibts das ja schon?
Viele Grüße
wurstbrot
-
Könnte man nicht den Falkenseer Bereich von Spandau M&Z nutzen?
Der ist ja etwas Modernisiert worden.
Ich glaube das wäre keine gute Idee. Die Version von M&Z ist noch aus OMSI1 Zeiten als Grundlage, Falkensee wird also nicht auf Geodaten beruhen sondern ein Anhängsel an die alte OMSI1 Karte sein.
-
Ich möchte hierzu anmerken dass der Rheinhausener TW6000 fast das gleiche Problem hat. Nur wackelt dieser nicht beim Richtungswechsel, sondern schildert einfach um und rührt sich dann eben nicht vom Fleck. Auf unveränderter Rheinhausen-Map (V1.2) wird man das aber nicht beobachten, da die Trips an den Kehrstellen in Herrenholz und Neundorf kein Haken bei "reversed" haben. Da findet dann eben ein Despawn statt.
-
Und nicht aus versehen im Alt-Menü die Lenkradsteuerung deaktiviert?
-
Auf Rheinhausen hab ich festgestellt dass bei mir im KJ O530 die Problematik besteht dass die Linien-Suffixe nicht an die Matrix übergeben werden.
Der Eintrag
0031_0902_15_002
müsste ja Linie "N2" ergeben, auf der Matrix taucht aber "902" auf. (Beim C2 mit DGM Matrix übrigens "N02"...)
Es gab ja mal mit dem letzten Update die Problematik dass gar keine Linie übermittelt wurde, was dann dank eines Tipps hier behoben wurde. Das müsste hier in diesem Abschnitt passieren, auch dann für die anderen Positionen:
{macro:IVU_Route_waehlen_Pos_1}
(L.$.IVU_Routendaten_1_Stunde) $StrToFloat 60 * (L.$.IVU_Routendaten_1_Minute) $StrToFloat + (S.L.IVU_Routendaten_Uhrzeit)
(L.L.IVU_Route_1_Linie) (S.L.IVU_eingegebene_Linie)
(L.L.IVU_Route_1_Suffix) (S.L.IVU_Suffix)
(L.L.IVU_Route_1_Fahrt) (S.L.IVU_eingegebene_Fahrtnummer)
0 (S.L.IVU_manuelles_Ziel) (S.L.IVU_HST_pos)
1 (S.L.IVU_ITCS_Auswahl_Korrekt)
2 (S.L.IVU_TB_Modus)
(L.L.IVU_manuelles_Ziel) 0 =
{if}
"" (L.L.IVU_eingegebene_Linie) 100 * (L.L.IVU_eingegebene_Fahrtnummer) + (M.V.GetRouteIndex) (M.V.GetRouteTerminusIndex) (S.L.IBIS_TerminusIndex)
{else}
(L.L.IVU_eingegebenes_Ziel) (M.V.GetTerminusIndex) (S.L.IBIS_TerminusIndex)
{endif}
(L.L.IVU_eingegebene_Linie) (S.L.IBIS_LinieKurs)
(L.L.IVU_eingegebene_Linie) $IntToStr (S.$.IBIS_LinieKursSpecial)
(L.L.IBIS_Linie_Suffix) (S.L.rg_IBIS_Linie_Suffix)
{end}
Alles anzeigen
Wenn mich nicht alles täuscht übersetzten die letzten Zeilen die Linie für die Matrix. Stimmt da vielleicht was nicht dass der Suffix ignoriert wird?
Übrigens müssten laut HOF Datei 900er Liniennummer (wie in Spandau) eh automatisch ein "N" ergeben. Das ignoriert aber die IVU sowieso, oder?
-
wenn du immer wieder microruckler, nachladehänger etc hast.
Die resultieren aber häufig auch auch nicht optimiertem Content, z.B. schlecht gescriptete Innenanzeigen in Bussen oder Objekte mit falschen Texturformaten. Nachladehänger kann man deutlich reduzieren, wenn man einfach sauber arbeitet. Was man OMSI an der Stelle vorwerfen kann, ist die empfindliche Reaktion auf Pfusch.
So ist es. Und wenn man hier mit unoptimiertem Content arbeitet wird man immer Probleme haben, ob bei 30 oder 100 fps. Eine AI Liste mit 30 verschiedenen Bussen ohne spezielle KI-Versionen wird Dir immer den Spaß versauen, genauso wie schlecht optimierte Scriptobjekte die alle x Millisekunden irgendwas abfragen oder die Log vollspammen. Wenn man das aber im Griff hat ist es schon ein Riesenunterschied ob man mit 30 oder 120 fps fährt. Und genau in diesen Szenarion würzt Frame Generation das ganze nochmals enorm. Ja, auch ich würde gerne in die AI List alles reinknallen wollen was ich habe ganz ohne optieren und basteln. Aber das geht alleins chon mal wegen 32 Bit Grenze nicht, denn dann ist eh nach kurzer Zeit Sense. Und DAS ist das Hauptproblem von OMSI.
-
Hat auch viel mit der Hardware zu tun 
Auf jeden Fall. Aber sicher spielt keiner mehr auf Hardware von etwa 2010. Wenn man tatsächlich unter 30 fps ist dann muss man schon nicht nur ein älteres System haben sondern auch einiges falsch machen. Von 30 auf 60, 90 oder 120 kommt man dann mittels Frame Generation, theoretisch sogar (aber mit Einschränkungen) von den erwähnten 10 als absolutes worst case. Bisschen was sollte man aber unter der Haube als Grundlage haben.
-
Wenn man bedenkt wie alt OMSI ist dann muss man schon sagen dass OMSI definitiv erfolgreich ist und sich bisher gegen alles Neue behaupten konnte. Das Programm ist über 10 Jahre alt. Das ist quasi wie im Jahr 1995 noch die erste Version vom Flugsimulator zu spielen 
Die einzige Krücke die wir noch haben ist die 4 GB Grenze. Für Frameraten etc gibt es ausreichend gute Lösungen sodass keine mehr irgendwo mit 30 fps rumdümpeln muss.
-
Was konkret ist im Bundle dabei?
-
Ja grün ist er glaub ich, nicht blau.
-
Bisher hab ich da nichts diesbezüglich gemacht, und ich meine in die Model.cfg hab ich auch nicht reingeschaut. Aber stimmt, das müsste man um einen Trigger zu erstellen. Offensichtlich gibt es diesen ja nicht für den blauen Taster, nur für die andere Variante. Am komfortabelsten wäre es ja wenn man für beide Varianten den gleichen Trigger nutzen könnte.
-
Es geht ihm glaub ich darum dass beim MX C2 OMSI abschmiert wenn man OMSI nach einer Fahrt beendet. Dieses Phänomen wegen zu langer Scripts.
-
Das Problem kann ich zum Teil bestätigen. Das betrifft die Türfreigabe. Die ist nach dem neuladen der Situation etwas verbugt/verdreht. Die einzige Lösung: Bus neu spawnen und in Zukunft drauf achten, die Türfreigabe beim beenden von OMSI zu deaktivieren! 
Ich glaube es ist die Haltestellenbremse um es genauer zu sagen (somit natürlich auch die Türfreigabe). Das Problem hat man aber auch wenn die Haltebremse drin ist, also auch die ohne Türfreigabe und die mit Komfortfunktion. beim Speichern also immer gucken dass NUR die Feststellbremse aktiv ist.
Ich wüsste auch nicht wie man die aufgehängte Bremse wieder löst.
-
Heute mit Museumswagen in Mainz unterwegs. Zunächst ein morgendlicher Verstärker auf der 68 und anschließend ohne Fahrplan Verstärker zwischen Innenstadt und Uni. Und trotzdem angepflaumt worden wegen Verspätung... 

Leerfahrt zum Lerchenberg.

Dann auf 68/22 zur Rheingoldhalle.


Danach ab Kastel freie Verstärkerfahrt Richtung Uni.

Vorletzte Fahrt ging von der Uni zur Bauhofstraße, und Anschließend noch zurück zum Hauptbahnhof.
Map: Mainz
Bus: O305G
-
Die müsste zu jeder Zeit fahren. Es gibt aber Mitte 2015 einen Fahrplanwechsel. Hab aber nicht im Kopf ob das von Bedeutung ist für die N4.
Im Handbuch findest Du nichts darüber da die N4 und die Wochenendliche Ringlinie später dazu kamen. Vielleicht gibt irgendwo Changelogs wo da mehr steht.
-
Genau. Ich würd nur bei denen mit Schaufenstern schauen ob man die als 1024er oder was auch immer die haben lässt, denn das ist doch schon recht markant, im Gegensatz zu irgendwelchen leuchtenden Schlafzimmerfenstern...