Beiträge von Chrizzly92

Zitat von Roadmaster '93

Hier muss meiner Meinung nach ganz dringend eine Lösung her. Ich habe keinen blassen Schimmer, wie Force Feedback in OMSI Funktioniert, aber das dürfte ja auch über Scripts gesteuert werden.

RE: Add-on MAN Standardbus II

fehlt im SL und SÜ tatsächlich der Sound. danke für den hinweis! SG müsste aber gehen - da hab ich nur vergessen, diese aus dem nachläufer in den solo zu übertragen.

Für Voith fehlt mir die Vorlage.

das geht leider nicht, da es sich um das gleiche Fahrzeug handelt. du kannst allerdings, sofern das Umstellen nicht vom Repaint untersagt ist, das Getriebe auch einfach auf dem Drucker umstellen. Eine Beschreibung der Funktionen findest du im Handbuch.

Zitat von wurstbrot

Kann sein dass die LVA einen Bug hat: Als Endhaltestelle wird eine Haltestelle unterwegs angezeigt. Vielleicht liegt es aber auch daran dass kein Fahrplan beim Test aktiv war.

ist die Linie vielleicht auf zwei Routen aufgeteilt oder die Hofdatei nicht komplett mit Standardfahrzeugen kompatibel? Die Anzeige generiert aus Linie und Route die Haltestellenanzahl und nimmt den letzten index in ebendieser Linie. Da kann eigentlich nichts falsch sein, außer man weicht vom OMSI-Standard ab. Schick mir mal die Hofdatei als PN, inklusive der verwendeten Linien/Routenkombination. dann schaue ich mir das gern mal an.

Zitat von Pictor

Ich bin jetzt bereits ein bisschen mit dem Bus unterwegs gewesen. Die Busse mit den weißen, sauberen Repaints haben alle weiße LED-Anzeigen, Flipdots oder Annax. Soll das so und kann man das irgendwie beeinflussen, dass die Flipdot und Annax grün und die LED orange wird?

das wird übers Repaint gelöst und ist so umgesetzt, damit diese Funktion auch hier und da Verwendung findet. die entsprechenden Tauschtextureinträge musst du einfach nur aus der CTI rauslöschen und dann sind sie wieder standardmäßig orange oder grün. Die MVG hatte beispielsweise Weiße Annax-Segmentanzeigen, sodass ich diese Repaintfähigkeit benötigt und dann kosequenterweise auch für alle Anzeiger umgesetzt habe.

Zitat von Capacity10

Ich musste bei einer engen Kurve mit dem Gelenkbus zurücksetzen, dabei ist mir aufgefallen, der Bus hat keinen Knickschutz, also wenn ich weiter zurückfahre und das Gelenk voll eingeknickt ist, stoppt der Bus nicht und schiebt das Hinterteil mit.

Zitat von Fahrzeuganleitung

"Sollte je der maximal zulässige Knickwinkel erreicht werden, kommt zur Konstantdämpfung ein elastisch einsetzender mechanischer Endanschlag zur Wirkung."

sowie:

"Höchstgeschwindigkeit von ca. 5km/h bei Rückwärtsfahrt nicht überschreiten (entspricht in etwa der Schleppdrehzahl des Motors)

sowie:

"Im Rangierbetrieb auf engstem Raum die Fahrgeschwindigkeit durch dosiertes Lösen der Betriebsbremse regulieren. Nur wenig "Gas" geben, nicht mit dem Fahrpedal spielen"

Alles anzeigen

Von Gaswegnahme oder einer mechanischen Sperre ist da keine Rede. auch das Vorbildfahrzeug hatte dahingehend keinerlei Taster oder Warnungen verbaut. Damals hat man scheinbar noch auf die eigenverantwortung des Fahrers gesetzt, dass man mit einem Gelenkwagen rückwärts aufpassen muss. Das könnte man sich aber optional für ein Update merken, denn es war als Sonderausstattung durchaus auch zu bestellen.

Zitat von Dominique/NEW´MöBus

Also ich muss ganz ehrlich sagen Add-On gekauft und direkt verliebt ich kenne zwar die Fahrzeuge nicht persönlich bin auch noch nie mit einem SL/SG gefahren aber der Sound und alles drum und dran ist einfach nur Pornös.

Meine Frage ist aber ist das mit dem Force-Feedback so gewollt das das Lenkrad einem die Ohren voll klappert weil abgesehen von dem ist das Add-On einfach nur meeeeeeega gut und klasse wie man es halt von dir kennt Chrizzly

mit standard omsi force-feedback vibriert das bei niedrigen drehzahlen, ja. das ist so auch vorgesehen, ist halt kein Neuwagen.

im MAN_SG_misc_constfile.txt kann man im Bereich FF_vibampl_n die Curve so ändern, dass es im Leerlauf nicht klappert. dafür einfach anstatt

[newcurve]
FF_vibampl_n

[pnt]
0
0

[pnt]
250
0.75

[pnt]
500
1

[pnt]
600
0.1

folgendes eintragen:

[newcurve]
FF_vibampl_n

[pnt]
0
0

[pnt]
250
0.75

[pnt]
350
1

[pnt]
500
0.1

und damit ist das vibrieren des Lenkrades bei niedrigen Drehzahlen weg.

Edit:

Zitat von wurstbrot

Daher warte ich auch gerne auf das Update und hoffe dass das Linienband da auch eins ist und nicht dreigeteilt. Wäre aber glaub ich in OMSI was neues.

Ja, das Linienrollband bleibt einteilig. das macht die "Rolllogik" aber nicht gerade einfacher, denn im Original sind dort häufig nur die verwendeten Linien und Sonderzeichen hinterlegt, in OMSI müsste man dann konsequenterweise ja "alle" hinterlegen. und dann durch 999 Linien drehen....

Das ist eins der Probleme, die das Script dafür halt recht komplex machen. es müssen genug rein, dass es authentisch beim Drehen bleibt, es müssen aber auch Linien, die auf der Karte nicht existieren, Schilderbar sein (für Screenshots etc.). Da wird aufjedenfall irgendeine intelligente Lösung für folgen, das ist aber nicht in 2 Tagen erledigt.

Die fehlenden Templates werden im Laufe des Tages eingepflegt und sind spätestens morgen früh verfügbar.

Für Repaints der Außentexturen empfehle ich allerdings grundsätzlich, die 8k Varianten zu verwenden. Je nach Repainttyp kann es aber sinn machen, diese in "16k" zu entwickeln und dann herunter zu skalieren - das ergibt häufig bessere farbverläufe bei z.bsp. rundungen. die native Nutzung der 16k Texturen kann ich nicht supporten, das führt vermehrt zu Ladeschwierigkeiten und 3D-Device-Resets.

Zitat von Neoplan VEST

Zitat von flOmsi

Hätte mir ja den SG 240 H gewünscht aber denke, das ich trotzdem darin investiere

Zum Thema SG 240 H hatte Chrizzly meine ich auch seine Gründe genannt warum die nicht umgesetzt wurde.

Das eine war glaube ich wegen der Verfügbarkeit eines realen Vorbild und das andere war auch Physik bedingt in OMSI da die Hinterachse in der Kurvenfahrt mitgelenkt wird und dieses mitlenken wird, wenn ich das noch richtig in Erinnerung habe, von OMSI nicht unterstützt.

Bitte verbessert mich wenn ich falsch liege

Zum Addon:

Da bin ich mal gespannt auf morgen

Mir fällt auch erstmal keine großartige Frage dazu ein.

Dann warten wir mal ab

Alles anzeigen

Das ginge im Grunde schon, aber nicht wirklich realistisch. man kann den Drehpunkt zwar so verändern, dass es optisch mit lenkt, aber die Nachlaufachse bewegt ja aktiv den Nachläufer und verursacht damit eine Wechselwirkung, die auch auf den Winkel wirkt. und genau DAS geht eben nicht. Zudem ist das ja auch eine ganz andere Baureihe, zu der ich kaum Bezug habe. ist dann eher so eine Rolf Westphalen oder Perotinus baustelle.

fairerweise muss man erwähnen, dass ich das erst NACH seiner Frage hinzugefügt habe. Die Frage von Herrn Grey war also berechtigt.

Dies ist der Support-Thread für das Add-on "MAN Standardbus II".

This is the support thread for the add-on "MAN Standardbus II".

Dies ist der Kommentarthread zum Add-on "MAN Standardbus II".

Eine Vorstellung des Projektes findet ihr Hier: OMSI AddOn MAN Standardbus II

Das Addon erscheint am 11.01.2024.

ich prgrammiere meine Fahrzeuge i.d.R. so, dass sie zu 100% mit standardcontent kompatibel sind. dass heißt, ich setze auf grundorf und spandau als KI ein und checke, ob die fahrzeuge ordnungsgemäß fahren. wenn du also fahrpläne definierst, würde ich immer mit den standardfahrzeugen arbeiten, da man bei drittanbieterwagen immer irgendwelche sonderheiten hat und erst zum schluss die ai-list mit eigenen fahrzeugen bestücken. aber gut möglich, dass so ein verhalten dort nicht auftritt, weil die wartezeit auf grundorf an den endstellen i.d.R. mehr als 4 minuten beträgt.

es sind ja auch unterschiedliche scripts.
wie gesagt, omsi bietet für die KI Interaktion i.d.R. nur eine Variable, mit welcher man arbeitet - und das ist AI_Scheduled_AtStation.
Referenz: System- und vordefinierte lokalen Variablen
Diese Setzt OMSI (Abfahrtbereit machen!) auf "-1", was für mich heißt: Türen schließen und abfahrt. sind alle bedingungen erfüllt, setze ich wiederrum die Variable auf 0, damit wird die Steuerung wieder an OMSI übertragen und die KI fährt das Fahrzeug weiter.
Ich habe damit im Grunde keinen Einfluss auf das Verhalten in OMSI. vergleiche ich beide Scripts, ist die routine auch nahezu identisch. das einzige, was die KI beim normalen Script zusätzlich macht, ist elektronik einschalten, motor starten, gang einlegen, bremse lösen, weil das fahrzeug sonst logischerweise nicht fährt.
da gibts auch keine kontrollroutine, ob die fahrplanzeit erreicht ist oder so, dementsprechend wüsste ich jetzt auch nicht, wie man das beheben kann. man könnte ein künstliches delay einbauen, dass er erst losfährt, wenn die abfahrtszeit erreicht ist oder so, aber das führt bestimmt zu anderen, bisher nicht absehbaren fehlern, wenn die KI losfahren will, das fahrzeug sich aber minutenlang nicht bereit macht.

grundsätzlich machen beide scripts nicht viel anders. omsi übermittelt ja dem fahrzeug, was es machen soll, das fahrzeug sagt nur sachen wie "Ja, abfahrtbereit" oder "nein, noch nicht abfahrtsbereit".
um wie viel abweichung handelt es sich denn?

ganz ausschließen würde ich nicht, dass ich für TheBus etwas mache. Das Problem ist hier eher wieder, dass die - zum aktuellen Zeitpunkt existierenden - Möglichkeiten des Moddings nicht an die von OMSI heran reichen, und durch "hausgemachte" Einschränkungen Projekte, die die Funktionen der Engine super nutzen könnten, technisch nicht in einem vernünftigen und qualitativen Rahmen umsetzbar sind. Das mag gehen, wenn man wie für Fernbus generische Splines und 0815 Kreuzungen verwendet. Gehts aber beispielsweise um Überhöhungen, Graderprofile oder komplexe Topographie im Kartenbau und damit um eine realistsche Abbildung der Fahrphysik (z.bsp. das durch die Straßengeometrie verursachte Wippen des Gelenkbusses beim Überfahren einer Kreuzung, aktive Force-Feedback-Eingriffe durch Straßenquerneigung etc.), kann man TheBus vergessen.
Die Engine selbst ist potent genug, viele Einschränkungen werden quasi erst hereinprogrammiert, um das Modding auf der einen Seite zu vereinfachen, was aber unweigerlich die "Experten" einschränkt.
OMSI 3. mehr braucht es eigentlich nicht. Gleiche Gedanken, gleiche Simulationstiefe, gleiche Schwerpunkte, mit einer effektiven Engine. Alles andere kann und wird an den Erfolg von OMSI nicht anknüpfen können.

ohne die entsprechenden Hofdateien kann man dir nicht helfen. dass das Fahrzeug während der Fahrt auf München das Ziel wechselt, ist so gewollt, da die Fahrgäste, die schon an der Haltestelle stehen, sonst an der ersten Tür "hängen bleiben", und vorallem im Buszug nie die hinteren einstiege benutzen würden.

Zitat von Lazarus

Ich glaube stark, dass er mit der Situation nicht zufrieden ist. Ich finde es total positiv, dass Qualität einen großen Faktor spielt.

In diese Position haben sie sich aber aufgrund der Ignoranz, Überheblichkeit und Besserwisserei selbst manövriert. "Wir wissen, was wir tun." Qualität ist nicht nur die Umsetzung einer speziellen Sache innerhalb des Simulators, das Gesamtkonzept muss funktionieren.

Zitat von gt670dn

Zitat von Chrizzly92

Maximalprofit

Inwiefern wird denn mehr durch das geschlossene Content-System mehr verdient?

Ansonsten stehe ich an dem Punkt tatsächlich auf Deiner Seite, hatte mir auch immer einen Tramsimulator erträumt bei dem man sich dann allerlei Fantasie selbst zusammen modden kann mit der Freiheit von Omsi. Aber ist jetzt halt nich so geworden...

Manche haben aber auch schon gesagt, dass sie mit einem offeneren System gar nichts für Lotus machen würden, weil sie auf die Zustände wie bei Omsi keine Lust hätten. Das finde ich persönlich zwar sehr schade, aber eben eine Abwägungsfrage der Reichweite die man als Entwickler treffen muss wenn derartige Ansichten existieren.

Eigentlich bräuchte es in der Nahverkehrs-Sim-Community mal eine spielunabhängige Platform auf der quelloffene "Rohfahrzeuge" frei getauscht und inkrementell verbessert werden können und aus diesen Grundmodellen immer wieder für konkrete Spiele abgeleitet werden.

Alles anzeigen

Die Frage kann man sich beantworten, in dem man darüber nachdenkt, warum solche Maßnahmen ergriffen wurden. Onlinezwang, verschlüsselte Container, verschlüsselte Meshes, compilierte Scripts. Dies dient - natürlich - zum einen der Wahrung des Copyrights, zum anderen ist das aber eine Maßnahme, um Leute zum Kauf zu "zwingen", weil man es eben nicht auf LOTUS-Mods.ru runterladen und spielen kann.
Das ist aus betriebswirtschaftlicher Sicht sicher sinnvoll, keine Frage, aber wenn man schaut, warum OMSI so eine stabile Performance ablegt, ist doch eigentlich klar, warum. Das Lego der Bussimulation quasi. Ist zwar schön, wenn man ein fertiges Modell erwirbt, damit spielt man auch mal 1-2 Stunden, aber ohne die Möglichkeit, mit den Steinen rumzuspielen, macht es halt deutlich weniger Spaß.
Interessierte, die ein Projekt kaufen wollen (Qualität, Umfang, Support, welcher Grund auch immer) tun dies. Eventuell erst in einem Sale, aber im großen und ganzen holt man mit einer fairen Preis-(Leistungs)politik die meisten potentiellen Käufer auch ab.
Die Leute, die Spiele "Cracken", tun dies doch entweder aus Überzeugung, oder weil sie keine andere Möglichkeit haben. In jedem Falle fallen die doch aus der Kalkulation sowieso raus, da sie so oder so kein Geld dafür ausgeben wollen(oder können). Was verliert man also? Zumindest bei meinen OMSI DLC's kann ich jetzt keine relevanten Unterschiede zwischen Kopierschutz und "offen" in der Verkaufsperformance erkennen. Es mag den ein oder anderen egozentrischen Menschen geben, der keinem anderen etwas gönnt und lieber crackt als kauft, sofern es einen gibt - aber das ist keinesfalls die Masse und in der Kalkulation vernachlässigbar. Solche harten Einschränkungen sind also meiner Meinung nach absolut kontraproduktiv und verursachen mehr Einschränkungen und "Schaden", als dass sie Vorteile mit sich bringen.

Das ist im übrigen nicht nur ein LOTUS Problem, auch TheBus geht ähnliche Wege. Ein Beispiel:

Die TheBus Moddingtools sind eigentlich ganz nett - wenn man im flachen Brandenburg wohnt. Man legt sich quasi die Gehwegsplines, markiert die edges und erstellt dazwischen Flächen, welche dann die Fahrbahn darstellen. Soweit, sogut.
Was machst du aber, wenn du Überhöhungen oder Querneigung umsetzen willst? dann ist das Splinesystem nicht benutzbar. Zum Glück kann man sich ja, wie in OMSI oder LOTUS, welche schreiben, die die komplette Straße abbilden.
Was machst du jetzt aber, wenn du mit einer überhöhten oder quergeneigten Fahrbahn aus 4 richtungen an eine Kreuzung anschließen willst? am besten noch in Hanglage? das geht nur mittels Objektbau.
OMSI hat dafür die optimale Lösung: Splineexport. damit holt man sich die Anschlusssplines aus dem Editor in Blender, baut die Kreuzung als Modell, lädt sie in OMSI und setzt sie in das Konstrukt einfach ein. fertig.
NICHT aber in TheBus. denn dort ist aus Gründen des Copyrights und intellektuellen Eigentums der Export aus der Engine grundsätzlich deaktiviert. Es gibt also nur rein in die Engine, nicht aber raus. Damit ist der Editor für komplexe Überlandkarten, für welche sich die Unreal Engine durch die guten Möglichkeiten im Hinblick auf Weitsicht und Flora top eignen würde, unbrauchbar. Flache Karten, ohne topografische Tiefe, ohne interessante Straßenführungen, sind mit den tools natürlich zügig umsetzbar. Aber alles, was aus der Ebene rausfällt, ist nichtmehr korrekt Umsetzbar. die einzige Lösung wäre, das komplette Straßennetz als Modell zu bauen, aber dann stellt sich mir die Frage: wofür brauche ich dann einen Editor? Selbst der BusSimulator21 bietet hier unterm strich bessere Moddingmöglichkeiten.

Das gleiche Schicksal wird auch LOTUS erfahren, da bin ich mir sicher, wenn an der Container-Politik festgehalten wird. so viele Kartenerweiterungen, so viele Mods (selbst wenns nur andere Haltewunschtaster oder scriptkleinigkeiten sind) aus nem 2-Türer nen 3-Türer modden, haltestellenhäuschen tauschen - all das wird nur noch auf Absprache möglich sein. Und wenn man Inhalte aus dem Workshop nutzt und diese dann mal entfernt werden (warum auch immer) ist es mir nichtmal möglich, die Probleme im Editor selbst zu fixen.
Und all diese Einschränkungen, damit ein Modell nicht nach Proton oder so konvertiert wird? Auch da Frage ich mich, was für ein Schaden entstehen soll. Es ist unmoralisch, ja, aber solange damit kein Geld verdient wird, who cares? Bei rechtlichen Problemen kann man entsprechend dagegen Vorgehen, Wenns einer aus Hobby oder privat macht, ist das mMn. irrelevant. Sollen die 50 Spieler doch ihren Spaß haben, währenddessen man dafür tausende im eigenen Franchise begeistern kann.

LOTUS scheitert schon an den eigenschränkten Moddingmöglichkeiten im Vergleich zu OMSI. Wenn man Glück hat, definieren die Entwickler entsprechende Modulslots, wenn man Pech hat, kann man gar nichts ändern. Ein perfektes Beispiel, wie die Sucht nach Maximalprofit und ein übertriebenes Copyright die Kernkomponente des Erfolges kaputt machen.