Beiträge von Chrizzly92

Bus: MAN SL2x2 (W.I.P)
Karte: Grundorf

Zitat von Tabley-Kun

Wenn erstes: Das ist nur ein Displaying-Fehler.

Ne, das ist ein Mappingfehler. der Alpha-Bereich hin zur Scheibe ist zu knapp gewählt bzw. die Faces bis zum Rand der Textur gemappt.

erstell doch mal nen testscript mit
"String123" (S.$.Dest1)

"String123" (S.$.Dest2)

"String123" (S.$.Dest3) etc.

und PRÜFE, ob das funktioniert.
Wenn man etwas debuggen will und hilfe im Forum suchst, solltest du das auch schrittweise sinnvoll durchführen, und nicht davon ausgehen dass es funktioniert, nur weil eine beschreibbare variante funktioniert.

Also Grundsätzlich finde ich die Art des Scriptens suboptimal (Textfelder einfach mehrfach überschreiben, wenn ein vorheriges Ergebnis nicht (mehr) valide ist) aber grundsätzlich kann ich da jetzt rein vom syntax nichts kritisches erkennen. Was sagt das Logfile? Hast du wirklich alle Textfelder mal geprüft, ob sie sich per Script beschreiben lassen? Ist der Font in Ordnung?

Maßgeblich für die Ladezeit beim Starten sind die Internettexturen und die Fonts. viele Fonts -> lange Ladezeiten. viele *.itx - lange Ladezeiten.

Zitat von Elias_

Hallo zusammen,

ist in nächster Zeit noch ein Bugfix für den mitgelieferten MAN geplant? Einige Bugs, die ich vor sehr langer Zeit schonmal gemeldet habe, sind leider immer noch vorhanden. Die Räder werden im Display bei aktiver Feststellbremse nicht ausgemalt und man kann Gänge einlegen, ohne die Bremse zu betätigen.

Ich hab das Fahrzeug zwar in OMSI importiert und gescriptet, Bugfixes wird es von meiner Seite aus unterschiedlichen Gründen allerdings nicht geben. Eventuell findet sich ja jemand im Hause Halycon, der sich dem Ding nochmal annimmt.

Zitat von Thomas U.

KI-generierte Welt klingt zwar interessant, aber die KI, die mir auf Mausklick die Linie 1234 von Hohenwulsch nach Hintertupfingen nachbaut, möchte ich erstmal sehen. Für Fantasiekarten wäre das vielleicht denkbar, aber hier liegt doch auch der Reiz beim kreativen Bauen.

als vollständigen Ersatz in einer Simulation ist das natürlich nicht zu gebrauchen, aber um beispielsweise plausible Vegetation zu generieren, schon eher. Ich sehe das realistischerweise bei Sachen wie einem Fluss, der entsprechend ordentlich begrünt wird, als "Lückenfüller" für Seitenstraßen und so weiter. Das würde in der Entwicklung so einiges erleichtern.

Tatsächlich kam ein Update, welches aber NICHTMEHR von Janine gepostet wurde, sondern von Marcel selbst. Janine hat seit Anfang des Jahres keine Beiträge mehr gepostet.
Diese Tatsache ist aber grundsätzlich als Vorteil zu Werten, auch wenn der Zug für LOTUS mMn. abgefahren ist (haha) - Viele Leute haben ja kein Problem mit LOTUS oder Marcel, sondern mit Janine - und das wegbleiben dieser kann für die Community nur Vorteilhaft sein.

Zitat von IREgio612

Naja an sich kannst du Sounds schon repaintabhängig machen. Bedarf nur einen kleinen Umweg.

Du musst in der cti-Datei einen neuen setvar-Eintrag reinschreiben, der einen Wert enthält - bspw.:

Code

[setvar]
tuersound
1

Und dann musst du herausfinden, wo der entsprechende Soundtrigger steht; also in welchem Script. Türsounds finden sich in der Regel im Türscript.

Wenn du den Trigger gefunden hast, musst du diesen nur noch in eine Bedingung schreiben:

Code: VORHER

(T.L.Mein_Soundtrigger)

Code: NACHHER

(L.L.tuersound) 0 =
{if}
    (T.L.Mein_Soundtrigger)
{else}
    (L.L.tuersound) 1 =
    {if}
        (T.L.Mein_Soundtrigger_2)
    {endif}
{endif}

Das kann natürlich auch beliebig erweitert werden.

Alles anzeigen

geht sogar noch leichter - dem Soundtrigger in der Sound.cfg duplizieren, einen [conditionsingle]-tag hinzufügen und so einfach mit der Variable steuern, welcher Soundtrigger jeweils ausgelöst wird.

Bus: MAN SG 2x2 (Privat)
Map: Grundorf

4-stellige Linien werden von diesem Fahrzeug nicht unterstützt.

Zitat von DerErzbusfahrer

ent-BVG-isiert.

Frech!

Zitat von Busfahrer1991

Das ging mir mathematisch ein wenig zu schnell
Wir suchen uns mal Beispiele aus an denen du mir das bitte nochmal erklären kannst:

Bei den großen Objekten hätten wir:

Die Textur vom Hotel Adlon hat eine Größe von 2859x1489
Die Textur vom Europahaus 2613x2136

Bei den kleinen Objekten hätten wir:

Die Textur vom LützowCarree mit 710x640 und 445 KB

(da dachte ich eigentlich bin ich schon ganz gut mit)

Alles anzeigen

Deine Frage wurde ja nun schon von anderen beantwortet. In blender mappst du grundsätzlich relativ, also Prozentual. ein vertex bei 0,5 (50%) wäre also immer in der mitte, egal welches Seitenverhältnis du wählst. Die Texturen können also jede x-beliebige größe annehmen, solltest aber beim ungefähren seitenverhältnis bleiben, damit die Texturen nicht zu sehr gestaucht oder gestretched werden.

Hotel Adlon von 2859x1489 auf 2048x1024
Die Textur vom Europahaus von 2613x2136 auf 2048x2048

Die Textur vom LützowCarree von 710x640 auf 512x512

die Texutrkoordinaten in Blender sind relativ, nicht absolut. Also immer abhängig von der Breite der Textur.
Hättest du jetzt beispielsweise ein Quadrat auf eine Textur gemappt und dieses einmal in der MItte geteilt, liegt diese Edge auf den Koordinaten
X0,5; Y0
und
X0,5; Y1.

hat das Bild jetzt eine Breite von 512 px, wäre diese Edge genau bei 256px.
Hätte das Bild jetzt 600px, läge diese Edge bei genau 300. Es wird also immer relativ halbiert.
Du kannst also bedenkenlos alle Texturen zur nächst kleineren oder größeren 2'er Potenz verkleinern/vergrößern.
Im Beispiel von omsi_sw könntest du die DDS Datei so bedenkenlos auf 512x512 skalieren, ohne dass sich etwas an der Optik ändert. Auch formate wie 512x256 px oder 128x2048 sind möglich.
Beachten solltest du außerdem, dass Intern alle Texturen, die nicht der zweier-potenz folgen, immer auf die nächst größere Dateigröße skaliert werden.
Hättest du jetzt übertrieben gesagt 513x513 px bilder, würden sie einen Speicherplatz von 1024x1024px benötigen, also das 4!! Fache der eigentlichen Texturgröße. Dann lieber um den einen Pixel auf 512x512 verkleinern, um massiv zu sparen.

Zitat von Lµkas

Ich glaube, dass da in Richtung Modding Tools noch mehr kommen wird. Der Karteneditor ist ja erst der Anfang und mit der mächtigen Engine kann man quasi wie OMSI alles machen, was einem lieb ist.

hmn, schön wäre es, glaube ich aber nicht daran.
Das aktuelle System ermöglicht einen recht zügigen Straßenbau für flache Topographie. In Berlin mag das gehen, in Brandenburg eventuell auch noch. Spline legen, Poly erstellen, gib ihm. Bisschen eine Mischung aus LOTUS und OMSI. Vor allem aber im Überlandbereich, wo die UE durch dynamisches Nachladen und optische Shader, Weitsicht und optische Tiefe Punkten kann, versagen die Moddingtools auf ganzer Linie.
Das erstellen von Kreuzungen mit z.bsp. Überhöhungen in Hanglage ist mit dem Splinesystem nicht umsetzbar. Hinzu kommt, dass u.a. aus Assetschutz-Gründen der Export von zum Beispiel Splines deaktivert wurde.
Es ist also nicht möglich, wie beispielsweise in OMSI, Straßen zu verlegen, die Spline-Endstücke zu exportieren und so den Kreuzungsbereich in Blender umzusetzen.
Übrig bleiben hier also im Grunde nur folgende Möglichkeiten:
- Der Verzicht auf Inhalte in topografisch anspruchsvollen Gebieten
oder
- Den Straßenbau vollumfänglich in z.bsp. Blender auslagern.

Ersteres entspricht nicht meinem Anspruch in 2023, für letzteres Bedarf es keine Moddingtools, die beim Inhalt-Erstellen helfen.

Um eine Kreuzung ordentlich in den TheBus-Moddingtools bauen zu können, muss sie in allen Ausrichtungen nahezu Waagerecht liegen. Kommt man auf einer Straße mit Gefälle auf eine Kreuzung zu, wäre diese Polygonmüll wenn man sie wirklich versucht in Hanglage zu bauen oder man müsste sie flach setzen und dann, a la San Francisco, die abgehenden Straße kippen. Das kann man eventuell auf einer fiktiven casual-karte bringen aber nicht auf einer realistischen.

Die Ansätze sind wirklich gut, aber gefühlt hat man an den Grenzen Berlin's aufgehört über die Machbarkeit nachzudenken und wichtige Features wie den Splineexport kategorisch ausgeschlossen, um ein paar Assets zu schützen.

Und wenn hier schon die Machbarkeit eingeschränkt wird, wird sich das beim Busmodding auch nicht groß ändern. Selbst wenn du innerhalb des Blueprints ggf. machen kannst was du willst, wird man mit Sicherheit die relevante Logik von einer Parentclass erben müssen. Ich hoffe, dass wenigstens dort ein einfaches Pawn referenziert werden kann und wirklich alles andere dem Nutzer überlassen wird. sonst kommt einer mit einem Megashuttle an und scheitert an der physikalischen Grundlage eines 4-Achsers oder einem SG242H mit aktiv gelenkter Hinterachse, weils nicht vorgesehen ist.

und das ist wieder Einbildung. Diese Variable kennt nur "hat antrieb" oder "hat keinen Antrieb" (1 oder 0.) das Drehmoment, welches vom Script in die vordefinierte, lokale Variable "M_wheel" geschrieben wird, wird auf alle angetriebenen Räder gleichmäßig aufgeteilt. Kommastellen funktionieren nur, weil OMSI alles, was nicht 0 (false) ist, als true interpretiert.
0 ist also ohne antrieb
0.1 ist mit antrieb
0.627 ist mit antrieb
52125 ist mit antrieb.
Wäre es ein Multiplikator, wie du es beschreibst, müsste das Fahrzeug ja bei positiven Werten das Drehmoment am Rad verdoppeln, verdreifachen, ver-52125-fachen. würde ich im Nachläufer 0,1 eintragen, hätte das Fahrzeug nur noch 1/10 seines Drehmoments - und das ist nicht der Fall.
Das kann man auch selbst testen. es macht keinen unterschied, welcher wert bei Achse_antrieb steht, entweder ist es 0, dann ist die achse nicht angetrieben, oder sie ist irgendeine andere zahl, dann ist sie angetrieben.

vermutlich, weil der "echte" Bus gegebenenfalls schnellere Entlüftungsventile hat und/oder bei der Verwendung von E-Gas das Gasgeben unterbindet, solange die Bremsen angelegt sind. Habe ja selbst gesagt, dass die Simulation hier nicht perfekt ist.

Mir ist das im Grunde auch wurscht. Dieses grundsätzlich physikalisch korrekte Verhalten damit zu kompensieren, einen Allradbus zu bauen, damit es "realistischer" wird, macht es faktisch aber unrealistisch und das regt mich schon seit Jahren auf.

Zitat von Volker_Rieck

Sofern die Zahlen von Steam DB stimmen, sind es nicht wirklich viele Spieler.
Peak Mai 2022 mit 78 und aktuell um die 15 in der Spitze.
OMSI recht kontinuierlich 1400 am Tag. Peak war im Dezember mit 2.300 im letzten Jahr.
Da spricht schon Bände.

Wobei man da fairerweise sagen muss, dass die Spielerzahlen seit Release auch kontinuierlich bei OMSI gestiegen sind. das ist ja jetzt auch kein Spiel was gestern erschienen ist. Das kann LOTUS ja auch noch erreichen. Die Frage ist halt, ob sie es überhaupt zu dem Punkt schaffen, sich im Markt als richtige alternative durchzusetzen.

Nun, ich kann jetzt nicht beurteilen, wieviel davon Mutmaßung und wieviel wirklich so kommuniziert wurde, aber wenn man sich folgende Punkte überlegt:
-Marcel, einer der Entwickler, kommt Ursprünglich aus der Flusi-Szene;
-Das Logo im Menü von LOTUS ist quasi ein Flugzeug;
-Das Fliegen wird/wurde als 3. Modul angekündigt: Hier Klicken
-Auf der realen LOTUS-Welt können Kacheln nur einmalig bebaut werden, es ist keine Doppelbelegung möglich.

Die Idee dahinter ist meiner Meinung nach, eine Welt zu erschaffen, bei der mehrere DLC oder Inhalte verbunden werden können. Gäbe es Beispielsweise das Add-on Köln und das Add-on Düsseldorf, könnten so die Beiden Karten an der Kachelgrenze verbunden werden und im optimalsten Falle so ganze Landstriche mit Inhalten gefüllt werden.
Genauso könnte man dann beispielsweise auch größere Flughäfen als DLC entwickeln und so in Kombination mit der Community diese Welt immer weiter mit Inhalten füllen. Kannst dann irgendwann mit nem Leichtflugzeug in irgendeinem Dorf Starten und wo anders landen - vorausgesetzt, die Inhalte wurden auch entwickelt.
Diese Mengen an benötigtem Content muss man sich aber auch erstmal vor Augen halten. Wer soll das alles bauen und einpflegen?

Doch, das ist so realistisch. Das hat was mit Lastwechsel, Fahrdynamik, Hebelwirkungen bzw. Drehmoment und dem Gewicht auf der mittleren Achse zu tun. Da gibts auch keine Diskussion, das ist nunmal Physikalisch so.
Der Bus schiebt über die Hinterachse das Fahrzeug an. blockierst du aber durch die Haltestellenbremse die mittlere Achse, wird das Fahrzeug mittig angehoben und taucht vorne leicht ein.
Wenn du beim Auto mit blockierter Handbremse losfahren willst (welche nur auf die Hinterachse wirkt), taucht das Fahrzeug ebenfalls hinten ein.
Jetzt kann man sich drüber streiten, dass die Simulation in OMSI dahingehend nicht perfekt ist - da gehe ich mit. Eventuell könnte OMSI hier ein wenig mehr Dämpfung im Nickwinkel des Gelenkes vertragen - auch da gehe ich mit.
Dieses Phänomen allerdings damit zu lösen, die Mittlere Achse ebenfalls anzutreiben und das Fahrzeug quasi zu einem "Allradbus" zu macht, macht das ganz nicht realistischer, sondern unrealistischer.

Warte doch mal testweise eine sekunde, bevor du mit Vollgas losfahren willst. du wirst feststellen, dass das Fahrzeug - sobald die Bremsen gelöst sind - von alleine losrollt und du dann - oh wunder - auch sofort beschleunigen kannst. Solange die Bremsen nicht vollständig gelöst sind, besteht auch dieses Phänomen.

Wenn man nämlich mal drüber nachdenkt und wirklich mal ordentlich beobachten würde, stellt man fest dass die grundsätzliche Umsetzung so sehr wohl korrekt ist.
Wenn du beim Motorrad zu viel Gas gibst, würdest du einen Wheelie machen. Warum? Weil das Drehmoment am Hinterrad auf das Fahrzeug wie ein Hebel wirkt und so die Vorderachse entlastet wird. Umso größer das Drehmoment und umso leichter die Mittelachse, desto höher wird sie auch "angehoben. hättest du ein Gelenk am Motorrad und ein drittes rad weiter vorne, würde das Fahrzeug genauso in der Mitte einknicken.



Würde man jetzt beide Achsen antreiben mit jeweils 50% des Gesamtdrehmoments, kann das Fahrzeug rein physikalisch nichtmehr knicken (wir gehen von einer optimalen Gewichtsverteilung und dem gleichen Schwerpunkt im Bezug zur Achse aus). Bleibt die Haltestellenbremse dabei aktiviert und das Rad kann sich nicht drehen, würde sich dieses Konstrukt genauso wie ein Auto mit angezogener Handbremse beim losfahren nicht in der mitte aufbäumen sondern die hinteren beiden Achsen würden durch die "effektiv wirkende" Kraft das Fahrzeug näher zum Boden ziehen.

Das ist jetzt physikalisch natürlich nur angeschnitten mit dem Versuch, das ganze anschaulich zu machen. und wer das nicht versteht nochmal zurück in die 6. Klasse und in Physik aufpassen. Setzen, 6!