Beiträge von Chrizzly92

Logfile mal hier rein bitte.

Zitat von BusfahrerP

zur Aerosoft Blackweek habe ich mir das Addon auch mal gegönnt. Bei der Matrix und dem Fahrscheindrucker muss ich etwas umbauen, gut das ist aber Geschmackssache. Vom Modell, Sound und Funktion sind die einfach top. Durch die große Variantenvielfalt wird eine Repaint.cti gerne mal 80 - 100 Zeilen lang. 8)

Wo finde ich denn die im Handbuch angesprochenen obj-Dateien? Mag für so Kleinigkeiten nicht ewig unnötig blind rumsuchen in Blender, bis die Position passt. Habe bei den Templates schon geschaut, den Modell-Ordner durchsucht, aber nix gefunden.

Hier: Klick

Bitte dran denken, dass es sich hier auch nur um eine Hilfestellung handelt und nicht um die Modelldateien. Mittlerweile gibts den abgespeckten Gelenkwagen in der München Demo allerdings als Freeware, unverschlüsselt.

Zitat von omsi_sw

Bei mir hat der KI Wagenkasten einen breiten Ausschnitt trotz schmaler Heckanzeige.

Betrifft den Dreitürer Solo und den NG Viertürer KI Wagen.

Welches Repaint verwendest du? kannst du mir dazu ggf. mal per PN die CTI-Datei Schicken? Der Bug ist mir neu, wir haben das beim Release eigentlich ausführlich getestet.

es hilft auch, Textfelder oder Bitmaps nicht gleichzeitig zu aktivieren und/oder die Textur geladen zu halten.
Eine Möglichkeit wäre beispielsweise, ein verstecktes Mesh mit den benötigten Texturen zu mappen und damit "vorzuhalten". tauscht das Script dann die Texturen aus, ruckelt es nicht da diese nicht erst geladen werden müssen.
Tritt das Problem bei Textfeldern auf, kann man diese auch "zug um zug" aktualisieren anstatt alle auf einmal. Das ist häufig ein Problem bei der Haltestellenweiterschaltung, wo auf IBIS, Bordcomputer, Innenanzeige und mehr gleichzeitig etwas passiert. Dort macht es sinn die Aktualisierungen je um ein paar Frames verschieben, um so den Rechenaufwand für diesen einen Wechselframe zu minimieren.

Hält man die Dateien vor, wird natürlich der Speicherbedarf erhöht und für versetztes aktualisieren muss das Script entsprechend angepasst werden.
Wagen300

eine Textur, die Beispielsweise 513x513px groß ist, wird automatisch auf die nächst größere 2 hoch x Texturgröße hochgerechnet - deine Textur ist also fürs Spiel eigentlich 1024x1024px groß, obwohl sie nur ein Pixel größer ist als das nächst kleinere Format.

reduziere die Auflösung der angezeigten Textur bitte auf 512x512 Pixel.
Wird - neben den Texturen selbst - auch noch ein Textfeld verändert?

Zitat von Lions City 1

Ich finde es auch wichtig, dass heruntergeladene Mods - wie in OMSI - selbst anpassbar sein sollten. Da nunmal jeder Verkehrsbetrieb seinen (BSP) C2 anders ausstattet, wäre es enttäuschend, wenn man nur eine "neutral-Version" und dann noch an die standart-Vertreter wie Hamburger Hochbahn oder BVG angepasste Varianten hat. Wenn so eine Möglichkeit nicht existiert, dann landet das Spiel eher nicht auf meinem PC.

das ist aber tatsächlich nicht so einfach. Die UE4 lädt das ganze in Container, so wie es LOTUS auch macht. TML müsste dafür die UE4 anpassen und nen "Parser" entwickeln, der sich die Dateien aus einer Baumstruktur holt und nicht einfach nur die *.pak reinlädt. Das ist auch nicht wie in OMSI einfach nur mit einem Mesh+Textur getan, allein ein Material kann Scripts und Abhängigkeiten enthalten, bei bei Veränderungen zerstört werden können.. Mein Glas-Material für den Urbino in BS18 enthält mehrere Masken, Fresneleffekte, Scripts für den Wischer und die Sichtbarkeit des Wischbereichs, lädt Werte aus der Welt für die Beleuchtung, Reflexion, Niederschlagsstärke.
Mit steigender komplexität wird auch das Verändern kleiner Details schwieriger. Wenn überhaupt sehe ich für TheBus ein Modulsystem wie in LOTUS. Das muss nichts schlimmes sein, damit das richtig und vernünftig funktioniert muss da aber auch jedes Rad und jeder Schalter einzeln ersetzbar sein und ich weiß nicht, ob TML dort genügend Möglichkeiten implementiert.
Das erstellen von eigenem Content ist dann wieder ein Anderer schuh, da kann man sich meist komplett austoben. Das tiefgründige Editieren wie in OMSI ist mit zunehmender Komplexität aber immer schwieriger Umzusetzen, daran müssen wir uns wohl oder übel gewöhnen - oder bei OMSI bleiben.

Zitat von mrecht1

Naja, wenn du praktisch ein Modul "Kasse" entwickeln kannst, dass du dann über feste Schnittstellen in der Konfiguration in jeden Bus einbauen kannst ist das ja gut möglich. In wie weit du dann bestehende Teile als Vorlage nutzen kannst sollte doch dem Urheber überlassen sein. Die UE bietet da prinzipiell auch Möglichkeiten Objekte zu verschließen oder zu öffnen.

Das System hätte auf jeden Fall große Vorteile für die große Zahl der weniger modding-erfahrenen Nutzer.

Das Problem mit festen Schnittstellen ist allerdings, dass du dann auch auf die Funktionsweise beschränkt bist. Der KT4D von Kartoffelphantom in LOTUS ist da ein paradebeispiel. Sänften einhängen, Drehgestelle definieren und master/slave animationen bauen ist ja gut und schön, wenn aber alle Wagenteile über ein Gestänge miteinander interagieren, reicht dann halt die Schnittstelle nicht aus. Hier würde man die Fähigkeiten der Engine, die Sie ja grundsätzlich so attraktiv macht, künstlich beschneiden oder der Entwickler muss dann für diesen Fall eine Möglichkeit implementieren. In OMSI kannst du beispielsweise keine Differentiale sperren - ohne Zugriff auf die Zugrundeliegende Mechanik kann man das auch über ein Modul nicht realisieren.

Grundsätzlich hat er ja auch nicht ganz unrecht - ist aber auch immer eine Frage, wie man das kommuniziert.

Nutze ich beispielsweise Scripts, die schon gut funktionieren, darf ich mir anhören "ist ja nur Stadtbusfamilie 2.0"; "Standard M&R script, gibt sich keine Mühe"; "kopiert die Arbeit von anderen und verlangt dafür noch Geld" und so weiter und so fort.

Setze ich mich dann mal hin und entwickle Lösungen, die schlanker sind und aus der eigenen Feder stammen, ist es dann auch nicht okay - "fühlt sich anders an"; "meine Mods funktionieren damit nicht"; "Funktion XYZ fehlt oder ist anders"; "warum geht mein Blinker nicht bei einer bestimmten Konfiguration".
Du kannst als einzelner nun mal nicht an alles denken, dafür ist OMSI zu offen und zu variabel. Das Bremsruckeln ist KEINEM!!!! Betatester aufgefallen, sonst wäre das vor Veröffentlichung auch schon behoben gewesen. Um das Problem zu beheben ist es auch nicht einfach mit einem Vorzeichenwechsel in einem Script getan, dafür muss ich die ganze Logik überdenken und die Eigenheiten von OMSI einbeziehen. Das habe ich beispielsweise für andere Fahrzeuge entsprechend getan, wo das Problem bei gleicher Scriptbasis nicht besteht - und das wird beim Urbino II Patch ebenfalls mit eingepflegt. Unabhängig davon ist für das Problem nicht zwangsläufig mein Script verantwortlich - Ursächlich sind niedrige Frames und dadurch ungenaue und zu große Berechnungsintervalle zwischen den Frames.

jup, die Materialbeschaffung gestaltet sich recht schwierig. ich will auch nicht einfach nur ein Fahrzeug aus der Stadtbusfamilie ausklinken und mitliefern - soll schon ordentlich auf DUS abgestimmt sein und außerdem möchte ich in diesem Zusammenhang das Fahrzeug auch auf den "Stand der Dinge" bringen. Man darf nicht vergessen, die Stadtbusfamilie stammt aus 2016!, das sind mittlerweile reichlich 4 Jahre indem sich auch meine Fähigkeiten entsprechend verbessert haben. Soll wenigstens so sein wie der Sprung von Ruhr zu DUS.

Zitat von Maik

Kann man hier endlich mal auf Bugfixes hoffen? Hier gehts immer noch um das Bremsruckeln und weiteres. Der feine Herr arbeitet ja wieder mal an was neuen, seine Aussage, dass er nach München am Solaris arbeitet war wohl mal wieder gelogen.

Nach München ist nichts erschienen, was nicht schon terminiert war. Insofern ist hier gar nix gelogen. Ich könnte dich verstehen, wenn ich jetzt 3 Add-ons in dem Zeitraum rausgebracht hätte obwohl der Patch als nächstes geplant ist. Das ist aber nicht der Fall.

Zitat von gt670dn

Zitat von Lµkas

Man kann sich also die Frage stellen: Ist Rückwärtsfahren in einer Straßenbahnsimulation (wohlgemerkt mit Einrichtungsfahrzeugen) überhaupt etwas so Essenzielles?

Wenn der entsprechende Drehschalter dafür in allen Stellungen stellbar und animiert ist schon. Würde man den quasi "festschweißen" wäre klar das geht nicht. Unschön, aber nun ja. Doch ein Richtungswender den ich auf rückwärts stellen kann und der Wagen fährt dennoch vorwärts ist für mich einfach ein Fehler.

dann bitte auch bei Marcel beschweren, der MAN NG272 hat einige Blindschalter mit dummyanimationen ohne Funktion.

Ist halt auch Wien und nicht Berlin. Bau' mal ne Strecke in Japan, da kannste vom Haltestellenboden essen.

tja, das passiert halt, wenn man unreflektiert seine subjektive Empfindung als objektiven Fakt hinstellt. Den Spielumfang legt der Entwickler fest, nicht der Spieler. Letzterer kann ja gern äußern, was ihm noch fehlt und Viewapp wird entsprechend reagieren.

Um mal den Vergleich zu ziehen: In TramSim habe ich aktuell immerhin ein Ziel - Fahrgäste von A nach B Transportieren. Das hat mehr spielerischen Inhalt als auf Diorama seine runden zu drehen, gern auch Rückwärts. Iin LOTUS wirst du wohl glücklicher, da du dort deine Simulationstiefe ausleben kannst. Für alles andere Ist das Spiel noch nichts Wert. Bei TramSim isses anders rum: dort kannst du dich spielerisch ausleben, der Simulationsaspekt ist allerdings noch nicht so weit entwickelt. Was nun besser oder schlechter ist, liegt immer im Auge des Spielers.

Und ich nehme auch an, dass - sobald es spielerisch erforderlich ist, Rückwärts zu fahren - diese Funktion auch implementiert sein wird. Für den aktuellen "Spielverlauf" ist das nicht notwendig - kein Ein/Ausrücken, kein Rangieren, keine Zweirichtungsfahrzeuge, keine Strecken die das nötig machen - warum sollte ich also rückwärtsfahren müssen? just for the lulz?

ist halt immer eine Frage des Anspruchs und was man als notwendig betrachtet. Ich hab beispielsweise keinen Bock mich erst durchs Handbuch zu wühlen und irgendwelche Routencodes rauszusuchen. Im Menü die Fahrt wählen reicht mir absolut aus. Andere Leute haben da andere Ansprüche, ob das Spiel nun also fertig ist oder nicht lässt sich aus subjektiver sicht nicht bewerten.

Klar, Bugs müssen weg aber unfertig ist meiner Meinung nach was anderes.

Mit deinem Argumentationsschema wäre dann jedes Spiel nicht realisierbar. Einige meiner IBIS-Systeme haben auch keine vollen Funktionsumfang, einiges geht in OMSI aber gar nicht oder eine Umsetzung wäre Sinnfrei. Warum spawne ich in einem Rennspiel meist im Auto an der Startlinie und muss nicht erst einsteigen? Warum muss ich in OMSI den Bus nicht erst aus dem Depot holen, eine Abfahrtskontrolle machen, mich per Funk und per normaler Kommunikation beim Disponenten Ab/Anmelden? Ist OMSI jetzt unfertig?

Der Funktionsumfang zum aktuellen Zeitpunkt ist für dich nicht stimmig. Das ist okay. Unfertig wäre etwas, wenns als Feature vermarktet wird und dann aber nicht funktioniert und das ist hier mMn. nicht der Fall.

bei gleitkommaberechnungen wirst du in den seltensten fällen auf einen genauen Wert kommen, vorallem dann nicht, wenn du einen Timer nutzt.

du solltest also immer Bedingungen nutzen, die auch wirklich erfüllt werden können. also quasi aus, wenn kleiner als 1, sonst an wenn kleiner als 2 und wenn beides nicht zutrifft, dann den Timer nullsetzen.

(L.L.Timer) (L.S.Timegap) + (S.L.Timer) s0 1 <
{if}
    "Lampe aus.tga" (S.$.STD_an)
{else}
    l0 2 <
    {if}
        "Lampe an.tga" (S.$.STD_an)    
    {else}
        0 (S.L.Timer)
    {endif}
{endif}    

Die Systemvariable Timegap enthält die Frametime, also einen Wert, wie lange der letzte und der aktuelle Frame außeinananderliegen. Bei 10 FPS hast du dort einen Wert von 0.1 drinstehehen, wenn du also 10 frames lang 0,1 addierst, kommst du auf eine Sekunde -> 10FPS. Das klappt so aber nie, die Werte werden immer ein wenig schwanken, sodass da a im Zweifel ein Wert von 0.99 drin steht und im nächsten Frame 1.02 - deine Bedinungen wäre also nicht erfüllt. kleiner als 1 trifft aber auch bei 0.99 zu und kleiner als 2 bzw. größer 1 trifft auch bei 1.02 zu.

Wurde denn das IBIS als Funktionsfähig beworben? Wenn nicht, finde ich nicht, dass man das Spiel wegen dem Fehlenden IBIS als unfertig bezeichnen sollte. BusSim18 hat das beispielsweise auch nicht.

Bus-Sim 18 ist da halt auch wirklich ein Negativbeispiel, die Halycon AI Packs find ich aber gar nicht so schlecht und die sind auch professionell eingesprochen.
Ich finde halt, dass solche Mühen auch irgendwie gewürdigt werden sollten. kostenlos ein Modul als Dankeschön oder sowas sollte ja drin sein. Und genau das isses ja - sonst wird kein Wert darauf gelegt was die Community zu sagen hat aber wenns um einen eigenen Vorteil geht, dann wird sich ins Zeug gelegt, extra ne Software entwickelt und angespornt, mitzumachen. Es fällt mir also schwer, in der Aktion was positives zu finden.

viewpoints einfach komplett entfernen, außer die, die für KI notwendig sind. dann siehst du auch von innen alles was außen dran ist, beschwer dich aber nicht wenns dann nicht richtig läuft oder sowas.

Zitat von Jamonalk

Was ich cool finde ist, dass jeder der LOTUS besitzt die Chance hat einem Fahrgast die Stimme zu leien und nicht irgendwelche voreingestellten mitgeliefert werden, das macht das ganze persönlicher. Leider werde ich nicht mitmachen können, weil ich es vor Weihnachten nicht schaffe mir ne Lizenz zu kaufen, Bock hätte ich irgendwie schon.

Na gut, das kann man natürlich wieder als super krasse Communityeinbindung betrachten und jeder mit pinker Brille wird das feiern, unterm Strich wirds aber so laufen, dass du für deine Mühen wenns gut läuft ein "Danke" erhältst (das wäre schon viel!), das wars aber schon. Deinerseits übernimmst du die Arbeit anderer, das ganze auch noch kostenlos, alle Rechte an deinen Soundaufnahmen gibst du unwiderruflich ab.
Andere machen die Arbeit, Oriolus hat keine Kosten außer ein wenig Zeit zum Sichten. Wäre halt auch zu professionell, das ne Firma machen zu lassen die auf sowas spezialisiert ist. Hauptsache keine Kosten verursachen aber das Spiel selbst darf natürlich nicht zu günstig sein. lol.

Unabhängig davon ist die KI auf den ersten blick aber tatsächlich nicht schlecht. Bisher auch keinen Einfluss auf die Performance gemerkt. An den Modellen kann man natürlich noch einiges optimieren, aber von den Animationen und vom Rigging her kann man eigentlich nicht meckern.

Kern vom OMSI ist doch eben das Modding. Klar hab ich auch was dagegen, wenn man Stumpf klaut oder Fremde Arbeit als die eigene Ausgibt - aber irgendein Moddingverbot ist doch quasi komplett Gegensätzlich zum OMSI Grundsatz. Darum hab ich da auch fast nie was dagegen. Keine Ahnung, was so ein Moddingverbot effektiv bringen soll. Wird doch eh gemacht, selbst wenn die Dateien verschlüsselt sind.

Zitat von TrisiBusfahrer

Jemand sollte sich mal an einen vernünftigen VDL Citea machen. Es gibt zwar einen von Mx200, aber nach der Experten-Aktion einer gewissen Person hier in der Webdisk ist dessen Release verständlicherweise eher unwahrscheinlich.

alter es gab sowas auch schon vor Jahren, so wurde beispielsweise eine frühe Beta der Stadtbusfamilie geleaked und rumgeschickt. Hab ich deswegen die Entwicklung eingestellt oder nicht veröffentlicht?
mx soll die Tränen abwischen, das nächste mal seine Vertrauenspersonen/Tester genauer auswählen und aus den Fehlern lernen. Es gibt immer Leute die Arbeit nicht schätzen oder sich nicht im klaren sind, welche Tragweite solch ein Verhalten haben kann.

da gibts für die UE4 sogar direkt Plugins fürn Arduino. sogar Kostenlos. inwieweit man das als "Modder" implementiert bekommt weiß ich nicht - aber ich glaube auch nicht, dass Viewapp dort keine Lösung oder zumindest Unterstützung bietet. Die kommen ja selbst aus der Szene.