Beiträge von Chrizzly92

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!
    • achtet && auf TRUE und FALSE (Bsp.: 18 5 && wäre 1) oder ob die Werte wirklich identisch sind (Bsp.: 18 5 wäre 0)


    (L.L.ABC) 10 =

    (L.L.DEF) 5 = &&

    {if}



    würde also nur ausgeführt werden, Wenn ABC "10" ist und DEF "5" ist.

    Da OMSI alles als true interpretiert, was nicht Null ist, wäre also 18 5 && immer true, also 1, 18 0 && wäre aber false, also 0.


    • Werden auch bei den Vergleichsoperatoren die beiden miteinander verglichenen Werte gelöscht? Ich meine nein, möchte aber sichergehen ...



    Bei Vergleichsoperatoren werden, soweit ich das Verstanden habe, auch die beiden Stackwerte gelöscht. Das verhält sich genauso wie eine Addition - nur dass anstatt dem Ergebnis halt eine "0" oder eine "1" in den Stack geschrieben wird.



    • Wie genau funktioniert $IntToStrEnh? Ich kann das leider aus dem Wiki-Artikel nicht ganz verstehen ... Was sind die Parameter und was der Output?


    $IntTostrEnh ist quasi dafür da, Ein bestimmtes Format zu bestimmen. Nehmen wir mal an, ich möchte Einen String anzeigen, welcher Immer 2 Zeichen hat - bei einer Digitaluhr beispielsweise.


    Diese zeigt bei Null Uhr "00:00" an; hätte ich jetzt aber eine Variable Für die Stunde und Minute, welche beide "0" als Wert haben und ich diese als Werte verwenden möchte, könnte ich diese mit $IntToStr Umwandeln und mit einem Doppelpunkt verbinden.


    (L.$.Stunde) $IntToStr ":" $+ (L.$.Minute) $+ Ergibt nun aber nicht "00:00" sondern "0:0" - was aber nicht korrekt wäre.


    Mit $IntToStrEnh kann man den String entsprechend Manipulieren und "auffüllen". (L.L.Stunde) "02" $IntToStrEnh würde den String quasi auf 2 Stellen mit Nullen auffüllen, also aus "0" würde es "00" machen. Wäre die Variable 2-Stellig, wäre "02" $IntToStrEnh das gleiche wie $IntToStr, Wäre die Variable 3-Stellig, würde $IntToStrEnh anstatt der umgewandelten Variable "Error" ausgeben.


    Gäbe es eine fiktive 3-Stellige Uhr, welche das Format "000:000" anzeigt, würde man $IntToStrEnh folgenderweise nutzen:


    (L.L.BlockA) "03" $IntToStrEnh ":" $+ (L.L.BlockB) "03" $IntToStrEnh $+ (S.$.3_stellige_uhr)


    Das erste Zeichen innerhalb der Gänsefüßchen ist das Zeichen, mit dem die fehlenden Stellen aufgefüllt werden, das zweite Zeichen in den Gänsefüßchen ist die Länge des Strings.


    • Was passiert bei arctan und arcsin, wenn das Ergebnis nicht möglich/unendlich ist?


    das kann ich dir nicht beantworten, ist in der Regel aber auch nicht relevant. da es sich um eine 32-Bit Anwendung handelt, wäre vermutlich spätestens bei -2.147.483.648 bzw. bei 2.147.483.647 Schluss.

    • Im Fall von (L.L.variable1) ! (S.L.variable1) wird die Variable zu 1 bzw. zu 0, es kommt darauf an, ob die Variable 0 oder 1 ist.
      Wenn die Variable aber bspw. 18 (also größer 0, True) ist, wird sie auch zu 0?

    Exakt. OMSI interpretiert alles außer 0 als "true"; invertierst du also 18, wird null draus; bei einem erneuten Invertieren dann zu 1.


    • Bei der If-Anweisung: (L.L.variable) ! {if} ... muss die Variable alles andere als ihr Wert sein.

    Könnte man so formulieren. Im Grunde wird aus einer 0 eine 1 bzw. aus jedem Wert eine Null.


    • Bei jeglichen Operationen werden die Operanden aus dem Stack entfernt. Also wird der Wert 5 auch bei bspw. 5 random entfernt.
    • True ist alles, was größer als 0 ist.

    True ist auch, was kleiner als 0 ist. Nur die Null selbst wird als "false" interpretiert.


    soweit wie ich das Verstehe, liegt der Vorteil bei diesem Scriptsystem und der umgekehrten polnischen Notation darin, dass das Script Wie ein Buch "gelesen" werden kann. es gibt ja deshalb auch keine Sprünge oder Loops innerhalb eines Frames. Stacks oder Register gibts in anderen Sprachen auch, die eine ähnliche Funktion haben.

    Ich meinte mich zu erinnern, dass im Fahtplan vom Omsi die Auswahl eines Umlaufs zu einer Linie immer identisch war, mit den Umläufen, die man ins IBIS eingibt. Da lag ich wohl falsch.

    Ja, wenn der Kartenentwickler das so hinterlegt hat, ist das durchaus möglich. Das ist aber nicht die Norm.

    an die KI übergeben und trotzdem noch user-eingaben für gas und bremse und türen und sowas von Hand steuern. Das ging bei reinen schienenfahrzeugen zumindest. müsste man mal testen ob das bei bussen auch machbar ist.
    oder mit hunderten getheightabovepoint abfragen das streckenprofil "abtasten", das würde aber nur bis 2.2.032 gehen und ich glaube man kann den lenkwinkel auch nicht aktiv per script beeinflussen...
    ne lösung kann man sich bestimmt irgendwie aus der nase ziehen aber alles wäre halt nur halbgares zeug...

    Ich kann ja damit leben, "nur" zwischen zwei Umläufen wählen zu können...

    Diese unterschwellige Rüge ist hier Fehl am Platze. Dir Fehlen keine Inhalte, weil du "nur" 2 Routen auswählen kannst. Wenn ich von Dresden nach Berlin Fahre und von Berlin zurück nach Dresden, sind das nunmal nur zwei Routen - Hin und Zurück. würde ich jedes zweite mal einen Umweg über Leipzig fahren, hätte ich dann neben Dresden-Berlin und Berlin-Dresden auch noch Dresden-Leipzig-Berlin sowie Berlin-Leipzig-Dresden. Und siehe da - auf einmal gäbe es 4 Routen und nicht nur Zwei.

    Umläufe funktionieren zudem in OMSI nicht. Diese Information wird von OMSI nicht an das Fahrzeugscript weiter gegeben. Es gibt rudimentäre Versuche, so etwas umzusetzen, müsste aber für jede Karte entsprechend hart in das Script reinprogrammiert werden. Das könnte man rein technisch für München machen, willst du den Bus dann aber wo anders Fahren, würde diese Funktion nichtmehr funktionieren.
    Meine Fahrzeuge folgen aber grundsätzlich dem OMSI-Standard und können so Kartenunabhängig mit meist vollem Umfang problemlos eingesetzt werden.


    Ein Kurssystem war in OMSI außerhalb des Fahrplanfensters nie vorgesehen (oder nie von den Entwicklern umgesetzt) und funktioniert nicht so, wie du es eventuell "in Erinnerung hast".

    Mit der Auswahl des Kurses im Fahrplanmenü hast du faktisch diesen Kurs angewählt. die Entsprechend korrekten Zeiten werden nun von OMSI an das Fahrzeugscript übermittelt. der KI-Bus, der auf diesem Kurs unterwegs ist, wird ausgesetzt, da du ja quasi automatisch dessen Kurs übernimmst.


    Das Schildern über das IBIS funktioniert im übrigen eben NICHT. Korrekt ist, dass das Fahrzeug die Liniennummer (die ersten 3 Stellen der Eingabe) als Linie wertet und anzeigt. Ist die Route ungültig, wird allerdings kein Ziel geschildert. Hier bleibt eventuell das zuletzt geschilderte Ziel stehen, wenn die Eingabe nicht korrekt ist, mit 15003 oder 15004 kann das Fahrzeug technisch nichts Anfangen. Wenn das IBIS sagt, dass die Eingabe nicht korrekt ist, dann wird auch nicht in den "Fahrplanmodus" gesprungen.
    Hier noch eine kleine Hilfestellung:
    Du suchst dir deinen Kurs im Fahrplanmenü raus, den du fahren möchtest. diesen wählst du ganz normal aus und merkst dir am besten die Abfahrtszeit an der Starthaltestelle. Nach der Auswahl wählst du im IBIS die passende Route zu dem Kurs aus, auf der 150 gibts nur Hin und zurück. dann stellst du die Uhr auf ein paar Minuten vor der Abfahrt und fertig.

    Und nochmal, zum Verständnis: das Fahrzeug erwartet eine Kombination aus LINIE (XXX00) und ROUTE (000XX). Linie 150 mit der Route 01 wird also als "15001" eingegeben. Nur weil ein Kurs existiert, der als "15003" geführt wird, ist das nicht das gleiche wie die Kombination aus 3-Stelliger Linie und 2-Stelliger Route.

    Warum die Gegenrichtung nur 2 Umläufe hat, wird dir sicher Olgu_M erklären können.

    In Ihrem Funktionsweise gibt es keinen Unterschied. die Operanden stehen faktisch nie im Stack, denn mit dem Operand werden ja die ersten beiden (oder die letzten beiden? Je nachdem wie man das sehen will :D) Werte verarbeitet . die beiden alten Werte werden aus dem Stack entfernt und der neue Wert wird reingeschrieben. Im Grunde prüft ein "&&" ja auch nur, ob beide Werte größer Null sind und wenn ja, schreibt er eine "1" als Ergebnis in den Stack.

    Die korrekten Abfahrtszeiten holt sich OMSI zudem aus dem aktuell aktivierten Fahrplan, also aus der Information, die du beim "Schildern" über das Menü definiert hast. Den Umlauf musst auch eigentlich nicht definieren, denn das entsprechende KI-Pendant entfernt OMSI automatisch, sobald du diesen Umlauf nimmst.

    Ich glaube du kannst bei den objekten über den Editor einstellen, ob und wann diese aktiv sind. wie geanu das funktioniert, kann ich aber nicht sagen.

    scheint so als hättest du das script in der sco nicht hinterlegt.

    nehmen wir mal die kirche aus dem standardcontent als beispiel:


    6dFYidp.png


    genauso musst du in der *.sco die varlist und das script eintragen. OMSI erkennt das nicht automatisch, das muss entsprechend definiert werden.


    im grunde checkt das Script, ob vor 5 uhr oder nach 22 uhr; wenn ja, setze auf 1, sonst auf null und speichere dann in schranke_state. das ist halt die kompakteste form des scriptes, man könnte es auch so schreiben:


    Code
    {frame}
        (L.S.Time) 18000 <=
        (L.S.Time) 79200 >= ||
        {if}
            1 (S.L.Schranke_state)
        {else}
            0 (S.L.Schranke_state)
        {endif}
    {end}

    sollte so besser erkennbar sein. Grundsätzlich hast du das aber schon richtig verstanden. :-)

    InUse ist eine OMSI Interne variable, die dem Objekt sagt, ob es aktiv ist. das kannst du mit sicherheit irgendwo einstellen. willst du ein Script nutzen, musst du eine Varlist mit "Schranke_state" als variable erstellen und definierst diese in der sco.

    dann brauchst du noch ein kurzes script, welches jeden Frame aufgerufen wird:


    Code
    {frame}
    (L.S.Time) 18000 <=
    (L.S.Time) 79200 >= || (S.L.Schranke_state)
    {end}



    Schranke_state ist "true" oder "1" vor 5 Uhr und Nach 22 Uhr; ansonsten ist schranke_state false oder 0. dementsprechend musst du die Konfig anpassen:


    fertig.

    Zumindest in meiner Hofdatei gibt es lediglich die Routen 15001 sowie 15002.
    AN6EorO.png


    Die, die du nutzen willst, können also eigentlich nicht funktionieren.


    Mit einem Blick ins Handbuch erkennt man auch, welche Routen/Linienkombinationen vorgesehen sind:


    8b2nZic.png


    sowie


    ofpigFz.png


    15003, 15004 oder ähnliche sind nicht vorgesehen. In welcher Form der BBS hier ggf. die Spielinhalte manipuliert kann ich nicht sagen und du solltest dich für support entsprechend an die BBS-Entwickler wenden.

    Grundsätzlich unterstützt die UE4 Controller wie den Sony DS4 oder die XBox-Controller out of the box. für Logitech gibts auch einige Plugins.
    Als was gibt sich dein Arduino denn genau aus? alle DirectInput und X-Input Controller sollten eigentlich auch problemlos funktionieren.


    Die UE4 ist nahezu grenzenlos erweiterbar. Für Arduino gibt es beispielsweise UE4Duino als OpenSource-Plugin. Vorraussetzung für die Kommunikation ist allerdings, dass dies Spielseitig auch eingepflegt wurde - und das ist soweit ich weiß nicht der Fall. Selbst wenn es mal Modding geben sollte, wird Viewapp mit Sicherheit keine Möglichkeit schaffen, C++ Plugins zu entwickeln. Ist also keine eigene Lösung geplant, wirst du Leuchtmelder, Innenanzeigen o.ä. nicht ansteuern können.

    Ja, terrain lässt sich exportieren, aber auch nur dieses - keine Bäume. Das sollte aber für Objekte, die den Eintrag [tree] oder wie der hieß haben, irrelevant sein - denn OMSI fasst das intern schon zu einem großen Face zusammen. Das hat Marcel sogar mal irgendwo geschrieben.
    Ansonsten würd ich für das Collisionmesh auch erstmal versuchen, dies durch eine leere o3d oder x-datei zu definieren.

    alles im editomode selektieren -> M (für "Mirror") und dann einmal "Z" drücken, um es auf der hochachse zu invertieren. Natürlich vorrausgesetzt, dass du die krezung beim import korrekt gedreht hast. (Z-Hochachse, Y-Vorwärtsachse, X Seitliche Achse)

    Urbino_II_brea.osc, Zeile 508 und 509 für automatisches kneeling;
    Urbino_II_brea.osc, Zeile 560 und 561 für manuelles kneeling.
    Einen Kneelingwinkel oder eine Sollhöhe gibt es nicht. Die Feder wird quasi "dünner" gemacht, sodass das Fahrzeug auf einer seite tiefer steht. erhöhst du die Werte zwischen den beiden Variablen, wird die Feder weicher, verringerst du die Werte, wird die Feder härter.

    JpDg7mS.png