Beiträge von Berlin&Brandenburg

Zitat von Jamonalk

Das stimmt. Vor ein paar Tagen ist seit langer Zeit ein neuer Patch rausgekommen, dieser war aber wie erwartet nicht gerade umfangreich...

Bei JM wird eher gekleckert als geklotzt. Jedesmal, wenn ich die Patchnotes lese, hoffe ich immer auf den Urknall. Irgendwas richtig erhellendes i. S. d. der Entwicklung. Entweder die M1 ist fertig oder LOTUS hat keine Performanceeinbrüche mehr oder was weiß ich. Stattdessen kommt dann immer nur, dass Schneidealgorithmus XY jetzt unter diesem und jenem Einsatz bei dieser und jener Bedingung keine Löcher mehr produziert und Stevens FIS-Datei wieder geupdated wurde. Das war's dann meistens auch schon wieder. Und dann passiert danach wieder wochenlang gar nichts mehr. Ich finde, dass Verbesserungen an bestehenden Funktionen einfach auch nebenbei ausgemerzt werden können. Braucht es dafür dann jedes Mal extra eine Ankündigung und ein komplettes Update?

Zitat von Chrizzly92

Naja, fairerweise muss man auch sagen dass jetzt vermutlich die "Patch-Sommerpause" vorbei ist und die Arbeiten weiter gehen müssen. Dein Gedankengang gefällt mir aber wesentlich besser.

Naja... Wer weiß, was am 28. August so vorgestellt wird. Zwar gibt es bei Computersimulationen keine Konkurrenz wie bspw. bei Industrieprodukten wie Joghurt o. ä., sondern letztlich kauft irgendwann jeder auch jede Simulation. Aber ein "Konkurrenzsimulator" wäre idealerweise eine Benchmark, an der sich LOTUS messen lassen muss. Und im direkten Vergleich würde sich dann auch zeigen, wo Schwächen liegen und was andere Entwickler so schaffen.

Zitat von Lµkas

Für die M1 werden weder (Eisenbahn-)Signale noch Tunnel gebraucht. Die Straßenbahn-Ampeln (mit den Strichen und Punkten) gibt es bereits und auch Unterführungen/Brücken sind möglich. Da läuft also nichts falsch.

Ganz verwerflich ist die Notwendigkeit für die Signaltechnik nicht, weil die M1 auch eingleisige Abschnitte hat, die entsprechend "gesichert" befahren werden müssen. Ich denke, dass mit "Eisenbahnsignalen" eher die Implementierung von Zugsicherungssystemen gemeint war. Die gibt es eben noch nicht in LOTUS und würden für den Standardcontent erst vollumfänglich für die U-Bahn benötigt werden.

Inwiefern das alles mit den derzeitigen Möglichkeiten umsetzbar ist, ist eine andere Frage.

Die wissen doch eh nicht, was sie überhaupt tun oder womit sie weitermachen wollen. Es sind ja nun zig Baustellen aufgerissen, die eigentlich alle eine Vollzeitstelle in der Entwicklung benötigen.

Aber irgendwie hat die Umfrage für mich Geschmäckle. Seit fast einem Jahr gab es schon keine Abstimmungen mehr - nun rückt die GamesCom-Ersatzveranstaltung näher und es sind neue Simulationen angekündigt - und schwupps ist plötzlich eine von Janines Umfragen da, die suggerieren soll, dass LOTUS ja demnächst sooo viele neue Features erhalten wird und allem Drum und Dran... Naja. Sollen sie erstmal liefern. Schnell und gut wäre wichtig.

Könntest du deinem Update dann ein Changelog beilegen, sodass man ungefähr sehen kann, was noch dazu kam? Ich habe leider schon einiges privat angepasst, sodass "komplett überschreiben" ziemlich viel Arbeit wieder bedeuten könnte. So könnte man schauen, was ergänzt wurde und nur diese Anpassungen dann selbstständig übernehmen.

Bei mir geht es um den Standard-Gelenkomnibus mit drei Türen. Ich hatte ja bereits den Wagen so gemodded, dass der "versenkte" Türtaster als globale Türkontrolle fungiert und immer leuchtet, wenn noch irgendeine Tür offen ist. Siehe dazu den Beitrag von Sgt. Maximus oben in meinem Zitat.

Das "Problem" war jetzt bei mir, dass wenn nur die erste Tür offen war und geschlossen wird, die globale Türkontrolle (versenkter Taster) früher erlischt, als das Licht des Taster für die erste Tür.

Zitat von Sgt. Maximus

Soo,

ich hab mal auf die Schnelle mal nachgeschaut und probiert, und jetzt sollte es passen.

Man gehe in die lights.osc und macht ggf. mein Scriptschnipsel raus und ersetzt ihn mit den ursprünglichen Werten, sodass es wieder so aussieht:

Code

        (L.L.door_4) 0 > (L.L.door_5) 0 > ||
        {if}
            1 (S.L.door_light_3)
            0 (S.L.light_timer3)
            (L.L.lights_stand)
            {if}
                1 (S.L.door_spotlight_3)
            {else}
                0 (S.L.door_spotlight_3)
            {endif}
        {else}
            (L.L.light_timer3) (L.S.timegap) + 2 min (S.L.light_timer3)
            2 =
            {if}
                0 (S.L.door_spotlight_3)
            {endif}
            0 (S.L.door_light_3)
        {endif}
    {endif}

Alles anzeigen

Danach muss erstmal "1 (S.L.door_light_3)" in Zeile 3

auskommentiert werden, also ein Apostroph am Anfang der Zeile rein.

Code

'            1 (S.L.door_light_3)

Unter dem vorletzten {endif} kommt schließlich das hier rein:

Code

        (L.L.door_1) 0 > ||
        (L.L.door_2) 0 > ||
        (L.L.door_3) 0 > ||
        (L.L.door_4) 0 > ||
        (L.L.door_5) 0 > ||
        {if}
            1 (S.L.door_light_3)
        {else}
            0 (S.L.door_light_3)
        {endif}

Also zu Veranschaulichung, am Ende sollte der Abschnitt so aussehen:

Code

        (L.L.door_4) 0 > (L.L.door_5) 0 > ||
        {if}
'            1 (S.L.door_light_3)
            0 (S.L.light_timer3)
            (L.L.lights_stand)
            {if}
                1 (S.L.door_spotlight_3)
            {else}
                0 (S.L.door_spotlight_3)
            {endif}
        {else}
            (L.L.light_timer3) (L.S.timegap) + 2 min (S.L.light_timer3)
            2 =
            {if}
                0 (S.L.door_spotlight_3)
            {endif}
            0 (S.L.door_light_3)
        {endif}
        (L.L.door_0) 0 >
        (L.L.door_1) 0 > ||
        (L.L.door_2) 0 > ||
        (L.L.door_3) 0 > ||
        (L.L.door_4) 0 > ||
        (L.L.door_5) 0 > ||
        {if}
            1 (S.L.door_light_3)
        {else}
            0 (S.L.door_light_3)
        {endif}
    {endif}

Alles anzeigen

Im Prinzip wars so, dass in meiner ersten "Version" auch die Variablen für das Display und die Türbeleuchtung beeinflusst wurden. Daher wurde jetzt hier die eigentliche Variable aus dem Block auskommentiert und in einem neuen Block definiert.

Alles anzeigen

Sorry, dass ich hier nochmal reingrätschen muss: Aber kann es sein, dass die Knöpfe eine Verzögerung zum Abschalten ihrer Beleuchtung eingebaut haben?

Wenn ich nämlich die erste Tür schließe, dann erlischt der dritte, versenkte Knopf früher als der Türknopf für die erste Tür. Kann man die Verzögerung auch dafür noch einstellen?

Zitat von Perotinus

Hm? Irgendwie ist das Zitat von B&B mir zugeordenet worden? Wie kann denn das passieren?

[...]

Zitat von e2h1986

Ohne die beiden in Schutz nehmen zu wollen, aber als ehemaliger Selbständiger weiß ich, was ein Burnout it. Wenn Du tagein, tagaus ohne feste Arbeitszeiten oder Urlaub vor derselben Arbeit sitzt und nicht rauskommst, bist Du irgendwann hinüber und brauchst eine Auszeit, vor allem auch bei dieser teilweise geistig sicherlich sehr fordernden Arbeit. Wir wissen ja auch durch unsere private Tätigkeit für Omsi, dass irgendwann die Motivation weg ist und man einfach mal 1-2 Wochen (oder auch mehr) etwas anderes braucht, um neue Kraft und Lust zu schöpfen oder einfach das schöne Wetter zu genießen.

[...]

Meine IBIS Um- und Einbauten habe ich in den letzten Tagen auch nächtlich bis morgens um 03:30 Uhr hingefummelt - der Großteil meiner Arbeitsleistung im Studium entstand auch immer nachts... Von daher bin ich da irgendwie drin.

Ja, aber du hast recht. Auch wenn das hart klingt, so ist in heutiger Zeit aber leider das Schuften knapp an der Leistungsgrenze aber leider einfach Normalität geworden. Zumindest in Jobs, wo das persönliche Potenzial groß ist.

Sicherlich hat die Selbstständigkeit viele Vorteile - aber eben auch Nachteile gerade bei der Arbeitszeit... Irgendeinen Tod muss man dann auch sterben.

LOTUS ist vom geplanten Umfang eben auch eine hohe Herausforderung. Ohne Frage. Aber wenn man die Simulation in dem Umfang plant, dann sollte man sich eben auch damit abfinden müssen, das man Zeitpläne braucht und diese auch einhalten muss oder sollte - und dann endet der Arbeitstag idealerweise nicht um 16 Uhr, sondern irgendwann nachts und beginnt am nächsten Tag im frühen Morgen. So ist das dann leider... Ich glaube nämlich, dass die Fertigstellung von LOTUS gar nicht mehr beziffert werden kann, weil sie irgendwann in dem kommenden Jahrzehnt oder darüber liegt.

Zitat von Lazarus

Das [G]anze kann man natürlich auch auf unseren geliebten LOTUS-Simulator übertragen. Keine Zeitpläne fahren, mindert auch die Enttäuschung. Ich würde da echt abwarten und Tee trinken. [...]

Naja... Als ehemaliges Teammitglied mit genügend Einblick muss ich leider sagen, das nach anfänglicher Euphorie bei mir mittlerweile sich ziemliche Enttäuschung breit gemacht hat.

Wer bei LOTUS Tee trinkt und abwartet, der sitzt wie an einer Bushaltestelle und wartet auf einen Bus, der bisher nicht einmal losgefahren ist. Wo die Reise hingeht, weiß bei LOTUS niemand mehr.

Mal angenommen, LOTUS besäße schon sämtliche Kernfunktionen - dann rechne dir nur 'mal hoch, wie lange benötigt wird, um den Standardcontent für M1/100 zu entwickeln! Ich würde behaupten wollen, dass unter Berücksichtigung des selbst proklamierten "LOTUS-Standards" für die Linien mindestens knapp über 10.000 Objekte benötigt werden, wenn LOTUS alles in dem Detailgrad darstellen soll, der favorisiert wurde. Angenommen, zwei Entwickler bauen vier 'High-Quality'-Objekte am Tag, dann beträgt der Arbeitsaufwand alleine 2.500 Tage. Das wären fast sieben Jahre. Und das scheint mir sehr unglaubwürdig, dass sie das durchziehen werden. Vor allem wäre LOTUS dann rund 10 Jahre in der Entwicklung - das ist ja nicht mehr erstrebenswert.

ViewApp hatte mit seinem wesentlich größeren Team für sein LOTUS-AddOn wesentlich mehr Drive gehabt. Wahnsinn, was er alles geschafft hat in nicht ganz zwei Jahren. Aber das liegt ja nun auf Eis. Natürlich schafft man mit zwei Leuten nicht so viel in zwei Jahren - aber wenn man den Standardcontent verspricht, sollte man ihn auch in absehbarer Zeit liefern können. Seit mehr als einem Jahr ist an dem Stückchen M1 in LOTUS beispielsweise gar nichts mehr passiert. Und das ist schon erbärmlich, muss ich sagen. Sorry. Aber jede andere Formulierung wäre dafür noch zu nett.

Ich finde es auch interessant, dass die beiden sich mehrere Wochen "Ferien" zeitlich leisten können neben einer Entwicklung. Alle meine Bekannten, die selbstständig sind, haben sich so viel Urlaub nie genehmigt. Die haben vielleicht gerade einmal fünf freie Wochenenden - im ganzen Jahr!

Wer weiß, ob nicht vielleicht schon Alternativen irgendwo in der Entwicklung sind... Vielleicht wäre es auch überhaupt erst einmal sinnvoll, ein Medium - wie bspw. Tram - erfolgreich zu entwickeln, bevor mit einem Simulator das 360-Grad-Super-Mega-Angebot kreiert werden soll. Entwickler sollten sich Ziele setzen, die auch realistisch sind.

Vor allem verliert man mit Stillstand einfach viel Zeit. Zeit verlieren für Problemlösung wäre ja okay und notwendig - aber wenn gar nichts passiert, geht auch gar nichts voran.

Außerdem erschließen sich mir auch nicht diese komischen "Nightly-Build-Patches" oder wie das heißt... Will man dann die eher schlecht als recht fertigen Neuerungen nochmals der breiten Öffentlichkeit vorenthalten?! Mit welchem Ziel?! Ob ich jetzt bspw. Stevens FIS-Datei oder leichte Scriptanpassungen drei Wochen früher oder später erhalte, ist mir dann auch ziemlich irrelevant...

Ehrlich gesagt kann man sich die Mühe sparen, überhaupt irgendwas konstruktives an Kritik für LOTUS zu formulieren. Erstens interessiert das dort weder Marcel noch Janine und zweitens hilft es auch nicht wirklich, weil der Entwicklungsfortschritt nahezu Null ist seit Monaten. Da auch kein Standardcontent weiterentwickelt wird, wäre somit auch kein Ergebnis durch folgende Updates feststellbar.

Ich frage mich eh, was seit Monaten nicht stimmt. So richtig großartige Sachen kommen einfach nicht. Stillstand. Den KI-Verkehr ziehe ich für meine Betrachtung vor die Klammer - denn bekanntermaßen (wir erinnern uns an die Situation mit ViewApp) sollte dieser schon 2019 implementiert sein, sodass ich den KI-Verkehr 2019 zurechne. In 2020 ist dahingehend dann kaum irgendwas passiert - an Corona kann das ja kaum liegen, schließlich entwickelt man allein daheim. Aber selbst wenn man nur zu zweit entwickelt, sollten die Fortschritte größer sein. Auch in der Selbstständigkeit sind 14 bis 16 Stunden tägliche Arbeitszeit, Bereitschaft zur Wochenendarbeit und hohe Leistungsbereitschaft selbst an Feiertagen keine Kür mehr, sondern im Jahre 2020 einfach Pflicht.

Zitat von Sgt. Maximus

Hi!

Ja, ist mir leider auch schon aufgefallen, ebenfalls wird die Tür im Display auch noch als offen angezeigt, obwohl diese schon zu ist.

Ja, stimmt. Das geht auch nicht.

Morphi hatte doch hier im Thread auch schon eine Möglichkeit skizziert - vielleicht sollten wir diese probieren.

Zitat von Sgt. Maximus

Hab das mal umgesetzt - ich denke das ist das erwartete Ergebnis.

Dafür in der lights.osc nach

Code

        (L.L.door_4) 0 > (L.L.door_5) 0 > ||

suchen und durch

Code

        (L.L.door_0) 0 >
        (L.L.door_1) 0 > ||
        (L.L.door_2) 0 > ||
        (L.L.door_3) 0 > ||
        (L.L.door_4) 0 > ||
        (L.L.door_5) 0 > ||

ersetzen.

Zwei Sachen hätte ich dann noch:

1. Ist mir aufgefallen dass ein Zusammenhang zwischem dem Druckerstart und dem Vorratsdruck beim Spawnen besteht. Ich habe einfach mal spaßeshalber den random-Wert so verändert, sodass der Vorratsdruck so gut wie immer zu niedrig beim Spawnen (<3 bar) liegt. Der Drucker ist nie hochgefahren.

Als ich aber gewartet habe, bis der Vorratsdruck auf ca. 5 bar angestiegen ist, den Bus komplett ab- und wieder aufgerüstet habe, ist der Drucker ohne Probleme hochgefahren.

2. Eine kleine Anregung wie man den Lautsprecher Knopf belegen könnte:

In meinem Umfeld gibt es mehrere Busse, die über zwei verschiedene Hupen verfügen, welche mit dem besagten Knopf umgeschaltet werden können. Einmal ne Pressluft-Hupe, wie damals in alTerrs Version, und einmal diese Softhupe wie in der 5.1F.

Grüße!

Alles anzeigen

Sorry, wenn ich hier nochmal nachhaken muss. Dein Script funktioniert soweit, jedoch bleibt die Türraumbeleuchtung an Tür 3 an, solange wie Tür 2 noch offen ist. Da müsste also noch irgendeine Bedingung rein. Vielleicht weißt du ja noch eine Lösung.

Zitat von Blade

Du meinst z.b. so?

"Mit diesem Patch verabschieden wir uns in eine kleine Patch-Sommerpause bis August."

Hart erarbeitete Sommerpause.^^

Dazu wollte ich mich nicht äußern, aber wenn die Entwicklungsmeilensteine von LOTUS ähnlich "voluminös" wie deren Urlaubsbedarf ausfallen würden, dann dürften wir eigentlich schon längst bei der Fertigstellung des U-Bahn-AddOns angelangt sein. 8)

Ja, also diese Aussage ist in der Tat fragwürdig: Bei zwei publizierten Payware-AddOns, von denen eines von höchster Stelle eigenmächtig "beiseite" geschafft wurde, bliebe ja dann nur noch das andere übrig... Dann ist auch klar, dass es nur das erfolgreichste sein kann, wenn es dazu keine Benchmark gibt...

Naja... Man kann sich das ganze LOTUS-Desaster im aktuellen Zustand auch entwicklerseitig schönreden...

Zitat von Morpheus

Ich kannte das bisher auch nur so. In einem Video von Mehmet Oe habe ich dann allerdings auch die andere Variante sehen können.

Ergo, ist dann eben Geschmackssache, wie man es haben möchte. Es wurde ja inzwischen auch erklärt, wie man das ändern kann.

Im Grunde dienen die "eingedrückten" Türknöpfe lediglich der Redundanz im Falle eines Displayausfalls als Statuswiedergabe.

Dieses Feature gab es "serienmäßig" eh nur bei den zuletzt gebauten Vor-Facelift-Fahrzeugen (ab Baujahr 2005 inkl. dem FAP mit digitalem Fahrtenschreiber/VDO-Schublade) und natürlich bei der später folgenden Facelift-Reihe.

Beim C2G entfiel dieser Taster wieder... Gibt zwar Betriebe, die im C2G ähnliches haben, aber das ist dann eben auch alles wieder Bestellwunsch oder im technischen Gespräch so im Vorfeld abgesprochen. Bspw. haben die C2/C2G der BVG auch so einen eingelassenen Schalter, der aber darüber hinaus als Taster ausgeführt ist, mit dem sich dann die automatische/n Tür/en manuell öffnen lässt/lassen...

Mir fällt gerade auf, dass die Farben der Beleuchtung hier unterschiedlich sind... Wurde das schon gemeldet?

- - - - - - -

Was mir gerade noch einfällt: Ich kenne es eigentlich so, dass der versenkte, dritte Tür"knopf" solange leuchtet, wie noch irgendeine Tür geöffnet ist. Geht das eigentlich allein im Script anzupassen oder ist die eigenmächtige Umsetzung nicht so einfach zu bewerkstelligen?

Richtig. Diese Taster vom ZF-Ecolife gibt es bei MAN nicht.

MAN verbaut nur die schwarzen Voith-Taster mit beleuchtetem Voith-Logo oder komplett schwarze Taster, die dann für das ZF Ecolife genutzt werden.

Ältere MAN haben hingegen die Weiß-Rot-Weißen-Taster, die für beide Getriebe genutzt werden konnten. Sie unterschieden sich wie bei Citaro nur durch ein einrastendes N (ZF) oder halt keines (Voith).

So. Einige Tage Ruhe. Ich habe zum Wochenende nochmals sehr akribisch an meinem Problem gearbeitet und konnte zielführende Beobachtungen erlangen.

Am Freitag hatte ich nochmals alle vier installierten Hamburg-AddOns deinstalliert und komplett neu installiert. Leider blieb auch nach dieser aufwendigen Vorgehensweise das Ergebnis ähnlich.

Auch mit verschiedenen AI-Lists war mein Problem nicht behoben - nach längerer Runtime des Games kam irgendwann der plötzlich Abfall auf 8 FPS.

Letztlich habe ich mir dann den Taskmanager zur Hilfe genommen. Ich hatte mir kaum vorstellen können, dass mein Problem offenbar doch hardwareseitigen Ursprungs ist. Ich habe mich in einen KI-Bus gesetzt und mich durch die Map chauffieren lassen und auf dem zweiten Bildschirm die Leistungsdaten meiner Datenträger aufführen lassen. Als wieder der plötzliche Abfall auf 8 FPS erfolgte, traute ich meinen Augen kaum, da der Auslastungsgrad des Laufwerks "I", auf dem OMSI läuft, von 3 Prozent urplötzlich auf 82 Prozent aufwuchs, woraufhin im gleichen Moment die Performance von OMSI auf Null zurückfiel!

Auf meinem Laufwerk "I" ist OMSI seit über sechs Jahren installiert und hat noch nie für solche Schwierigkeiten gesorgt. Ich kann mir das kaum erklären - ich vermute, dass OMSI auf der Hamburg-Map bei gewissen Berechnungen in einem Augenblick sehr viel Daten laden möchte, was dann die Lese- und Schreibfähigkeit meines Laufwerks so unter Druck setzt, dass es kurzzeitig abraucht und OMSI keine zügigen Berechnungen mehr durchführen kann.

Im Ergebnis habe ich nun mein Hauptverzeichnis genommen und auf die SSD meines Rechners verlegt. Nach mehreren Tagen des Testens sind keine dieser 8 FPS-Anomalien mehr aufgetreten. Ich habe testweise die "Hafencity Performance"-Einstellungen geladen und OMSI durchgeprügelt, mit dem Ergebnis, dass ich im guten Mittel 30-40 FPS habe, an kritischen Punkten vielleicht etwas weniger, OMSI stabil läuft und selbst bei diesen höheren Einstellungen noch ordentlich was schafft. Tja. Ich glaube, ich habe mein Problem nun beseitigen können, obwohl ich mir das nicht so ganz erklären kann, weil ich mit diesem Laufwerk nie Probleme hatte.

Ja, das wäre die Frage... Es kann gut sein, dass ich sie gar nicht habe. Oder es liegt wirklich an meinen beiden Monitoren. Die sind beide zwar baugleich, aber keine High-End-Geräte...