= Englisch [EN], 
= Deutsch [DE], 
= Französisch [FR]. Wenn du die angegebene Sprache nicht beherrschst, schreibe auf Englisch! Ist das nicht Fußgängern eig so, dass sie immer auf dem Fußboden laufen, egal wo der Pfad ist?
Auf jeden Fall ist auf vielen Maps zu beobachten, dass die people invis Spline auch gerne mal in 5 Meter Höhe gesetzt wird und dort auch bleibt. Dort laufen die Fußgänger dann auch nicht in der Luft, sondern auf dem Bürgersteig
Ist das nicht Fußgängern eig so, dass sie immer auf dem Fußboden laufen, egal wo der Pfad ist?
Auf jeden Fall ist auf vielen Maps zu beobachten, dass die people invis Spline auch gerne mal in 5 Meter Höhe gesetzt wird und dort auch bleibt. Dort laufen die Fußgänger dann auch nicht in der Luft, sondern auf dem Bürgersteig
Anscheinend nicht immer... Aber bei Autos hatte ich das letztens auch schon gesehen und mir gedacht wozu die ganze Mühe mit der Höhe bei der Genauigkeit wenn sie trotzdem auf richtiger Höhe fahren. Deshalb auch bei den Fußgängern erstmal nicht drum gekümmert, bis ich das an einer Fußgängerampel angeguckt habe wo sie auf Bordsteinhöhe blieben.
dass die people invis Spline auch gerne mal in 5 Meter Höhe gesetzt wird und dort auch bleibt
Das liegt vermutlich daran, dass beim invis_sidewalk (Marcel-Ordner) aus welchen Gründen auch immer der eigentliche Pfad ein paar Meter unter dem sichtbaren Spline liegt (beim invis_human Spline ist das nicht der Fall -> sh. Bild).
Die Personen laufen also (meiner Erfahrung nach) eigentlich schon immer auf der Höhe, auf der auch der Pfad im Reiter Tracks & Trips angezeigt wird (und zwar nicht auf Höhe des waagerechten Teils, sondern dort, wo der senkrechte Teil endet). Zumindest ist das bei invis Splines so, bei Kreuzungsobjekten scheint es ja, wie hier bereits diskutiert, andere Möglichkeiten zu geben.
gabs denn neuere?
nicht das ich wüsste. Weiss auch nicht, woher das kommt. Hat aber soweit ich weiss keinen Einfluss.
Und was bedeutet die [traffic_lights_group]?
Die Zahl direkt darunter, ist die länge deiner Ampelschaltung in Sekunden. Anschliessend folgen die restlichen Einträge zu deiner Ampelschaltung.
Weiss auch nicht, woher das kommt.
Denke mal das die Version intern war. Bis auf das fehlende Mesh ist der rest völlig normal.
Es soll auch einen X Konverter gegeben haben der die O3D Datei verschlüsselt hatte.
Es soll auch einen X Konverter gegeben haben der die O3D Datei verschlüsselt hatte.
den gibt es. Hab den bei mir im SDK-Ordner
Ja den gibt es auch, aber es gibt noch einen Konverter der den O3D verschlüsseln tut, damit man mit ein §D Programm wie zum Beispiel Blender mit entsprechenden Plugin nicht öffnen kann.
Wie ist das denn mit den Schaltzeiten, ich setze 2s für Gelb nach Grün und 3s für Gelb nach rot, dazwischen 2s noch als Puffer wo beide Seiten rot haben. Ich meine generell, nicht nur bei Fußgängerampeln. Da geht es mir darum was sich in OMSI bewährt hat, falls es da reale Vorgaben gibt ist das schön und gut, aber die OMSI KI ist ja schon eigen
Was mich auch noch gerade wundert und wo ich keine Dokumentation zu finde ist warum es im Ampeleditor so wie viele Zustände für Grün, rot etc gibt. Ich glaube je drei, und es steht nicht bei wo da der Unterschied ist. Gibt es irgendwo eine Liste was das dokumentiert?
Die realen Schaltzeiten funktionieren für Omsi ganz gut. Da gibt es ganze (kostenpflichtige) Regelwerke, wie Ampeln in Deutschland programmiert werden müssen. Ungesicherste Linksabbieger (also wo geradeaus und Linksabbieger gleichzeitig grün haben) brauchen in Omsi etwas länger um von der Kreuzung runter zu kommen. Faustregel für Fußgängerampel: 3s gelb, 2s rundumrot, 5s Fußgänger, 3s pro Kfz-Spur rundumrot, 1s rot-gelb.
Die vielen Zustände können von anderen Ampeln interpretiert werden. Es ist meines Wissens hard gecoded, dass grün+aus "go" heißt und gelb+rot+rotgelb "stop". Ich habe die verschiedenen Zustände z. B. für eine Fußgängerampel mit Räumanzeige verwendet.
