= Englisch [EN], 
= Deutsch [DE], 
= Französisch [FR]. Wenn du die angegebene Sprache nicht beherrschst, schreibe auf Englisch! Ich denke die paar cm sieht man kaum, und ich glaube sogar in Spandau wurde nicht drauf geachtet. Aber wenn man vor so einer Ampel steht und sieht jemanden rübergehen dann kann das komisch wirken.
Die Idee mit absheight klingt gut, ich glaube das könnte das einfachste sein.
Jetzt nochmal ui dem Pfad der Fußgänger über die Straße... Das soll ja ein Pfadsegment sein. Wir haben aber erstmal auf beiden Seiten Bürgersteige mit sagen wir mal 10 cm Höhe. Wenn ich den Pfad also als ein Stück rüber lege über die Straße schweben die Fußgänger ein wenig. Ich würde ja am liebsten nach dem Bordstein eine kleine Senkung bzw Erhebung haben, kann das aber nicht tun weil sie dann ein Stück auf der Fahrbahn warten würden. Mach ich das auf dem Bürgersteig stecken sie im selbigen mit den Füßen. Sieht aus als ob man das eine oder das andere hinnehmen müsste, oder gibt es einen Trick?
Du musst in der Kreuzungsdatei mit dem Texteditor die [approachdist] für die Ampelphase Fussgaenger anpassen. Die ist default bei 0, d. h. wenn ein Fußgänger auf der Kreuzung läuft, kommt die Anforderung - macht natürlich keinen Sinn. Hier den Wert auf 1 setzen! Jetzt kommt die Anforderung, wenn er auf dem segment steht oder (in Gehrichtung) bis zu 1 m davor ist. Passt wunderbar, denn der Drücker für Fußgänger ist auch in echt kurz vor der Kreuzung
.
[approachdist] zu editieren macht generell Sinn bei Anforderungen. Bei Fußgängern ist es aber ein Muss. Beim erneuten Speichern wurde bei mir auch nie was überschrieben.
Das klappt nun;-)
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?
Ich finde es schade das er jetzt für den Schrott Lotus ein Addon erarbeitet . Es hätte noch sehr viel für Omsi machen können und ich glaube (eine Vermutung) sind mehr „Busspieler“ als in Lotus ?
Das hängt einzig und allein mit dem Content zusammen. Straßenbahn war und ist nun mal das erste was da funktioniert hat, zum Busfahren gab es lange nur einen unfertigen DD. Das lockt keinen Bus-"Spieler". Allerdings hat nur eine kurze Runde mit den Ding gereicht um zu sehen dass der schon in diesem Rohzustand 1000 mal realer angefühlt hat als jede andere Bussimulation inklusive The Bus und auch zig realer als ETS. Da war genau das mit Physik was hier schon angesprochen wurde, was das A und O der Simulation ist und was OMSI hat und andere eben nicht.
Bei den letzten Installationen hatte ich ein wenig drauf geachtet. Ich hatte neu den O530, Stadtbus II und Hohenkirchen, und den S415 wenn ich mich nicht irre. Schön Backup gemacht und dann alles geprüft ob was verändert wurde. Nix, auch die exe blieb gepatcht. Dann gab es für die Busse je ein Update und hab wieder alles geprüft, es wurden nur die betreffenden Daten geändert. Also bis dahin völlig unproblematisch. Irgendwann vor ein paar Tagen fuhr ich den O405 wieder und hab festgestellt dass irgendwas komisch war (hatte da paar kleine Modifikationen). Hab da einfach ein Backup zurück gespielt und es war wie ich es kannte. Ich hab keine Ahnung wann , was und wieso am O405 von Steam gemacht wurde... Rest wie die gepatchte exe und andere Dinge waren anscheinend unberührt. Schon irgendwie undurchsichtig, und man kann sich 0 darauf verlassen ob Steam was prüft und ändert und wenn ja was.... Man muss IMMER ein Backup parat haben.
Nee, meine Anforderung springt dann zu 35, während es ohne in der Schleife 0-35 bleibt...
Hab aber den Fehler gefunden:
Tatsächlich muss ich die erwähnte ApproachDist von 0 auf 1 in der .sco Datei setzen da dies der Editor wohl nicht tut. Mal gespannt ob er mir das jedes Mal dann mit einer 0 bei Änderungen überschreibt. Aber nun funktioniert's;-)
Was bleibt ist dann noch das mit der mangelnden Kundschaft an der anderen Ampel
Das klappt nun ganz gut nachdem ich den ganzen Pfad zwischen den Bordsteinen als Ampel markiert habe.
Die Anforderungsfunktion klappt aber noch nicht, ich habe dann ein Dauergrün für die Autos. So sieht meine Schaltung aus:
Eigentlich müsste es dann doch Dauergrün geben wenn kein Fußgänger da ist, wenn einer rüber will müsste die Anforderung starten. Der Fußgänger wartet aber ewig und es bleibt bei Grün für Autos. Irgendwas ist da also nicht richtig bedacht? Gleiches Ergebnis übrigens wenn ich das zweite Häkchen wegmache. Irgendwo hab ich mal was von einer Approach-Dist was gelesen, wüsste aber nicht wo ich denn diese eintragen muss. Vielleicht liegt es daran?
Bei einer anderen Ampel tauchen keine Peds zum rübergehen auf- Auf beiden Seiten gibt es in jede Richtung eine Verbindung mit den Pfaden vom Bürgersteig wo auch dauernd Leute vorbei gehen. Die Pfadverbindungen müssten ausreichend gut sein, ich versuch da immer testweise ein StnLink drüber zu legen um zu schauen ob OMSi eine Verbindung erkennt, und das tut es.
Der Drucker verdient die Auszeichnung "schlimmster Fahrkartendrucker in OMSI seit 2011". In keiner Version funktioniert er richtig. Kurz dahinter kommt der "Kindergarten"-Drucker aus dem Bad Hügelsdorf DLC. Der funktioniert zwar, ist aber an sich sowas von von bäh
Die AIlist ist definitiv Kaputt, in den Fahrplänen sind andere Fahrzeuggruppen wohl eingetragen als in der AIlist, daher die Errors anfangs.
Der angesprochene Fehler weist auch auf Fehler in der AIlist hin, meist irgendein Verschreiber im Pfad oder im bus-Datei-Namen.
Nach knapp über einer Stunde ist die 32 Bit Speichergrenze erreicht und da ist eh Schicht im Schacht. Ich kenne die Map nicht, aber um diesen Punkt rauszuzögern musst Du vor allem die Vielfalt in der Ailiste reduzieren und/oder auf speicherhungrige Busse da verzichten. Im Verdacht hab ich da vor allem die diversen O530er, da gibt es nicht mal spezielle AI-Versionen. Beim C2 setzt Du auch nicht konsequent die AI-Versionen ein, zum Beispiel hast Du den MB_C2_E6_LE_Solo.bus drin. Außerdem unzählige Typen des C2, der out of the box auch nicht gerade sparsam ist.
Mir fällt nur ein polnischer Solaris-Mod ein der das nicht konnte. Alle anderen die ich kenne können das und haben höchstens die Ausblendung des Kennzeichens als Option. Bei Wagennummern kann ich es noch halbwegs verstehen dass man diese aufs Repaint der Einfachheit halber pinselt weil ja jedes Unternehmen die an anderen Stellen hat, denke aber wenn man sie wirklich für sein Betrieb an einer bestimmten Stelle haben möchte dann wäre es besser die Texttextures entsprechend zu erstellen. Der Speicherverbrauch würde danke sagen Bei wenigen Wagen würde sich die Mühe natürlich nicht lohnen.
Aber zurück zu Kennzeichen:
Wenn dann kann man ja auch in der Bildbearbeitung direkt an der Stelle das Wunschkennzeichen doch hinschreiben, den entsprechenden Font vorausgesetzt und den Hintergrund mit Plaketten und EU-Zeichen.
Also bei 100 Bussen im Depot 100 Repaints? Sehr klug.
Warum eigentlich der Azfwand? (Fast)jeder Bus und jedes AI Auto liest die Kennzeichen aus der AIList oder ordnet sie gemäß der Regs-Datei zu... Oder wollt Ihr auch das Datum auf den Plaketten lesen können?
Sinnvoller fänd ich einen Kennzeichengenerator der mir eine Liste zufallsgenerierter Kennzeichen rausspuckt, die aber für die ausgewählte Region auch gültig sind. Sowas hab ich mal gesucht und nicht gefunden.
In den OMSI Einstellungen unter Geräusche die Anzahl auf maximum stellen.
Glaube kaum dass es was bringen wird. Die Sounds sind wohl auf gewisse Weise priorisiert, sodass auch bei nur 50 maximalen Sounds Fahrgaststimmen oder Geräusche des eigenen Busses zu hören sein sollten. Eher entfällt dann Vogelgezwitscher, Glockengeläut, Martinshorn oder Geräusche der KI. Ich schätze das Problem liegt woanders.
Ach, also der gersamte Bereich der über die Straße geht? Wäre ich nie drauf gekommen, weil bei Autos macht man es eben auch vorher damit sie dann noch die Kreuzung räumen können. Aber macht irgendwie Sinn. Setzt aber voraus dass zwischen den Straßenseiten nur ein Pfadsegment besteht. Ist aber da der Fall.
Moin!
Meine Fußgängerampel funktioniert soweit, habe aber gesehen dass mal ein Fußgänger stehen blieb kurz vor dem Ende der Straße und dann erneut wartete. Ich vermute mal die Ampel wurde rot während er rüberging, und auf der anderen Seite gibt es ja auch einen PFadabschnitt mit der Ampelphase. Da die Fußgängerpfade 2-way sind gibt es da doch grundsätzlich das Problem dass sowas passieren wird. Wie löst man das denn am Besten? Ich sehe einmal die Möglichkeit an dieser Stelle zwei Pfadstücke übereinander zu legen mit jeweils entgegengesetzter Richtung und nur für eine Richtung das mit der Ampel zu verknüpfen, oder den zeitlichen Puffer zum Überqueren zu erhöhen.
Erste Möglichkeit ist wohl sehr fummelig im Editor. Die zweite wäre recht simpel, man wäre aber nicht vor allen solchen Situationen geschützt, da diverse Umstände dann ja trotzdem dazu führen könnten.
Wie macht Ihr das?
Zweite Sache:
Diese Ampel schaltet im Moment voll zeitgesteuert. Ich würde gerne sie aber nach bedarf schalten. Dazu habe ich mir die Busschleife Reimerweg angeschaut wie da die Anforderungsampel funktioniert, und das Prinzip müsste dafür ja auch gehen. Gibt es aber vielleicht irgendwo eine Fußgängerampel deren Phase man als Template für sowas übernehmen könnte?
Nun ja, nach so langer Zeit muss man sich als Entwickler oder Vertrieb eben umschauen. Es kann ja theoretisch sein dass Microsoft mit einer neuen Windows-Version ungewollt OMSI unspielbar macht, und die werden das zu 100 Prozent nicht patchen. Und dann wird es ganz schnell ganz düster, da Otto-Normal-Spieler sicher nicht für ein Uralt-Spiel eine separate alte Windows-Installation bereithält.
Interessant ist aber schon dass nach 10 Jahren NIEMAND eine ersthafte Alternative zu OMSI zustande gebracht hat. Bus SImulator XX ist Spielzeug, The Bus schon besser auch auch eher keine Simulation. Von SImBus erwarte ich nicht viel;-D
F9 ändert (mehr oder weniger gut) den Andockpunkt des Objekts, was du gerade (bewegbar) in der Hand hast. Eine Weiche hat bspw. ja drei Andockpunkte, normalerweise wird aber der genutzt, der "vor" der Abzweigung (nur ein Gleis) liegt. Mit dem Drücken von F9 bewirkst du, dass diese Andockpunkte durchgegangen werden, also auch die "nach" der Abzweigung genutzt werden können. Ist in der Handhabung ein bisschen schwierig, funktioniert aber einigermaßen.
So wie Du es beschreibst könnte das in diesen Fällen tatsächlich die Lösung sein. Muss mal ausprobieren wenn das Problem wieder auftaucht.
Aber 32 Bit jetzt auf 64 Bit noch zu portieren, das hat 0 Vorteile.
Och, das hätte enorme Vorteile. Die Speichergrenze ist mit Abstand das größte Problem in OMSI. Die Performance machen immer schnellere Rechner wett, und das garnicht so schlecht da OMSI fast 1:1 mit der Core-Performance skaliert. Da beginnt dann aber ein Teufelskreis: weil modernere Rechner augenscheinlich mehr Objekte etc erlauben ist ganz schnell aufgrund der Speichergrenze Schicht im Schacht. Diese Grenze aufzulösen wäre gerade in der heutigen Zeit bei der heutigen Map- und Busqualität ein enormer Sprung nach vorne.
Übrigens hat der TSC immer noch massive Speicherüberlauf-Probleme und segnet den User mit Abstürzen ab bestimmter Speichernutzung. Die 64 Bit-Version da ist eher eine 33 Bit Version
mal F9 probiert, während du die Kreuzung in der Hand hast?
F9? Kenne da keine Funktion drauf. STRG hab ich zum andocken verwendet.... Bei den letzten 3 Kreuzungen gab es keine Probleme.
Ich versuch mal einen anschaulichen Screen zu machen wenn das Problem genau wieder da ist.
Ich muss ja an die Car-Pfade andocken. Manchmal dockt aber eine Spline über die Fußgängerpfade plötzlich an, das ist auch ein Problem was ich nicht so ganz verstehe.
Hier ein grundsätzliches Beispiel, eine Kreuzung in Ober-Olm:
Hier liegen nun die temporären Pfade mit Invis-Splines. Ich hab schon beim erstellen gesehen dass ich zum Beispiel oben rechts nicht andocken konnte, nur links oder unten. Ich muss schon beim Export wissen wo ich später das Objekt andocken kann, da dies die erste ausgewählte Spline bestimmt. Und wenn ich später dann keinen Andockpunkt dort habe war entweder alles für die Katz oder ich brauche Chirurgenhände und muss es frei platzieren.
