Beiträge von wurstbrot

Willkommen in der OMSI-WebDisk!
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!

    Das Problem ist dabei, dass im Rahmen einer Payware mit dynamischen Modifikationsmöglichkeiten keine spezielle Hofdatei vorrausgesetzt werden sollte und die Fahrzeuge so nativ wie möglich zu funktionieren haben.
    So eine Tiefe integration kann man machen, wenn man wie Darius mit Hamburg oder Rolf damals beim O305 eine passende Karte mitliefert. Bei vielen Karten, ob Free- oder Payware, werden aber gar keine Rollbänder mitgeliefert.

    Die Matrixanzeiger können das, das "Rollband" liest ebenfalls extra Strings für die Seitenanzeige aus, sofern vorhanden. Schaut man durch die Steam rezensionen verschiedener Produkte stellt man fest, dass schon das reine reinkopieren von Hofdateien für einige Spieler zu viel verlangt ist. Mehr als MS Paint ist da auch nicht drin zum Erstellen von Rollbändern.
    Das ist alles nett und cool für uns Enthusiasten, aber so ein Fahrzeug muss auch für den 0815-Dulli funktionieren, wenn er dafür geld bezahlt hat.
    Perspektifisch wird auch der SL/SG eine passende Funktionalität erhalten, aber du hast ja schon selbst schön festgestellt, dass die Umsetzung keinesfalls einfach ist. Vorallem dann nicht, wenn das gesammte Rollband simuliert werden soll, auch wenn keine Texturen vorhanden sind.

    Würd ich tatsächlich wie beim O405 lösen. Der braucht keine extra Hofdateien sondern begnügt sich mit dem Standard, es müssen nur die Rollband-Strings eingetragen sein, sonst nix. Du lieferst ja zum Beispiel die Spandau-Hofs mit, die haben das schon eingetragen. Zwar in sinnloser Reihenfolge aber technisch würde der O405 Rollband das locker fressen. Beim Seitenrollband könnte man auch so einen Kompromiss machen wie beim O405 dass das gleiche genommen wird, oder wie schon erwähnt die Variante mit standardisiertem Suffix.


    Allgemein sind gesonderte Texturen für die Seitenanzeige schon wegen der Vorbildtreue erstrebenswert, auch bei Flipdot- oder LED-Anzeigen. Erst recht natürlich, wenn das Format ein anderes ist.

    Für den O405 hab ich vor einiger Zeit mal privat ein Rollband erstellt. Man kann für abweichende Texturen der seitlichen Anzeige unterschiedliche Wege gehen, z.B. für die Seite ein Suffix an den Dateinamen hängen oder einen weiteren String in der Hofdatei dafür nehmen. Ich hatte letzteres gemacht, weil ich verschiedene Bandpositionen vorne und seitlich kombinieren wollte, wenn zwei Linien dasselbe Ziel vorne mit unterschiedlicher Verlaufsangabe an der Seite nutzen. Für das einteilige Linienband hatte ich noch einen String verwendet und zur KI-Schilderung die Liniennummer als Dateinamen. Die hat das Script dann in der Hofdatei in den Terminus-Strings gesucht und mit der aktuellen Position abgeglichen, damit das Kurbeln auch bei der KI anständig aussieht. Das Script war am Ende recht komplex und hatte noch ein paar Bugs insbesondere bei der KI-Schilderung der Ziele, daher habe ich es nicht veröffentlicht.

    Auf jeden Fall interessante Ideen. Ich würde es auch begrüßen die Seitenanzeige zumindest optional gesondert zu behandeln, favorisiere da aber die Suffix-Variante aus Gründen wie oben erwähnt. Beim O405 wär es mir aber wurscht, da wäre ich tatsächlich um eine Veröffentlichung des Mods dankbar;-D Find es ist auch kein großer Mehraufwand beim erstellen der Texturen, da man häufig genau das gleiche nimmt wie vorne, nur packt man es in einen knapperen Rahmen. Hatte letztens für Mainz die Originalrollbänder vom O405/SG263 nachgebildet und dabei gesehen dass die an der Seite die exakt gleiche Schrift und Schriftgröße hatten wie vorne. Gab aber auch Betriebe die hatten Seitlich etwas mehr Text als vorne.

    VieleN Dank für die Mühe!


    Sieht ganz okay aus jetzt:


    Dachte aber vielleicht reduziere ich die Trans-Datei von 4096 runter (sind ja nur weisse Flächen...) aber dann sah es echt bescheiden aus. Ich glaube der interpoliert da was beim runterrechnen, vielleicht geht es besser auch mit geringer Auflösung.


    Von innen wäre es jetzt top wenn das die Farbe des Aufklebers hätte aber ohne die Piktogramme. Das geht aber sicher nicht so ohne weiteres?


    Auf der Haupttextur hast Du also an den Stellen der Aufkleber auch was gemacht? In meinem Beispiel hab ich die Alpha der Haupttextur nicht verändert.


    Finde auch die Arbeitsschritte aus der Haupttextur hin zur separaten Trans umständlich. Ich glaube das geht auch noch effektiver. Muss mir das in Fleisch und Blut aneignen, denn als i-Tüpfelchen sollen da später (und bei anderen Bussen) die Wagennummern auf die Türen, aber nicht jetzt per Hand einzeln sondern als Texttexturen. Das wird noch ein Spaß;-D


    Der Aufkleber sieht auch noch nicht ganz so toll aus, aber geht glaub ich nicht besser bei der Auflösung. Von innen gefällt der mir aber nicht:

    Wäre jemand so nett mir zu erklären wie ich korrekt Aufkleber auf Fenstern erstelle? Ich habe das schon gemacht aber das war wohl per trial and error dann richtig. Ich habe vorhin die Aufkleber im Template plaziert und dann im Alpha Kanal an diese Stellen 100% weisse Flächen gemacht. In OMSI sieht man aber nix davon. Ich denke mal ich brauche eine Transmap wo dann nur diese weisse flächen aus dem Alpha sind? Aber wie mache ich das? Ich kann ja nicht nur den Alphakanal abspeichern?


    Bus ist heute übrigens Stadtbus MAN NL und ich arbeite mit Photoshop.

    Das ist alles richtig. Trotzdem klappt es eben nicht immer wenn man "frei" setzt. Und vermutlich spielt die Bauart der Karte eine Rolle oder ob der Würfel und die Peopleboix auf einem Objekt sind oder auf Splines und und und. Und sogar auf Vorbild-Karten wie Spandau gibts das: ich meine "Am Bogen" Richtung Freudstraße hat so ein Problem.

    Das kann sein dass sowas dann stört. Ich meine aber das so noch nie gesehen zu haben. Habe aber hier immer mal gelesen dass Leute People-Boxen mit dem Würfel verbinden über die Parent-Funktion. Das könnte auch so kontraproduktiv sein wie in Deinem Beispiel.


    Bei mir ist es ein wüstes try and error immer bis das halbwegs an einigen Stellen ging, ohne wirklich erkennbare Muster. Manchmal 10 Würfel nebeneinander platziert und einer davon war dann "der Richtige"XD Macht man am Besten in dem man aber alle Fahrpläne vorübergehend löscht, denn dann wird jeder Würfel mit Leuten befüllt, außer denen die eben das Keine-Leute-Phänomen aufweisen...

    Moin!

    Ich möchte in der IVU Ticketbox das Fortschalten der Haltestellen mit Ansage mittels Kupplungspedal wieder aktivieren. Im Mmment hab ich schonmal die Fortschaltung samt Ansage über den cp_microphone Trigger im IVU Script aktiviert, was kein Hexenwerk war da dieser nur auskommandiert in der Triggerliste war. Funktioniert so wie ich es wollte. Nun aber will ich das ganze auch mittels Kupplungspedal haben, so wie in 99% der Busse auch. Im Cockpit-Script wird das Drücken der Kupplung ja abgefragt, ich weiss aber nicht wie ich das nun mit der IVU verbinden soll.


    Am Beispiel vom MX200 C2 Atron hier der Codeteil aus dem Atron der eben dies wohl tut:


    und hier wohl die gleiche Funktion aus dem MAN NL/NG von M&R aus dem IBIS2 Script:


    Wie münze ich das nun um für die IVU Ticketbox? Der Trigger dort der das tut was ich will sieht so aus:


    Es müssten also genau diese Macros und Funktionen irgendwie in das obige Scriptteil rein und das ganze dann im IVU Script zwischen die Trigger und Macros....

    Der einzige Unterschied bei der MAN Stadtbus-KI ist nur, dass die KI ein eigenes Script verwendet. der Rest ist nahezu identisch zum Standardfahrzeug. die KI Funktionalität (ausblenden von Meshes, reduzierte Modelle, LOD's etc.) existiert so auch schon in den "normalen" Wagen. Für den Placebo-effekt kann ich gern Busdateien mit anderen Namen in den Fahrzeugordner packen, das wird aber nichts messbares an der Performance ändern.

    Die einzige Lösung, die Vorteile mit sich bringt, wäre ein komplett eigenes KI Fahrzeug mit komplett eigenen Texturen, die deutlich kleiner ausfallen. Das bringt den Nachteil der Repaint-inkompatibilität mit sich.

    Tja, OMSI Und Placebo-Effekte... Ja da ist was dran;-D Ich bin mir bis heute aber nicht sicher ob mit [visible] (oder war es [viewpoint]???) ausgeblendete Objekte nicht trotzdem geladen werden und nur die Anzeige unterbinden. Genauso mit Gerätschaften die per CTI ein/ausgeblendet werden.


    Aber mit den Texturen und Repaints wird es natürlich kompliziert insbesondere dann für den Innenraum. Vielleicht eine eigene CTI Variable für KI-Innenraum machen die dann greift wenn KI-Version geladen wird? Der Repainter müsste dann natürlich KI und Non-KI eintragen und bereitstellen. Vielleicht kann man sich dann aber auch selbst basteln wenn gewissen Grundlagen da sind, nämlich dass das Modell dann tatsächlich auf eine andere Textur zugreift. Da habe ich eben beim C2 und Facelift für gewisse Teile ein Extra-Modell angelegt damit es beim Spielerbus hochauflösend ist und bei KI nicht. Diese beiden Busse sind aber ein extremes Beispiel dafür wie schlecht man mit Texturen umgehen kann, das ist beim SL/SG bei weitem nicht so der Fall.


    Scriptmässige Reduktion wäre super, da beiße ich selber oft ins Gras bei solchen Versuchen es selber hinzukriegen. Aber wenn Du das machst, schau mal ins AI-Script vom Stadtbus MAN NL NG: gerade gestern wieder eine Macke entdeckt wo das AI-Script das Kennzeichen am Nachläufer verschluckt. Das andere war das Dauerblinken dort in den Pausen und zu frühes Abfahren (aber lösbar durch Fahrplananpassungen).

    Ich denke ich werde bei den E5ern erstmal einfach die die "Konvekta" auf die vordere reduzieren, dann stimmt es halbwegs. Zumindest optisch, Steuerung davon ist ja wieder ein Thema für sichXD


    Hat sich eigentlich schon was ergeben beim Speichern-Bug mit aktivierter Hst-Bremse? Das nervt unheimlich immer dran zu denken keine Bremse drin zu haben beim Speichern.

    Moin!

    Jetzt wo es so kalt draußen ist seh ich in OMSI die KI-Autos dampfen als gäbe es kein Morgen mehr... Vielleicht passt das ja zu 80er/90er KI aber sicher nicht zu heutigen Autos. Die ganzen moderneren KI-Fahrzeuge dampfen aber auch genauso, bis auf die Aachener, die haben nicht mal Abgase;-D


    Hat denn jemand realistische Werte für "Dreck" und "Qualm"? Dreck ist wohl der reine Abgas, und Qualm der Dampf den man vor allem bei Kälte sieht. Find aber letztes immer noch viel zu viel. Würde das gerne reduzieren aber auch nicht ganz abstellen. Vielleicht wäre durchsichtiger machen eine Option wenn das geht, immerhin gibt es da irgendwelche Alpha-Werte.

    Beim MAN NG NL Stadtbus bin ich ratlos... KI Version hat das Problem, die normale anscheinend nicht. Habe dazu auch den Bus vom Backup eingespielt und das geprüft, ist auch der Fall.


    Beim Mainzer ist es nun insofern komisch da meine Version ohne K++ Matrix anscheinend das Problem nicht hat, die mit K++ aber schon. Der K++ GUE auf Grundorf taucht ohne Kennzeichen am Heck auf, der mit Standard-Matrix hatte kein Problem. Beim LC G ähnlich, aber mit K++ sehe ich auch Busse mit Kennzeichen hinten. Ohne K++ hingegen anscheinend auch ohne den Fehler.


    Ich vermute irgendwas bei den Texttexturen, habe aber keinen Schimmer ob das Problem in der Modeldatei dann liegt oder in den Scripten.


    Hier zur Anschauung am LC GUE testweise als Grundorf-KI:
    Vorne Kennzeichen okay

    Hinten kein Kennzeichen

    Nach dem Anklicken des Busses ist es da.... (Bus immernoch unter KI Kontrolle)


    Rätsel gelöst! Naja, zumindest die Ursache gefunden;-)


    Im Modell bei Texttexturen zu suchen war ein Irrweg. Problem ist das Script:

    Sowohl der Stadtbus-MAN NL NG (KI_Version) als auch der Mainzer LC G/GUE nutzen für AI-Betrieb ein anderes Script. Im Stadtbus-MAN ist es ein eigenes, im Mainzer das AI-Script aus dem D86. Das erklärt beim Mainzer warum beim draufklicken auf den Bus sich das Kennzeichen wieder zeigt. BeiM Stadtbus-MAN passiert das natürlich nicht, die AI-Version hat ja nur "Ihr" Script.


    Lösung ist erstmal bei den Mainzer LC's ist es das AI-Script rauszuschmeißen und beim Stadtbus-MAN dann leider die KI-Version nicht zu verwenden oder sich eine zu basteln die mit dem normalen Script läuft.


    Das ist natürlich nur ein Workaround, ich nehme mal an dass in den AI-Scripten eine kleine Änderung das ganze lösen würde. Das wäre der Königsweg hier. Ich vermute übrigens ganz stark dass der NG 92 von M&R ein ähnliches Problem hat. Komisch ist aber dass beim Mainzer das Verhalten unterschiedlich war mit K++ und ohne, zumindest beim GUE in Grundorf.

    ja, das ist geplant. :-) nen gewissen texturverbrauch wirst du aber immer haben, zumindest wenn man volle repaintfähigkeit beibehalten will. man könnte natürlich alles deutlich verkleinern oder generische texturen für den innenraum verwenden, dann geht aber eventuell sitzpolsterdesign und innenraumdesign verloren.

    Das ist halt die Frage. Aber ich sag mal so: wenn ich eine KI-Variante einsetze interessiert mich am Innenraum nur das was man von Außen sieht. Also die grobe Farbgebung, Sitzpolster, Stangen. Aber ich muss nicht die Aufkleber lesen können. Denn wenn ich ablösbare Busse will dann kann ich eh nicht die KI-Varianten nehmen, für solche Linien müsste man den normalen Bus nehmen und hoffen dass da mit [visible] alles vernünftig eingestellt ist.


    Was KI generell betrifft sehe ich aber dass im Gegensatz zu früher wo der Fokus auf FPS lag eher dahin gehen müsste Speicher zu sparen. Mit modernen Rechnern erreichen wir eigentlich ganz passable Bildwiederholraten, aber nach 3,2 GB Größe der EXE ist eben Sense, und das mit 4GB Patch. Ich bin also schon sehr dankbar wenn es Einsparmöglichkeiten gibt.

    Wie bereits bestätigt wurde, liegst du mit deinen Annahmen richtig. Sobald die Kachel mit der Ampel geladen wird, startet der Zyklus bei Null. Ob du bei grün ankommst, ist also Abhängigkeit von deiner Geschwindigkeit, der Anzahl der geladenen Nachbarkacheln und aus welcher Fahrtrichtung du kommst.


    Bei Omsi 1 waren deshalb alle Ampeln mit der gleichen Umlaufzeit immer synchron geschaltet, was dann mit Omsi 2 auf einmal nicht mehr funktionierte. In mindestens einem Fall hatte ich deshalb die Schaltphase einer Ampel verschoben, weil man an jener Stelle meist mit konstanter Geschwindigkeit ankommt.


    Eine richtige kachelübergreifende Grüne Welle hatte ich vereinzelt auch verbaut. Es ging zum Beispiel um 2 Kreuzungen im Abstand von 120 Metern mit unterschiedlichen Objekten. Dort habe ich dann die "Haltelinien" (also die Pfade mit Ampelzuweisung) aus dem einen Objekt in das andere verschoben. Ist nur nicht ganz trivial, die Koordinaten dafür herauszufinden. Also mehr oder weniger zwei Kreuzungsobjekte in eines gemacht nur dass ich zwischen den beiden Kreuzungen trotzdem Splines verwenden kann.

    Ich bin bei BRT auch relativ flott über die Kö gekommen und hatte einigermaßen "grüne Welle", obwohl ich das mit den Haltepunkten noch nicht ganz geblickt habe und dank SEV hatte ich eh keinen planmäßigen Halt. Ist es da irgendwie per Anforderung gescriptet oder gut gelungendes Timing?


    Wenn ich auf einer Karte die ganzen Kreuzungen von Spines auf Objekte umgestellt habe will ich schone in gutes Durchkommen erreichen, da erstens es eine wichtige Hauptstraße ist und zweitens der Fahrplan in der Realität wohl eine ÖPNV Bevorzugung eingeplant hat. IIn OMSI muss dann wohl das Timing stimmen, und hier und da vielleicht echt Anforderung.


    Kann ich auf einfache Weise die ganze Phase "verschieben"? Also angenommen die Phasen sind gut, wegen Timing will ich das aber +30 Sekunden alles verschieben. Geht das oder muss ich per Hand wirklich jede Phase im Kreuzungseditor ändern?

    Zitat



    nö das geht problemlos. :-) irgendwann wirds aber einfach unangenehm, die ganzen dateien zu handhaben, darum hab ich darauf verzichtet. rein theoretisch kann man auch einen trailer mit sitzbänken an einen vorderwagen mit stühlen hängen. :P

    Nee das wäre dann auch zu unübersichtlich. Ich kenn das ja vom MX200 C2, da blicke ich kaum noch durch. Ist ja einfach gemacht.


    Planst Du noch KI-Versionen? Für einen ernsthaften KI-Einsatz (kommt natürlich drauf an wo) würd ich auf jeden Fall kleinere Außentexturen nehmen, zumindest für einfache Repaints. In Grunddorf hingestellt war der Speicherverbrauch schon mal enorm im Vergleich, könnte sich also lohnen für die KI zu reduzieren.

    Ich denke mal es sollte kein Problem sein Mehrzweck-Vorderwagen mit Nicht-Mehrzweck-Trailer zu koppeln? Das wäre meine bevorzugte Variante beim SG.


    Muss mir aber noch eine Extra-Sicht für den Drucker basteln, das ist etwas komisch so mit der Nase unter den TastenXD

    Und nochmal zu den Ansagen:

    Im Script ist ja die Funktion im Prinzip da nur auskommandiert. Man kann sie leicht aktivieren, und ich hab das was ich wollte. Nur das blöde Kupplungspedal tut es nicht, es geht nur über die Tastatur. Versteh ich irgendwie nicht, da die Funktion ja im Cockpit Script steckt und weiterhin doch eigentlich aktiv ist.

    Heute habe ich in der AI-Liste wieder die KI-Versionen vom Stadtbus-MAN NL/NG aufgenommen statt der "Spielerbusse". Promt dann gesehen dass bei diesem ungefähr bei jedem zweiten Gelenkbus am Trailer kein Kennzeichen angezeigt wird. Davor hab ich das eine Weile nur beim Mainzer MAN LC gesehen. Irgendwie wird das Kennzeichen nicht immer korrekt an den Trailer weitergereicht. Und beim Stadtbus-MAN hab ich das nur bei der KI-Version. MX200 C2Gs und Facelift O530G haben keine Probleme. Jemand eine Idee?


    Edit: wenn ich den KI Bus dann anklicke und zu ihm wechsele erscheint hinten am Trailer dann das korrekte Kennzeichen. Kontrolle hat dabei immernoch die KI, aber der Status des Busses ändert sich und das Kennzeichen wird dann übertragen. In der Modell-Datei beim MAN NG ist übrigens als viewpoint 0 eingetragen, die SIchtbarkeit also auf immer gesetzt...