Ein Ladefehler ist wohl am wahrscheinlichsten. In einem von 100.000 Fällen fährt ja auch mal ein Bus auf dem Gehweg 
Beiträge von Thomas U.
Als Gast kannst du nur Inhalte in deiner ausgewählten Sprache sehen. Registrierte Nutzer können die Sichtbarkeit anderer Sprachen in ihrem Kontrollzentrum aktivieren, weitere Infos hier.
Alle Themen sind in den Foren mit einer Sprachflagge gekennzeichnet:
= Englisch [EN], 
= Deutsch [DE], 
= Französisch [FR]. Wenn du die angegebene Sprache nicht beherrschst, schreibe auf Englisch! -
-
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...
-
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
-
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.
-
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
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
-
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.
-
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. -
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
-
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.
-
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.
-
Wird eine Version folgen oder Anleitung wie man die Objekte von der München Demo gegen die vom Payware Addon tauschen kann?
Größtenteils musst du einfach nur die Dateinamen anpassen, das geht mit Notepad++ ganz fix, wenn man alle Kacheldateien reinlädt und dann in allen ersetzt. Ersetzt werden muss "_DEMO" durch "", also nichts. Außerdem gibt es einige Objekte, die im Ordner "Muenchen_1" liegen, die sich in der Demo woanders befinden, dabei hilft Maptools.
Das große Aber: es gibt einige Gebäude, die im richtigen München-Addon entweder ganz anders heißen oder irgendwie zusammengefasst wurden. Betroffen sind diverse Objekte aus der Von-der-Tann-Straße. Wenn man die aus den Kacheln entfernt, dürften sich ein paar Lücken ergeben.
___
Was mir sonst auffiel:
- bei Dohos Discounter-Set gibt es einige falsch verlinkte Objekte (Sceneryobjects\Discount Set\Dohos_Objects\Discount Set\...)
- diverse Nemolus-Verkehrsschilder sind solche mit verkorksten Dateinamen, die in einer sauberen Installation nicht vorkommen sollten
Weiter bin ich noch nicht
-
Hier war doch noch was...
Du musst folgendes machen:
Ja, ich weiß, aber das funktioniert ja auch nicht
Kann rumrudern, wie ich will, er erkennt da nix. Eigentlich komisch. Das Zuweisen der Achse funktioniert, er erkennt also das Vorhandensein der Achse, nicht aber ihren Regelbereich.Die Idee mit der alten Lenkradelektronik war auch noch nicht von Erfolg gekrönt, die wird vom PC gar nicht erkannt. Da muss ich noch mal genauer schauen. Vielleicht ist sie ja auch einfach defekt.
_____
Derweil wurde zum E1 das Releasedatum 31. März genannt. Kostenpunkt 14,95€.
-
Ich für meinen Teil finde es im Übrigen ziemlich schade, dass wir immer wieder darüber diskutieren müssen, Funktionen zu beschränken, nur weil einzelne User sie für eigene Zwecke nutzen missbrauchen. Das Problem liegt hier ganz klar auf Seiten derer, die noch nicht verstanden hat, wie man sich in einem Internetforum benimmt. Wenn wir Wind von solchen kontrollierten Aktionen bekommen, gibt's hin und wieder auch das Vorhängeschloss als virtuelles Accessoire.
So ist es. Nicht die Reaktionen sind das Problem, sondern diejenigen, die damit Unfug treiben. Das ist aber das Problem einiger weniger und kein generelles.
Ich brauche diese Funktion zwar auch nur selten, aber hin und wieder ist sie doch praktisch. Und ein "Haha" ist bei einem lustigen Beitrag eben nunmal sehr viel passender als ein "Gefällt mir" oder "Danke".
Die einzige Reaktion, die meiner Meinung nach wirklich überflüssig ist, ist der grüne Haken. Was soll man damit aussagen? "Dich hab ich abgehakt"?
"Applaus" und "Feier ich" wären zumindest diskussionswürdig, weil durch andere ersetzbar, aber Gefällt mir, Danke, Haha und das Herz würde ich beibehalten, weil sie eben spezifische Bedeutungen haben, die durch ein einfaches "Danke" nur schlecht ersetzbar sind. -
Ich muss wohl öfters mal in andere Bereich des Forums schauen, ich verpasse zu viele Projekte
Sieht doch schon gut aus. Wie habt ihr das mit dem Spurbus umgesetzt? Reale Breite der Fahrbahn mit Kollisionen dürfte ja eher nicht klappen in OMSI.
-
Nein und ich gehe auch nicht davon aus, dass das später möglich sein wird. Dafür bräuchte man eine Art Plugin-Schnittstelle und bei dem, was ViewApp unter "Modding" (Repaints) versteht sehe ich da schwarz.
Ja, das ist zu befürchten... dabei müsste man dort doch eigentlich ziemlich genau wissen, dass so ein Ein-/Ausgabe zu einem guten Spiel dazugehört, zumal es mit der von Chrizzly erwähnten UE4-Arduino-Schnittstelle ja schon was fertiges gibt, das man "nur" einbauen müsste, aber das sollte es doch wert sein. Das eröffnet doch ganz andere Möglichkeiten des Spielens. Klar, Eingaben gehen immer irgendwie über Gamepads, Joysticks und Geräte, die sich dafür halten, aber Leuchtmelder oder sowas kriegt man damit halt nur entkoppelt vom Spiel hin.
Als was gibt sich dein Arduino denn genau aus?
Dürfte ein DX-Eingabegerät sein. Also eigentlich etwas, das für so ziemlich alle Spiele kein Problem darstellt
Arbeitet ja auch sonst prima, nur eben in Tramsim nicht. Meine manuelle Gangschaltung für ETS und Omsi läuft z.B. auch mit dieser Bibliothek (die übrigens, falls mal wer testen will: https://github.com/MHeironimus/ArduinoJoystickLibrary). Tadellos.Probier nochmal, die Einstellungen im Achskonfigurations-Fenster neu zu setzen und zu speichern.
Das würde ich gern, aber in dem Fenster sind außer "abbrechen" alle Bedienmöglichkeiten ausgegraut und lassen sich auch nicht überreden, irgendwas anderes zu tun
Ich weiß noch, dass meine anderen Geräte früher auch dieses Problem hatten. Irgendwas hat man zwischenzeitlich also wirklich geändert, aber zumindest für diesen Fall hat das nix gebracht.
Alternativ könnte ich mal die Elektronik meines alten Lenkrades rauskramen und damit testen. Das ist zwar ein Uraltgerät, aber vielleicht funktioniert es ja. Dann schließe ich meine Technik halt eben daran an statt an den Arduino
Betrifft ja eigentlich sowieso nur die Achse für den Fahrschalter, Knöpfe drücken geht wunderbar auch vom Arduino aus.Letztlich träume ich ja hin und wieder immer mal von so einem Enterhakenfahrschalter a la Bogestra-M6 bzw. NF6D. Aber so ein Projekt gehe ich, wenn überhaupt, erst an, wenn die Technik vernünftig funktioniert...
