Beiträge von Chrizzly92

Steven3233 nimmst du quasi hier in der Webdisk den gleichen Platz ein wie ich damals im OMSI-Forum? Stunk machen einfach nur des Stunkes wegen? Ich glaub dann muss ich mal ähnliche Konsequenzen für dich anregen. Dass du aber ja nur meckern kannst ist ja mittlerweile bekannt, dementsprechend sehe ich mal über deine unfreundliche und unsachliche Art hinweg und erkläre hier gern für dich und andere, Warum diese Problematik existiert.

Vorab sei gesagt, dass es keine Pflicht gibt, irgendeinem Standard zu folgen. Und wenn ich das machen würde, regt man sich dann drüber auf, dass nur kopiert wurde. Entweder man geht seinen eigenen Weg oder man bleibt beim Standardumfang.

Grundsätzlich achte ich allerdings stark auf eine Kompatibilität meiner Fahrzeuge. Für diese sind - abgesehen von Sonderfunktionen - beispielsweise nie spezielle Hofdateien von Nöten. Beim MAN Stadtbus habe ich sogar auf kompatibilität mit der universellen Hofdatei geachtet!
Das Fahrzeug wurde allerdings explizit für das Düsseldorf Add-on entwickelt und ist dort problemlos einsetzbar. Darum gehst bei einem Karten+Bus DLC. Auch die Metrolinien lassen sich dort schildern. Für viele Andere Karten besteht die Möglichkeit, über den Copiloten das Ziel zu verändern und beispielsweise eine SB-, E-, SEV oder X-Linien zu schildern, genauso wie bei der Standard M&R Matrix. Das ist auch der Grund, warum ich eben NICHT auf die vordefinierten Sonderzeichen gesetzt habe. das ist quasi ein Relikt aus den 90'ern und moderne Bordcomputer besitzen andere Möglichkeiten zur Manipulierung der Zielanzeige. Im Übrigen bietet die "Standardlösung" weit weniger Möglichkeiten als mein Ansatz es tut. Auch bin ich nicht auf 99 Sonderziele limitiert, ich kann tausende Implementieren wenn ich das möchte. Auch eine echte Freitextmatrix wäre Umsetzbar. Das ist mit dem M&R Ansatz nicht möglich. Richtig ist allerdings, dass dort aktuell keine freien M-Linien möglich sind, da das für DUS bisher nicht gebraucht und dementsprechend nicht umgesetzt wurde. Das werde ich im kommenden Patch dementsprechend nachreichen.

Im übrigen habe ich weder mit Kevins Karte noch mit seinem MINI-DLC etwas am Hut. Auch fahre oder interessiere ich mich nicht für das MINI-DLC. Mich begeistert die Technik und der Modellbau, nicht aber Düsseldorf. Dementsprechend wurde das Fahrzeug meinerseits auch nicht auf Kompatibilität auf einer Karte geprüft, die ich selbst nicht habe. Auch ist das MINI-DLC nicht bestandteil des DUS Addons, auch wenn es mit diesem kombinierbar ist. Ich sehe mich also hier auch nicht in einer Position, wo ich mein Fahrzeug hätte betatesten müsste oder sicherstellen muss, dass ein DLC eines Dritten damit kompatibel ist.

Abschließend sei noch gesagt, dass allein Aufgrund der Kombination von Linie+Kurs, wie es auch in echt ist, die Möglichkeit, Sonderzeichen über die letzten beiden Ziffern der Linie einzugeben, sowieso weggefallen ist. Wie stellst du dir also vor, Sonderzeichen im M&R Style zu schildern? Das ist realistisch mit dem Copilot nun mal gar nicht möglich!

wenn du uns nun material zukommen lässt, in welchem Erkennbar ist, was dort überall steht, was die einzelnen buttons machen und was die untermenüs der buttons machen setzte ich mich sofort an die Umsetzung.

das ist halt schon wieder so ein richtiger Megabrain Kommentar, der mich richtig hart motiviert, an einem Update zu arbeiten.
Grundsätzlich muss man hier erstmal erwähnen, dass der DUS-Copilot noch gar nicht final ist. Wenn du also Material hast, wie es denn sein sollte, nehme ich das gern entgegen, um deinem Wunsch, ein Update für das Fahrzeug zu erstellen, gerecht zu werden. Als Ossi aus Dresden habe ich leider nicht die Möglichkeit, nen bekannten Fahrer in Düsseldorf in seiner Pause zu nerven, um mal eben Vorbildfotos des Fahrzeuges zu erstellen. Du scheinst es ja besser zu wissen, also teile uns doch mit wie es sein muss! Aber nicht hier, machs im DUS-Thread.

Zitat von Lµkas

Stimmt nicht ganz, in LOTUS ist der Kerncontent OpenSource, öffentlich für Jeden. Also selbe Geschichte wie bei OMSI. (ausgenommen halt Workshop&Payware-Entwickler - wobei ich glaube, dass viele ihre Sachen für LOTUS auch offenlegen werden, ähnlich wie es ja bei Cities:Skylines auch ist. Da gibt's teils riesen GitHub-Projekte...)

Naja, das Standardscript als Basis zu haben macht daraus aber noch lange kein funktionsfähiges Modell. In OMSI konnte man einfach mal mit den variablen rumspielen oder - der klassiker - nen haltewunschsummer hinzufügen. das geht in LOTUS eben nichtmehr. Bis man also was "vorzeigbares" hat, haben viele schon wieder aufgegeben.

Zitat von Lµkas

Ein kleines Beispiel: Ihr kennt ja alle das Oberflächensystem von OMSI (0 für Asphalt, 1 für Beton usw.). Das beschränkt einen in der Hinsicht, dass man nur vorgegebene Konstanten hat, die man nutzen muss. Eine mögliche Alternative dazu wäre, jeglichen Untergrund selbst definieren zu können, z.B. anhand von Härte, Griffigkeit usw. Wenn ich jetzt aber zu jeder Asphalt-Textur noch den Reibungskoeffizienten bei verschiedenen Gummi-Sorten und immer in der Unterteilung trocken und nass angeben müsste... - wo kämen wir da hin? Sicherlich gäbe es dann vordefinierte Werte, die man nutzen könnte, aber das alles mit so viel Overhead, dass die meisten das System als "zu kompliziert" betrachten würden.

Grundsätzlich richtig, Aber dafür kann es doch Presets geben. Neben den vordefinierten Varianten könnte es ja auch noch die Auswahlfläche "Custom" geben, wo man entsprechend eigene Werte hinterlegen kann. Programmierseitig wäre das kein massiver Mehraufwand, würde aber nach hinten raus die Möglichkeiten deutlich verbessern. Alles kann, nichts muss.

der zweite visible-wert hat immer Priorität, weil die OMSI-Sachen immer von oben nach unten abgearbeitet werden. das kann je nach Anwendungsfall funktionieren, muss es aber nicht.

Perotinus , Ich empfehle in so einem Fall (und mach es auch selbst so), ein kleines Script zu schreiben, um den Visible-Eintrag zu steuern.

(L.L.VariableA) 
(L.L.VariableB) &&
{if}
    1 (S.L.Visible_Variable)
{else}
    0 (S.L.Visible_Variable)
{endif}

Wenn beide Variablen aktiv, setzt er die visible-variable auf 1, sonst null. das geht natürlich auch mit "oder" oder kombinationen, die ungleich sein sollen.

(L.L.VariableA) 
(L.L.VariableB) ||
{if}
    1 (S.L.Visible_Variable)
{else}
    0 (S.L.Visible_Variable)
{endif}

in dem fall nur aktiv, wenn mindesteins eine von beiden aktiv

(L.L.VariableA) 0 =
(L.L.VariableB) 1 = &&
{if}
    1 (S.L.Visible_Variable)
{else}
    0 (S.L.Visible_Variable)
{endif}

oder hier nur aktiv, wenn VariableA nicht aktiv und Variable B aktiv.

Das ganze einfach irgendwo in einem frame-marco eintragen und fertig.

Für die Profis hier ließe sich so ein script auch noch abkürzen:

(L.L.VariableA) (L.L.VariableB) && (S.L.Visible_Variable)

da für OMSI alles, was größer 0 ist, "true" ist und 0 "false", lässt sich das script oben auch noch abkürzen. der operator (und, oder, kleiner gleich, größer gleich etc.) gibt ja 1 und 0 aus wenn true oder false, was direkt wieder als Wert für die Visible-Variable genommen werden kann. spart die {if}-Schleife ein, ist aber schwieriger zu verstehen und zu lesen.

dieses "auf der Physik rumgereite" ist wirklich langsam ausgelutscht. Das ist schon lange kein Verkaufsargument oder Alleinstellungsmerkmal mehr für LOTUS. Ja, die Physik aus dem Hause M&R War bisher besser als in anderen Entwicklungen im bereich Simulation. Das wars aber auch! LOTUS bietet keine direkte Kontrolle über das Fahrzeugverhalten, alles folgt einer vordefinierten "Physik". Klasse! nen Objekt entlang eines Pfades zu animieren hab ich ohne tiefere Programmierkenntnisse in der UE4 innerhalb weniger Tage umgesetzt. Inklusive diesem übertriebenen Sinuslauf. Das ist alles simple Mathematik, ab und zu auch mal was komplexeres wie Vektorrechnung (z. Bsp. zur Bestimmung der Winkel der Fahrzeugteile zueinander) Das ist alles nun wirklich keine Kunst. Die Physik vom Bus wurde eventuell nicht selbst entwickelt sondern eingekauft. war auch in OMSI nicht anders, dort wurde die open dynamics engine genutzt. Und wer weiß, eventuell hat man sich dort auch Arbeit gespart und eine fertige Fahrzeugphysik "nur" auf die eigenen Anwendungsbereiche angepasst. Wieviel der so hoch-gepriesenen Fahrzeugphysik ist also das Werk von Marcel?

Eine Kunst ist es allerdings, die Physik den Content-Devs im Editor komplett offen zu legen. Der LOTUS Ansatz mag für 0815 Fahrzeuge funktionieren, bei komplexeren Konstellationen sieht das anders aus. Ich nenne hier immer gern den KT4D von Kartoffelphantom, welcher aktuell nicht korrekt umsetzbar ist. Tatra hat bei OMSI beispielsweise die fehlende Kontrolle über die Differentiale gestört. Sobald in LOTUS mehrere Wagenteile physikalisch voneinander abhängig sind, funktioniert das System nicht mehr bedingungslos und da draußen wirds noch genügend Fahrzeuge geben, die eben nicht "kompromisslos realistisch" abgebildet werden können. Und selbst wenn man aus Programmiersicht versucht, alle Eventualitäten abzudecken, kommt jemand um die ecke der aufzeigt, dass es eben nicht geht.

Solang man also mit "Vorgaben" arbeitet, ist man eingeschränkt. War bei OMSI auch nicht anders - der Einstieg an allen Türen kam auch nur mit dem Wien Add-on iirc und ist nicht Bugfrei. Die Erkennung, ob jemand sitzt brauchte Darius in Hamburg. Gelenkphysik kam mit OMSI 2. Doppelgelenkphysik wieder für Darius. Nie wurde das Spiel effektiv für die Community erweitert, das passierte nur weil es für Payware gebraucht wurde. Und "workarounds" oder Abstriche bei der Funktionalität, die ja beispielsweise in OMSI immer so negativ betrachtet wurden wenns um Straßenbahnen oder Züge ging, sollten in LOTUS nun wahrlich keine Verwendung finden. Inwiefern ist man also in OMSI oder LOTUS freier als in anderen Spielen? Die Grundlage war nur schon solide und es ist recht einfach, darauf aufzubauen. Aber selbst das ist beim Containersystem in LOTUS nicht mehr möglich. Selbst in Payware - und da schließe ich mich keinesfalls aus - stecken verdammt viele Scriptschnipsel die wiederverwendet wurden. Das macht das Modding halt einfach und den Einstieg leichter.

Konsequent wäre es, ALLES frei definierbar zu machen. Wie Bei Lego. Du brauchst nur die Achse auf der Schiene, alles andere baust halt selbst. Ob das jetzt nen Zug mit Jakobsdrehgestellen ist, normale Drehgestelle oder irgendwas spezielles. Völlig egal, alles ist Möglich. Dazu benötigt es aber frei definierbare physikalische Verbindungen mit 6 Freiheitsgraden, bei denen jeder Freiheitsgrad manipuliert werden kann. Fertig. Dann baut man nen KT4D halt "physikalisch" und nicht mathematisch nach.

Nachteil: Kostet halt Rechenleistung, ist selbst schwer zu implementieren und eine gute, fertige Physikengine kostet Geld.

Ein Spielkern ist das, was die Inhaltentwickler draus machen. Nur weil die Fernbusvehicles nen beschissenes Getriebe haben, liegt das nicht am Spiel. Nur weil beim BS18 selbst die Gelenkfahrzeuge Mittelmotoren haben, die Gelenke beschissen aussehen und mitgelenkte Achsen starr sind, liegt das nicht am Spiel. Das liegt an den Leuten, die ebendies im Spiel implementieren und das steht und fällt mit den Fähigkeiten der Content-Entwickler und die Möglichkeiten, die die Engine bereitstellt. Man kann also nur hoffen, dass die Aerosoft Interpretation der Schienensimulation genügend Möglichkeiten für Entwickler bietet, wirklich mal frei zu sein. Dazu braucht es eine nahezu uneingeschränkte Moddingfähigkeit und Soliden Grundcontent, auf dem man aufbauen kann. Ansonsten muss man immer irgendwo Abstriche machen.

Aus eigener Erfahrung kann ich sagen, dass der BS18 zum aktuellen Zeitpunkt mehr Moddingmöglichkeiten bietet als LOTUS. Wie das mal aussieht wenn LOTUS fertig ist, weiß ich nicht. Das Potential wird nur nicht genutzt, weil der Grundcontent schon zu Wünschen übrig lässt, zumindest aus der Sicht der non-casual Spieler.
Für BS18 habe ich ja beispielsweise mal mit einem Gelenk-Urbino herumexperimentiert. Es wäre problemlos möglich, viele Probleme, die das Spiel mitbringt, selbst zu verändern und entsprechend zu verbessern. Ich habe aber nicht die Zeit, "Grundlagenforschung" zu betreiben, da könnt ich mir auch selbst nen Spiel programmieren.

Der große Unterschied zwischen M&J und anderen Entwickler"studios" ist nur, dass Marcel aus der Szene kommt. Er weiß, wie es sich richtig anfühlt - das können andere Entwicklerstudios oftmals nicht. Ein gutes Skateboarding-Spiel kann nur von oder mit Leuten entwickelt werden, die aus der Szene kommen. Ein gutes Drift-Spiel kann nur von oder mit Leuten entwickelt werden, die aus der Szene kommen. Ein guter ÖPNV-Simulator kann nur von oder mit Leuten entwickelt werden, die - und jetzt Achtung - aus der Szene kommen. Warum sich Entwicklerstudios da so schwer tun ist mir bis heute ein Rätsel und das ist nicht nur ein Problem im Bereich Simulation.

tl;dr:
Solange Entwicklerstudios nicht Anfangen, aktiv mit Leuten aus der Szene zu arbeiten, kann und wird ein Projekt oft am Content scheitern, selbst wenn das Spiel dahinter gut programmiert ist. Damit steht und fällt auch die Aktivität potentieller Modder, denn wenn der Einstieg schwer ist macht sich keiner die Arbeit.
Gut ist, dass auch LOTUS mMn. nichtmehr mit Physik oder leichtem Modding Punkten kann. Dieses Alleinstellungsmerkmal gibt es mMn. nichtmehr. Es bleibt also spannend, wie sich andere Projekte schlagen werden.

naja, bei der Optimierung gehören schon immer beide Parteien dazu. In OMSI könnte ich problemlos nen Script schreiben, was OMSI in die Knie zwingt - ist deswegen der Spielkern nicht optimiert? So einfach ist es dann auch nicht. Aber man darf auch nicht vergessen, dass wir aktuell im Jahre 2020 sind. Da ist 4k mittlerweile der Standard bei Texturen, 8k z.T. im Vormarsch. Man muss ja gerade bei so einer Indy-Entwicklung keine Maßstäbe setzen, sollte aber dennoch Zeitgemäß arbeiten. Das hat Viewapp halt gemacht, die Engine kann das aber nicht. Wer da den fehler gemacht hat ist wohl Ansichtssache.

Lazarus ja, von schlecht war nicht die Rede, keine Frage - aber es ist jetzt auch nicht so, dass ich nen top of the line rechner habe, der "unverhältnismäßig" schnell ist. Gekauft hab ich meine Hardware im August 2018, also quasi vor zwei Jahren, wo LOTUS in den Early Access ging. Jetzt, zwei Jahre später sollte meine Kiste aufjedenfall noch als gute Mittelklasse durchgehen und Leistungsmäßig ein recht großes Spektrum abdecken und selbst da ist halt zu merken, dass der Spielkern auf sich selbst warten muss.
Auf Notebookhardware oder wirklich alten Maschinen kanns natürlich wirklich an der Rechenleistung liegen und ein Upgrade der Hardware für LOTUS macht sinn. Ordentlich Spielbar (und da rede ich von 60FPS+, auch auf Düsseldorf oder größeren Freewarekarten) kann LOTUS aber aktuell gar nicht werden und das Abschalten von Features wie Schatten zählt da mMn. nicht als Lösung. Dann brauch man sie auch gar nicht erst implementieren.

Perotinus Ja, Rolfs Zeug sieht wirklich, wirklich gut aus, wobei ein Stilles Bildauch besser aussehen kann als ein bewegtes. Screenshots aus OMSI könnten auch manchmal als Fotorealistisch durchgehen, Bewegtbilder sind dann wieder was anderes.
Interessant wäre zu wissen, mit welcher Framerate sich Rolfs Hamburg aktuell spielen lässt, wenn die Effekte auch so wie auf den Screenshots aktiviert bleiben. Denn München sah stellenweise auch super aus, aber ein Entwickler, der die Möglichkeiten ausreizt war dann ja schuld an der unterirdischen Performance. Ich würde mich soweit aus dem Fenster lehnen und behaupten, dass Rolfs zeug zum aktuellen Zeitpunkt ebenso nicht vernünftig Spielbar ist. Solche Bilder sollten dementsprechend auch nicht als Benchmark a la "guckt mal wie gut das aussehen kann" herangezogen werden.

Zitat von Perotinus

Deshalb ist der Stand für mich momentan: LOTUS bietet mehr Materialeigenschaften. Alles andere (Technik) habe ich in OMSI, oder ich kann es mangels NASA-Rechner nicht benutzen (Schatten, 3D-Vegetation).

auch wenn das von den Entwicklern und vielen Spielern oft behauptet wird, kann ich nachweislich behaupten, dass das so nicht stimmt. Meine Hardware - und diese ist nun nichtmehr das Maß der DInge (GTX1070ti, Core i7 8700k) wird von LOTUS nicht ausgelastet. der Spielkern limitiert bisher. Es ist also ab einem bestimmten Punkt nichtmehr relevant, ob dein PC schneller ist oder nicht, das Spiel selbst ist mit den Berechnungen überfordert und skaliert nicht proportional zur Rechenleistung.
Du kannst es also mangels Optimierung nicht benutzen, nicht mangels NASA-Rechner. Selbst wenn dein Rechner nichtmehr der modernste ist, kann ich dich "beruhigen" - auch bei mir läuft LOTUS nicht rund - Diorama zählt da nicht wirklich aufgrund der Kartengröße und selbst dort habe ich mit Microrucklern zu kämpfen. Aber Grundsätzlich gebe ich dir recht - was bringen Effekte, die man aus Performancegründen eh nicht sinnvoll nutzen kann? Nen Mehrwert sehe ich da aktuell auch nicht, abgesehen vom Multiplayer, der recht spaßig sein kann, auch wenns nur von kurzer dauer ist.

OMSI 1 als auch OMSI 2 waren nunmal keine performancewunder und vorallem unter Betrachtung des OMSI 2 Releases, bei dem durch die unterschiedlichsten Optimierungsversuche ein unspielbares Produkt veröffentlicht wurde und dies erst durch einige Patches erträglich wurde, finde ich es sehr wohl richtig als auch wichtig, auf die Framerateproblematik hinzuweisen. keiner hat Bock auf eine Diashow, vorallem nicht mit Hinblick auf VR. Es liegt hier an Marcel, "uns" vom Gegenteil zu überzeugen und zu zeigen, dass es auch vernünftig geht. Und wenn aktuell mit massig fehlenden Features das Spiel nicht den Eindruck erweckt, später mit entspannten 140FPS in VR zu spielen, fällt es mir wirklich schwer zu glauben, dass es irgendwann überhaupt so weit ist. Man darf auch nicht vergessen - den aktuellen Stand haben wir seit 2! Jahren und zumindest auf meinem Rechner hat sich die Framerate nicht verbessert, sondern stetig verschlechtert (wohlgemerkt auf "Tu es nicht!") Und dabei ist die Hardware auch irrelevant, zumindest wenn man einen bestimmten Schwellenwert überschritten hat. Denn weder CPU noch GPU werden von LOTUS zu 100% ausgelastet, das Spiel selbst limitiert hier immernoch, unabhängig der Hardware.

Zitat von Morpheus

Zitat von Perotinus

Ja, das sage ich auch, nachdem gerade ein Bus von mir unerlaubt gecrackt und in ein anderes Spiel konvertiert wurde.

Leider wird das immer wieder passieren. Gerade die Ripping/Converting Fraktion ist ziemlich aktiv.

Wobei ich sagen muss, dass ich das durchaus nachvollziehen kann(zumindest im Rahmen von OMSI). Sinn und Zweck der "Offenheit" von OMSI ist es ja eben, die Spielinhalte anzupassen. Sei es jetzt nen einfaches Repaint oder tiefere Eingriffe ins Fahrzeug. Diese essentielle Eigenschaft zu beschneiden, nur weil irgendwo irgendjemand eventuell keinen Wert aufs Copyright legt empfinde ich als falsche Herangehensweise. Außerdem ist es nur eine Frage der Zeit, bis solche Maßnahmen ausgehebelt werden. Mittlerweile gibts für OMSI schon Blender-Importer, denen du einfach nur die model.cfg geben musst und das Modell wird dir 1:1 in Blender importiert - und es gibt auch Methoden, Kopiergeschützte Fahrzeuge zu importieren. Das wird auch in LOTUS möglich sein, selbst wenn man sie sich aus dem Grafikspeicher ziehen muss. Wo ein Wille, da ein Weg. Modelle in andere Spiele zu portieren geht ohne Erlaubnis und öffentlich natürlich nicht.
Meiner Meinung nach steckt hinter dem ganzen Containersystem auch nicht nur der Kopierschutz, sondern auch ein ganzes Stück Kontrolle.
Man stelle sich vor, Ich baue ein Werbeschild mit Internettexturen(gibts sowas noch?). Das setzen viele Leute auf ihren Karten ein, in ein paar Jahren packe ich da eine unliebsame Textur drauf - Marcel und Janine hätten bei OMSI keine Möglichkeit, wirklich dagegen vor zu gehen. Jetzt ist der Container aber schön mit Content-ID und Eigentümer versehen, der Workshop kann bei unliebsamen Updates bedenkenlos moderiert werden und es besteht quasi volle Kontrolle über jedes einzelne Polygon was ein potentieller Entwickler setzt. Ich kann mir auch gut vorstellen, dass der Komplette Viewapp-Content per Knopfdruck gesperrt werden könnte. Jede Mod die man veröffentlicht hat quasi einen digitalen Fingerabdruck.

Ach sorry, stimmt ja - sind ja nur die Tools bisher. Pardon.

Edit: Aber wenns noch gar nicht auf dem Markt ist, wie kann es dann sein dass ich es schon vor zwei Jahren oder so gekauft hab? Ist aktuell auch auf Steam verfügbar. hmn...

Zitat von gt670dn

Zitat von Hamburg-Harburg

The Bus: Neueste Grafik

Besser weniger gute Grafik und dafür mehr Fahrzeuge gleichzeitig, sodass auch ein großer Hbf mit Straßenbahnen und Bussen ruckelfrei in der HVZ mit vielen Fahrgästen funktioniert. Diese ganzen Effekte fressen dann nur unnötig Ressourcen.

Ach, und du meinst ernsthaft, dass LOTUS genau DAMIT überzeugen kann, vorallem zum aktuellen Zeitpunkt? Da krüppelt man schon auf manchen Freewarekarten mit 10 FPS rum und von Fahrplan-KI, Fahrgästen und vorallem von RUCKELFREI ist noch absolut gar nix zu erkennen. Aber ich weiß schon - Early Access, noch nicht optimiert und und und...

Zitat von gt670dn

Zitat von Hamburg-Harburg

Train Simulator / TSW: Neueste Grafik, detaillierte Umsetzung, z.T. große Modding-Community

Die TS/TSW-Reihe hat meiner Meinung nach ein riesiges Problem damit was alles um das reine Fahren herum liegt. Das ist nämlich in den Spielen meistens einfach nicht vorhanden. Also sowas wie Zug aus der Abstellung aufrüsten, zum Bahnsteig rangieren, verstärken, schwächen während der Fahrt... Da ist das Fahrplansystem wie in Omsi (und dann bestimmt auch Lotus) deutlich ausgereifter und näher an einem realistischen Betrieb als "Ich fahr von Bahnhof A nach Bahnhof B". Ja, er mag ganz hübsch aussehen. Aber mir reicht der Simulationsaspekt der Aufgaben eines Tf nicht.

Hast du dir Train Sim World überhaupt schonmal angeschaut? Da brauchts quasi nen Bordhandbuch um die Scheißdinger ohne Tutorialhinweise aufzurüsten. Auch Rangieren, Verstärken, Abstellen, umstellen und co gehört da zu den -zugegebenermaßen - vordefinierten Szenarien und Aufgaben.

Zitat von gt670dn

Zitat von Hamburg-Harburg

...muss man seine Nische finden, die einen Kunden überzeugen muss.

Zum Beispiel Straßenbahnen! Die funktionieren bisher in keinem Simulator wirklich gut - sondern eher mit Krücken und Workarounds. Oder so Systeme wie Zweisystemstadtbahn "Tram-Train".

Du meinst, mit vorgefertigten Animationen und vorgegebenen Verhaltensweisen glänzt LOTUS hier ohne Krücken und Workarounds? Was ist denn mit dem KT4D von Kartoffelphantom, der mit seinem Schub- und Zugstangenabhängigen Kurvenverhalten zum aktuellen Zeitpunkt EBEN NICHT ohne Workarounds möglich ist? Und wo kann ich mir die Funktion von Zweisystemstadtbahnen, Spurbussen oder Oberleitungsbussen anschauen?

LOTUS ist bei weitem der eingeschränkteste Simulator auf dem Markt, der mit der Modbarkeit wirbt. Da hat man selbst im BS18 mehr Möglichkeiten als Content Creator.

"nightly-builds" werden i.d.R. nachts automatisch erstellt und enthalten ALLE veränderungen, die am Tag davor getätigt wurden. Im zweifel auch ungetestet. Schon allein der Name ist hier fehlt am Platz, denn dafür müsste am Tag vorher auch was verändert worden sein. im betabranch gibts aber halt einfach nur ne beta, bevor sie an die "Masse" ausgespielt wird. Man spart sich damit halt die internen Betatests und bei Problemen kann man dann einfach sagen "ja ist ja ne early beta vom early access vom spiel das eigentlich nur die Tools sind™"

Sehen wir es doch positiv - umso länger Oriolus braucht, um ihr Spiel in ein somewhat-fertiges Produkt zu verwandeln, umso größer werden die Ansprüche - und auch die Konkurrenz schläft nicht. In Zeiten, wo der MSTS das nonplusultra in Sachen Simulation darstellte, konnte man mit OMSI noch Punkten - jetzt darf man sich vorallem in Sachen Flugzeug mit dem neuen Flugsimulator messen und das wird schwierig.

und um den Beitrag von DerGrafikfehler noch um deine andere Frage zu vervollständigen:

Werte bleiben IMMER im Stack stehen, außer du nutzt einen Operator.

Nehmen wir an, du baust folgendes Script, auch wenns Sinnlos wäre:

1 5 (S.L.TestVar)
 (S.L.TestVar)
 (S.L.TestVar)
 (S.L.TestVar)
 (S.L.TestVar)
 (S.L.TestVar)

Dann packst du erst die 1 in den Stack und schiebst diese mit der 5 um einen platz nach oben. (S.L.XYZ) schreibt jetzt quasi den Wert aus dem "untersten" Stackplatz in die Variable. Dannach machst du genau das nochmal. und nochmal. und nochmal. die Werte im Stack werden nicht verändert.

Anders läuft es beispielsweise bei einer Addition.

1 5 + (S.L.TestVar)
 (S.L.TestVar)
 (S.L.TestVar)
 (S.L.TestVar)
 (S.L.TestVar)

hier wird aus beiden Werten das Ergebnis im Stack hinterlegt, die Werte selbst bleiben dann nicht im Stack stehen. Aber auch hier bleibt das Ergebnis stehen und wird durch (S.L.XYZ) nicht gelöscht.

Wenn du explizit möchtest, dass ein Wert "zwischengespeichert" wird, kannst du auch das Register nutzen. Dort kannst du insgesamt 8 Werte mit s0-s7 speichern und mit l0-l7 wieder laden. Das funktioniert aber nur innerhalb eines Frames - entgegen einer Variable werden diese nicht zwischengespeichert.

Zitat von DerGrafikfehler

Vorweg: Sie hören sich nicht unbedingt schlecht an, allerdings merkt man, vor allem beim Außensound, dass das verwendete Aufnahmegerät nicht unbedingt von höchster Qualität ist. Davon abgesehen passt der Sound nicht zum dargestellten Busmodell. Im Addon ist ja ein Euro-6-MAN enthalten, die Sound-Charakteristik lässt aber eher vermuten, dass das Fahrzeug, an dem die Sounds aufgenommen wurden, ein Euro-3-Bus war. Ich nagle mich hier nicht darauf fest, da ich selber noch nie mit einem €3-Löwen mitgefahren bin, der Außensound, der durchaus eine passende Charakteristik zum Innensound aufweist, würe aber sehr gut zu einem €3-Löwen passen.

Tatsächlich hast du in beiden fällen recht. das ECAS-System und die Achseinstellungen wurden für jedes Fahrzeug überarbeitet. Die Außensounds, die bereitgestellt wurden, sind quasi nicht verwendbar gewesen. Die Innensounds waren auch nicht das gelbe vom Ei, da hat Perotinus aber durchaus was vernünftiges rausholen können. Deshalb habe ich aus meiner eigenen "Datenbank" bedient und den bestmöglich passenden Sound genommen. Stammt aber nicht von einem €3 Löwen sondern von einem €5 EEV Modell. Ich selbst komme ja aus Dresden und bin dementspechend auf (gute) Zuarbeit angewiesen, da ich nicht mal eben in München nen Fahrer in seiner Pause für Soundaufnahmen belästigen kann. Das Ergebnis kann nunmal nicht besser als die Aufnahmequelle sein.

Perotinus:

1. Es fehlt der Sound zum anlegen der Federspeicherbremse -> Dieser liegt mir leider nicht im original vor.

2. Ist es so gewollt, dass es keine optische Rückmeldung über Leuchtmelder oder Display gibt, wenn der Retarder aktiv ist? -> da hatten wir ja privat auch schonmal drüber gequatscht. ist bekannt und kommt auch noch, muss mir nur ne vorlage aus nem Fahrzeug besorgen wo die Position zu erkennen ist. Das script sollte darauf schon vorbereitet sein,

3. Mir kommen die Bremsen sehr schwach vor, vor allem im Solobus. Ich bekam eben trotz Vollbremsung kein Gemecker der Fahrgäste. -> Die Bremskraft lässt sich recht einfach verstärken. Kann ich gern für einen kommenden Patch vermerken.

4. Das hätte ich auch selber machen können: Der Klimaanlagen-Lüftersound hat Loop-Knackser. -> Danke, schau ich mir mit an!

Zitat von Morpheus

Streng genommen bleibt der erste Gang sogar eingelegt, es wird lediglich ein bestimmter Planetensatz mit Hilfe der Lamellenkupplungen angesteuert, so dass ein Freilauf entsteht. Daher entsteht beim ZF dieses typische NBS-Summen.

da hast natürlich recht, so genau bin ich da dann auch nicht drauf eingegangen. Beim Auto in "P"-Stellung gibts i.d.R. auch keine Extra Vorrichtung für sondern es wird der Vor- und Rückwärtsgang gleichzeitig eingelegt.

Zitat von Citaro G Voith

Zitat von Jessi99

Mal ne blöde Frage: Was heisst NBS???

Grüsse

Jessica

Das heißt Neutral Bus Stop und ist das bekannte Summen im Bus Stillstand vom Ecomat Getriebe. Was das genau ist bzw. wie es funktioniert kann ich dir leider nicht sagen.

genauer neutral at bus stop. und es macht genau das, was der Name schon sagt. Beim Wandlergetriebe wird - sofern eine Fahrstufe eingelegt ist - Drehmoment übertragen, es besteht also ein Kraftschluss zwischen Motor und Straße. Deswegen rollt ein Automatikauto auch immer automatisch los, wenn man von der Bremse geht.
Das NBS schaltet das Getriebe auf Neutral, wenn das Fahrzeug steht. Dadurch besteht kein Kraftschluss zwischen Motor und Straße, die Leerlaufdrehzahl ist höher, der Motor läuft ohne last ruhiger, der verbrauch ist geringer, die Vibrationen sind geringer. Das Getriebe wird im Stand nicht dauerhaft belastet, ist also für den Verschleiß und die Getriebeöltemperatur ebenfalls von Vorteil.

ist auch nicht die korrekte Version.