Beiträge von wurstbrot

Zitat von beedle der barde

Aus der ferne werden die Lichtpunkte eine Kachel "vorher" angezeigt, bewegt man sich eine Kachel näher, verschwinden diese wieder.

Das klingt exakt nach dem was ich hier beobachte. Daher vermute ich dass das Problem ähnlicher Natur ist. Die AMpeln sind zwar attached an die Masten (Objekte), hatte aber gleiches Phänomen als ich da testweise welche lose hingeklatscht habe.

Probleme hatte ich mal an anderer Stelle wo der Lichtschein einer Ampel mal durchkam die wegen Chrono aber garnicht da sein dürfte. War aber dort gleiche Stelle, nur falsche zeit.

Moin!

Mir ist was seltsamen aufgefallen, und ich bin mir nicht sicher ob ich es nur immer übersehen habe oder ob das recht neu ist. Auf der Karte Mainz an der Haltestelle Hallgarter Straße hab ich das entdeckt und dachte dass es vielleicht ein selbst verursachtes Problem ist, weil ich derzeit an Ampeln sowieso gebastelt habe. Das Betrachten der Vanilla-Karte im Backup brachte mich aber dazu anzunehmen dass es vermutlich irgendein Baufehler ist. Mich würde interessieren ob jemand von Euch sowas ähnliches schon mal gesichtet hat und ob es eine Lösung gibt.

Lassen wir erstmal ein Bild aus dem Editor sprechen. Dazu sei gesagt dass man es im dunkeln natürlich besser sieht, daher Tageszeit dort auf Nacht gestellt:

Wie Ihr seht gibt es nach der Kreuzung kurz nach der Haltestelle drei Ampel-Lichtpunkte eine grünen Ampel (der linke etwas schwach). Die Ampel zu der diese Lichtpunkte aber gehören befindet sich weiter hinten die Straße rauf. Die Pfeile zeigen die Lichtpunkte, die Kreise umranden die zugehörige Ampel.

Wenn cih mich nun im Editor (und auch im Spielmodus) vorwärts bewege verschwinden die falschen Lichtpunkte. Entferne ich mich zurück bis vor die Kreuzung sieht man sie wieder. Lösche ich die Ampel, verschwindet auch der Lichtpunkt. Füge ich eine Ampel daneben hinzu, gibt das einen zusätzlichen Lichtpunkt.

Ich habe auch testweise einen anderen Ampeltyp versucht, es ist das gleiche. Und aufgefallen ist es mir nur an dieser Stelle, sonst nirgendwo.

Allerdings sind wohl Ampeln an sich nicht das Problem. Drauf kam ich als ich mit dem Bus da lang fuhr, an der Kreuzung wartete und neben mir auf der Gegenspur mehrere rote Lichtpunkte sah die nach Bremslicht aussahen, aber ohne Autos. Dann verschwanden sie. Jetzt vermute ich dass es die Lichtpunkte der KI Autos sind die an der nächsten Ampel standen. Also ebenfalls um 199-200m verschobene.

Damit würde ich nun annehmen dass an der Kachel was nicht stimmt. Wenn man eine Kachel weiter ist dann verschieben sich irgendwie die Lichtpunkte. Aber was wäre die Ursache?

Alles klar, das macht Sinn, denn aktuell blinkt die bei jeder Ampelphase durch.

Danke, Genau so ein Verbindungsstück hab ich vermisst;-) Wobei ich bei zwei Ampeln mir beholfen habe mit zwei gegenüberliegenden Attachmentpoints und dann Ampeln dran im 90 bzw 270 Grad Winkel. Aber bei 3 würde es nicht mehr so gehen, die in der Mitte würde dann rausragen.

Ich verstehe aber auch noch nicht ganz dieses eine von Helferlein mitgelieferte Verbindungsstück für Grünpfeile oder ander 2-feldige Anhängsel. Wo würde das denn attached werden?

Weisst Du vielleicht auf die schnelle wie man dieses blinkende Schutz-Zeichen konfiguriert? Also zum Beispiel bei Linksabbiegern vor dem Fußgängerweg während dieser grün hat. Was muss ich da tun, eine zusätzliche Gelbphase einbauen für die Zeit?

Moin!

Ich spiele gerade etwas rum mit dem LED Ampelset von Helferlein. Gerade versuche ich an einem Mast zwei 3-feldige Ampeln nebeneinander zu plazieren. Ich habe alle Halterungen durchsucht, sehe aber keine Winkel oder ähnliches um das hinzukriegen. Bei Zubehör finde ich auch nichts. Hat da jemand eine Idee?

{trigger:taster_standheizung}

    (L.L.cp_taster_standheizung_target) ! (S.L.cp_taster_standheizung_target) s1

    1 (S.L.cp_taster_standheizung)

    (C.L.auxheat_via_button) !
    {if}
        l1 (M.L.kippschaltersound)
        l0 (S.L.cp_taster_standheizung)
    {endif}
        
{end}

Bis zu dem Teil mit dem auxheat via button ist das doch ziemlich standard? Ich glaube ich habe testweise diesen Teil auch mal gelöscht und keinen Unterschied gesehen.

Kann es sein dass es gar nicht an den Scripten liegt sondern am Schalter selbst? Das Klacken bei diesem Schalter ist nämlich auch umgekehrt. Man hört den Sound für "ein" wenn ich ihn ausschalte und umgekehrt. in der Model-Datei ist er aber wie alle anderen Schalter konfiguriert:

########################################################
Kippschalter
########################################################
[mesh]
dash/K1.o3d

[mouseevent]
taster_standheizung

[newanim]
origin_from_mesh
anim_rot
cp_taster_standheizung
-10

--------------------
[mesh]
dash/K2.o3d

[mouseevent]
cp_dummy_sw08_toggle

[newanim]
origin_from_mesh
anim_rot
cp_dummy_sw08
-10

--------------------
[mesh]
dash/K3.o3d

[mouseevent]
cp_heizluefter_toggle

[newanim]
origin_from_mesh
anim_rot
cp_heizluefter_sw
-10

--------------------

Ich würde annehmen die Animation ist falsch konfiguriert, bei jedem anderen Schalter ist es aber auch so und richtig...

Edit: Nee, doch wohl eher Script. Wenn ich die Standheizung auf andere Schalter lege funktioniert sie auch verkehrtrum.

Moin!

Ich wollte im Mainzer LC mal das Heizungschaos aufräumen und die Taster korrekt zuweisen. Soweit so gut, Taster 1 funktioniert nun per Maus und Tastatur als Standheizung, Taster 2 als Raumheizung. Vorher war Taster 2 die Standheizung und die Raumheizung war nur per Tastatur-Trigger ansprechbar. Jedoch hab ich jetzt das Problem dass der Taster 1 (Standheizung) umgedreht funktioniert: ist er gedrückt dann ist die Standheizung aus, ist er nicht gedrückt ist diese an. Damit einher geht ein dass nach dem Auswählen des Spielerbusses standardmäßig die Standheizung an ist. Ich möchte aber natürlich dass der Taster beim drücken die Standheizung aktiviert und natürlich standardmäßig aus ist.

Aber wo lege ich seine Zustände fest? In der cockpit.osc beim Trigger sicher nicht? Im Macro standheizung_frame der heizung.osc?

Hier die Taster:

Auszug Model-Datei:

########################################################
Kippschalter
########################################################
[mesh]
dash/K1.o3d

[mouseevent]
taster_standheizung

[newanim]
origin_from_mesh
anim_rot
cp_taster_standheizung
-10

--------------------
[mesh]
dash/K2.o3d

[mouseevent]
cp_dummy_sw08_toggle

[newanim]
origin_from_mesh
anim_rot
cp_dummy_sw08
-10

--------------------
[mesh]
dash/K3.o3d

[mouseevent]
cp_heizluefter_toggle

[newanim]
origin_from_mesh
anim_rot
cp_heizluefter_sw
-10

--------------------

Das ist der aktuelle Code den ich testweise nutze:

######################################
Fahrgäste
######################################

[sound]
chat-low.wav
1

[viewpoint]
2

[3d]
0
0
0
7

[volcurve]
humans_count

[pnt]
0
0

[pnt]
5
0

[pnt]
15
0.5

[pnt]
60
0

[conditionSingle]
humans_count
0
3

[volcurve]
Time

[pnt]
0
0.2

[pnt]
39600
1

[pnt]
54000
1

[pnt]
86399
0.2

[sound]
chat-high.wav
1

[viewpoint]
2

[3d]
0
0
0
7

[volcurve]
humans_count

[pnt]
15
0

[pnt]
90
1

[conditionSingle]
humans_count
0
3

[volcurve]
Time

[pnt]
0
0.2

[pnt]
39600
1

[pnt]
54000
1

[pnt]
86399
0.2

Vielleicht hat ja jemand bessere Werte?

Versuch mal

cp_Stadionschalter_up

cp_Stadionschalter_dn

Die sind aber nur für den Modus als Kipptaster, nicht für den grünen Taster, da fehlt ein Trigger mit Toggle-Funktion.

Zitat von BusfahrerP

OMSI zählt die Text Texturen selbst, die Zahlen oberhalb von [texttexture_enh] sind bla bla für den User / Modder zur Orientierung

Richtig, aber wenn man sie löscht oder ein Chaos damit veranstaltet dann möchte ich denjenigen sehen der sie dann später korrekt bei den [useTextTexture] einfügt. Es ist schon eine sehr große Hilfe.

Also bräuchte es da eine Art Übersetzung im IVU Script? Z.B. IVU Port 3 bis 5 auf einen String?

Vielleicht ist es da schlauer direkt den Bildschirm durch einen kompatiblen zu tauschen.

Hat jemand beim NLC schon das Infotainment-Display an die IVU angeschlossen? Ich krieg da nächste Haltestelle hin, aber bei den Folgehaltestellen hört es schon auf. Ich sehe auch nur 3 Texttexturen dafür:

118
[texttexture_enh]
IVU_freier_Port_03
nlc_Infotainment
418
129
0
0
0
4
1
1

119
[texttexture_enh]
IVU_freier_Port_02
nlc_Infotainment_B
423
43
0
240
0
0
1
1

120
[texttexture_enh]
IVU_freier_Port_10
nlc_Infotainment_B
504
81
0
198
189
11
1
1

Bei der "einfachen" Innenanzeige gab es ja das Problem dass sich da alles überlappt hat, nehme mal an das ist immer noch so.

Zwei Dinge hab ich heute:

Passagierpfade:

Mir fiel öfter schon auf dass an Tür 1 immer mal jemand am zweiten Türflügel auftauchte und wieder verschwand. Jetzt hab ich gesehen wo sich diese Personen hingebeamt haben. Hier ein Bild mit zwei Damen auf Stehplätzen im vorderen Busteil des 18C:

Beide kamen anscheinend durch Tür 2 rein, gingen dann nach vorne zu Tür 1 (zweiter Flügel) und taten so als würden sie aussteigen, verschwanden jedoch an der Türkante und beamten sich zu den Positionen im Screen. Das finde ich ein wenig seltsam, denn sie müssen im Gang ja an den Positionen erstmal vorbeigelaufen sein.

Anfahren 18C bei aktivierter Start-Stop-Automatik:

Im Gegensatz zum 12C hab ich hier oft den Eindruck dass beim Anfahren was hängt bzw nicht gelöst wird. Laut Display ist Gang bereits drin, Umdrehungen öfters schon am Verlassen des grünen Bereichs, erst dann fährt die Kiste los mit relativ heftigem Ruck. Es ist aber nicht immer so, es ist auch öfters wie gewollt: Motor springt an, langsam steigen mit Gas die Umdrehungen, man merkt wie das Heck anschiebt und es geht los. Ich habe den Eindruck dass da irgendwas noch blockiert. Ist Start-Stop deaktiviert verhält sich der Bus auch erwartungsgemäß.

Laut Logfile lädst Du gar nicht Mainz sondern Ingolstadt, und bei dieser fehlen haufenweise Objekte. Das einzige was hier mit Mainz zu tun hat ist ein einziges Mainz-Objekt welches nicht gefunden wird und aus dem Lieferumfang der Karte Mainz stammt.

Danke, jetzt funktioniert's. hab den Bus relativ vollgepackt mit Leuten, dann Uhrzeit auf 11 Uhr gestellt, dann auf 23 Uhr und zurück auf 11. Um 23 Uhr war es mucksmäusschenstill bei 50 Leuten

Jetzt nur noch eine sinnvolle, realistische Kurve austüfteln.

Also wo keine Bordsteine mit im Spiel waren war zum Beispiel mehrfach in Mainz beim runterfahren von der Theodor-Heuss-Brücke Richtung City in etwa da wo die Rampe aufhört. Da bin ich zig mal mit diversen Bussen lang und hatte die Stelle nie als kritisch in Erinnerung, bin mit dem NLC aber mehrfach wohl so aufgesetzt dass alle aussteigen wollten. Bei Tempo unter 30. Sowas ähnliches hatte ich in Grundorf am Bauernhof kurz vor der Ampel beim runterfahren. Man muss aber schon Beförderungsfälle geladen haben, ein normales Rumpeln darf ja schon hier und da natürlich sein.

Ansonsten kann ich Dir leider keine weiteren exakten Stellen benennen. Hohenkirchen will ich zum Beispiel nicht mit aufführen denn da ist es mit jedem Bus problematisch.

Das Küssen der Bordsteine ohne sie sichtbar zu berühren ist zum Beispiel auch nicht an bestimmte Orte gebunden. Es fällt nur auf dass es mit dem NLC passiert und mit anderen Bussen eben nicht.

Zitat von Karbonat Erol

ich musste damals für den Ruhr-Urbino die Boundingbox ebenfalls verkleinern (bzw. höher legen), weil bei der Nitzschmännchen-Splinebauweise die Karre auch überall kollidiert ist. Realismus hin oder her, wenn die Fahrbarkeit drunter leidet, sollte man das gegebenenfalls etwas entschärfen. Nicht jede Karte hat millimetergenaue Kreuzungsobjekte mit perfekter Kollision.

Es sind nicht nur Spline-Straßen. Mich zerhaut es regelmäßig auch an Orten die aus einem individuellen Gesamtobjekt bestehen. Es kann aber schon gut sein dass es bei Spline-Gepfusche häufiger ist. So ganz eindeutig ist es aber auch nicht, ich kenne Stellen da würde ich im Vorfeld sagen dass da sicher gleich die ganze Mannschaft aussteigen will, dem ist dann aber nicht so. Und dann setze ich auf bei Stellen wo ich mir denke was ist denn da los...

Ich finde den Ansatz gut da der Spielbarkeit Vorrang zu geben und zum Beispiel die Boundingbox wenn diese das verursacht eben leicht anzupassen. Wahrscheinlich geht es nur um Millimeter die ausreichen würden.

Hab es vorhin ausprobieren wollen, leider kommt beim Laden dann "Time ist kein gültiger Intergerwert".

######################################
Fahrgäste
######################################

[sound]
chat-low.wav
1

[viewpoint]
2

[3d]
0
0
0
7

[volcurve]
humans_count

[pnt]
0
0

[pnt]
5
0

[pnt]
15
0.5

[pnt]
60
0

[conditionSingle]
humans_count
0
3

[volcurve]
Time

[pnt]
0
0

[pnt]
39600
1

[pnt]
54000
1

[pnt]
86399
0

[sound]
chat-high.wav
1

[viewpoint]
2

[3d]
0
0
0
7

[volcurve]
humans_count

[pnt]
15
0

[pnt]
90
1

[conditionSingle]
humans_count
0
3

[volcurve]
Time

[pnt]
0
0

[pnt]
39600
1

[pnt]
54000
1

[pnt]
86399
0

Kann ich bestätigen. Da wo andere Busse keine Probleme haben gibt es beim 12C und 18C Probleme. Es fühlt sich an als würde der Boden aufsetzen, aber auch mit Bordsteinen gibt es Probleme. Ich hing auch schonmal irgendwo fest obwohl nichts sichtbar war. Ich glaube aber auch vor dem Update war der Bus sehr sensibel was Kaugummi auf dem Asphalt betrifft.

Die Experimentelle Version zeigt die Abfahrtzeiten an den Haltestellen an, sofern eine passende Datenroute in der Hofdatei vorliegt. Weitere Unterschiede hab ich leider nicht auf dem Schirm, da ich gefühlt seit immer schon diese Variante nutze.

11 wird nicht zu 115. 11 bleibt 11. Ab 57 wirds geändert um 50 (experimentelle Version) bzw. 44 (Stable Version).