Beiträge von Odinsson

Das Forum befindet sich im reduzierten Betrieb. Die Addon- und Supportforen bleiben weiterhin verfügbar.
Bitte beachte, dass OMSI nicht mehr weiterentwickelt wird. Ein Teil der Entwickler widmet sich inzwischen der Entwicklung eines neuen Simulators. Weitere Informationen zum LOTUS-Simulator findest Du hier.

    Wenn das so angekommen ist, dass ich gegen den Kreuzungsbau mit "Blender" argumentieren möchte, dann tut mir das leid. Das war nicht mein Ziel. Ich wollte eher ausloten, ob es für die Zukunft denkbar ist, dass man eine Kreuzung aus Einzelmodulen (Objekte und Splines) im Map-Editor zu einer komplexeren "Gesamtkreuzung" zusammenbauen kann. Ich selbst habe sogar auch schon versucht, mit "Blender" zu hantieren. Habe mir sogar ein Lehrvideo dazu gekauft, und ein Buch auch noch. Alles schicke Sachen. Aber die "Input-Masse"daraus, selbst wenn (oder gerade weil?) von Grund auf erklärt, ist für einen ahnungslosen Blindfisch wie für mich erst einmal enorm. Dann geht's schon damit weiter, dass im OMSI-Kreuzungstutorial die "Blender"-Version 2.49 verwendet wird; alles das, was man heutzutage aber an "Lehrmaterial" für "Blender" bekommt, schon auf die Versionen 2.5x oder neuer zugeschnitten ist, wo "Blender" schon wieder eine etwas andere Benutzeroberfläche hat. Für einen "Newbie" eine weitere Hürde.


    Dann noch was. Das, was ich weiter oben "Kreuzungseditor" nannte, ist so ja nicht ganz richtig. Gemeint war natürlich der "SceneryObjectEditor" des SDK. Und da sind wir schon beim nächsten "Pferdefuß". Man versuche bitte beispielsweise einfach mal, ein Kreuzungsobjekt ("kreuzhaumichtot.sco") eines neueren Addons für OMSI2 in diesen zu laden. Da "grinst" einem eine Fehlermeldung frech ins Gesicht, dass das an die sco gekoppelte o3d-file zu neu! für die Editorversion ist. Würde ja bedeuten, dass eine Überarbeitung des Objekteditors eh notwendig zu seiin scheint?

    Ich habe ja mit dem Kreuzungseditor nicht wirklich das Problem. Dort habe ich ja schon reingeschaut. Im Zusammenhang mit der weiter oben angedeuteten "Projekt-Szczecin-Methode" wird ja in der zwar in polnisch verfassten aber auch mit Bildern illustireten Anleituing zu diesem Objektwürflel eine Konstrukiton eines Pfadnetzobjektes erklärt. Durchaus auch recht anschaulich. Wenn man nun dafür einfach eine grafische Hintergrundreferenz zur Verfügung hätte, ware das Ganze dann etwas weniger umständlich, als ohne. Man kommt ja um die die Erstellung des Pfadnetzes auch bei einem Blender.-Konstrukt nicht herum.


    Wenn man 3D-Design wirklich vernünftig betreiben will, muss man mehr können, als nur ein parr faces extrudieren. Texturieren, mappen und noch dies und noch das. Allein mit "Blender" umgehen können reicht da noch lange nicht. Auch noch mit Grafikprogrammen muss man halbwegs vernünftig zurechtkommen. Wer damit vorher nicht zu tun hatte, für den ist es schwer, und vor allem braucht es Zeit. Und nicht jeder hat die so üppig wie vielleicht manch anderer.


    Da ich, zum Bleistift, Wechselschichtarbeiter bin und auch noch Alleinerziehender, ist das Zeitvolumen für einen eigenhändigen Kartenbau eh schon knapp. Und trotzdem möchte ich selbst mal was vernünftiges auf die Beine stellen und mich nicht in die Reihe der Downloadlechzer einreihen. Und das, ohne zwingend Neuland betreten zu müssen, was dann möglicherweise auch nur oberflächlich geschieht.


    Auch aus diesen Gedanken heraus enstpringt der Wunsch nach dem "Ausbau" dieses Werkzeugs, welches für mich so 'ne Art Schlüsselwerkzeug darstellt.


    Kann natürlich auch sein, das ich das überbewerte...

    Okay, begriffen...


    Auch wenn es mir noch immer nicht plausibel erklärt, warum das so ist; der Unterschied ist zumindest klar.


    Das lässt in mir den Wunschtraum reifen, dass bei einer möglicherweise beabsichtigten Weiterentwicklung des SDK, der Kreuzungseditor dahingehend ausgebaut werden könnte, dass zur Erstellung dieses Pfadgelflechtobjektes Hintergrundbilder eingelesen werden können, ähnlich wie diie Sache im aktuellen Map-Editor mit der Unterlegung mit Bildern aus Google, bing oder sonstwoher funktioniert. Das würd den Bau realitätsnaher Straßenzüge unheimlich erleichtern, ohne zwingend auch ein autodidaktes Freitzeitstudium in Sachen 3D-Design ablegen zu müssen. So könnte man dann unter Nutzung solcher bereits entwickleten schicken Sachen, wie die Tarrain-Splines und ähnlichem, quasi nach einer Art Baukastensystem sich aus verschiedenen Komponenten ohne "Blender"-Kenntniss eakzeptabel aussehende Straßen- und Kreuzungsbilder zusammenbauen. Schließlich gehört das ja gewissermaßen zum Herzstück der Simulation dazu (die Wege, auf denen sich die Fahrzeug unterschidlichster Art im Sim bewegen und wi sie untereinander "interagieren")


    Es würden sich dann eventuell auch mehr für den Bau von Karten realer Vorbilder interessieren. Und die wirklich guten 3D-Designer und Skripter hätten mehr Zeit für gute Objekte, Busse, Bahnen etc.da der Straßenbau gewissermaßen durch jedermann erledigt werden kann.


    Wie gesagt, ein kleiner Wunschtraum.

    ;)

    Invissplines zählen je als Einzelobjekt, unter denen keine Verkehrsregeln beachtet werden. Die Methode von Szczecin ist mir bekannt, ist aber ein enormer Aufwand

    ;-)


    Damit ist die "Gretchenfrage", die mich zwickt, für mich nicht so richtig beantwortet. Oder besser, ich habe meine Frage wohl nur unzureichend verständlich formuliert.


    Bei der "Szczecin-Methode" strick man ein Pfadnetz zu einem Objekt im Kreuzungseditor zusammen. Okay! Bei einem Blender-Konstrukt tut man meiner Auffassung nach im Kreuzungseditor eigentlich genau das Gleiche, nur dass man da die "grafische Unterlage" defacto parat hat. Nun hat man die Möglichkeit, Ampeln zu schalten; mit Schaltphasen und allem Komfort. Soweit auch Okay. Die Pfade, die man im Kreuzungseditor verlegt, unterscheiden sich also in ihrer Funktionsweise von den Splines "invisible_street"? Wenn ja, was ist der Unterschied und warum gibt es diesen? Letztlich sollen diese ja den Fahrweg der KI-Fahrzeuge bestimmen, und nix anderes. Was ist funktional der Unterschied zwischen Pfaden, die man im Kreuzungseditor verlegt und "invisible_street" Splines, die man im Mapeditor vewrlegt:. Erschließt sich mir nicht so ganz. Letzlich knüpft man sie ja an "konventionelle" Straßensplines an.

    ... wurden viel mit Invis-Splines gebaut --> darauf sind keine Verkehrsregeln möglich...


    Ist das tatsächlich so? Gibt es für diese Aussage eine verlässliche Quell? Warum funktionieren dann solche Dinge wie die Ampelsplines?


    Im Zusammenhang mit dem Projekt Szczecin 4.0 wird da ja noch eine andere Variante der Kreuzungskonstruktion ohne "Blender" quasi nebenbei "mitgeliefert". Da verlegt man quasi im SDK-Kreuzungseditor Pfade von einem Objekt aus und "schweißt" gewissermaßen ein Pfadnetz der Verkehrswege einer Kreuzung zusammen, bloß ohne den Untergrund einer Blenderkonstruktion. Im Mapeditor legt man dann dieses Pfadkonstrukt als Objetauf Terrainsplines. Was ist nun der programmintern logische Unterschied eines solchen Konstrutkes gegenüber dem, was man sofort im Mapediter mittels den invisible-street-Splines zusammenbaut?

    Habe ein eigenartiges Phänomen mit den alernativen ailists der Stettin -4.0-Karte. Die standardmäßig als ailists.cfg eingestellte Datei funktioniert erst einmal unproblematisch.


    Sie hat aber keine Gelenkbusse in sich eingestellt. Also greift der abenteuerlustige Heide zu den anderen schon vorgefertigten Dateien und passt sie ein wenig an. Im speziellen Fall habe ich mir hier die die Datei ailists_special.cfg gegriffen. Sie ist ja in weiten Teilen mit der standardmäßig verwendetenen aiilists.cfg gleich. Nur es befinden sich einige Buseintragungen zu Glenkbussen mehr darin. Nach einigen eigenen Änderungen (Zuordnungen von anderen Bussen, die bei mir installiert sind zu den einzellnen Typgroups) habe ich mir diese dann zur ailists.cfg umbenannt, nachdem ich die standardmäßig verwendete mit einem anderen Namen versehen hat.


    Und nun fängt's los. Karte gestartet ohne Busse. Und schon da fällt nach dem Laden auf, dass als unscheduled traffic nur LKW unterwegs sind, obwohl ich diese Typgroup (Trucks) genau so unangetastet gelassen habe, wie auch die der PKW (NormalCars). Kein einziger PKW rollt. Die Busse fahren ohne Beanstandungen. Auch die von mir neu zugeordneten. Habe jetzt die Standard ailists.cfg und die von mir abgewandelte hin und her verglichen. Ich finde einfach nicht den Stein des Anstoßes nicht.


    Hat dieses Phänomen auch schon mal jemand an anderer Stelle auch so beobachtet (und gelöst bekommen)?

    Hast Du über das Menü das Fahrtziel geschildert, bzw. wird das Fahrtziel in der roten Schrift (2x Shift+z) angezeigt ?


    Hmmm, ist ja komisch. Im IBIS Linie gewählt, Route gewählt. Im IBIS selbst wird diese auch angezeigt. Nachdem das Fahrtziel angezeigt wurde, steht dann kurze Zeit später die Ausgangshaltestelle. Soweit alles klar, wie ja sonst auch immer. Aber nach 2 x "Shift-Z" steht hinter "Zielschild:" "Betirebsfahrt"?


    Hatte ich so noch nie. Das muss nicht (und wird sicher auch nicht) an dem Mod hier liegen. Aber hier liest vielleicht auch jemand mit, der vielleicht 'ne Lösung parat hat. Ich vermute ja, es hängt mit der vermaledeiten hof-Datei zusammen, nur wie?




    EDIT:


    Berndie, da warst Du fixer. Aus der Sicht habe ich es noch gar nicht gesehen. Danke, für den Tip.

    Die meisten denken ja immernoch, ich hätte einen kompletten Bus hochgeladen. Raffen es aber nicht, verpeilen die Readme, weil sie sie nicht lesen etc. usw. Sie sehen halt den Ordner OMSI 2 - ziehen den einfach rüber und sie denken, es sei damit getan. So stelle ich mir das ganze inzwischen vor. Für diese ganze Inkompetenz gebe ich auch keine Support mehr. Kostet mir einfach zu viele Nerven.


    Da ich offenbar nicht zu den "meisten" gehöre, habe ich es eben nicht so gemacht. Und trotzdem hat mir die Installation strikt nach der Anleitung ein paar Probleme bereitet. Ich habe den Citaro nochmals neu installiert gehabt. Diese Frischinsatalltionen - für den G und den Solo -habe ich dann nochmals kopiert und die entsprechenden kopierten neuen Ordner umbenannt, um darauf den Mod zu installieren. Das Ganze weil: Als ich so verfahren habe, wie in der Anleitungs-Readme steht, meckerte OMSI2 beim Aufruf der Nürtingen-V5-Karte mit 'ner Fehlermeldung. Weiß jetzt nicht mehr genau welche, war hier in dem Thread aber schon mal angeführt. Hängt wohl irgendwie mit der Nutzung der Orginal-Citaros in der ailists.cfg der Karte zusammen. Deshalb dieser Versuch mit der Kopie der Orginalen, was ja auch generell nicht unsinnig ist, da im Mod ja auch andere Dateinamen für die bus-Dateien genutzt werden. So hat man gleich beides separat. Original und Mod-Version.


    So weit, so gut, dachte ich. Nun noch die hof-Datei in den Mod-Bus-Ordner, und ab geht der Gelbe. Und nach meckerfreiem Start der Nürtingen-Karte war die Welt wieder heil. Aaaaber: typischer Fall von "Denkste". Man wählt nun einen der Mod-Citaross in den Sim, dazu 'nen Fahrplan und los geht's. Fahren tuts, aber mitfahren will keiner. Es steigt einfach keiner zu. Passiert (bislang) nur auf der Nürtingen-Karte, sowohl in Spandau, Stettin, Hamburg ist alles bestens. Gibt es von hier vielleicht 'ne Idee, wo da der Hase im Pfeffer liegen könnt'? Ihr seids da ja Experten.

    In den Ciraro mit dem Morphi-Sound-Mod steigen keine Fahrgäste ein. Die neueste hof-Datei ist im entsprechenden Bus-Ordner. Auf Spandau gibt es mit den Fahrzeugen diesbezüglich kein Problem. Auf Stettin hae ich 's noch nicht probiert.

    Eine Sache, die mich gerade stutzig macht: Da ich ja immer das Download-Wetter nutze... Gibt es gar keine Wolken mehr? Hatte unter der 2.1 noch kein einziges Wölkchen. Oder herrscht Tatsache über ganz Deutschland wolkenloser Himmel?

    Ich tu's am besten hier rein, da ich jetzt nicht die Zeit habe, in jede Feedback-Rubrik was zu schreiben. Kommt vielleicht in die ein oder andere noch.


    Erstes Fazit nach dem neuen Update: Ja, so, sollte OMSI sein. Erste Halbstunden-Fahrt, ohne dass man hier und da das Gefühl hat, das Programm kollabiert gleich (Ladepausen), ohne Bereichsfehler-Blablabla und es läuft recht flüssig. Erfahrung hier auf der Nürtingen V5-Karte, die nun so richtig Spaß macht, mit den O405N2. Angenehm auch: die KI-Fahrzeuge (PKW und LKW und so..) sind nicht mehr gar so vollpfostenartig unterwegs. Da kriegt der Begriff des vorausschauenden Fahrens endlich seine Bedeutung zurück. Nicht mal in die Nähe eines Crashs bin ich gekommen. So fetzt das ein. Kleine Ruckler gibt's schon noch, aber die halten sich in vertretbaren Grenzen.


    Habe von Grund auf neu installiert. Läuft super so.


    Weiter so, Jungs...


    Danke---

    :thumbup:


    EDIT:


    So, und jetzt nach einer Fahrt mit dem 272er Gelenk auf Spandau im Mai 1992 nach Falkensee. Was ist das für 'n Gefüh!: Kein Verkehrsblinder der KI rauscht einem völlig irrational in den Nachläufer. Fazit: bisher nicht einziger Unfall oder Programmabsturz. Nach insgesamt knapp 30 km und 'ner Stunde Fahrzeit. Das gab's mit OMSI2 noch nie. Jetzt passt das.

    :thumbsup:


    Nächstes Abenteuer: Szczecin 4.0 installieren und testen! Aber das wird erst morgen. Bin begeistert...

    Also, nun erstmal auch von mir ein kleines Dankeschön... Langsam, aber sicher wird das Kärtchen gewissermaßen "erwachsen". Gefällt mir soweit schon ganz gut. Kleine Macken hat 's dennoch.


    Beispilesweise habe ich schon an einer Ampelkreuzung im Verlauf der Linie 183 vom Kleeweg weg (müsste laut Google-Earth die Neuffener Straße oder so sein) die Fußgängerampeln korrigeren müssen, da sie gleichzeitig mit den Kraftfahrampel der praktisch "konkuriierenden" Hauptfahrbahn im Geradeausverkehrs "Grün" zeigten.
    Die Vorfahrtregeln scheinen allgemein auch noch nicht optimal zu sein. Aber das will ich nach dem Update zu 2.1 des OMSI mir nochmall neu anschauen. Da hoffe ich auf generelle Besserung der Basisissoftware, was das KI-Verhalten anbetrifft.


    Irgendwas haut bei mir auch mit dem OVK-Kircheim Repaint nicht hin. Zumindest bei mir habe ich ein selbst über die Fenster des Fahrgastbereicha kompleet weißes "Citaro-Gespenst" herumfahren. Aber das wenigstens mit Kennzeichen...

    :D

    Sobald man in der V5 auf das SSB-Depot schalten will, sucht die Karte nach einem Objekt "...OMSI2\Sceneryojects\YufaObjektwe\Depot\Betriebstankstelle.sco", und scheitert (Programm hängt sich auf). Ich habe das Depot-Set von Yufa über den Addon-Manager installiert. Dieser zeigt mir an, dass es aktuell ist (Version 1.0.1). Doch in meinem Ordner "YufaObjekte" existiert kein Ordner "Depot" und schon gar keine Datei "Betriebstankstelle.sco".


    So, konnte das Problem für mich lösen. Es war der Download des Depot-Sets V2.0 nötig, der hier zu finden ist: Klick mich doch.


    Die Installation läuft aber nicht über den Addon-Manager.