Beiträge von Maik Goltz

Discord Einladung
Trete unserem Discord-Server bei (klicke hier zum Beitreten).

    Ich würde eher sagen dass deine Herangehensweise falsch ist. Was ist es denn für ein Sound der da erklingen soll und warum ist der von Vist und Fahrschalter abhängig? Eigentlich würde doch Vist reichen als Trigger denn sobald du den Hebel bei der Büchse nach vorn verlagerst geht das Ding ab wie ein Zäpchen auf Trip und da brauchst den Fahrschalter nicht extra auswerten.

    Kann man sowohl im Trigger machen als auch im Script. Ich präferiere bei sowas das Script, da man dort viel besser steuern kann was passiert und was nicht. Im Proxy kannst du den Sound so oft triggern wie du lustig bist, auch mit verschidenen Controllern, aber musst eben zusehen, dass er nicht mehrfach getriggert wird. Da die InstanceGroups nicht wirklich gut arbeiten seit TS2013 musste rumexperimentieren.

    Nö, eigentlich noch nicht. Aber die Zeit kommt auch noch bei all dem Theater rund um den TS. Wer da nicht in der Klapse landet, arbeitet nicht richtig oder hart genug ^^

    Nene, da muss man doch jetzt nochmal unterscheiden was ich mir als Ziel fü rdie LZB gesezt habe und was HRQ gemacht hat (trifft gleichermaßen auf PZB zu). Ich möchte eine vernünftig arbeitende LZB. Die mir nicht irgendwas meldet was nicht da ist. Dies ist deutlich schwerer zu realisieren als was HRQ macht die einfach das ICE3 Scipt in der alten Fassung kopiert und etwas angepasst haben. Meine LZB ist anders. Sie funktioniert anders. Ich habe das ICE3 Script auch aber das ist totaler Murks und funktioniert nur unzureichend vorbildgerecht. Und klar, meine LZB funktioniert momentan aufn Punkt gebracht gar nicht, aber sie wird es und dann viel besser :) Das ist das vorgegebene Ziel. Ich möchte keine weitere falsche LZB erschaffen. Ich könnte das noch genauer erklären aber ich denke kein Mensch hier wird das technische vom Script verstehen.

    Dann formuliere es bitte klug und schicklich um, dann tausche ich es aus. (obwohl das wohl sinnlos ist, denn bisher hat sich kein Mensch gemeldet. War wohl nur zum Meckern gut dass es nicht erlaubt war. Jetzt wo die Möglichkeit besteht will keiner mehr.)

    Eine insteressante Frage hätte ich noch. Man schreibt das European Asset Pack wäre integriert in die Installation. Ich gehe davon aus dass die Lizenzen auch dafür abgeklärt wurden? Meines Wissens ist es nicht einfach so möglich diese Assets mitzuliefern, es sei denn man hat mit RSC einen entsprechenden Vertrag und zusätzlich mit den Entwicklern der darin enthaltenen Assets die nicht von RSC stammen.


    Gibt es die Strecke auch als Download. Boxen kaufe ich nicht. Ich bin ein Internetmensch. Was ich nicht sofort downloaden kann das kaufe ich nicht. Das gilt natürlich nur für Software. Brot und Butter lassen sich noch nich runterladen, aber sicher bald ausdrucken :D

    Ich will nix meckern aber da ich die Funktionen der Lok zu verantworten habe muss ich etwas loswerden. MIr fällt auf dass viele die solche Tutorials und Videos überhaupt machen, keine ansprechende Performance im System aufweisen können um dies wirklich zu tun. Über den gefühlten Daumen hinweg würde ich auf unter 10FPS tippen und das tut der Lok einfach nicht gut. Das sieht an den Regelvorgängen und dem PZB Lampengeblinke dass die ganze Sim viel zu langsam läuft. Das Wecheselblinken zB hat einen Intervall von 0,5s und bei dir sind das locker 2. Da stimmt also was nicht. Dazu kommen natürlich die anderen genannten Dinge. Vorbereitung ist alles. Die Lok erst selbst kennenlernen und dann anderen vermitteln wie sie funktioniert. Als Entwickler der Lok kann ich sagen dass das Tutorial falsch ist und verwirrt.

    Tja, hier haben wir so einen Fall wo das Signal selbst nicht weit was es zeigt. bAspect ist 2 also DoubleYellow (Hp2/Vr2) und pAspect ist aber 3 also Red (HP0). Da ich nur bAspect auswerte stimmt also das gemeldete Signalbild nicht. Der bAspect ist der standard Simulationswert und der pAspect kommt von der erweiterten proMap Darstellung. Das ist eben auch der Grund warum RSC da so komisches Zeugs gemacht hat und ohne Doku kommste da nicht weit. Da muss weiter rumprobiert werden und all die Möglichen Kombinationen ständig ausgewertet werden im Scriptablauf. Solche "Endlosschleifchen" wollte ich aber tunlichst vermeinden um die Performance zu schonen.


    Bremse: ja, wenn du zu oft am rumzupfen bist dann leert sich der HLB schneller als er sich füllen kann. Sinkt der HLB unter 8BAR (glaub ich), dann kannst du die Bremse noch anlegen aber nicht mehr lösen bis er wieder über 8.3BAR gefüllt wurde. Das ist möglicherweise nicht ganz vorbildgerecht aber der Sache mit dem anfangs leeren HLB geschuldet. Mal schauen ob ich das noch rausbekomme. Der HLB wurde im Script simuliert da solche Funktionen vom TS nicht zur Verfügung gestellt werden.

    Sind bei der 111er (vR EL) die CabSway Paramater auch auf Kuju Standard gesetzt?

    Nein, sind die selben wie in der 103. Und die 111er hat das Problem auch schon immer gehabt, es fällt da nur nicht so sehr auf weil man da durchaus über 100km weit fahren muss weil die Lok insgesamt langsamer ist. Ich habe das gestern alles in einem 18h Fahrmarathon gestestet. Verändere ich die Standardwerte nicht kommt der Effekt nicht hervor. Ändere ich auch nur 0,01 nach oben oder unten passiert es wieder. Da frage ich mich wozu man die Werte überhaupt ändern kann. Mit den Standardwerten macht die 103 keinen Spass weil sie ich innen beweget wie eine Spielzeugeisenbahn. Es wird im nächsten Update aber dennoch so gemacht weil die JellyCam unzumutbar ist. Auf gut gebauten Strecken fällt bei Standardwerten nicht viel auf, nur gibt es keine gut gebaute Strecken. HH-H ist passabel aber nicht gut.


    PS : habs grad nochmals nachgefahren : Meldung ist "next SR Typ 3 : Lim : 80 DistTo 40 m" es war aber rot, d.h. da hätte wohl 00 stehen müssen, übrigens die Voranzeige im Tacho zeigte auch 80..

    Hmm, ok. Da stimmt das nicht in der Auswertung. Typ3 ist Rot. Die 80 zieht er sich aus einer zweiten Abfrage. Da überlagert sich was weil Signale nicht so stehen wie sie müssten. Warscheinlich steht ein Lf nebst dem Signal zu eng zusammen. Da gibts noch viel zu tun um die LZB richtig ans laufen zu bekommen bei all den verschiedenen Baustilen der Strecken.

    Ice das hats du etwas falsch verstanden. Natürlich kann jeder Bilder von seinen Repaints zeigen wie er will. Das kann keiner verbieten und wird auch keiner. Es geht darum, dass Repaints die zur Veröffentlichung eingereicht werden sollen, vorher abgesprochen werden um hier nicht wieder lange Gesichter durch das Forum zu schleifen, wenn ein Wochenlang gezeigtes Repaint dann doch nicht veröffentlich werden darf/kann/soll.

    Gibt es noch irgendwelche neuen Erkenntnisse zur LZB?........

    Zuerst, die LZB ist deklariert als Beta, nicht ganz umsonst wie man sieht. Wenn die Situation reproduzierbar ist, bitte ich um genauere Dokumentation. Dazu das Signal erneut anfahren und dazu den Meldungslevel auf 3 stellen. Dnan erscheinen rechts alle 20 Sekunden 4 Mitteilungen zur LZB. Diese wären hilfreich. Dazu natürlich die bauliche Situation der Strecke wo das passiert (welche Strecke, welche Signale etc). Dieser LZB "Mist" ist leider ziemlich unvorhersehbar. Es scheint mir auch so zu sein, dass bestimmte Signale nicht als restriktiv erkannt werden, oder einen falschen basicState zurücksenden, oder eben gar keinen. Ich habe die LZB vorzugsweise auf Berlin-Wittenberg entwickelt. Dort werden rote Siganle einwandfrei erkannt. Auf München-Augsburg und Hamburg-Hannover kann ich leider nur raten was die Signale so tun. Die funktionieren auf jeden Fall anders und nicht wie man es erwarten würden



    ZUm JellyCab: die Lösung ist so profan wie schei*piep*e. Man setze die CabSway Paramater auf Kuju Standard zurück und schon passt es wieder. Dann ist der Wackeldackel-RuderbootAufHoherSee-Effekt weg aber dafür das rumgehopse des Cab wieder da. Es verträgt sich einfach nicht beides, also sanfte, die Trägheit wiederspiegelnde Bewegungen des Führerstandes mit oderntlicher Lage auf dem Gleis. Wobei nicht wirklich klar ist was da genau passiert. Fakt ist dass die Kamera am Pivot sitzt und das Cabmodell und das Aussenmodell an der Kamera hängen und darum wobbeln (eben das CabSway Dingszeugs was so fantastisch real auschaut...). Ändere ich die Däpfungswerte des CabSway Dingsbums dann verdreht sich die Kamera gegen den Pivot und wird instabil. Warum? Logik? Nö, nix nada niente. Bleibts eben standard.

    Ist nicht untergegangen Timo, steht auf der Liste. Da ist eine falsche Datei reingeraten.


    Das JellyCam Problem ist möglicherweise identifiziert, nachdem ich nun nochmal viele Lokblueprints verglichen und ausgetestet habe. Muss dennoch erst mal ausgibig testen. Könnte nämlich auch einfach nur wieder ein Zufall sein dass es gerade nicht passiert.

    Ne so ganz stimmt die Aussage nicht. Das ist schon ein Problem, vor allem wenn Dateien gelöscht werden müssen. Der Installer überschreibt möglicherweise nicht alles wenn es schon da ist. Das muss ich erst mit unzähligen Tests überprüfen. Die fehlerhafte Engine der TEE Version mit dem ORot im Engine-Name wurde jedenfalls korrigiert in V2 und sollte deswegen nicht mehr auftauchen. Allerdings in Szenarien die mit V1 gemacht wurden, wird sich die Korrektur nicht auswirken, da der Engine-Name in der Szenariodatei fest gespeichert wird. Da kann man die Lok hinterher ändern wie man will, im Szenario bleibt der Fehler drin. Da rührt auch das Input-Mapper Problem in manchen Szenarien her.

    Hab grad nochmal die 101 unterm Poppes und stelle da folgendes fest: es dauert bei der einfach nur länger. Nach 150km haste den Effekt etwa so wie bei der 103 nach 50km. Einen Reim kann ich mir darauf aber noch nicht machen. Es passiert aber definitiv bei allen Fahrzeugen im TS. Je schneller sie sind um so schlimmer wirds.


    die angesprochenen Videos gibts hier. Da sieht man das genau was da passiert. Man muss es vll mehrfach schauen um das Muster zu erkennen.
    http://www.youtube.com/watch?v=ax7y6_kAbDo
    http://www.youtube.com/watch?v=0tRRrsvZOas

    Ich würds ja gern lösen aber ich weis nicht woran es liegt. Ich hatte bei meinen Versuchen die Werte der Kuju 101 komplett in die 103 übernommen und es passierte dennoch. Am modell kanns nicht liegen denn da ist nichts anders, bis auf die Ammessungen und vll liegt das Problem da irgendwo begraben. Und es hat mit der zurückgelegten Gesamt-Entfernung der Fahrt und der Geschwindigkeit zu tun. Es wird extrem aufschaukelnd wenn man schneller als 140 fährt. In den ersten 20 km Fahrt passiert nix weiter. Nach 100km aber wird es extrem. Da scheint es also eine Gleitkommaungenauigkeit bei der Kamerapositionieren und der Kameryphysik zu geben. Das Modell selbst verhält sich völlig normal, das erkennt man wenn man in die Shift+2 Kamera wechselt. Würde es am Modell oder dessen WErten liegen müsste das draussen genauso stark wobbeln. Tut es aber nicht. Ich habe wie gesagt den vermeintlichen Bug bereits mehrfach gemeldet und dokumentiert. Ich kanns nicht ändern, aber es *piep*t mich genauso an weil es den Fahrspass mit den Loks versaut.

    Tja, ich versuche dieses Problem seit fast 2 Jahren zu lösen und es gelingt nicht. RSC hat mehr als einen Hinweis mit detaillierter Beschreibung und Videos dazu bekommen. Es scheint da drüben kaum jemanden zu interessieren. Woran es wirklich liegt weis ich nicht. Es tritt auch bei anderen Fahrzeugen und auch bei allen von RSC auf, nur nicht so häufig. Ich nenne das ganze JellyCam und man kann es vermeiden wenn man das Cab bei einer Aufgabe nie verlässt. Es tritt erst auf wenn man mindestens einmal das Cab verlassen hat. Das zeigt eigentlich auch schon deutlich dass es sich um einen Camera Bug im Core des Hauptspiels handeln muss. Theorien was es sein kann habe ich übermittelt und werde hier nicht weiter drauf eingehen da ich keine Lust habe ein Buch zu schreiben. Also wer gern drinnen fährt, einfach drinnen bleiben. Wer gern draussen fährt bekommt es eh kaum mit.