Beiträge von Chrizzly92

ist mir eigentlich wurst wie ihr das macht. Ich bekomme halt nur per PN an mich herangetragen, dass einige Dinge nicht funktionieren und ich mich halt Frage: warum? kann ich nicht nachvollziehen. Dann schaue ich mir die Steamversion an und stelle fest, das tatsächlich Fehler existieren, die so in meiner Version nicht enthalten sind. und das ist halt blöd, vorallem dann, wenn sowas nicht kommuniziert wird.
Das verursacht unnötigen Support, wenn Leute an mich herantreten und Fehler behoben haben wollen, die "dritte" Verursacht haben.
Bestes Beispiel dafür ist das weiße Repaint. Funktioniert in meiner Entwicklerversion einwandfrei, bei der Steamversion war das Wochenlang defekt.
Ich würde einfach bitten, mir mit ner PN mitzuteilen:
"Hey Christian, hier sind die Außenspiegel von uns, die werden wir im nächsten Patch mitliefern" - dann weiß ich bescheid, kann die in meiner Entwicklerversion - ggf. sogar mit Funktionalität - einpflegen und weiß über die Existenz. Alles andere ist einfach mist, solange ich für mein Fahrzeug support geben soll/kann/will.
Wenn zu viele Hände an einem Projekt rumspielen und die linke nicht weiß was die rechte macht, führt das zu vermeidbaren Komplikationen.

Zitat von onur58

Einige Fans hatten sich die zwei langen Außenspiegel gewünscht, die bei einigen Subunternehmern in München zum Einsatz kommen.

Als Basis zum Skripten haben wir den langen Spiegel vom Düsseldorfer Solaris genommen, um es intern zu testen und soweit möglich zu lernen.

Bedenke, dass auch viele München-eigene Dateien/Modelle z.Z. im Düsseldorfer Bus eingebaut sind (Automat, IBIS etc.), wie zwischen uns abgesprochen.

Auch die Innen-Bildschirmtextur der MANs findet sich im Texturordner des Solaris-Busses wieder. Work in Progress...

Legitimierst du die Verwendung meiner DUS-Spiegel damit, dass ich Content aus München für DUS Verwendet habe?

Du solltest dabei nicht vergessen, dass ein Großteil der Objekte, die von Olgu vorbereitet wurden, gar keine Verwendung fanden und zu 100% aus meiner Hand stammen. Das sieht man beispielsweise am Automaten sehr gut:

links Olgu, rechts Chrizzly92.

oder aber auch am Copiloten, unten Chrizzly92, oben Olgu:

Wenn ein Objekt aus meiner eigenen Hand stammt, kann ich damit auch anstellen was ich möchte. Die spiegel stammen aber nicht aus eurer Hand, das ist nen kleiner aber feiner Unterschied. Das ist bei allen Objekten, die in DUS Verwendet wurden, der Fall. Viele Texturen, so zum Beispiel die Bootsequenzen des Automaten oder der Innenanzeige, aber auch die Displaytexturen des Copiloten habe ich eigenhändig gezeichnet. Natürlich auf Basis der Vorlagen - aber in den Bordcomputern steckt zu 100% Chrizzly92.

Aber ist auch egal, mir gehts da gar nicht um den Content selbst und woher die Spiegel stammen sondern darum, dass diese enthalten sind und ich davon nichts weiß. Wenn ihr das Fahrzeug eigenhändig mit Funktionen füttern wollt, hab ich da auch absolut nichts gegen, auch wenn dieser aus dem DUS-Urbino stammt. Stell dir aber mal vor, mir schreibt jemand sowas wie:

"Hey Chrizzly, ich hab mir den langen Spiegel eingebaut und jetzt geht der Bus nicht mehr." Da stehste halt selbst erstmal auf dem Schlauch und weißt gar nicht, von was der Spieler spricht.

Schickt mir doch einfach mal die Steamversion vor Veröffentlichung und ich schau drüber, bevor das offizielle Okay gegeben wird. Eine Vorabinformation drüber, was ihr am Fahrzeug macht, wäre auch nicht schlecht. Dann würden hier Projektpartner nicht einfach im Regen stehen gelassen und es gäbe nicht bei jedem Steam-Update Probleme.

Zitat von der_Nik_

Jetzt, wo einige Spieler den Spiegel nutzen, hätte das fatale Folgen, da nach einem Entfernen bei vielen der Bus nur noch halb laden würde...

Ich würde aber spontan vorschlagen, dass ihr sowas nicht öffentlich klärt

Und jetzt stell dir mal vor, man hätte irgendwann einfach meine Dev-Version, wenn neuer Sound und Nachtmodus für den Copiloten kommt, eingespielt. Hätte wieder zu Problemen bei einigen geführt und genau darum finde ich das nicht gut.

Warum soll man sowas Intern klären? Grundsätzlich habe ich die Community schon beim MAN Stadtbus stark in die Entwicklung involviert. Hinzu kommt, dass Ich für Probleme verantwortlich gemacht werde, die gar nicht von mir Verursacht wurden und im Interesse der eigenen Reputation finde ich es schon wichtig auch öffentlich sagen zu können, dass ich an vielen Problem nicht schuld bin. Die Leute kommen nämlich oftmals direkt zum Fahrzeugentwickler und laden dort ihren Frust ab, obwohl ich gar nicht dafür kann. Ich will aber nicht der Mülleimer für die Fehler von anderen sein.

interessant. wie kommen die Spiegel da rein? ich hab sie nicht implementiert.

Tatsächlich funktioniert ein separat eingetragenes Script im Trailer nicht in Kombination mit Scriptshare. Interessant.
Jetzt gibts zwei Möglichkeiten: Den Vorderwagen und den Nachläufer via Steuerleitungen verbinden (sofern das geht) oder

die Koordinate der GetHeightAbovePoint Abfragen über den Nick- und Gierwinkel des Gelenkes berechnen.

Edit: alternativ gäbe es noch eine dritte möglichkeit:

Zitat

This command shares the script system. That means that THIS vehicle

will use the entire script system of the previous created vehicle

(it is not important, if this is coupled in front or in the back,

this only depends on which vehicle was create before THIS one)

eventuell könnte man Probieren, den Nachläufer eines Busses als "erstes" Fahrzeug zu definieren und den rest vorn dran zu hängen. das wäre aber recht viel Aufwand.

Edit: geht nicht.

Nun, einen Vorteil haben diese eigentlich nicht, da stimme ich dir zu. Ist aber einfach sauberer Meiner Meinung nach. Dazu kommt, dass - wenn er die Oberleitungs"mitte" mal verliert, dann trotzdem in der Nähe bleibt und die Werte auch nicht durch die Decke schnellen. Kann man natürlich auch mit nem script abfangen. Es führen ja viele Wege nach Rom und dein Ansatz funktioniert natürlich genauso.

Wenn du das script im Trailer aufrufst, musst du natürlich die {init} und {frame} schleifen nutzen. wenn du da nen script einträgst, welches andere macronamen hat, musst du diese in den haupt init und frame abschnitt eintragen. Fast jeder Bus in OMSI hat ja ein "main" script, in welchem alle unterscripts und deren macro definiert werden.
also entweder ein basisscript bauen, dass so aussieht:

{init}
    (M.L.trolley_Init)
{end}

{frame}
    (M.L.trolley_Frame)
{end}

welche dann die macros in deinem "sub-script" aufrufen - oder einfach in dein trolley script entsprechend {init} und {frame} verwenden. würde ich zumindest tippen, da ich das script nicht kenne.

Zitat von DerGrafikfehler

Für das Problem wäre glaub ich tempo1 der beste Ansprechpartner, der hat mWn die NF6D gebaut/war an der beteiligt, und bei der sind ebenfalls verschiedene Scripte in verschiedenen Fahrzeugteilen eingetragen.

Dann wohl eher Feindflug oder ich. Unabhängig davon funktioniert die NF6D nicht mit Scriptshare sondern mit Steuerleitungen.

Zitat von GAMINGONK

Vermute mal, dass Omsi herumzickt, da zwar Scriptshare genutzt werden soll, jedoch der Nachläufer nicht die selbe Anzahl an zu ladenden Scripts hat, als der Vorderwagen.

Die [script] und [constfile]-Einträge müssen die selbe Anzahl im Nachläufer haben, wie der Vorderwagen.

wäre ja kein Problem. man kann die variablen für den nachläufer ja in eine x-beliebige constfile oder varlist eintragen.

ahh, ich verstehe. Das ist wirklich eine berechtigte Frage und diese kann ich ohne eigene Tests auch nur spekulativ beantworten.
Die GetHeightAbovePoint Variable erwartet die koordinaten an einem absoluten Punkt, abhängig vom Nullpunkt Des Fahrzeuges aus. Das Impliziert, dass das in einem Nachläufer rein technisch gar nicht gehen würde - denn dieser bewegt sich ja. Ich würde also die Logik für einen O-Bus in ein eigenes script werfen, dass du nur im Nachläufer implementierst. Das sollte trotz scriptshare gehen. eventuell könnte man sogar Steuerleitungen eines Zuges zwischen die Wagen hängen - dann wäre auch eine Kommunikation ohne Scriptshare möglich - ob das geht weiß ich aber nicht.

Halt mich gern auf dem laufenden, was deine Tests angeht!

Ich lass dir hier auch nochmal meine Idee da, wie so etwas umsetzbar wäre.

Ich würde eine Spline bauen, die über dem Fahrdraht eine "einbuchtung" hat, die von GetHeightAbovePoint erkannt wird. links und rechts in unterschiedlichen höhen, damit du per Script die beiden abnehmer unterscheiden kannst. das würde auch unterschiedliche breiten des Fahrdrahtes ermöglichen. Einfacher wäre natürlich eine Einbuchtung zwischen den Fahrdrähten und damit würde ich auch erstmal an deiner stelle beginnen.

Hast du so eine Spline fertig, setzt du am besten die Abfrage der GetHeightabovePoint in Sollhöhe des Stromabnehmers. davon brauchst du allerdings eine ganze menge, damit der Stromabnehmer der Leitung auch entsprechend realistisch folgt. Diese vergleichst du miteinander und kannst so den Punkt finden, der aktuell von den anderen Abweicht - also den, wo der Panthograf hin soll.

Für eine Weichensteuerung könntest du beispielsweise auf Höhe der Fahrerposition links und rechts unter dem boden wieder mehrere GetHeightAbovePoint Abfragen positionieren. Dann setzt du, wenn du dich zum Beispiel auf einer Linksabbiegerspur befindest, einen Dummycube unter die karte, die dann von GetHeightAbovePoint erkannt wird. hast du links eins, merkst du dir vor dass, sobald deine GetHeightAbovePoint abfragen zeigen dass sich die Fahrbahn trennt, der Panthograf eher linksseitig geführt werden soll. Wie du das bei einem Gelenkbus allerdings durch das Fahrzeug schleifst, weiß ich noch nicht.

Bedenken musst du allerdings, dass es sich nur um Annäherungswerte handelt - ändert sich zum Beispiel die Höhe des Fahrdrahtes, würde sich ja auch die Position der GetHeightAbovePoint Abfragen ändern. Theoretisch könnte man diese Punkte aber auch mimt einer "Höhenerkennung" kombinieren und dann entsprechend die Punkte zum Auslesen verschieben.
Das Script dafür wird dann aber auch entsprechend komplex und ich weiß nicht, ob das einen großen EInfluss auf die Performance hätte. War meinerseits bisher ja auch nur trockene Theorie.

welche koordianten willst du denn auslesen, bzw. was hast du denn vor?

Zitat von Bananafood21

Wäre es möglich, die Wagennummern der Fahrzeuge per Setvar ein-, bzw. auszublenden? Also dies mit einzubauen, wenn der Bus schon einmal gepatched wird..

iirc sollten die wagennummern ein eigenes mesh sein. Eine setvar dafür hinzuzufügen ist kein Problem und wird für den nächsten Patch vorgemerkt.

Naja, fast perfekt ist der nun nicht. Gerade im Bereich Sounddesign ist da noch viel Luft nach oben. Gut Ding will weile haben und mein Tag hat auch nur 24h. Entweder man wartet bis ich die Sounds erledigt habe oder sucht sich jemanden, der das für einen macht - alles andere ist nix halbes und nix ganzes.

das reine löschen vom Material reicht nicht aus - solang die Texturen je nach Modi mal aufs Mesh geladen wurden, bleiben diese auch referenziert.
Um Texturen aus Blender dauerhaft zu entfernen, mit Shift+Klick im UV Editor auf das "X" drücken.

die Textur wird dann im Auswahlmenü mit einer "0" vor dem Namen gekennzeichnet:

Dannach speichern und das Projekt neu öffnen. fertig.

Zitat von PingPong

Zitat von Chaoslokführer

Das weiße Repaint existiert sogesehen wirklich, nur liegt es in einem extra Order (weiss) und nicht im Werbe Hauptordner.

Jo, die CTI ist nicht angepasst. Aber ich sags nochmals: Sowas darf bei einem Payware-DLC nicht passieren!

ich frage mich sowieso, warum man nicht einfach meine Entwicklerversion des Busses hochlädt sondern immer daran herummanipuliert. die CTI's der Repaints funktionieren einwandfrei. Vermutlich kopiert Olgu einfach den Repaintordner in meine Entwicklerversion und dabei geht die hälfte kaputt.

bei den Sounds kann ich leider nicht helfen. diese wurden zum wiederholtenmale von Olgu_M nach der Abgabe meiner Arbeit verändert, für Bugs diesbezüglich ist er verantwortlich.

ich habe versucht, dem Gelenk auch seitliche freiheit zu geben, wie es bei LKW der Fall ist. das Schluckt omsi aber nicht. die Fahrzeuge sind auf der längsachse starr verbunden, das geht leider nicht anders.

BusfahrerHeinz du hast absolut recht. Sorry für den Vorwurf! Selbst ich als Entwickler des Fahrzeuges!! wusste nicht, dass hier einfach so Sounds aus meiner MAN Stadtbusfamilie verwendet wurden.

Warum höre ich dann den Sound der MAN Stadtbusfamilie ? Das Problem wird im nächsten Fahrzeugpatch behoben.

Zitat von BusfahrerHeinz

Also, entweder ist das ein Bug oder ich verstehe die Münchener Türsteuerung nicht.

Chrizzly92

Fahrzeug ist gemodded, dafür kann ich keinen Support geben. 1 2 manuell, 3 automatisch. dass der leuchtmelder mitleuchtet ist ein bug.

übergestern.

Spaß beiseite, die Updates kommen, wenn sie fertig sind. Und es bringt dir auch nichts, wenn du mich bei Discord oder Facebook sowohl auf meiner Seite als auch Privat anschreibst.

Viel Produktiver wäre doch, wenn du deine Kraft in konstruktive Kritik steckst und du hier in kurzen, klaren Worten mitteilst, was du denn in einem nächsten Update gerne sehen würdest.

Findest du die Scheiben auch bei den Standard-Repaints zu dunkel? Oftmals werden die Repaints für die Busse aus meiner Hand falsch erstellt und mit halbtransparenzen (10% sichtbarkeit o.ä.) gespeichert - das ist bei meinen Fahrzeugen aber nicht notwendig. Das führt dazu, dass - weil die Scheiben im Template ja schwarz sind - bei 10% sichtbarkeit die Scheiben auch 10% schwarz getönt sind. Sollten bei den Standardrepaints die Scheiben auch zu dunkel wirken, hat hajo die korrekte Lösung dafür.

Zitat von Perotinus

ETS ist natürlich thematisch etwas weniger speziell als OMSI, weil sich, denke ich, mehr Leute für LKW interessieren, als für Linienbusse. Das spielt in den Erfolg mit rein, aber, und vor allem auch, dass SCS dieses Spiel pflegt, wie kein anderer. Und das nicht nur mit hervorragend gemachten DLCs, die sich in der Qualität auch immer noch steigern, sondern auch durch kostenlose neue LKW und vor allem Verbesserung der Engine. Dass dann noch die Modding-Community höchst aktiv ist und eigentlich jeden in der Realität neu erschienenen LKW in kurzer Zeit ins Spiel bringt, aber auch mit Soundupdates, Texturupdates und anderen Großig- und Kleinigkeiten kommt, tut aber eben auch einen entscheidenden Teil dazu bei.

Wie sieht eigentlich die Steam-Benutzerkurve des FBS aus?

im Schnitt 150 Spieler - besser als LOTUS aber kein Vergleich zu OMSI.

SteamDB

ja, das wäre gut, um gleiche Startvorraussetzungen zu haben. bitte auch gleiches Datum und Uhrzeit.
Ich tippe aus der ferne auf einen Font, der aktualisiert wird, zum beispiel auf einer Abfahrtsanzeige oder irgendwo im Bus.

ja, das muss aber nicht mit dem UII zusammenhängen. Nehmen wir mal an, das Spiel fängt an rumzuspuken und du spawnst nen bus neu. dann wird das element auf der Karte, welches das Problem verursacht - zu beispiel eine DFI - entladen und das problem ist behoben, obwohl es nicht am Fahrzeug lag.
Für mich ist es auf die "Entfernung" schwer einzuschätzen, was das Problem sein könnte. deswegen wäre es von Vorteil, wenn man es reproduzieren könnte und so die mögliche Ursache eher finden kann.