Beiträge von e2h1986

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!

    Zwischenstand zum Mapping des Wagenkastens.


    Wenn mir dies gestattet ist: das Heck ist für meinen Geschmack zu buckelig (Heckscheibe zu schräg) und auch der Knick der Seitenwände ist zu stark (Mitte zu breit? Dach zu schmal?). Das war schon bei Julians Bus für mich der größte Fehler in Sachen Optik. Vielleicht lässt sich das am besten durch eine Vermessung der Heckscheibe (Länge Ober- und Unterkante) bewerkstelligen.

    Ich empfehle außerdem eine sehr intensive Bilderrecherche wenn's gut werden soll. Das hat allerdings bei meinem SÜ240-Projekt dazu geführt, dass ich ständig neue Änderungen vornehmen musste, weil ich wieder etwas Neues oder eine Unstimmigkeit entdeckt hatte. Beim Weiterbauen hat sich dann z.B. auch erst die endgültige Form der Seitenwände ergeben über die Türen und deren Drehpunkte.


    Ansonsten weiß ich nicht so genau ob es sinnvoll ist, bereits jetzt mit dem Texturieren zu beginnen... Aber jeder macht das wahrscheinlich anders. Mach aber nicht den letzten vor dem zweiten Schritt; bis so ein Bus komplett steht, vergeht locker ein Jahr oder mehr.

    Was meinst du genau? Ich finde das so völlig authentisch. Ansonsten werden die Schaltgrenzen im Antrieb-Constfile für jeden Gang separat eingestellt. Kleine Änderungen können da aber schon große Auswirkungen haben, vor dem Herumtesten sinnvollerweise eine Sicherheitskopie erstellen, aber das sollte ja ohnehin selbstverständlich sein.

    Ich hoffe du verstehst was ich meine.

    Ich meine nicht den Command wann er hoch oder runterschaltet, sondern bei dem Video hört man das zwischen den Gängen oft eine Sekunde gar kein Sound kommt -

    mir ging es nur darum, dass er im Prinzip schneller einkuppelt beim Schalten.

    Wie heißt der Command hier in der Constfile?


    Jetzt musste ich das erst noch dreimal anhören um zu wissen was du meinst: es geht offenbar um das Pfeifen des Retarders? Das hat nichts mit dem Schalten zu tun, ich finde den Sound nach wie vor einigermaßen überzeugend. Ich bin jetzt (zum Glück) schon länger keinen Facelift mehr mit Voith-Getriebe gefahren, kann daher zu solchen Details nichts weiter sagen.

    Es fehlen hier sowieso noch einige Angaben: ist das der Original-Sound? Ist das eine Mod? Wessen?


    Ohne den Bus aus dem Effeff zu kennen: das Pfeifen wird zum einen über das Antriebsscript generiert (hier wird das Ein- und Aussetzen des Retarders definiert und auch die Drehzahl genutzt für die Höhe des Pfeiftons) und zum anderen über die Sound.cfg, wo z.B. Lautstärke, zu verwendende Sounds und anderes konfiguriert wird. Da wird nur Studieren der betreffenden Dateien helfen, so schwer sind die gar nicht, wenn man das Grundprinzip von Programmiersprachen und die umgekehrt polnische Notation verstanden hat ;)


    Viel Erfolg!

    Das wird grundsätzlich im Motorscript geregelt, da hier aber jeder Bus quasi sein eigenes Script verwendet, kann man da keine genaue Anleitung geben.

    Beim SD200 geht das zum Beispiel über Motortemperaturen, beim 2017er Citaro von Darius gibt's einen Zufallsgenerator. Hier wie dort werden zusätzlich Konstantwerte aus den Engine-Const-Files verwendet.

    Was meinst du genau? Ich finde das so völlig authentisch. Ansonsten werden die Schaltgrenzen im Antrieb-Constfile für jeden Gang separat eingestellt. Kleine Änderungen können da aber schon große Auswirkungen haben, vor dem Herumtesten sinnvollerweise eine Sicherheitskopie erstellen, aber das sollte ja ohnehin selbstverständlich sein.

    Nochmal ein Kleines update vom Kieler HBF.

    Ich bin mal gespannt wie sich der HBF Performance technisch geben wird, ich denke aber dass es Kritisch sein wird xD


    Sieht eindrucksvoll aus! Das Gebäude selbst wird gar nicht so kritisch sein, aber beim sehr detailliert ausgestalteten Eingangsbereich mit Treppenstufen, Rampe, Vordach, Stützen dafür etc. ist sicher ggf. noch Potential für eine Optimierung :S


    Was mir in deinem letzten Post schon aufgefallen war: die Ziegelwände haben teilweise unschöne Wiederholungstexturen (vor allem unterhalb von Fenstern), aber das ist natürlich Klagen auf hohem Niveau :sunglasses: und lässt sich aber wohl bei den großen Flächen auch kaum ändern, wenn man den Texturenspeicher nicht sprengen will.

    Fehlermeldungen spuckt das Addon bei mir auch aus in Blender 4.0, es funktioniert aber zumindest beim Importieren von o3d einwandfrei.


    Ansonsten kann es sicher nicht schaden, mehr als nur die aktuellste Blender-Version auf dem Rechner zu haben, der x-Export funktioniert zum Beispiel nur bis Version 2.79.


    Übrigens lassen sich nicht alle o3d-Dateien öffnen, der O305 und O305G zum Beispiel sind in der Hinsicht geschützt.

    Dafür gibt's natürlich keine Pauschalanleitung, die für jeden Bus passt. Guck dir das Script 16_cockpit.osc mal genauer an, dort wird mit dem Globaltimer gearbeitet, der in bestimmten Abhängigkeiten als Grundlage für das verzögerte Einschalten der Zündung genutzt wird. Beim Drehen des Schlüssels wird der Wert des Timers in einer Variable (schluesselzeit) gespeichert und erst wenn dieser Wert plus 1.2 überschritten wird, schalten sich die Verbraucher ein.


    Viel Spaß beim Basteln!

    Grundsätzlich werden dann alle Türen dann geöffnet/geschlossen (sofern die Variablen passen), aber da hängt dann noch mehr dran wie ein Sound und/oder die Überprüfung ob eine Tür schon offen ist oder nicht usw... Das Ganze kann dann sehr komplex und verschachtelt aussehen.


    Richtig. Das ganze fängt schon an, wenn die Automatiktüren realistisch mit Zeitverzögerung (Abtastung der Lichtschranken, spätestens ab der dritten Tür auch gesetzlich vorgeschrieben), u.U. auch mit Türpiepen, schließen sollen. Und wie du richtig schreibst, gehört auch die Zustandsüberprüfung der Türen dazu, denn evtl. überlagern ein Kinderwagenwunsch oder ein bereits ausgelöster automatischer Schließvorgang die Zielvorgabe "Tür schließen". Soundeffekte sehe ich als eher unkritisch an, da die in der Regel bereits im bestehenden Türscript abgearbeitet werden.

    Die vorderen Türen werden aufgrund ihrer normalerweise vollständig manuellen Bedienung auch scriptmäßig komplett anders behandelt als die Automatiktüren.

    Mit dem Scripten ist es ja dann auch noch nicht getan, denn es wird ja vermutlich einen zusätzlichen Schalter oder Taster für die Funktion geben müssen, der ebenfalls in mindestens zwei weiteren Scripten verarbeitet bzw. eingearbeitet werden muss. Und wenn man schon so eine unternehmensspezifische Funktion integriert haben möchte, liegt einem ja auch an der korrekten Schalteranordnung, die garantiert anders ist als die bei der Hochbahn. Ich persönlich würde einfach mit der vorhandenen Stadionschaltung vorlieb nehmen und die erste Tür dann eben manuell bedienen, da steigt in der Realtität ohnehin kaum jemand ein oder aus, da man dann ja mit dem Fahrgaststrom an der kurz dahinter befindlichen Tür 2 kollidiert, das jedenfalls ist meine Erfahrung aus meiner Tätigkeit bei der Hochbahn.

    So oder so müsste Tür 1 auch immer manuell geschlossen werden

    Bei uns hier (im Reallive) gibt es dafür ein eigenen Taster den man drücken kann, da gehen halt alle Türen gleichzeitig auf und zu.


    Ich kenne das zwar hier aus Essen nur mit den hinteren Türen, aber das meinte ich auch nicht. Ich bezog mich dabei eher auf das Script. Natürlich ist es auch möglich, die vordere Tür mit einzubeziehen, aber das würde einen noch tieferen Eingriff in das Script erfordern.

    Ein Tutorial speziell für Türscripte gibt es nicht, hier hilft nur konzentriertes Lesen und Verstehen des vorhanden Scripts. Was aber auf jeden Fall notwendig ist, ist die Beschäftigung mit der Scriptsprache allgemein, schon auch weil die "umgekehrt Polnische Notation" einem sonst im Alltag eher nicht begegnet.

    Aus einem SD200 schnitzen? Panik breitet sich aus...

    Mal abgesehen davon, dass es auf den Bildern ein Büssing DE ist (ohne MAN), Nick hat mal einen DE als Modell gebaut, den könnte man als Basis zum weitermachen nehmen, WENN man die Dateien bekäme. Und selbst dann fließt da einiges an Scripten an, wenn man es ordentlich machen möchte, Vorglühen sollte dann ja z.B. auch bei sein. Und dann die Frage welcher Zustand, schließlich wurden die Autos einer GR unterzogen, da hat sich manches geändert.

    Und bitte nicht denken man könnte aus einem Standard 1 Bus einen 60er Jahre Büssingdoppeldecker bauen, einfach nur Nein.


    Danke, endlich jemand, der den Unterschied zwischen D2U und DE kennt (zwei vollkommen verschiedene Busse). Die letzten DE liefen aber tatsälich bereits unter MAN (-Büssing). Büssing ging ab 1971 an MAN, der DE wurde bis 1974 gebaut.


    Einen DE von einem SD200 ableiten zu wollen, ist komplett abwegig, die Busse haben bis auf die groben Abmessungen keinerlei Gemeinsamkeiten (ich wollte ja ursprünglich den SÜ240 vom O307 ableiten, am Ende ist aber kein einzger Vektor an seinem Platz geblieben, obwohl die oberflächliche Ähnlichkeit der beiden ja viel größer ist als die von SD und DE). Die Scripte kann man da noch am ehesten weiterverwenden, auch wenn z.B. Türanimationen komplett neu erstellt werden müssten. Vorgeglüht wurde übrigens nur bis Baujahr 1967, da klingt auch der Motor nochmal anders. Überhaupt, das Bauen des Modells ist die eine Sache, die sich, wenn man sich nicht wie ich (beim SÜ240) in Details und (vermeintlicher) Perfektion verzettelt, in vertretbarer Zeit bewerkstelligen lässt. Texturen, Sound und eben Scripting sind dann nochmal mindestens derselbe Umfang, wenn nicht sogar mehr, wenn es gut werden soll. Es würde ein neues Getriebescript benötigt, denn das irgendwo kursierende Zweigang-Script (einfach nur ein kastriertes D851-Script) für den SD200 taugt ohnehin schon nicht viel, für den DE wäre es völlig unbrauchbar und weit an der Realität vorbei.
    Und wenn man dann schon einen DE bauen würde, würde auch die Lübecker Ausführung dazu gehören, wo es dann nochmal Unterschiede gibt, die es zu berücksichtigen gäbe (Auspuffklappenbremse, Bedienung bei Starten und Abstellen des Motors, Dreigang-Getriebe, das aber wieder anders funktioniert als das D851)

    Hätte der Tag 48 Stunden, müsste ich nicht arbeiten und hätte ich auch sonst Zeit und Geld wie Heu, würde ich das Ding bauen. Da dies aber alles nicht der Fall ist, wohl eher nicht. Zumal es da noch andere Busse gibt, die mich mehr interessieren würden, wie zum Beispiel der Routemaster und dessen Vorgänger RT, auch wenn beide in Omsi keinen großen Nutzen hätten. Und vor allem dies, nämlich das Interesse an einenm bestimmten Modell, führt ja ünberhaupt erst dazu, dass sich jemand die ganze notwendige Zeit für die Erstellung ans Bein bindet, das dürfte für Freeware noch mehr der Fall sein als für Payware.


    etwas aus dem MAN SD200 schnitzen

    Vielleicht die Frontscheinwerfer und das wars.

    Der D2U hat, wie man sieht, komplett andere Proportionen und wirkt auch nicht so "Glatt".

    Aber so die Idee ist nicht schlecht wenn man einen SL200 bauen möchte.


    Für den SL200 mit StÜLB-Front könnte man den Bereich der unteren Front nehmen und evtl. den Fahrerarbeitsplatz in Teilen, das war's dann aber auch. SD und SL sind zwei grundlegend unterschiedliche Fahrzeuge mit lediglich ähnlicher Optik. Wenn man ins Detail geht, sieht man dann, dass selbst die Türen und die Frontklappen unterschiedlich hoch sind, von der Fensteraufteilung und einem komplett anderen Innenraum einmal ganz abgesehen. Da wäre es sogar sinnvoller, den SL200 vom O307 abzuleiten, aber selbst das würde noch sehr viel Nacharbeit erfordern für eine halbwegs originalgetreue Ausführung (Dachform, Front, Heckecken, Radausschnitte, kompletter Innenraum).

    Wenn ich dann mal irgendwann den SÜ fertig bekommen sollte (sicher nicht vor Weihnachten), werde ich daraus tatsächlich noch einen SL200, SG240H und einen SG220 ableiten, denn das ist dann fast "nur" noch Baukasten-Bastelei.


    Die Frontscheinwerfer sind übrigens, um auf das Zitat zurückzukommen, ebenfalls anders, beim DE stehen sie schräger in der Front (beim SD/SL völlig gerade), haben aber auch andere Abmessungen und eine eher leicht ovale als kreisrunde Form.

    ich würde sehr gerne eine zentrale Türsteuerung (dass alle Türen gleichzeitig aufgehen) in den C2 Capacity (MX) einbauen.


    Da ich die Türscripts leider nicht verstehe, wollte ich fragen, ob jemand mir Tipps geben kann, wie ich es umsetzten kann.


    Zumindest für die Türen 2-5 geht das doch schon, dafür die Türfreigabe aktivieren und den Kinderwagentaster betätigen. Automatisches Schließen durch Kinderwagen OFF.


    Tür 1 da mit hineinzubasteln, ist nicht ganz so trivial, zumindest nicht mal eben auf die Schnelle; da deren Ansteuerung anders aufgebaut ist als bei den Automatiktüren. So oder so müsste Tür 1 auch immer manuell geschlossen werden.

    Ein kurzes Lebenszeichen von mir. Ihr werdet euch beim Ansehen des Bildes wahrscheinlich denken, dass da ja nicht viel Fortschritt im Vergleich zu den vorher gezeigten zu sehen ist. Und ganz unrecht habt ihr nicht, dennoch habe ich an vielen Stellen (viel zu viel) Feintuning betrieben. Der SÜ mit den VÖV-Türen (VM) ist allmählich auf der Zielgeraden, die Übertragung auf den "echten" SÜ ist dann nicht mehr viel Arbeit. Der Fahrerarbeitsplatz (FAP) benötigt dann aber noch eine Menge Arbeit und schlussendlich ist auch mein "Lieblingsthema" Texturen noch lange nicht auserzählt...


    Zum Bild: ich habe mich entschieden, auch die jüngeren vor-Facelift-Varianten (bis ca. Mitte 1980) mit abzubilden, auch wenn es nochmal eines anderen FAP bedarf. Den VM wird es auch noch mit Dachauspuff geben, sowas wird dann später per cti-Variable gesteuert werden. Die Texturierung ist wie immer noch nicht final.


    dimn4l66.png


    Ich hatte das lürzlich schonmal woanders gezeigt. Hier kannst Du dir die Ausrichtung der Flächen (bzw. korrekterweise der Flächennormalen) anzeigen lassen:


    28u9f8h6.jpg


    Wenn Du alle Flächen markierst und mit ALT-N Flip (oder recalculate) drehst, werden halt alle Flächen gedreht, was aber selten zum gewünschten Ziel führt. Dies ist allerdings nötig, wenn Du Teile eines Meshes oder auch ein komplettes Mesh spiegelst, dabei werden nämlich immer alle Flächen gedreht.

    Die Ausrichtung der Normalen sieht man im Gittermodus am besten im Flächenmodus (Taste 3), weil dann die Wurzeln der Normalen angezeigt werden. Im Solid Shade Modus (weiße Kugel rechts oben) erscheinen die Normalen, die von dir weg zeigen, gar nicht erst, so geht's dann auch recht übersichtlich und einfach.

    Ich habe Alt + N und dann Reset Vectors ausgewählt danach war alles wieder normal, nur habe ich immer noch keine Idee was der Auslöser für das ganze ist.

    ALT-N öffnet das Kontextmenü für die Normalen (die Ausrichtung von Flächen). Oft macht es keinen Sinn, alle Normalen zu resetten, weil das nicht immer zum gewünschten Ergebnis führt. Es bietet sich an, über das Dropdown im Header die Normalen anzeigen zu lassen, am besten im Ebenen-Modus (Taste 3), weil dann die Wurzeln der Normalen einfacher zu sehen sind.


    28u9f8h6.jpg


    Mit Size daneben kannst Du die Länge der "Antennen" ändern. Wichtig ist, dass das Ende, das von der Fläche weg zeigt, zum Betrachter zeigt. Wie gesagt ist es manchmal nötig, auch nur einzelne Normale zu ändern. Das ganze passiert u.a. beim Spiegeln von Flächen, wobei die Normalen immer ebenfalls gespiegelt werden und damit in der Regel in die falsche Richtung zeigen, aber auch beim Extrudieren passiert das regelmäßig.. Ebenfalls wichtig ist, dass die Normalen miteinander verbundener Flächen (Vektoren zusammengeführt - per Merge, Taste M) in dieselbe Richtung zeigen, sonst gibt es die Darstellungsfehler wie in deinem Bild.

    Nur hat das touch ein nachteil wenn du ausversehen aufs gaspedal kommst löst die haltestellenbremse was du bei den alten vdv taster nicht hast solange du sie nicht manuel rausnimmst. die hochbahn schreibt auch vor das du die haltestellen bremse solange eingelegt haben sollst bis du wieder los fährst. Die hochbahn sieht es nicht gerne wenn man die taste der haltestellenbremse einlegt und sofort wieder in die Grundstellung bringt.


    Das ist zwar richtig, mir hat aber in den über 6 Jahren, die ich bei der Hochbahn gefahren bin, niemand das Klick-Klack abgewöhnt oder auch nur irgendwie negativ angekreidet. Auch gibt es dazu keine Dienstanweisung, auf die man sich berufen könnte. Wenn das in der Fahrschule begebracht wird, bin ich fein raus, denn meinen Führerschein habe ich schon viel früher woanders gemacht. Davon abgesehen, ist die Benutzung der Haltestellenbremse an einer Ampel keine Vorschrift, da kann ich genauso von der Bremse rutschen oder versehentlich den Druck nachlassen, wie ich auch versehentlich mittels leichtem Druck auf das Gaspedal die Hst-Bremse lösen kann.
    Bei meinem aktuellen Arbeitgeber, der Ruhrbahn in Essen, gibt es gar nur Taster für die Haltestellenbremse, das ist dasselbe wie das gern genommene Klick-Klack in Hamburg und birgt grundsätzlich dieselbe "Gefahr". Auf Nachfrage konnte mir aber niemand bestätigten, dass es da überhaupt Unfälle gibt, die auf das versehentliche Lösen der Hst-Bremse zurückzuführen ist.


    So, wie komme ich jetzt wieder on topic?


    Meine Fahrzeugwünsche werde ich mir selbst bauen (müssen) (SÜ240, SG192, SG240H, evtl. SL200 als Freeware) oder es gibt die Fahrzeuge ohnehin schon (O 307, O 305 (G), O 303). Einen O 405N2 wünsche auch ich mir inkl. der Derivate GN und GNÜ.