Beiträge von Chrizzly92

rüschtüsch. deswegen zeig ich solche experimente gar nicht erst.^^

nö muss man natürlich nicht und das war auch keine Kritik, die OMSI Community ist aber durchsät mit kleinen Kindern, die ebendies nicht verstehen^^

ist halt mehr oder weniger Hobby. Warum man damit die Community heiß macht, wenn man eh nicht veröfentlicht, bleibt mir allerdings auch ein Rätsel.

unter dem Aspekt der Payware ist das notwendig und wird auch gemacht - auch von Kevin. Gabs da nicht auch damals mal Stress mit dem Yufa-Zeug, als Gladbeck das erste mal Payware werden sollte? Die beiden hatten sich dann auch irgendwie geeinigt.

Ohne mich auf Kevins Seite stellen zu wollen, muss man fairerweise auch festhalten, dass eine Karte in der Größenordnung nicht real darstellbar ist. Wer schonmal Kreuzungen - egal ob Spline oder Objektkreuzungen - gebaut hat, weiß, dass das ein langwieriger Prozess ist. Arbeitet man da mit Google-Earth Bildern und legt jeden Randstein so, wie er sein soll, ist das bei einer so großen Karte eine neverending Story - von der restlichen Bebauung will ich gar nicht Anfangen. Ich nehme an, die Qualität bei Wuppertal wird aufgrund der Größe etwas besser sein, aber auch da wird altbekannt mit Splines gearbeitet.

Über bewusst und vorsätzlich lässt sich streiten und das lässt sich ohne den Datenschutz immens zu verletzten auch nicht öffentlich beweisen. Ansonsten gebe ich dir recht, meine Kritik an 2.3 und anderen Dingen, die vorgefallen sind, hat vorallem der Forenadministration nicht geschmeckt und ich lass mich auch nicht mit einer 60-Punkte Drohung zum Stillschweigen Zwingen, so wie Janine es versucht hat. Das mag bei anderen Forenusern funktionieren, nicht aber bei mir. Die Konsequenz daraus war halt eine Sperrung, nicht der Versuch die Wogen zu glätten oder meine Kritik offen und ehrlich zu beantworten oder eventuell sogar komplett zu entkräften. Aber wie heißt es so schön: getroffene Hunde bellen und wenn es nichts zu vertuschen gäbe, könnte man auch offen drüber sprechen.

UE4 could do that too. for a personal project, i am parsing textures in runtime with a small c++ extension - and you can do the same with textfiles, scripts and everything you wish. the limits are basically the knowledge of a programmer working on such a project. besides the encrypted Object files, you basically can read everything in a unecrypted form, you "just" need an interpreter for the scripts and all the map-related stuff. So yeah, i would also say OpenOmsi would be the better idea, but i don't think that there is enough demand for such a thing due to omsi beeing a alive product. Maybe if people want to revisit omsi a few years from now on - we will see.

Ich hab mit der Tram-Geschichte übrigens gar nix am Hut, hatte mich nur als "dritter" drüber Aufgeregt. Wie oft angekreidet fand ich die Informationspolitik einfach unter aller Sau. Sie wussten, dass sie die Routine verändert haben - warum also nicht direkt Kommuniziert? Nein, erst nachdem die Community einen Aufstand macht. Selbst wenn man damit Tramfahren unter OMSI erschweren wollte, wäre das unter dem Aspekt das LOTUS kommt absolut okay, aber hinterrücks Dinge verändern ohne eventuell betroffene Entwickler zu Informieren ist echt beschissen. Selbst wenn der Content aus dem Hause Nitzschmann stammt (was so auch nicht wirklich korrekt ist) sollte man private Differenzen von Geschäftlichen trennen und irgendwo professionell bleiben - und die NF6D lief gut und hat garantiert auch viele Spieler zu OMSI gebracht, die es vorher nicht gab - und damit hat auch M&J von der Entwicklung profitiert. Viel schlimmer fand ich, dass 2.3 so halbherzig umgesetzt wurde - wofür Doppelgelenkbus ohne Einstieg an allen Türen sowie eine Unterscheidung zwischen Steh- und Sitzplätzen? Wofür Doppelgelenkbus, wenn das Ding bei niedrigeren Frames über den Boden rutscht wie auf Eis? Wofür Doppelgelenkbus, wenn mit verschobenen Achsen getrickst werden muss, anstatt den einzelnen Wagen eine aktivie Lenkung zu verpassen? Der Witz ist ja: die Variable "GetHeightAbovePoint" soll ja angeblich für die Rampen des AGG verändert worden sein - in 2.2.032 funktioniert die Rampe beim AGG genauso wie in 2.3. Es wurde ja auch Argumentiert, dass das Spiel keine "Garantien" auf Funktionalität gibt - das sehe ich anders. In 2.2.032 funktionierte die Variable zum Beispiel auch noch während der Fahrt, so hätte man Overhead-Ladestationen für E-Busse in OMSI Umsetzen können, wie man sie von der Innovationslinie in Hamburg kennt oder der E-Solaris in Berlin mit seiner Induktionstechnik. Diese Funktion funktionierte seit dem Release von OMSI 2. Geht jetzt auch nicht mehr, da die Variable nur noch im Stand ausgelesen werden kann, es sind also nicht nur Trams betroffen, sondern auch Busse, die Stromabnehmer haben. Es wurde also die Einzige Möglichkeit, on-the-fly als Bus mit der Außenwelt zu kommunizieren entfernt.

Das wäre zumindest für Freewarecontent denkbar. Payware ist verschlüsselt, das ist nicht so einfach. Aber klar, in den Grundlagen wäre ein OpenOmsi durchaus denkbar. Viele Informationen wie Splinepositionen liegen ja in lesbaren, unverschlüsselten Formaten vor, diese müsste man nur vernünftig interpretieren. Die Idee ist gar nicht dumm, aber ich glaub da fehlt es der Community an fähigen Entwicklern.

passt auf, was ihr sagt. Kritik ist immer so eine Sache, nicht dass Janine oder einer der Mods wieder hyperventiliert und mit dem Bannhammer hantiert... Platformübergreifende sperren sind leider auch das Fachgebiet des OOF-Teams.

Dafür ist die Community - welche meiner Meinung nach eine wesentlich höhere Tragktraft hat - umso dankbarer. #EinHerzFürWörki

Die Administration hat halt kein Interesse mehr an OMSI und tut nur das notwendigste. Das ist an sich ja auch kein Problem, dann sollte man das entsprechend kommunizieren.

Ich kann mich noch an Zeiten erinnern, wo Rüdiger und Marcel für Fragen im Forum stets zur Seite standen - damals wäre es gar nicht dazu gekommen. Mit dem Release von OMSI 2 und dem Wechsel der Führungsebene ging es mMn. immer weiter den Bach runter. Mehr und strengere Regeln, weniger (oder keine) Kommunikation bis sich in der Community eine Blase bildet, welche dann mit Beschwichtigungen und Statements der Administration oder Moderatoren besänftigt werden.

Das Fängt beim Nitzschmann-Hass an, geht bei der Tram-Thematik und LOTUS Kritik weiter und endet in Sprüchen von Janine a la "Jetzt halt doch endlich deine Fresse", wie es der gute Michael erfahren durfte. Wahrlich die perfekte Besetzung für das Community-Management.

Ich sehe das ganz pragmatisch: keine Kommunikation, kein Interesse. Und ob die Webdisk im OOF verlinkt ist oder nicht - Leute, die etwas Suchen, finden selbst hier her oder werden von Communitymitgliedern hier her verwiesen.

ich hab sogar die Kreuzung 172/tornaer Straße bereits gebaut. auch splines für die 172 gibt es. Wenn ich mal Zeit habe, kann ich gern mal schauen, ob ich das Projekt noch irgendwo rumgammeln hab.

naja, wenn man auf Sci-Fi steht, sollte Interstellar durchaus mal geguckt werden - lohnt sich aufjedenfall. Ob es eine Bildungslücke ist - keine Ahnung.
Ich würde mich als Sci-Fi Fan identifizieren, habe aber nie Star-Wars gesehen. Ist wohl auch eine Bildungslücke aber scheiß drauf.

ach, an freetex hab ich gar nicht gedacht - ja, das sollte auch funktionieren und hat es scheinbar ja auch.

der Texturindex muss der gleiche bleiben. du kannst doch auch einfach die Texturen im Fahrzeugverzeichnis anpassen - zumindest für einfarbige Matrixen.

Wenn du RGB funktionen willst, kannst du versuchen, mit einer Scripttextur eine andere Textur zuzuweisen - ob das allerdings in Kombination mit der Transmap für Matrixen funktioniert, weiß ich nicht, müsste man mal probieren. Schau dir dazu das OMSI SDK an - das Stichwort ist "[matl_change]".

Les dir nochmal den Kommentar von Kartoffelphantom durch. wenn du versuchst, mit

[matl]
vmatrix_voll_led_h030s1.dds

0

den Materialkanal zu adressieren, wird dir das nichts bringen, da die Textur "vmatrix_voll_led_h030s1.dds" im Modell nicht hinterlegt ist. Du musst also den Texturindex mit "vmatrix_voll_nue.bmp" adressieren, damit OMSI auch weiß, welcher Textur er die Transmap zuweisen muss.

wie oben schonmal erwähnt: Du kannst in EINEM Objekt MEHRERE Kanäle haben. Die Matrix muss dafür aber auch entsprechend gebaut werden. Da dies beim Stadtbus nicht der Fall ist, kannst du auch MEHRMALS das Objekt eintragen mit jeweils EINEM Kanal. die Funktion ist dann quasi die selbe.

Aus deinem Script müsste man also entsprechend folgendes machen:

Der Stadtbus hat getrennte Matrixmodelle. Einmal das Trägermesh und einmal die Flipdots selbst. die Krüger ++ nutzt 5 Kanäle, du musst also das Modell 5 mal aufrufen, mit jeweils der nächsten transmap.

du kannst die textfelder auch mehrfach addressieren. einfach die modelldatei nochmal eintragen, mit der selben referenzierten textur, aber mit einem anderen Scripttexturkanal. Ob du nun ein Modell hast, in dem ein Mesh 3 mal mit 3 verschiedenen materialien existiert oder 3 meshes mit je einem kanal, ist egal. musst du nur entsprechend in der modelldatei umsetzen.

hast du, abgesehen von den scripttexture einträgen, auch das script selbst auf die Krüger ++ angepasst?
die Volle Matrix ist übrigens der Ausgangspunkt einer jeden Matrix. die Texture zu dieser findest du im Texturordner des Busses. Durch einen Transparenzkanal werden dann die Bereiche ausgeschnitten, welche keine Pixel enhalten. Irgendwas ist bei dir da vermutlich im Script oder in der Texturzuweisung schiefgelaufen.

ja, das ist problemlos möglich. Das beste Beispiel sind die Silvester Soundcubes, die Ambient Soundcubes auf Grundorf oder oder oder. Jahr, Tag, Monat sind nativ auslesbar, Uhrzeiten müssen anhand der Variable "Time" berechnet werden.

Zitat von MGT-K

Hey

Das mit den Passanten wird bereits gemacht

verlängert ihr die Splines dann mit einem Bogen in den untergrund oder enden diese Einfach im Haus? Sonst gehen die Leute ja rein und sofort angeekelt wieder raus