= Englisch [EN], 
= Deutsch [DE], 
= Französisch [FR]. Wenn du die angegebene Sprache nicht beherrschst, schreibe auf Englisch! take a look on how the logic part is done in my Urbino II Add-on. Buttonwise its pretty simple.
for the pneumatic height control, the NL92 bremse.osc basically sets a target height in the ECAS section - if the bus is lower than the target, its getting raised, if its higher it is lowered. you can simply add a logic that takes this target value and increase or decrease it as you wish.
Ohne jetzt genau im Bilde zu sein worum es hier geht, hab ich nen kleinen Hinweis: das geht sauberer.
mehr brauchst du für nen simplen Schalter nicht. 
Ging es nicht um Shadowbanns und dem Umgang mit Usern? Die Ursache ist dafür doch völlig irrelevant und nur weil Du/Ihr der Meinung seid, etwas sei unangebracht müssen das andere nicht so empfinden. War ggf. bisschen undeutlich formuliert, aber meine Aussage bezog sich nicht auf die Ursache, sondern auf die Tatsache.
Ich würde euch empfehlen, die Angelegenheit die Lukas beschreibt privat über Discord nochmal zu besprechen und zu versuchen es klar zu klären, einfach um hier nicht wieder sich unnötig hochschaukelnde Diskussionen zu provozieren.
Da ich dich Lukas, doch für ziemlich kompetent halte glaube ich schon, dass wenn ihr euch nochmal zusammenssetzt, ihr die Angelegenheit klären könnt. Zumindestens für dein "Einzelschicksal".
Und Nein, ich will keine Diskussion unter dem Teppich kehren, aber es ist unsinnig, immer dieselbe Diskussion zu führen.
Ich finde genau sowas muss ausdiskutiert werden. Es ist ja nicht nur die eine Situation, sondern das zieht sich seit Jahren hin und es lassen sich da ja auch Muster erkennen. Wer öffentlich als Person oder als Firma Auftritt, darf und muss auch öffentlich für solche Aktionen kritisiert werden dürfen.
Mein Account im LOF hatte nicht einen Kommentar und wurde mit einem Shadowbann versehen. rein technisch ohne Grund, nur weil man mich halt kennt. Das gleiche bei rmpll und das gleiche bei Lukas während nachweislich andere Accounts problemlos funktionieren. Es ist eben kein "Einzelschicksal" oder ein Versehen.
Wenn sie da nicht mitmachen wollen, bitte sollen sie halt einen TramSim programmieren bei dem man erst mal 10.000 Punkte sammeln muss bevor die Möglichkeit zum Weichen stellen freigeschaltet wird.
Immerhin hat das Spiel eine gewisse Langzeitmotivation. Ich habe in Tramsim mehr Spielzeit als in LOTUS nach 2 Jahren. Gut, die Samplesize ist 1 und man mag mir auch eine gewisse Befangenheit unterstellen können - aber ich bin da nicht der Einzige. In LOTUS habe ich genauso viel "Spiel"spaß wie in Blender, nur der Name ist ein anderer. In Tramsim kannst halt Spielen, hast ein Ziel und viele gamebreaking Bugs wurden bereits behoben. LOTUS ist aktuell unspielbar ohne Workarounds und Kompromisse.
Im übrigen ist die UE4 - was Modding betrifft - durchaus ganz weit oben mit anderen Spielen. Die Frage ist halt eher, was man unter Modding versteht. Das Verändern von Drittanbieterpaketen wie in OMSI ist schwierig, aber wenn man will kann man aus einem Bussim auch einen Egoshooter bauen, was bei OMSI wiederrum nicht möglich wäre. Die Contenterstellung für BS18 war Beispielsweise lächerlich einfach und wesentlich entspannter als in OMSI - das Paket jetzt aber zu ändern ist allerdings nicht so einfach, vorallem nicht für dritte.
So eine offene Struktur wie in OMSI werden wir wohl in naher Zukunft nicht wieder sehen und LOTUS ist ja auch nicht so offen wie sie sich selbst gern sehen.
Logfile mal hier rein bitte.
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.
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.
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. 
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.
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.
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.