Und immer dran denken sich eine Sicht zu basteln um den falschen Fahrschein abreißen zu können
Vielleicht wäre dafür ein Hotkey gut...
Beiträge von wurstbrot
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! -
-
Error: Fahrzeug mit Ident 29432 (Vehicles\MB_O530_Facelift\MB_O530G Facelift_3-Doors Main_k++_ki.bus) hat mit ung ltiger HDG versucht, eine Belegung zu erzeugen!
Explizit wird nur dieser eine Bus mit der Fzg-Nummer 29432 bemängelt.
Genau um diesen Fehler geht es mir ja, das mit den Unscheduled AIs ist was anderes, die prüfe ich auch gerade. Ich habe den Halycon -Gliederzug im Verdacht, da fehlt eine Datei die nicht mitgeliefert wurde.
Eine Fahrzeug-Nummer 29432 hab ich nicht, die sind Drestellig. Das muss irgendeine Interne ID sein? Der Bus läuft immer noch tadellos auf Grundorf...
-
Das ist die Log von gestern: logfile.txt
Da haben aber auch ein Halycon-KI-LKW was rumgespukt und seltsamerweise auch der Aachen-Atego. Das mit dem unscheduled bezieht sich dann glaube ich auf diese und nicht auf den Bus. Daher prüf ich das gesondert auf Grundorf.
Trotzdem hier mal der Unscheduled-Ausschnitt aus der AI-List von gestern:
ZitatCode
Alles anzeigen[aigroup_2] NormalCars vehicles\X10 Clio\Clio.ovh 3 vehicles\X10 Corolla\Corolla.ovh 2 vehicles\X10 Megane\Megane.ovh 3 vehicles\X10 Tiguan\Tiguan.ovh 3 vehicles\X10 Zafira\Zafira.ovh 4 vehicles\X10 S-Klasse\S-Klasse.ovh 2 vehicles\VW_Golf_2\AI_VW_Golf_2.bus 1 [end] [aigroup_2] Trucks vehicles\MAN_F90\AI_MAN_F90_Wechselbruecke.bus 20 vehicles\Halycon_AI_Pack_2\ai_gliederzug_v.bus 10 vehicles\Halycon_AI_Pack_2\ai_gliederzug_v_solo.bus 5 vehicles\Magirus_MK\Magirus_MK_Koffer.bus 2 vehicles\FW_Atego\Atego.ovh 5 vehicles\X10 R420\R420-Trailer1.ovh 20 vehicles\X10 R420\R420.ovh 1 [end] [aigroup_2] Taxi vehicles\X10 S-Klasse\S-Klasse_Taxi.ovh [end] [aigroup_2] RTW Mainz vehicles\X10 Ambulanz\Ambulanz_active.ovh 1 vehicles\X10 Feuerwehr\Feuerwehr_active.ovh 10 [end] [aigroup_2] Polizei Mainz vehicles\FW_B6_Polizei\B6_Polizei_MZ.ovh 7 vehicles\FW_B6_Polizei\B6_Polizei_MZ_Einsatz.ovh 1 [end] [aigroup_2] Polizei Wiesbaden vehicles\FW_B6_Polizei\B6_Polizei_WI.ovh 7 vehicles\FW_B6_Polizei\B6_Polizei_WI_Einsatz.ovh 1 [end] [aigroup_2] Commercials vehicles\MB_T1\ai_mb_t1_kasten.ovh 1 vehicles\VW_T3\VW_T3_Transporter.ovh 1 vehicles\X10 Sprinter\Sprinter.ovh 2 [end] [aigroup_2] Schiffe vehicles\Schiff1\Schiff1.ovh [end] [aigroup_2] Gueterzuege trains\kesselwagen.zug trains\kohle_voll.zug trains\kohle_leer.zug [end]Die Tabs werden aber hier zu Leerzeichen konvertiert...
-
Moin!
Ich habe im Logfile von gestern gesehen dass mein O530G Facelift in einer von mir angepassten KI-Version Fehlermeldungen ausgespuckt hat in der Log die ich so noch nie gesehen habe:
7057 01:35:16 - - Error: Fahrzeug mit Ident 29432 (Vehicles\MB_O530_Facelift\MB_O530G Facelift_3-Doors Main_k++_ki.bus) hat mit ungültiger HDG versucht, eine Belegung zu erzeugen!
Das kam dann zig mal untereinander, der Bus hat aber augenscheinlich funktioniert. Vor diesen Meldungen gab es das:
Die Bereichsprüfungen könnten damit zusammenhängen.
ABER:
Eben als einzigen Bus auf Grundorf in die KI gesetzt und das Ding fährt normal rum, zickt nicht und die Log liefert nur das hier:
Das weist auf die K++ Matrix hin, hat aber glaub ich wiederum nix mit dem obigen Fehler zu tun.
Versteh das also nicht ganz: Gestern trotz der Sachen in der Log ist mir der Bus mehrfach begegnet und jetzt auf Grundorf auch alles astrein. Müsste doch hier auch den Bereichsprüfungs-Kram bekommen?
-
Hallöchen!
Wer kennt das nicht, die lästigen weißen oder durchsichtigen Autos und dann geht irgendwann gar nichts mehr und man muss neu starten. 4GB Pacth installiert? Ja. Irgendwann ist man mit dem Latein am Ende. Entweder man lebt also damit oder reduziert radikal seine AI-Liste, versucht die Texturlast einzugrenzen oder führt diverse OMSI-esotherische Maßnahmen durch. Auch dieses Tutorial löst das Problem leider nicht ganz, es hilft aber es einzudämmen und richtet sich vor allem an die Fahrplanersteller, denn da geht was. Aber der Reihe nach.
Einleitung:
Die Ursache für die weißen Autos (und auch andere Objekte) ist Speichermangel. Die Texturen können nicht mehr in den Speicher geladen werden, also fahren neu geladene Autos und Busse ohne Textur durch die Gegend (weiss oder durchsichtig, manchmal auch schwarz), und dann erwischt es auch noch Objekte der Scenery. Wir wissen ja dass OMSI ein 32 Bit Programm ist und somit eine Adressgrenze von etwa 2 GB hat, die man mittels "4GB Patch" auf etwa 4 GB verschieben kann. Man muss bedenken: die maximalen 4GB umfassen sowohl den RAM (Hauptspeicher) als auch den VideoRAm (Grafikspeicher). Das heraufsetzen des Videospeichers auf 4 GB zählt dann zu den OMSI-esotherischen Maßnahmen;-) Auch die alte 2/3-Regel würd ich heutzutage in Frage stellen, stammt sie doch aus einer Zeit wo man es mit deutlich weniger Speicher zu tun hatte als heute. Also ist halt irgendwann Sense, auch dank der schönen Busse in der AI-List, überdimensionalen und schlecht proportionierten Texturen beim Mobilien und Immobilien. Alles hat meist Optimierungspotential, und man sollte es ausschöpfen: KI-Versionen verwenden, nicht übertreiben, Repaint-Anzahl gering halten usw. Hilft aber auch nicht ganz, kann aber manchmal den Unterschied machen.
Mein Ansatz baut an einer anderen Stelle auf. Es ist Euch vielleicht aufgefallen dass die OMSI.exe größer wird je länger das Spiel läuft und sich selten bis gar nicht verkleinert. Bei etwa 3,2 GB Größe knallen dann die Texturen durch. Logisch: 3,2 GB plus Texturen im Video-RAM ergeben 4 GB. Nicht nur dass OMSI nur 32 Bittig ist, nein, es ist nicht gerade schonend mit dem Speicher. Es hält unnötige und zweitweise nicht mehr gebrauchte Dinge im Speicher und stößt dann eben irgendwann an die Grenze. So werden anscheinend Daten von Bussen die auf die Karte gespawnt wurden die ganze Zeit vorgehalten, selbst wenn dieser Bus die Karte und erst recht den sichtbaren Bereich wieder verlassen hat. Kleines Beispiel:
Wir haben einen KI-Kurs morgens um 7:30 mit Schülern zur Schule und um 13:30 Uhr zurück, dazwischen verlässt der Bus die Karte. Wenn die Vormittags- und Nachmittagsfahrt in einem Umlauf sind, dann bleibt der Bus im Speicher wenn man ihm morgens begegnet ist bis Nachmittags wo er die Karte wieder verlässt und der Umlauf endet. Und jetzt mal überlegen was passiert wenn dies 20 KI-Linien sind? Die Antwort liegt auf der Hand... Man muss die KI-Kurse also am Besten dazu kriegen zu verschwinden sobald sie nicht mehr gebraucht werden, und dazu würde auch die Zeit zwischen Vormittag und Mittag in unserem Beispiel zählen. Hier wäre die Abhilfe schonmal den Umlauf in 2 Umläufe aufzuteilen. Eine Linie wird jetzt nicht viel ausmachen, aber 20 schon.
Abhilfe:
Wir splitten also die Umläufe auf und teilen sie in mehrere. Das machen wir per Hand mit Texteditor an den ttl-Dateien der Linien, da es im OMSI-Editor unglaublich kompliziert und unübersichtlich wäre. Hier ein kleines Vorher Nachher Beispiel
Vorher:
nachher:
(Fast) jede fahrt ist also intern zu einem "Umlauf" geworden. Der Bus wird also erscheinen und nach der Fahrt wieder verschwinden. Und: er wird den Speicher freigeben! Das Editieren war simples (aber mühseliges) Copy and Paste. Zwischen jede Fahrt wurde ein [newtour]-Bereich reinkopiert mit der alten Umlaufbezeichnung samt neuem Suffix, aus "Mo-Do 1" wurde "Mo-Do 1-1", "Mo-Do 1-2" usw. Für die Abendkurse hab ich mir das gespart, aber dazu später mehr
Um mal zu zeigen wie viel das bringt:
Vorher war mit meiner AI-Liste nach einer Fahrt im privat gemoddetem Mainz in der HVZ Schluss, da ich da mit der OMSI.exe bereits bei 3,1GB war. Jetzt hatte diese Grenze erst gegen Ende der Rückfahrt erreicht. Am Ende der Hinfahrt war die EXE bei 2,4 GB statt 3,1 GB. Mit gleichen Settings, gleicher AI-Liste. Dabei waren bei weitem nicht alle KI-Linien umgestellt auf dieses System, vielleicht nur etwas mehr als die hälfte. Viel Luft nach oben und mal gucken wie es aussieht wenn alles umgestellt ist;-)
Anwendungsbereiche:
Wo kann man dieses Prinzip anwenden? Es hängt ganz stark von der Art der Linien ab die eine Karte hat. Grundsätzlich bringt es viel bei Karten die viele KI-Linien haben, die auch die Karte verlassen. Ganz wichtig: KI-Linien. Keine vom Spieler fahrbaren Linien! Da würde zum Beispiel eine Karte wie ALU schonmal nicht in Frage kommen für diese Maßnahme (außer bei den Zügen!). Aber Karten wie Spandau, X10/BRT, Hamburg wären perfekt mit viel Potential bei den KI-Linien sowohl bei Bus als auch Zug, Allerdings wo keine Not da auch keine Mühe notwendig. So kann man sich das bei Abendfahrplänen oder fürs Wochenende vielleicht sparen. Kommt eben auf die Karte an. KI-Linien die auf der Karte enden und im sichtbaren Bereich Pause machen würde ich immer beim verlassen der Karte splitten, da also jede zweite Tour. Dennoch würde ich schonmal auf jeder Karte den gesamten Zugverkehr auf diese Weise regeln.Nachteile:
Als erstes werden die Fahrpläne natürlich furchtbar unübersichtlich fürs spätere Bearbeiten. Also immer dafür eine Kopie bereithalten. Dann ist es natürlich so dass so einen Umlauf immer ein anderer Bus fahren wird und nicht der gleiche wie vorher, denn technisch sind es ja verschiedene Umläufe. ist blöd, ja, aber beim Neuladen des Spielstands würden die Fahrzeuge sowieso wieder neu zugeteilt werden mit gleichem Effekt. Deshalb würde ich aber KI-Linien die zum Beispiel an der gleichen Endstelle wie der Spieler Pause machen von diesem System rausnehmen. Als Beispiel sei hier Spandau mit der KI-Linie 94 genannt die am Reimerweg endet oder die 56 in Ruhleben. Bei Verwendung von StnLinks werden manchmal Busse auch nicht gelöscht, Beim alten T&T System funktioniert das aber recht zuverlässig. Aber vielleicht lassen sich so auch besser "Geisterbusse" mit +1000min Verspätung finden bei StnLinks die dann auch den Speicher unnötig vollstopfen;-)
Ausblick:
Ich hoffe das probiert der ein oder andere aus und noch mehr hoffe ich dass jemand ein Tool schreibt welches diese Prozedur irgendwie automatisiert.
-
In der Tat kenne ich mich da nicht genug aus, sonst wärs mir egal und ich würd mir sowas zurechtmodden wie ich es brauche;-D Ich seh nur die Busse die es gibt oder gab und sehe die Gemeinsamkeiten und ich seh auch oft genug Skriptreste um erahnen zu können was die Eltern oder Großeltern des Scripts sind (dabei frage ich mich schon wie das denn so mit dem Copyright da ist...) Ich seh zum Beispiel eine SD83_Rollband.osc samt Varlist im O405/Scripts Verzeichnis
Der Kunde darf erwarten was im Vorfeld als Funktionen ihm ausgewiesen wurde, nicht was das Fahrzeug eventuell könnte oder wofür es theoretisch vorbereitet ist. Ich erwarte auch kein Rollband-Update. Wenn Du es wegen irgendwelcher technischer Schwierigkeiten canceln würdest, dann ist es halt so. Dann wird der Bus eben mit Matrix genutzt;-D Aber natürlich würd ich mich freuen wenn die technischen Hürden gemeistert werden und das Ding schön vor sich hin rollt
-
Der Plan sieht vor, ähnlich wie auch jetzt sowohl für die Front als auch für die Seiten getrennte Rollbandtexturen zu verwenden. Ist in der Hofdatei keine für die Seite eingetragen, wird die für die Front gewählt. sind beide nicht eingetragen, wird das Rollband aus den anderen Strings für den jeweiligen Terminus generiert. Das an und für sich ist kein Problem, allerdings wirds zu einem, wenn das ganze dann noch dynamisch eine drehanimation haben soll, sowohl beim Zieltext als auch bei der Liniennummer.
Das klingt doch gut. Die Animation wäre ja nur relevant für das Spielerfahrzeug und eigentlich auch kein Novum in OMSI. Die alten SDs konnten das, der O305, O405 usw. Das Prinzip ist denk ich mal das gleiche bei allen? Und sogar die Scripte sind doch eigentlich da zum Beispiel beim SD 83.
Es ist zwar schön dass der Bus die Rollbänder generieren kann für Karten wo der Kartenersteller es nicht vorgesehen hat, aber diese Karten sind auch aus anderen Ären. Wenn ein Kunde dann verlangt "ich will überall Rollbänder haben out of the box" nun ja selbst schuld. Streng genommen passt der SG ja auch nur auf vielleicht 5% der Karten, da es kaum historische gibt. Perfekt ist natürlich Spandau, und da gibt es die Rollbänder. Es ist dann ja auch Sache der Community eine Funktion wie diese aufzugreifen und mit Inhalten zu befüllen. Klappt ja gut sogar bei Sonderformaten wie beim O307 /407, warum nicht hier auch, erst recht wenn eine gewisse Verwandtschaft zum O405 besteht vom Format her;-) Ich für meinen Teil werde sobald die Mainz-Rollbänder sortiert sind sie veröffentlichen und gegebenfalls falls nötig auch an den SG anpassen. Da kannst Du gerne schon vorab die Spezifikationen durchgeben;-D
-
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.
-
Achso, und wir reden uns hier über technisches bis die Köpfe rauchen wo die Lösung doch so einfach ist
-
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"
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 sich
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.
-
genau, und die dampfen auch bei 50 km/h, méist sieht man den Dampf ja auch nur im Stand.
Hier mal ein Beispiel bei fahrender KI.
-
Merkst Du eigentlich unterschiede zwischen verschiedenen dds-Plugins? Ich hab eins von Intel und eins weiss ich garnicht von wem das ist und weiss nie welches besser ist...
-
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.
