Beiträge von Thomas U.

Habe ich auch überlegt... die Kurven im zitierten Beitrag sind doch riesig, wieso sollte da kein Gelenkbus passen? An anderen Stellen mag das anders sein, aber hier... das geht doch mit dem kleinen Finger.

Eine meiner OMSI-Macken ist ja, Solobuslinien auf ihre Gelenkbustauglichkeit hin zu prüfen, ganz besonders dann, wenn es heißt, dass es nicht anders passen würde. Das werde ich auch hier sicher wieder machen Der Unterschied zu manch anderer Karte ist zumindest, dass man hier auf realistische Straßenverhältnisse vertrauen kann.

Zitat von Lµkas

Der nächste Schritt wäre dann, die Position und Zustände der Busse von anderen Spielern zu nehmen (Multiplayer) und darauf aufbauend die Position der anderen Busse automatisch zu berechnen (KI).

Man könnte aber auch erst die KI-Fähigkeit herstellen und dieser dann statt automatisch ermittelter Werte die durch den Multiplayer zur Verfügung gestellten Werte übermitteln. Wie man's auch dreht, das eine klingt nicht komplizierter als das andere

An sich sind die Busse doch eigentlich nur schwarze Kästen mit einer Eingabeschnittstelle, und die bekommt entweder:

- Daten vom Spieler (Singleplayer)

- Daten von anderen Spielern (Multiplayer)

- Daten von der Automatik (KI)

Meinem Empfinden nach ist MP-Fähigkeit funktionell viel näher am Singleplayer als am KI-Verkehr, weil beides "menschlichen Input" enthält, nur eben stattdessen online übermittelt, während die KI diese Parameter fahrplan- und verkehrsbasiert selbst berechnen muss. Aber vielleicht irre ich mich da auch.

Ich weiß zwar nicht, welche Reihenfolge programmiertechnisch einfacher ist, aber KI-Busse als ein essenzielles Feature eines Bussimulators so weit rauszuschieben, ist schon irgendwie eigenartig. Fände ich persönlich zumindest wichtiger für den Spielspaß als Multiplayerfähigkeit.

Eben, je verstreuter die einzelnen Sachen, desto unübersichtlicher. Hier kann man alles sauber zentral zusammenfassen.

Mir ist ja so, als hätte es von Anfang an Stimmen gegeben, die Modifikationsmöglichkeiten als eine wichtige Funktion für den Erfolg eines solchen Spiels genannt haben...

"Mit dem Auto rumfahren" finde ich jetzt persönlich wenig spannend. Wäre das als Bussimulator aufgezogen, wäre mein Interesse größer, aber vermutlich gibt es mittlerweile genug in der Sparte (OMSI für die Freaks, Bussim xy für Spaßfahrer, TheBus und LOTUS als Zukunftsprojekte). Da bin ich als Kunde also eher nicht zu erwarten.

Das angesprochene TramSim-DLC... nunja. Als ich Betriebshof hörte, war ich freudiger Erwartung, dass man die Strecke der 19 nachbaut, welche dann zumindest mit einer Schleifenfahrt über den Hbf in ihrem Ostast fahrbar wäre. Da hätten sie mein Geld schon haben können. Aber dann die Ernüchterung, "Teleport"... nee, das ist dann halt auch nichts für mich.

Ein Ladefehler ist wohl am wahrscheinlichsten. In einem von 100.000 Fällen fährt ja auch mal ein Bus auf dem Gehweg

Ich würde sagen, der Punkt ist da, nur so nah an der 2, dass man ihn auf dem Bild schlecht sieht.

Vulkan kenne ich bisher nur vom TransportFever und damit neigte das Spiel im Gegensatz zu OpenGL bei mir gern zu Abstürzen. Von daher bin ich diesbezüglich erstmal etwas zurückhaltend. Muss aber ja nichts heißen.

Ich frage mich, ob so ein Umstieg denn überhaupt was bringt. Ein bekanntes, LOTUS sehr ähnliches, auf DirectX basierendes Spiel - wenn es auch nicht mehr ganz aktuell ist - ist ja auch nicht gerade ein Performancewunder. Und Zusi als ebenfalls DirectX nutzendes, konstruktiv nicht unähnliches Spiel ist es auch nicht.

Der Strom hängt ja letztlich von der Ansteuerung ab. Durch den Multiplexbetrieb leuchten nicht hunderte LEDs gleichzeitig, sondern immer nur wenige zusammen. Das allerdings mit höheren Strömen als dem üblichen Dauerstrom, denn durch die gepulste Ansteuerung für kurze Zeit braucht es höhere Ströme für dieselbe Leuchtkraft (was wiederum die Lebensdauer verkürzt).

Verglichen mit der Umsteuerung der Flipdot-Plättchen spart man aufgrund des nötigen Dauerbetriebs der LEDs wahrscheinlich nichts, aber wie Perotinus schon sagte, die wegfallenden Leuchtstoffröhren dürften den gewünschten Effekt bringen. Und natürlich die höhere Wartungsfreiheit aufgrund geringerer Anzahl von Verschleißteilen. Andererseits: sind ein paar LEDs kaputt, kannst du - im Gegensatz zur Flipdotanzeige - nicht mal eben einzelne Punkte tauschen. Bestenfalls bestehen die Anzeigen aus kleineren, tauschbaren Modulen, dann braucht man immerhin nicht die gesamte Anzeige ersetzen.

Dass die Anzeigen bei ausgeschalteter Zündung oft ebenfalls aus sind, ist aber manchmal wirklich ärgerlich. Ist allerdings Einstellungssache (und vielleicht auch herstellerabhängig), von "aus" über "leuchtet mit verringter Helligkeit" bis "bleibt über Zeit x an und schaltet dann erst ab" gibt es da alles. Wenn die Anzeige während der Standzeit des Busses an der Haltestelle dinkel ist, weiß man unter Umständen erst, dass das der Bus war, den man nehmen musste, wenn er abfährt...

Ich glaube aber, wir entfernen uns etwas vom Threadthema...

Zitat von Perotinus

weil sie von Sehbehinderten aufgrund des stärkeren Kontrastes wohl besser gelesen werden können.

Mir wurde erst vor kurzem mitgeteilt, dass die orangenen Anzeigen in der Hinsicht die besseren seien. Wäre sonst auch zu einfach, wenn es eine einheitliche Meinung dazu gäbe

Ich persönlich mag die weißen auch nicht so sehr. Aber Flipdots verbaut ja keiner mehr... bei den nach wie vor üblichen Preisunterschieden zwischen orangen und weißen Leuchtdioden müssten die weißen Anzeigen auch eine gute Stange mehr Euros kosten.

Und bei den Liniensymbolen hätte ich gerne Bogestra-Standard. Danke

Zitat von PingPong

besonders dann, wenn diese sehr komplex werden

Eben. Aber daran fehlt es hier im Überfluss. Variable lesen, negieren, eine 1 in den Stack schieben, vergleichen, das Ergebnis ins "Wenn" einsetzen, damit ist das kleine Männchen im Computer länger beschäftigt als mit einem fortwährenden "1 in Variable schreiben". Einsparung gleich null, eher im Gegenteil.

Solche arbeitseinsparenden Abfragen machen nur dann Sinn, wenn danach wirklich ein großer Klotz Anweisungen kommt oder aufwändigere Sachen wie Textvariablen auf Objekte pinseln. Aber bei einem einfachen "1 (S.L.Animation)" ist das eher nutzlos.

Zitat von BusfahrerP

ich meinte, dass gerade dann beim Neustarten der Situation die Daueranimation wieder ignoriert wird.

Nö, wieso sollte? Die Variable wird beim Platzieren des Busses einmal auf 1 gesetzt, mit diesem Zustand abgespeichert, beim Laden des Spielstandes auch wieder passend beschrieben und dementsprechend funktionieren auch die Animationen.

Der einzige Fall, in dem das ein "Problem" ist: wenn man OMSI startet, den Bus platziert, OMSI schließt, die Variable dann erst einführt und anschließend die alte Situation lädt. Dann kann es nicht funktionieren, klar, aber dagegen hilft Bus neu setzen oder in der laststn.osn die entsprechende Zeile suchen und die 0 gegen eine 1 ersetzen.

Grundsätzliche Probleme gibt es mit der Platzierung im init-Abschnitt aber nicht. Andernfalls würde keine meiner Basteleien, die so eine Variable erfordern, funktionieren. Oder mein OMSI arbeitet einfach anders als eures

Zitat von PingPong

Um Performance zu sparen, macht es aber Sinn den Wert im Frame abzufragen: wenn daueranimation nicht, dann daueranimation 1. Somit wird das nicht in jedem Frame neu gesetzt, da der Abschnitt dann ignoriert wird.

Damit sparst du in dem Fall aber nix, die Abfrage muss doch auch berechnet werden

Zitat von BusfahrerP

Init wird beim Platzieren berechnet, frame in jedem FPS.

Und damit ist die Daueranimationsvariable im Init-Abschnitt auch bestens aufgehoben, die braucht doch nicht fps-mal pro Sekunde neu gesetzt werden.

Zitat von Viktor A. Kaiser

Der Bus fährt ja so selten, weil die Nachfrage entsprechend gering ist.

Vielleicht ist die Nachfrage aber auch nur so gering, weil der Bus so selten fährt Ein typisches Henne-Ei-Problem. Ohne Angebot keine Kunden, ohne Kunden kein Angebot.

Zitat von Lµkas

Vielleicht wird man die ein oder anderen Objekte ja auch mal auf Freeware-Karten sehen.

Meinen Plan, die schicken Bäume für den schon viel zu lang stehenden Weiterbau meiner Strecke zu stibitzen, muss ich aber wohl überdenken. Payware als Voraussetzung war immer ein NoGo für mich

Für das, was bisher hier gezeigt wurde, zahle ich gerne. Zum einen stimmt hier die Qualität, zum anderen denke ich, dass man als Käufer bei euch auch keine Angst haben muss, ein halbfertiges Produkt zu bekommen oder dass ihr nach dem Release abtaucht

Zitat von Semedah

Vier Räder

Single-Bereifung kenne ich vom A37, aber beim S315?

Die Sache mit dem AVS klingt spannend. Mal was ganz anderes. Schön, dass ihr das hingekriegt habt.

Zitat von BusfahrerP

Es kommt drauf an, was das Fahrzeug aufnehmen kann, man müsste sich mal den GÜ anschauen, was der drin hat.

So ein Citaro G hat 17 "reale" Sitzreihen. Ein S415NF hat 13, der vordere Einstiegsbereich zählt also als zwei, macht beim Gelenkbus dann 19, also wäre SG419NF tatsächlich korrekt.

Wobei die alleinige Komprimierung schon auch auffällig ist. Da wird ein eigentlich scharfes 300kb-Bild dann noch mal auf die Hälfte eingedampft und bekommt herrlich unscharfe Kanten.