Posts by cshw89

    Ich bin bisher den X10er immer nur mit dem DL gefahren, wollte aber nun mal den AGG dort probieren. Dabei wurden aber keine Ansagen abgespielt. Im logfile stand, der Bus sucht z.b. die Datei "vehicles\HH_Doppelgelenkbus\sound\..\..\Announcements\X10 Berlin\Olivaer Platz.wav". Ein Blick in den Ansagen-Ordner zeigte mir aber, dass alle wav-Dateien den Präfix "Tel_" noch zusätzlich im Namen haben. Ich könnte natürlich nun alle wav-Dateien kopieren, und den Präfix löschen. Gibt es da vielleicht eine andere Möglichkeit/Trick, um die Ansagen auch in anderen Bussen abspielen zu können? Warum haben die Dateien eigentlich diesen Präfix?


    lg Kevin

    Nun habe ich mir heute den AGG auch geholt, und ich muss sagen, ist wirklich ein sehr schöner Bus geworden. Er ist schön modelliert, lässt sich gut bedienen und fahren.


    Zur Performance: nach den negativen Kommentaren hier zu Anfang, dachte ich mir, versuchst du mal direkt ein Stresstest: X10, Zoo, 07:00 morgens, bei meinen normalen, nicht wirklich niedrigen Einstellungen. Die Betriebsfahrt zum Zoo verlief noch halbwegs ohne Probleme. Doch bei der ersten regulären Fahrt war ziemlich schnell Schluss: ein hüpfender AGG, der sich auch nicht mehr einfangen lies. Dazu muss man aber auch sagen, ich fahre den X10er sonst immer nur mit dem DL, also nicht mal mit einem Gelenkbus. Der AGG besteht ja quasi aus drei Bussen.
    Also zweiter Test, gleiche Umgebung mit etwas niedrigeren Einstellungen (2 statt 3 Nachbarkacheln und 40 statt 100 KI-Fahrzeugen). Und siehe da, der Bus fuhr nahezu butterweich am Zoo vorbei. Auch während der Fahrt gab es keine Probleme mehr.


    Ein Punkt der mir auffiel: es wurden keine Ansagen abgespielt. Nach einem Blick ins logfile und in den Ansagen-Order denke ich aber, es liegt eher am X10-Addon. Die wav-Dateien haben nämlich alle den Präfix 'Tel_', der im logfile nicht angegeben ist. Da müsste ich vermutlich mal im Support-Thread vom X10 nachfragen.


    Zwei Punkte haben mich etwas irritiert, die aber vermutlich der Realität entsprechen. Erstens das Display zeigt die Türen von rechts nach links an, rechts wird also die 1. Tür angezeigt. Ist meiner Meinung nach nicht intuitiv. Zweitens die 2. Tür geht automatisch zu. Ich dachte eigentlich, sie würde komplett vom Fahrer gesteuert. Zumindest dachte ich, ich hätte das so in Aachen beobachtet. Es kann natürlich sein, dass dies in Hamburg anders ist. Wie gesagt, wenn es der Realität entspricht, sind dies natürlich keine Kritikpunkte (der erste Punkt höchstens an Van Hool :P).


    Nun möchte ich noch ein letzten Punkt ansprechen: das Fahrverhalten. Insgesamt lässt sich der Bus sehr geschmeidig fahren. Allerdings gefällt mir das Verhalten in Kurven nicht zu 100%. Leider gibt es ja bisher kein Gelenkbus in Omsi, der sich wirklich realitätsnah verhält. Sagen wir mal, rechts neben dem Nachläufer eines Gelenkbusses steht auf dem Gehweg eine Mülltonne in ca. 10-15cm Entfernung. Bei komplettem Einschlag nach links nimmt eigentlich kein Bus in der Realität die Mülltonne mit. In Omsi passiert das leider mit jedem Gelenkbus, selbst bei halbem Einschlag. Der Nachläufer drückt immer etwas nach außen, und die hinteren Reifen rutschen über die Straße.
    Das Interessante beim AGG ist jetzt, hier passiert genau das Gegenteil. Die beiden Nachläufer drücken nach innen. Vielleicht könnte ja Darius oder jemand anders, der für die Scripte verantwortlich ist, mal erklären, was für das Fahrverhalten unternommen wurde. Möglicherweise könnte man ja daraus einige Rückschlüsse ziehen, um die goldene Mitte zu finden. Davon könnten ja auch andere Gelenkbusse profitieren.
    Auch wenn Van Hool damit wirbt, dass der AGG sehr spurtreu fährt, in der Realität holen die Fahrer doch noch sehr weit aus bei Rechtskurven. Der hintere Nachläufer fährt eine Kurve doch noch ein Stückchen enger als der Vorderwagen. Allerdings ist dieser Effekt in Omsi deutlich stärker. Ich muss aber sagen, das ist mir dann doch noch lieber, als manch ein Gelenkbus. Wenn man bei manchen Gelenkbussen eine Rechtskurve mit vollem Einschlag fährt, steht man mit dem Nachläufer plötzlich zur Hälfe auf der linken Spur (und ich meine damit die Straße, aus der man gerade kommt).


    lg Kevin

    Ein Zitat aus dem Eröffnungspost im Thread:


    Zwischenzeiten setzen kann man in den Zeitprofilen durch Anklicken der makierten Check-Boxen:


    lg Kevin


    PS: ich glaube in Omsi 2 gibt es ganz oben zwei Check-Boxen für alle Haltestellen. Dann muss man nicht für jede Haltestelle einzeln setzen.

    Stimmt, in Freeware-Bereich gibts ein paar gute Beispiele. In Römerberg z.b. wurde es auch am Schulzentrum umgesetzt. Dennoch gibt es pro Linie oft nur zwei Trips (Hin und Rück) und jeweils genau ein Zeitprofil. Mehrere Zeitprofile für verschieden starken Verkehr wäre oftmals ja schon ein Segen.

    Da gebe ich dir zwar auch recht, aber leider bietet OMSI meines Wissens keinerlei Möglichkeit, das Fahrgastaufkommen für einzelne Haltestellen je nach Wochentag und/oder Uhrzeit zu beeinflussen. Man kann nur einstellen, ob an einer Haltestelle generell viele oder wenige Leute einsteigen und aussteigen (dies jedoch voneinander getrennt). Das allgemeine Aufkommen wird dann nur noch vom Hauptprogramm geregelt, wenn ich mich recht erinnere.
    Gerade so eine Ecke wie der Campus, wo nachts und am Wochenende praktisch nichts los ist (weil da nur Institute sind) und Mo-Fr tagsüber recht viel, ist in OMSI also nicht umsetzbar.

    Oh doch. Mit mehreren Buswürfeln und Fahrplänen wäre da durchaus einiges möglich, siehe X10-Addon. Leider geben sich in dieser Hinsicht, kaum Addon-Ersteller viel Mühe, und machen oft nur das nötigste für den Fahrplan. Da ist X10 sicherlich konkurrenzlos (im Payware-Bereich). Aber um mal das Thema von Tatra nochmal aufzugreifen. Jeder hat halt andere Prioritäten für ein (gutes) Addon.


    lg Kevin

    Hallo Leute,


    also ich bin der Meinung das jeder das Spielen sollte was Ihm auch Spaß macht,die anderen sollen doch Ihre Ballerspiele spielen was ich nicht für Realitisch halte weil es immer nur ums Töten geht. Die sollen nur froh sein das wir keinen Krieg haben dann würden die solche Spiele auf Ihren PC erst garnicht installieren.
    Aber das sind dann Die dann Amoklaufen was man sehr oft hört da finde ich OMSI2 noch am besten weil man sehr viel über Busse erfährt, sollen doch andere erst mal einen Bus Steuern in einem Simulator dann wissen die was ein Busfaher so leisten muss sich Tag Täglich an den Zeitplan zu halten, nur durch die gegend zur Ballern kann jeder !
    Yanniboy, spiele einfach das was Dir am meisten Spaß macht und lass die anderen doch denken was Sie wollen die haben einfach keine ahnung was heut zu Tage Realitisch ist !! Viele spielen lieber im Sandkasten und Backen Kuchen oder bauen eine Burg nur um zu Ballern oder Krieg zu spielen,das finde ich sowieso das letzte mit den Ballerspiele was eigendlich Verboten gehört wenn wir mal die realität so sieht.


    MfG


    Zu Omsi wurde ja nun schon viel gesagt. Zu diesem Post möchte ich mich aber noch äußern. Wir reden hier über Akzeptanz anderen gegenüber, richtest aber deinen Finger auf Leute, die was anderes spielen als du, was du vielleicht nicht verstehst. Das passt irgendwie nicht zusammen. Du sagst selber, jeder sollte das spielen, was er will, um im selben Atemzug genau das zu verurteilen.
    Die Argumentation mit der Realität ist da etwas heuchlerisch. Seit Jahrhunderten wird Krieg in Büchern, Filmen und Serien thematisiert, ohne dass es jemanden stört, warum nicht in Spielen? Klar in Killerspielen geht es nur ums töten, es wird nicht reflektiert mit dem Thema umgegangen, sagst du jetzt sicherlich. Da sind wir dann auch schon bei Vorurteilen anderen Sachen gegenüber. Das kennen wir Omsianer ja nur zu gut, nicht wahr? Es gibt einige gute Spiele, die mit dem Thema Krieg sehr reflektiert umgehen. Außerdem gibt es genügend Studien, die Vorteile in solchen Spielen sehen, Teamgeist, Reaktionsvermögen ect...


    (Im folgenden werde ich Prozentangaben verwenden, die nicht fundiert sind, aber vermutlich recht gut stimmen.)
    Und zu guter Letzt, das sogenannte Totschlagargument Amokläufer. Ganz ehrlich, ich kann das einfach nicht mehr hören. Ja es ist vermutlich richtig, dass 99% der Amokläufer schon mal ein Killerspiel gespielt haben. Aber weißt du was, 99,99% der Amokläufer hatten einen PC. Sollen wir alle PCs nun vernichten, damit sie nicht mehr stattfinden? Oder um es mal ganz absurd zu sagen, sicherlich haben 99% der Amokläufer schon mal, hm... Cola getrunken. Vernichtet alle Cola Reserven auf diesem Planeten!
    Mal im Ernst, drehen wir den Spieß doch einfach mal um: 0,000001% (vermutlich ist die Zahl sogar noch zu groß) der Menschen, die schon mal ein Killerspiel gespielt haben, werden zu Amokläufern. Findest du diese Zahl bedrohlich? Wenn jemand zu einem Amokläufer wird, hat er sicherlich ganz andere Probleme, als Killerspiele.


    lg Kevin


    PS: Och schade, Semedah, hättest ruhig den "Beitrag" stehen lassen können. Mehr Argumentation FÜR mein Post geht gar nicht :D

    Um eine Haltestelle zu verschieben, musst du erstmal die Peope-Box (das blaue Rechteck) verschieben. Ich denke mal, das hast du bereits getan. Der zweite Schritt ist, den Buswürfel (ein kleiner roter Würfel auf der Straße) zu verschieben. Da muss man aber aufpassen, dass der Würfel immer noch auf dem richtigen Pfadsegment liegt. Bei nur 5 Metern kann das noch sein. Dazu musst du im Trip/Track Menü einen Trip aussuchen, der über diese Haltestelle führt, und die Haltestelle auswählen. Wenn du das machst, sollte auch ein Pfadsegment rot werden. Der Würfel muss auf diesem Segment liegen. Wie es weiter geht, wenn dies nicht der Fall ist, kann ich gerade aus dem Kopf nicht sagen (hab den Editor nicht offen), da guck ich später, wenn es relevant ist.


    lg Kevin

    Schön beschrieben. In Vaals kenn ich mich leider auch nicht so gut aus, aber direkt vor der Grenze gibt es eine kleine Passage durch ein Wohngebiet für Leute, die es gern etwas kniffliger haben wollen. Gerade die beiden Einbahnstraßen haben es in sich, wenn da mal parkende Autos nicht perfekt stehen. Ich hoffe das wurde auch gut umgesetzt :).
    Mit Donnerstag würde ich auch mal gern wissen. Hab bisher noch nichts offizielles gefunden, außer Ende Oktober auf der Aerosoftseite.


    lg Kevin


    PS: hier steht der 27.10.16:
    http://www.shop.aerosoft.com/e…ation4u&s_language=german
    Ich will aber jetzt keine Releasediskussion entfachen. Nur antworten, wenn jemand eine offizielle Ankündigung kennt.

    @ACMG: Die Diskussion hatten wir doch schon mal:



    Das ist nicht gesagt. Es könnte auch sein, dass Omsi zum Start nur den Text der Datei einliest, im Speicher hält, und später bei jedem Frame den Text ausm Speicher parst. Dass die Scripte die umgekehrte polnische Notation verwenden, unterstützt auch meine These. Es ist die einfachste Form, wenn man beim Parsen das Script direkt ausführt, und es nicht erst in eine interne Datenstruktur packt. Zweiter Punkt ist das Definieren von Macros nach dem Aufruf. Im Wiki steht, dass es eine effektive Methode ist, keine Zykel zu bauen. Allerdings glaube ich, dass es einfach daran liegt, dass wie gesagt, das Script beim Parsen ausgeführt wird. Wenn ein Macro-Aufruf stattfindet, überspringt der Parser einfach solange den Text, bis er die passende Macro-Definition findet. Es gibt ja zudem auch keine Schleifen, was bei dieser Methode auch wirklich schwierig umzusetzen wäre (dritter Punkt).
    Was Omsi genau macht, kann natürlich nur Marcel sagen. Je mehr ich allerdings drüber nachdenke, umso mehr glaube ich an das Parsen in jedem Frame.


    PS:

    Quote

    Das liegt nicht an der Sprache, sondern am Compiler/Interpreter. Die
    Frage ist also, wie das in LOTUS umgesetzt wird. Da kann jede Sprache
    schnell oder langsam sein.

    Das ist nicht so ganz korrekt. Einen Compiler/Interpreter für z.b. Duck-Typing kann nicht effiziet geschrieben werden. Es muss halt zur Laufzeit geprüft werden, ob bspw. eine Funktionen mit einem bestimmten Namen existiert. Aber ich gebe dir so weit recht, dass man gute und schlechte Compiler/Interpreter schreiben kann ^^.

    Egal welche - Hauptsache interpretiert und nicht kompiliert.


    Bitte was? Ich hoffe doch nicht. Das ständige Interpretieren der Scripte in jedem Frame führt doch bei Omsi zu den Permormanceeinbrüchen bei zu vielen KI-Bussen. Einmal beim Laden des Busses kompilieren, und den Bytecode (oder was auch immer dann erstellt wird) bei jedem Frame ausführen. Ist um Längen Performance freundlicher. Ich weiß nicht, was Pascal Script da von Haus anbietet.


    @faaabiiii: Python ist eine schöne Sprache, ist aber auch nicht besonders schnell.


    Warum eigentlich nicht Lua? Wird im Gamingbereich seit Jahren erfolgreich eingesetzt. Lotus wird in Delphi programmiert oder? Ich meine, es gibt auch eine Schnittstelle in Delphi zu Lua.

    Dass die Scripte in OMSI in jedem Frame neu eingelesen und geparst werden ist ja schon dadurch widerlegt, dass sich Änderungen erst bemerkbar machen, wenn man ein neues Spiel startet. Die werden also offenbar nur einmal beim Lesen des jeweiligen Objekts geladen und sicher auch nur einmal geparst.


    Das ist nicht gesagt. Es könnte auch sein, dass Omsi zum Start nur den Text der Datei einliest, im Speicher hält, und später bei jedem Frame den Text ausm Speicher parst. Dass die Scripte die umgekehrte polnische Notation verwenden, unterstützt auch meine These. Es ist die einfachste Form, wenn man beim Parsen das Script direkt ausführt, und es nicht erst in eine interne Datenstruktur packt. Zweiter Punkt ist das Definieren von Macros nach dem Aufruf. Im Wiki steht, dass es eine effektive Methode ist, keine Zykel zu bauen. Allerdings glaube ich, dass es einfach daran liegt, dass wie gesagt, das Script beim Parsen ausgeführt wird. Wenn ein Macro-Aufruf stattfindet, überspringt der Parser einfach solange den Text, bis er die passende Macro-Definition findet. Es gibt ja zudem auch keine Schleifen, was bei dieser Methode auch wirklich schwierig umzusetzen wäre (dritter Punkt).
    Was Omsi genau macht, kann natürlich nur Marcel sagen. Je mehr ich allerdings drüber nachdenke, umso mehr glaube ich an das Parsen in jedem Frame.

    Weiterhin kommt erschwerend hinzu, dass OMSI eine offene Entwicklerumgebung bietet. Das hat den Vorteil, dass quasi alles umsetzbar ist, allerdings sind die Scripts für die Fahrzeuge nicht hardcoded und optimiert, sondern werden aus Textdateien frame für frame gelesen. Auch dies wurde mit der Zeit immer komplexer und damit unperformanter.


    Das könnte aber definitiv optimiert werden. Gerade wenn man viel Fahrplan-Ki-Verkehr auf einer Karte hat, sind die Scripte oft das Nadelöhr. Die Scripte beim Laden einmal parsen und in ein internen Bytecode überführen. Dann wäre die Ausführung pro Frame hundertmal schneller! Optional gäbe es dann noch die Möglichkeit diesen Bytecode auf die Platte zu speichern. Dann würde das Parsen sogar beim Laden entfallen (solange sich das Script nicht ändert). Und schwer ist sowas auch nicht zu realisieren. Ich weiß wovon ich spreche, hab schon oft Programmiersprachen und Bytecodes entwickelt.


    lg Kevin

    Hallo Leute,


    ich möchte mal einen "Fehler" melden, der mich eigentlich schon sehr lange nervt, und der auch schon seit Omsi 2 existiert. Besonders ärgerlich ist er, da er vermutlich recht einfach zu fixen ist (ich nehme mir die Meinung mal heraus, da ich Programmierer bin, Marcel kann mich aber diesbezüglich gerne korrigieren). Es geht darum, dass die Ampelphasen bei einer neu geladenen Kreuzung auf 0 gesetzt werden.
    Diesen "Fehler" (Anführungszeichen, weil es streng genommen kein wirklicher Fehler ist) gab es in Omsi 1 nicht, da dort alle Kacheln am Anfang geladen wurden. Er klingt zwar recht banal, hat aber drei mehr oder weniger störende Folgen:


    1. Mehrere zusammengehörige Kreuzungen über mehrere hundert Meter funktionieren nicht mehr zusammen, Stichwort "Grüne Welle". Maerkertram hat z.b. eine solche in seiner Map Teltow erstellt, die durch Omsi 2 nicht mehr funktionierte.


    2. Eigentlich die gleiche Ursache wie 1.: Kreuzungen die mit Ampel-Splines über mehrere Kacheln gebaut wurden, funkionieren nicht. Zugegeben, Omsi 1 unterstützte diese Bauweise offiziel nicht, und ich bin auch kein besoners großer Fan der Ampel-Splines. Aber einige Maps haben dadurch nicht mehr funktioniert.


    3. Nun zumindest für mich der wichtigste Punkt: eintönige Maps. Ich weiß, das klingt in diesem Zusammenhang etwas merkwürdig, hat aber was damit zu tun. Ich denke, vielen wird oder wurde bereits das folgende aufgefallen sein: Wenn man eine Map bzw. eine Linie öfter mal fährt, bekommt man immer oder sehr oft die gleichen Ampeln bzw. steht immer oder sehr oft an den gleichen Ampeln. Das ist kein Zufall, gerade wenn man mit nur einer Nachbarkachel fährt. Wenn eine Kachel geladen wird, ist man nicht sehr weit weg (bei einer Kachel nur ca. 300 Meter), und in diesem kurzen Weg passiert nicht mehr so viel, als dass die Ampelschaltung, die ja dann erst bei 0 startet, immer wieder etwas anderes anzeigt. D.h. ich weiß auf einer Linie ziemlich schnell, welche Ampel ich immer bekomme, und an welcher ich immer stehen muss, selbst wenn ich z.b. 500 Meter vor der Ampel mal für 10 Sekunden aufgehalten werde durch ein Auto, die Ampelphase ist am Ende eh wieder die gleiche, da die Kreuzung erst in 200 Metern geladen wird. Mehr Nachbarkacheln würden den Effekt nur abdämpfen aber nicht ändern. Das führt zu einem noch statischerem Omsi. Und das betrifft ALLE Maps.


    Aus diesen Gründen hoffe ich, dass dieser Fehler korrigiert werden kann. Ich weiß Omsi 2 hat noch einige Probleme, die vielleicht auch etwas schwerwiegender sind. Allerdings glaube ich, dass dies hier mit vergleichsweise winzigem Aufwand gelöst wird. Ich denke mal jede Kreuzung hat ne Variable, die den derzeitigen Zeitpunkt in der Ampelphase speichert. Dieser müsste z.b. beim Laden der Kreuzung einfach nicht auf 0 gesetzt werden, sondern auf sowas wie "(Zeitpunkt_Jetzt - Zeitpunkt_Omsi_Start) modulo Ampelphasen_Laenge". So hätte man alle Punkte egalisiert, und wieder das Verhalten von Omsi 1.


    Würde mich auf eine Antwort von Marcel oder Janine freuen.
    Vielen Dank schon mal.


    lg Kevin

    Das liegt leider an Omsi. Ich muss wegen meinem schlechten System die Fahrplan-KI-Fahrzeuge auf 40 begrenzen. Wenn ich vom Zoo aus fahre, stehen an der Hertzallee ca 20 Busse, aus der Stadt raus, sehe ich fast gar keine mehr. Wenn ich von Teltow fahre, ist am Zoo tote Hose. Liegt wohl wirklich daran, dass Omsi einfach munter jeden Bus lädt bis die Grenze erreicht ist. Eine prozentuale Berechnung wäre wirklich wünschenswert. Ich definiere die Grenze bei 40, Omsi guckt, wieviele Umläufe es gibt z.b. 100. Dann sollte Omsi einfach mit ner Wahrscheinlichkeit von 40/100 einen Bus laden oder so.


    Lg kevin