Beiträge von wurstbrot

So, nach langer Zeit gibt es eine Zwischenlösung. Ich hab ins init folgendes rein gemacht:

{init}
10 (S.L.DFI_Timer)
{end}

DFI_Timer in die Varlist nachgetragen und dann den ganzen Code im Frame in die Bedingung eingebaut:

(L.L.DFI_Timer) (L.S.Timegap) + (S.L.DFI_Timer) 10 >

{if}

****ursprünglicher Frame-Code hier****

{endif}

Idee ist aus dem X10-Daisy-Script und die Frametimes werden nun etwas weniger beansprucht. Ich sehe Ausschläge bei den Frametimes im Graphen, merke sie aber nicht mehr so stark wie vorher wo die Simulation immer kurz angehalten wurde. Es summiert sich aber dennoch, vor alloem wenn mehrere DFIs in der Nähe sind und verschiedene Zeilen blinken. Falls es einer performanter hinbekommt, jede Idee ist willkommen;-)

Durch die verzögerte Aktualisierung des Displays ist nun vermutlich auch der Bug weg dass manchmal sich mehrere Zeilen wild austauschen wenn die Abfahrtzeit gleich ist. Lösung bisher war in den entsprechenden Fahrplänen Sekundenbruchteile zur Abfahrtsminute zu addieren. Habs aber dahingehend nicht geprüft.

Das klingt nicht gerade danach als hätte das der Mitarbeiter ernsthaft geprüft. Eher in die Liste geschaut und als "Featurewunsch" weitergeleitet. Es ist immer noch nicht klar was da genau nun nicht gehen soll. OMSI schluckt im Prinzip ja alles was auch Windows schluckt und Rest lässt sich wunderbar umleiten , vor allem wenn es um Buttons geht. Da müsste das Ding ja ziemlich exotische Kommunikation haben um gänzlich nicht funktionieren, und es müsste explizit in den Spielen so einprogrammiert werden. Bezweifele ich ganz stark dass man das in den teils veralteten Spielen aus der Liste auch gemacht hat.

Irgendwer wird das wohl kaufen und dann wissen wir es. Ist an sich ja auch kein Ding das teil zurückzuschicken wenn es eben tatsächlich nicht geht. Es bedarf ja auch keine großen Begründung. Gefällt nicht, weg damit. So geschehen bei mir mit dem Landwirtschaftssimulator-Pack bestehend aus Lenkrad und Seitenkonsole. Das Lenkrad funktionierte technisch, was aber übel, genau wie die Pedale. Ging also alles zurück und die Seitenkonsole kaufte ich dann einzeln da sie prima auch für OMSI ist.

After a long time of using AUXI I'd like to suggest a few things AUXI could do:

1.

I think it would be a fantastic option if the traffic factor could be adjusted on the fly by AUXI depending on the current framerate. So let's say you have bad weather and OMSI struggles with fps were you normally would have no problem AUXI could reduce the traffic. But the user should be able to set the values at which fps it should be done and by which factor. Of course bad wheather could also be condition.

2.

As we all know OMSI is 32 Bit and gets into trouble when the exe gets around 3GB (WITH the 4GB Patch...) AUXI could monitor this and as an option reduce maximum timetable vehicles or/and traffic to prevent an overflow and white/black textures. A massive help would be if AUXI would be able to detect despawned busses to kick them off out of the memory just like their tour would have ended. If it is technicaly possible, AND if the vehicles would respawn again when it's time then it would bee a really massive help.

3.

I would appreciate if AUXI would detect if there are holidays on current date, so it could load another traffic profile. Also map detection woudl be cool in order to have seperate plans for different maps.

4.

I think we need the possiility to set up half-hourly profiles. I always get into the sitiation that I want a spike in the amount of passengers at 07:30, but I would have to take 07:00 or 08:00. 7 is too early, 8 too late and both would be too much.

5.

I think that is an easy one: on some maps there is no depot and as you know are the gas stations mostly bumpy and not really usable. It would be great if you just could refuel a fresh spawned new bus by AUXI. Or maybe even wash it;-)

Moin!

Ich versuche mir die Tastatur-Trigger beim NLC auf meinen Standard unmzubauen, indem ich den Trigger kw_wipermode_up fürs raufschalten des Wischer-Modus nutze und den Trigger cp_wischer_intervall_toggle zum runterschalten.

Die Modi sind:

0: aus

1: Automatik

2: Wischen langsam

3: Wischen schnell

Standardmäßig schaltet der Trigger kw_wipermode_up das ganze im Loop: bei der 3 angekommen geht es dann wieder auf 0. Das einzige was ich hier ändern will ist dass er den Loop nicht macht sondern dass bei 3 für den Trigger Schluss ist. Hier irritiert mich aber der allererste Absatz im Code und ich weiss ehrlich gesagt nicht wie ich ihn abändern muss um diesen loop zu vermeiden. Ich denke der Hund ist in diesen ersten Zeilen begraben. Jemand ne Idee:

{trigger:kw_wipermode_up}
    (L.L.cp_wischer_einaus_sw) 3 + (S.L.cp_wischer_einaus_sw) 3 >
    {if}
        0 (S.L.cp_wischer_einaus_sw)
    {endif}
    
    (L.L.cp_wischer_einaus_sw) 0 =
    {if}
        0 (S.L.cockpit_wischer_drehschalter)
    {else}
        (L.L.cp_wischer_einaus_sw) 1 =
        {if}
            1 (S.L.wiper_Automatik)
            1 (S.L.cockpit_wischer_drehschalter)
        {else}
            0 (S.L.wiper_Automatik)
            (L.L.cp_wischer_einaus_sw) 2 =
            {if}
                2 (S.L.cockpit_wischer_drehschalter)
                2 (S.L.wiper_speed)
            {else}    
                3 (S.L.cockpit_wischer_drehschalter)
                3.5 (S.L.wiper_speed)
            {endif}
        {endif}
    {endif}
    (T.L.ev_Wischerdrehschalter)
{end}

Wenn das ganze läuft dann geht es an den zweiten Trigger der das ganze in umgekehrter Richtung macht, also von 3 bis 0, ebenfalls ohne Loop.

Kommt auch vor dass sie an der zweiten Haltestelle Pause machen... Das hatte ich aber auch schon bei Tracks and Trips, und ich weiss nicht mehr wie ich das gelöst habe.

Das mit der Kachel ist wohl das was ich auch beobachte. Ich kann mir zig Anschlüsse anschauen und alle funktionieren. Komme ich aber selbst mit einem Bus da an ist die Chance da dass einer der Busse vorher los fährt.

Übrigens: das "wait until" ohne "always" hat den Haken dass wenn mal keiner aussteigen oder einsteigen will der Bus dann NICHT abwartet. Er wartet nur wenn er eh anhalten muss.

Geisterbusse kann man auch schön auf Vanilla-Spandau beobachten. Nachts am Depot tummeln sich zig Busse rum, aber auch sonst sieht man sie gerne auf der 92 / 137. Hinzu kommt dass die StnLinks derart unzuverlässig sind, dass man oft an der Stadtgrenze keinen Kollegen sieht, obwohl im 10min Takt da immer wer stehen müsste. Und pausiert man am Reimerweg sieht man gerne eine 92 / 137 aus Richtung Stadtgrenze kommen und an der Kreuzung verschwinden. Der Wagen kriegt es nicht von vom Hin- auf den Rücktrip zu wechseln. All das löst man mit klassischen Trips & Tracks.

Ich würd Dir trotzdem einen Umbau auf klassische T&T empfehlen. Allein schon wegen den Geisterbussen bei StationLinks die völlig außerfahrplanmäßig rumfahren und man sich fragt wo sie denn her kommen.... Und anderer Bugs.

Moin!

Ich beobachte auf Splines mit zwei oder mehr Spuren in die gleiche Richtung dass die KI manchmal beim Spurwechsel erst in die andere Richtung blinkt und dann erst in die Richtung des Spurwechsels. Das ist doch unschön und nervig und ich würde das gerne beseitigen. Meine Vermutung ist dass dies bei gemirrorten Splines passiert, aber zu 100 Prozent bin ich mir da noch nicht sicher. Kann dies jemand bestätigen?

Wie könnte man sich da behelfen? Leider kann man den Spurwechsel selten verbieten, da die Funktion "Überholen verboten" meistens nicht funktioniert.

Das Häkchen bei "mirrored" wegmachen würde die Richtung der Pfade umdrehen. Wie könnte ich ohne den Splinezug neu zu verlegen mir da behelfen?

Ich habe auch ähnliche Probleme. Habe einen Zentralanschluss abends und hab immer wieder Busse gesehen die vorher losgefahren sind. Das seltsame dabei war dass wenn ich mir die Situation aus der Nähe angeguckt habe dann funktionierte alles. Kam ich aber selbst mit einem Bus da hin begegneten mir hin und wieder Busse die zu früh da los sind. Habe auch alles geprüft und auch die verschiedenen Bustypen untersucht, konnte aber überhaupt keine Gesetzmäßigkeiten feststellen. Nur dass es anscheinend beim Spawnen aus der Ferne eher Schwierigkeiten macht als wenn man sich vor Ort hinstellt und die ganze Anschlussprozedur beobachtet.

Übrigens: Alles klassische Trips und Tracks, keine StationLinks.

Zitat von DerErzbusfahrer

Das liegt einfach daran, dass die Achsen so definiert sind, wie die Achsen definiert sein sollten. Bei vielen Nachläufern, z.b. Alterr oder Helvete Citaro liegen die Drehpunkte des Nachläufers ca 30-50 cm vor der Hinterachse. Beim NLC hingegen liegen die Drehpunkte immer auf den Achsen. Wendekreise sind außerdem auch penibel angepasst wurden. Auch der längere Nachläufer beim NLC sollte beachtet werden, auch der kürzere Vorderwagen des 18C sollte dabei beachtet werden.

Das könnte es erklären. Ich meine mich aber zu erinnern dass schon der MAN NG 272 aufgrund irgendeines Bugs Probleme mit dem Nachläufer hatte. Es gab da auch zig Mods für, und ich vermute um das zu umgehen hat Alterr da getrickst. Ich weiss jetzt nicht wie es beim Stadtbus-MAN ist, den habe ich zwar massiv in der KI aber fahre den irgendwie nie selber. Der "Mainzer" Lion City verhält sich aber ähnlich wie der NLC, auch was seine enorme Anfälligkeit für Schlaglöcher etc betrifft. ALlerdings wie ich schon sagte, die 12m-Varianten sind auch alles andere als frei von der Problematik, dahe rnehme ich an dass es eben nicht nur an den Achsen beim Nachläufer liegt. Gestern bin ich mit dem NLC Solo über einen von mir verhasstebn Kreisverkehr gefahren, um den ich mit KJ O530(G) oder MX200-C2(G) mittlerweile sehr gut rum komme, Mit den MANs keine Chancen ohne den Bordstein rechts hinten mitzunehmen. Mit viel Übung könnte es mit dem Sol,o-NLC vielleicht mal klappen...

Ja, sieht so aus. Und da hängt auch nix drunter denk ich. Eventuell was mit den Rädern? Oder doch die Fahrphysik an sich?

Das kann sein dass das eine Rolle spielt. Es ist aber auch schon beim Solo zu beobachten dass auch dieser an mehr Stellen Schwierigkeiten hat. Hinzu kommt dass die Fahrgäste viel mehr auf Unebenheiten in der Straße mit Gemaule reagieren, daher dachte ich an die Boundingbox oder generell die Kollisionsabmessungen, auch nach unten hin. Kenne mich da aber leider nur schlecht aus.

Obwohl der NLC an sich doch gar nicht so anders ist von den Abmessungen her wie andere Busse merke ich immer wieder, insbesondere beim Gelenkbus, dass man doch um einiges schlechter um gewisse Ecken kommt wie andere Busse. Das merkt man an engen Kurven wo man fast immer den Bordstein mitnimmt und mit anderen Bussen eigentlich ganz gut rum kommt. Mich würd mal interessieren was dafür verantwortlich ist, denn wie gesagt Abmessungen sind nicht sind ja mehr oder weniger Standard, der Wendekreis eigentlich auch in Ordnung. Boundingbox vielleicht?

Nicht funktionierende Tasten wäre nicht schlimm, da gäbe es zig Tools zum Umsteuern auf Tastatur-Befehle. Macht bei OMSI eh Sinn, da gefühlt jeder Bus seine eigenen Trigger nutzt und ich glaube kaum dass irgendjemand Lust hat sich zig Profile anzulegen. Entscheidend ist ob die Achsen korrekt funktionieren und das Force Feedback.

Moin!

Auf der Suche nach passenden S-Bahnen für die RMV Linien S1 und S9 bin ich auf den 422 aus dem Düsseldorf-Addon gestoßen. Ich erinnere mich dass ich den vor zig Jahren auf ALU im Einsatz hatte und der sich eigentlich ganz gut gemacht hat. Nun ist er aber grün lackiert und ich finde keine passenden Repaints in DB-rot. Gibt es denn da welche? Oder gibt es das Fahrzeug eventuell in anderen DLCs passend lackiert?

430 wäre da natürlich noch besser, aber ich wüsste nicht dass es eine für OMSI gibt.

Zitat von BusfahrerP

Obiges Beispiel vom Hst-Schild lies sich noch recht einfach per Beschriftung klären, ich denke auch, dass in der Realität mit einem Art von Template gearbeitet wird, dass alle Schilder gleich werden.

Ich hab das noch nie in OMSI irgendwo gesehen, dachte aber bei der ein oder anderen Karte dass es eben an den Endhaltestellen cool wäre den aktuellen Haltestellenfahrplan im Spiel anschauen zu können. Hab es auch nicht ausprobiert, nehme aber mal an dass es ab 4096er Textur durchaus ginge. Wäre aber vermutlich nur auf dörflichen Strecken praktikabel wo relativ wenige Busse fahren und die OMSI-exe nicht zu sehr anschwillt. Bei sowas wie X10 bräuchte man es wohl erst garnicht probieren.

Ich finde das obere Bild mit den Fahrplänen hat ausreichende Qualität, das untere erscheint mir zu verwaschen. Ich gebe aber zu bedenken dass bei der Verwendung von individuellen Einzeltexturen pro Haltestelle den Speicherverbauch nach oben treiben wird, exponentiell mit der Qualität. So kommt man dann auch nahe der 3 GB Grenze zusammen mit einigen anderen Individualitäten wie besonderen Repaints etc.

Und wenn Du schon so weit gehst das so zu machen, dann kannst Du an den Endhaltestellen oder Zwischenendhaltestellen für die Fahrpläne die Auflösung so hochschrauben dass man sie auch lesen und als Spieler nutzen kann. Wenn schon denn schon... Aus oben genannten Gründen würde ich das aber trotzdem nicht empfehlen.

Zitat von BusfahrerP

Innenanzeige ist schwierig, da die mit mehreren Textfeldern in einer o3d und mehr Funktionalität (Größe, Wechsel zu Linie...) ausgestattet war, was im alten Druckerscript steht.

Ich habe einen recht statischen Monitor drin, der auf die IVU-Strings zugreift, deren Text Texturen ich auf 101+ gelegt habe.

Was du machen kannst ist, einen Innenanzeigen String auf 101 legen und bei der Innenanzeige die useTextTexture auf 101 und fort folgende anpassen. Dann solltest du einen IVU gespeisten Innenanzeigentext bekommen, die anderen Textfelder greifen auf nicht existierende Text Texturen 102 und so weiter zu die dann leer bleiben.

Ja, da überlappen sich dann alle Varianten. Bei Deiner vorgeschlagenen Lösung müsste man ja sicherheitshalber die kleinste nehmen, was dann auch wahrscheinlich komisch aussieht. Vielleicht macht es dann mehr Sinn die ganze Anzeige rauszuschmeißen und mit einem TFT Monitor auszustatten, was meiner Meinung nach eher besser zum Bus passen würde. Was hat sich denn da als gut handelbar mit der IVU Box erwiesen?

Im übrigen hab ich im KJ O530 die Innenanzeige auch nicht zum laufen gekriegt. Hat es bei jemand geklappt?

Moin!

Um beim MAN NLC einen Einstieg an Tür 2-4 und einen Ausstieg an Tür 1 zu ermöglichen habe cih mir das Script angepasst und nun bin ich an den Pfaden. Scripttechnisch war es bis jetzt keine große Sache und funktioniert auch wie gewollt was das betrifft. Bei den Pfaden hat mich aber gewundert dass die Aussteiger an Tür 1 vor der Tür warten mit Blick nach innen. Warum machen die das? Im O530 von KJ ist dies ab Werk ja möglich und da glotzen sie nach aussen. Die Pfadpunkte haben ja auch keine Richtung wie zum Beispiel die Sitz-/Stehpositionen. Zufällig hab ich das aber auch an der zweiten Tür gesehen, und da ist ja ein Ausstieg ab Werk vorgesehen.

Ich dachte schon dass da die Pfade selbst das Problem sind da es keine Oneway-Pfade sind, der O530 hat allerdings auch keine und da funktioniert es.

Ich würd das gerne lösen, da ich das analog auch in anderen Bussen gerne hätte.

Edit: ich hab mir mal in Blender die Pfade beim 2-Türer 12C angeschaut und das sieht eigentlich ganz normal aus. Sie ergeben Sinn.

Zitat von IREgio612

Bin gerade nicht am PC, aber das waren glaube lediglich die Unterstriche die den Unterschied machten. Also alle „door_“ im IVU Script durch „door“ (ohne Unterstrich) ersetzen.

Danke, das war die Lösung. Einfach stur alle 27 "door_" mit "door" ersetzt und nun passt alles.