Beiträge von wurstbrot

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

Zitat von Strange4high

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}

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?

Zitat von Perotinus

Zitat von Theproloser

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.

Zitat von FD-UB 501

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.

Zitat von IREgio612

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...

Zitat von fLoMsi

Blöde Frage aber wo finde ich die Night-Texturen und welche genau sind das?

In Sceneryobjects\Aachen\Texture\night

Erkennen tust Du die am Aussehen: ganz dunkel mit hier und da Licht Aber in dem Verzeichnis ist es nur Nighttexturen. Zum Testen kannst ja Kopien anlegen und mitd er Endung _#low vor der Dateiendung versehen (Beispieltextur_#low.dds). Die werden dann aktiv wenn Du in den Optionen LowRes Texturen aktivierst.

(Diese Option nutzt übrigens nix wenn eine Karte oder ein Bus keine _#low-Texturen hat. Außer Spandau nutzt das aber kaum wer, trotzdem liest man immer wieder über die Wundersamkeiten die diese Option so allgemein bringen soll )

Zitat von fLoMsi

Also von der Performance her ist die Karte ja die reinste Katastrophe!! Da können meine Einstellungen noch so sinnvoll und meine neue Festplatte noch so schnell sein. Außerhalb vom Zentrum gehts ja noch aber innerhalb und vor allem Nachts (Beleuchtungen ziehen ja auch nochmal Performance) tun einem schon echt die Augen weh.

Ich glaube die Night-Texturen sind nicht optimal. Ich hab da vor langer Zeit mal Hand angelegt und es hat einiges gebracht. Wenn ich mich recht entsinne habe ich die Auflösung der Night-Texturen auf die Hälfte reduziert, außer da wo Schaufenster sind. Es gab aber auch einige sehr unoptimale. Ich weiss abe rheute nicht mehr ob die auf meiner Platte aus einem Update stammen oder meine Varianten sind.

Und ich nehme mal an Du meinst nicht Festplatte sondern SSD. Allerdings braucht man sich keine Illusionen zu machen, fast jede heutige SATA-SSD ist für OMSI ausreichend. Der Flaschenhals ist mittlerweile OMSI selbst. Daher verbessert sich das Nachladen nur noch mit schnelleren Prozessoren. Dass die SSD ins Schwitzen käme dazu müsste man erstmal eine so schnelle CPU finden oder OMSI umprogrammieren;-D

Moin!

Da ich mein System neu installieren musste hatte ich das zweifelhafte Vergnügen mich mit der GHUB-Software wieder rumzuschlagen. Der erste Versuch brachte das Ergebnis dass mein G29 in OMSI die Zentrierfeder nicht angesprochen hat und nur ein Mini-Force Feedback geliefert hatte, und das egal bei welcher Einstellung sowohl in OMSO als auch im GHUB. Es war immer das gleiche: im GHUB war das Lenkrad manchmal so fest wie ein Stein, im OMSI dann total ohne irgendwelche Kräfte. Unspielbar.

Hab dann auf eine ältere Version des GHUB gewechselt, hier ging es dann. Hab ein gutes Force Feedback und die Zurückstellung des Lenkrads klappt auch. Das Lenken ist mir aber hier noch etwas zu hart. Dummerweise ist es auch hier so dass jegliche Einstellungen in OMSI dazu nichts verändern, ebenso nicht die Eistellungen der GHUB Software. Ob 10 oder 100%, ob Häkchen gesetzt oder nicht, nichts verändert sich. Somit funktioniert auch diese Version des GHUB nicht korrekt, wenn auch besser als die neuste. Einfach für die Tonne diese Software.

Die Idee wäre nun die alte "Logitech Gaming Software" zu installieren und den GHUB rauszuschmeißen. Aus Erinnerung habe ich aber im Kopf dass diese Software das Steuerkreuz des Lenkrads nicht erkannt hat Vielleicht kann ich das aber mit JouToKey ansteuern. Ich meine mich aber zu erinnern dass auf meinem vorherigen Rechner die OMSI-Einstellungen sehr wohl Auswirkung hatten auf die Kräfte.

Daher würde mich mal interessieren ob jemand mit dem G29 in OMSI mit der alten Logitech Gaming Software unter Windows 11 fährt und wie es sich da so verhält. Funktioniert da auch das Steuerkreuz?

Zitat von ma7t3

Ein Ähnliches Problem sehe ich auch noch bei den Linienwegangaben ("via xy").

Grundsätzlich versuche ich eben immer, dass die meist vorkommende "Standardroute" einen möglichst kurzen Namen hat. Wenn beispielsweise im Normalfall ein direkter Linienweg gefahren wird und nur zeitweilig noch ein Schlenker mitgenommen wird, ist es recht klar. Da heißt die Hauptfahrt dann einfach 001_AAA-BBB und die mit Schlenker 001_AAA-BBB_vCCC.

Ein Problem hat man dann allerdings, wenn die Schlenkervariante die Standardfahrt ist.

Ich erinnere mich, mal einen Trip 21_NSW-KSM_oHTS genannt zu haben, für "von Nordspitze, Warthersee nach Kaisersee, Markt aber ohne (bzw. "nicht über" Herzt, Schule), da die Fahrt über die Schule eigentlich der Standardfall war und diese kleine Stichfahrt nur spätabends weggelassen wurde. Ich halte es rückblickend aber auch eher für verwirrend und würde es jetzt so nicht mehr machen.

Da hast Du recht. Auch hier muss man je nach Karte entscheiden was mehr Sinn ergibt. Ich tendiere es bei Abweichungen vom Standard anzugeben, würde aber bei fest eingetakteten Varianten tagsüber das vielleicht grundsätzlich dann angeben. Da hatte ich übrigens gelernt Umlaute zu meiden. Hatte mal ein "_ü" drin für "über" und es gab Probleme. Heute vermute ich aber dass sich da die .ttl Datei einfach von ANSI auf UTF8 umgestellt hat und da kriegt OMSI Schluckauf.

Zitat von ma7t3

Für Außenstehende mag diese ganze Diskussion und diese Überlegungen eh etwas absurd klingen, da kann ich mich aber wirklich extrem hieinsteigern, wenn ich will.

Ja. Wer aber jemals was umfangreicheres an Fahrplänen gebaut hat oder gar Trips und Tracks erstellt hat der wird Dir bei fast jedem Punkt zustimmen. Ebenso wenn man als Team mal an etwas gemeinsam geschafft hat. Wenn man alleine für sich nur eine Linie bei einer Karte wie Grundorf einrichtet dann ist das alles tatsächlich irrelevant.