Beiträge von Thomas U.

Zitat von LKA

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...

Zitat von DerGrafikfehler

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€.

Zitat von Lµkas

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.

Zitat von Lµkas

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.

Zitat von Chrizzly92

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.

Zitat von DerGrafikfehler

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...

Nachdem ich mittlerweile wieder über ein Betriebssystem verfüge, auf dem TramSim lauffähig ist, kann man sich ja mal wieder mit den wichtigen Dingen des Lebens beschäftigen, nämlich mit der Steuerung über Joystick oder ähnliches.

Mein Ansinnen ist ja eigentlich, meinen Arduino Micro dafür zu nutzen, der sich mit der entsprechenden Bibliothek als Joystick ausgeben kann. Windows erkennt ihn korrekt, in anderen Spielen (Zusi, Lotus, LS) funktioniert das auch prima, Tramsim weigert sich jedoch nach wie vor, die Achse korrekt zu erkennen. Irgendwas erkennt er, aber halt nichts brauchbares, der "Regelbereich" liegt bei ungefähr 0,1mm, dann schwingt der Fahrschalter komplett um. Gemäß der bei der windows-eigenen Kalibrierungsmöglichkeit anzeigbaren Rohdaten ist das der Punkt, an dem die gelieferten Werte das Vorzeichen wechseln, aber eine Änderung des Wertebereichs brachte bisher auch nichts, von daher hilft mir diese Info auch nicht weiter.

Die Achsen des Lenkrads und des alten, richtigen Joysticks erkennt das Spiel (mittlerweile) problemlos, also müsste das doch mit so einem Arduino-Ding auch gehen. Sollte also jemand eine solche Technik im Einsatz haben, würde mich mal interessieren, welche Funktionsbibliothek er dafür nutzt Falls es daran liegt.

Und nebenbei: wie sieht es eigentlich mit der Ausgabe aus? Sprich für den Anschluss von Leuchtmeldern und so? Kann das Spiel das schon irgendwie?

An der (H) Storchenstraße war ich vor noch nicht allzu langer Zeit erst, Baumaterialreste aus dem Haus rechts abholen Jau, der Wiedererkennungswert ist definitiv vorhanden, sehr schön.

Vielleicht schafft du es bei dem Haus noch irgendwie, dass man die Aneinanderreihung der Textur nicht so stark sieht, also die harte Kante in der Mitte.

Grundsätzlich finde ich eine Fehlerübersicht und deren mögliche Ursache gut, aber...

Zitat von IREgio612

So können sowohl User [...] einen Blick in diese Übersicht werfen und den Bus so wieder reparieren.

...ich habe ehrlich gesagt eher das Gefühl, dass viele User nicht mal selbst Lust haben, einen Blick in die Logdatei zu werfen - dann nämlich bräuchten sie vielfach keine Hilfe - sondern sie lieber der Allgemeinheit hinlegen und warten. Da werden sie eine Fehlerübersicht erst recht nicht anschauen.

Zitat von Senator B

Ist das so? Lüfter, Klima und Licht gehen doch auch über den Keilriemen und sind dennoch abschaltbar oder hab ich grad nen Denkfehler?

Das sind elektrische Verbraucher, die kann man natürlich abschalten. Die zugehörige Lichtmaschine allerdings nicht, die läuft immer. Genauso der Kompressor, weil er nicht elektrisch angetrieben wird, sondern eben mechanisch per Riemen.

Das, was beim Licht der Schalter für an/aus ist, ist bei der Druckluft das Ventil für "in den Vorratsbehälter"/rausblasen.

Zitat von PePu

Aber sage mal, ist es nicht höchst unwahrscheinlich dass nur wegen der Objekte ne ganze Kachel dort fehlt?

Nein, das ist sogar absolut 1000% wahrscheinlich. So arbeitet OMSI. Wenn ein Objekt fehlt, wird der Ladevorgang der Kachel abgebrochen und man hat ein Loch in der Karte. Doof, aber nicht zu ändern.

Aaaalso... mein O407 (der alte, den neuen habe ich sträflicherweise noch nicht ausprobiert) dötzt da auch irgendwo an. Mutmaßlich am Dach des Busbahnhofs bzw. an den herunterhängenden Schildern, denn wenn man das Objekt um ein [nocollision] ergänzt, funktioniert es. Wäre vielleicht die einfachste Lösung.

Ebenfalls mutmaßlich vermute ich, dass es an der Boundingbox des O407 liegt. In der Bus-Datei ist zwar 2m eingetragen (wieso eigentlich?), wenn man die Außenhülle aber mal als Kartenobjekt hernimmt, sieht man, dass die objekteigene Box die Höhe der Dachantenne hat, die Teil des Wagenkastens ist. Tja, und damit ist der Bus unsichtbar höher als die Unterkante der Schilder am Dach.

Beim Citaro geht die Box nur bis über den Nubbel hinten am Dach, ist damit tiefer und er passt unter den Schildern durch.

Ich hatte es auch schon mal, dass einige Busse Kollisionen verursachten, andere aber nicht. Erklären konnte ich mir das nie so recht.

Zitat von Stapellurch

Auf der anderen Seite amüsier ich mich schon etwas über die Diskussion, weil die Möhre halt komplett fiktiv ist. Aber lasst euch da nicht unterbrechen

Grad deswegen ist es ja diskussionswürdig Über reale Busse braucht man schließlich keine derartigen Gedankenexperimente machen.

Und besser als die x-te Frage nach einer bestimmten Version oder Lackierung ist es doch sowieso

Zitat von BusfahrerP

entscheidend für die Bezeichnung ist die potentiell maximale Anzahl an Sitzreihen. Fahrersitz + evtl. Reisebegleitsitze glaube sogar als "Reihe" mitgezählt.

Wenn man wegen Niederflurtechnik und Radkästen nur maximal 19 Reihen reinbekommt, ist es ein SG 319 NF, vielleicht kann man in Maximalkonfig (=Knie an vorderer Rückenlehne, denke ich) auch 20 oder 21 Reihen reintun, was dann ein SG 320 NF oder SG 321 NF wäre.

Genau das war meine Überlegung dahinter.

In einem Hochflurbus kriegt man ja tendenziell mehr Sitzreihen unter, weil der Boden (fast) durchgehend auf einer Ebene liegt. Bei einem NF-Bus kann man das durch den Einsatz von Podesten versuchen zu erreichen, aber an sich minimiert die gebirgige Bauweise eines NF-Busses ja die Sitzreihenanzahl.

Was ich mich aber grad frage: wäre 321 die korrekte Bezeichnung? Beim 200er ist die Stadtbusgelenkvariante ja nur ein 219er.

Ich kann dir zwar auch nicht weiterhelfen, aber dass OMSI auch keine funktionierenden Kacheln mehr lädt, wenn man einmal in der Nähe einer nicht funktionierenden war, hatte ich auch. Eigentlich ein untypisches Verhalten, keine Ahnung, wieso das bei der Karte so ist In meinem Fall (und auch bei vielen anderen) waren es ja Differenzen diverser Kreuzungsobjekteigenschaften, vielleicht verhält sich OMSI hier komplett anders, als wenn einfach nur ein Objekt fehlt.

Zitat von PingPong

Installier dir mal die Oberpfalz 3D-Objekte neu.

Das bringt nix, das ist eine falsch verknüpfte .cfg in der Modelldatei (falscher Name), das wird serienmäßig so ausgeliefert. Macht aber nix, für zu keinen Problemen.

Edit: gut, wurde schon geklärt. Egal

Zitat von Hamburg-Harburg

Thomas U. Schreib bitte mal in den Supportthread deine Logfile, könnten Fahrzeuge oder David M Objekte sein

Fahrzeuge eher nicht. Auf die DavidM-Objekte tippe ich auch, ich habe bisher aber keine gefunden, die funktionieren würden, und bestimmt habe ich mir durch das rumkopieren jetzt irgendwelche anderen Karten zerschossen... man kennt's ja. Es ist ein Kappes mit diesen Objekten, am besten verwendet man sie gar nicht erst -.-

Aber gut, hier mal die Logdatei zum fröhlichen rumraten. Aus meiner Sicht nichts drin, was OMSI stören würde. Geladen wurde eine frische Situation im Bereich Nesselwang, der komplett fehlt. Aus Richtung Kutenholz ist kurz hinter der Bahnbrücke Schluss, aus der anderen Richtung in Stück hinter dem Naturgymnasium. -2/-7 müsste die erste Kachel sein, die aus dieser Richtung nicht geladen wird, allerdings sind auf der ja nicht mal DavidM-Objekte verbaut. Vielleicht könntest du mir die genutzten Kachelnummern zwischen diesen Stellen nennen, dann bastle ich mal etwas herum...

Zwischenzeitlich hat er mal an anderen Stellen weitere, vorher fehlende Kacheln geladen, aber das war einmalig und seitdem nie wieder. Alles irgendwie typisch OMSI, aber wenig befriedigend

Im Gegensatz zu einem Drei-Sterne-Menü hat man hier mit dem Setra aber wenigstens ordentlich was auf dem Teller

Eine Stellschraube wäre die Kraft, die die Kupplung übertragen kann. Ist bei umgebauten OMSI-Bussen öfters mal der Haken, weil mehr Motorleistung gern gesehen wird, man aber vergisst, dass die auch übertragen werden können muss.

Von älteren ZF-Scripten kenne ich es, dass man öfters mal an Steigungen kleben bleibt, wird vielleicht so eines verwendet? Da dreht der Motor dann mit Höchstdrehzahl, aber der Bus rollt rückwärts.