Die Ansagen sind aber eben komplett extern. Das einzige was im TS passiert, ist dass die Trigger beim Überfahren eine Zeichenkette in eine Datei schreiben. Diese Datei wird von dem Soundboard im Hintergrund monitored und ausgelesen. Das kann man für Ansagen sicher machen, für eine EBuLa denke ich muss man die Daten anders aus dem TS rausbekommen. Dass das geht weis ich, aber da gehören dann etwas umfangreichere Programme programmiert als das Soundboard dass letztlich nur ein Soundplayer ist der ferngesteuert wird (nein, ich möchte das Soundboard nicht abwerten, aber der Unterschied zum Aufwand eine EBuLa zu bauen ist meiner Meinung nach gewaltig). Ausserdem warum ein neues Programm schreiben. Es gibt eins. Es will nur mit den richtigen Daten gefüttert werden. Man braucht also eine Übersetzungsmaschine zwischen der eigenen Datenausleitungslösung und dem Zusi-TCP Server der dann die Daten an ZusiDisplay weiterreicht. Das ist eine reine Theorie. Wers versuchen will, nur zu.
Beiträge von Maik Goltz
-
-
Die Fahrpläne mit zu schleppen wäre nicht das Problem, jeder Tf hat ja seine Ebulakarte
Doch im TS ist das ein Problem, weil alle Seiten-Texturen aller Fahrpläne für alle Strecken in der Lok hängen würden und geladen werden wenn die Lok geladen wird. Rechnen wir kurz durch: ~10 Seiten pro Plan * ~10 Pläne Pro Strecke * 10 Strecken (bei 1024er Texturen weil man das ja auch lesen will) = ~1000 1024er Texturen in der Lok als extra Gepäck. Jede der Texturen ist im Idealfalle im Speicher etwa 1Mb groß, in nicht Idealfall bis zu 6Mb. Also eimert man sich damit mal eben 1Gb in den Speicher, im Idealfall. Untragbar.Könnte man sowas vlt als Extra Programm Erstellen, um es via Tablet oder ähnlich dar zu stellen?
Die Idee habe ich verfolgt, auch einen Ansatz wie man die Daten rausbekommt zur App, aber da isses dann auch stehengeblieben weil der Aufwand einfach heftig wird und wer hat hier bitte ein Tablet, und vor allem welche Plattform. Vergiss den Gedanken einfach. Ich habs in der Schublade. Wenn die Zeit mal reif ist, ja, aber momentan eher nicht. Ausserdem muss die Strecke ausgestattet sein, das Fahrzeug ausgestattet sein und und und. Ein wenig lohnedes Prozedere.
-
Augen auf! Genauer lesen. Nicht nur überfliegen, ne?
Uuuuhh
Und funktioniert das Brötchen auch richitg oder liegt es nur im Gleis und schimmelt?
-
Die "Track-Monitor" Angaben können nicht ausgelesen werden. Die stehen nur im HUD zur Verfügung und nicht in den Fahrzeugen. Ich habe schon versucht die Abfragen des ScenarioManagers, welche man so im Decompilat finden kann, aus einem EngineScript heraus aufzurufen aber da kommen keine Daten.
-
Jo stimmt. Hab ich gar nicht gesehen obwohl ich da kurz geschaut hatte. Aber Verwendung findet der nicht. Warscheinlich funktioniert er gar nicht. Müsste man probieren (wenn man zu viel Zeit hat für andere die Strecken nachzurüsten).
-
Moin,
wie hast Du es mit den Bremsen geregelt?
Keine Bremsart ist bei mir noch ansteuerbar, weder per Maus, Tastatur oder Joystick.
Selbst aus dem HUD ist die Bremse geflogen
Gruss Schmiddi
Im Simple-Mode hat man keine separaten Bremsen. Ist ein Trafo-Modus und den sollte man einfach nicht benutzen, denn dann fehlen viele Dinge in den Fahrzeugen. -
Eine Antwort wirst du wohl nicht bekommen mit ausreichender Erklärung. Aber was dann ist kann ich dir sagen. Nichts. Es bleibt bei Version 1.0 und das ist dann eben maßgebend für alle. Einen wirklichen Grund das Update deswegen nicht zu bringen gibt es nicht, ausser der Angst zuarbeiten zu müssen um Szenarien anzupassen. Bei der nächsten Strecke weis man eben dass man statt 100 mal drüber zu schauen dann 500 mal drüber schauen muss damit auch alles 100% perfekt ist zur Ablieferung. Dann dauert aber der Bau 2 Jahre länger und der Preis steigt warscheinlich auch, bzw wenn das nicht geht wird der Umfang der Strecken geringer.
-
Keine Ahnung wo ihr eure HH-H her habt, aber in meiner ist kein PZB_500Hz.bin vorhanden. Und die Strecke ist auf dem neuesten Stand (meine ich zumindest).
-
Maik, dass DTG das Update nicht liefert ist ein Problem, dahinter steht aber das Problem das Virtual Tracks eine unfertige Strecke geliefert hat
Und woher nimmst du diese Weisheit? Wer sagt dass das nicht so gewollt war? Der eigentliche Streckenast der mal anmoderiert wurde ist doch komplett vorhanden. Dass die S-Bahn bis Teltow auch ausgebaut werden sollte, stand meiner Erinnerung nirgendwo geschrieben. Das war eine Zusatzleistung die der Jan erbracht hat weil er sowieso an der Strecke was korrigieren musste. Zeig mir eine fehlerfreie Strecke auf dem Markt.
Du hast ja z.B. die Ludmilla auch nicht mit einem fehlenden Rad geliefert....
Doch, kein Ersatzrad im Kofferraum. Dafür halt 2 Lengkräder als Ausgleich.
-
Ein flüchtiger Blick nach HH-H zeigt mir keine vorhandenen PZB Magnete mit Funktion in der Assetstruktur. Die Magnetfunktion ist in den Signalen integriert und 500er gibts dort überhaupt nicht als Funktion. Die Sichtbaren Magnete sind nur Scenery und die kann man freischalten (ggf die .pak löschen).
-
Maik bitte ich glaube darüber brauch man nicht weiter reden. Das Bahnjan hier die A karte gezogen hat sollte klar sein denn bei ihm bleibt der ganze Sch.hängen ob er will ode nicht.
Du lässt es aber mehr oder weniger so verlauten. Dann lass es einfach wenn du nicht genau weist wer nun schuld ist.Es ist halt so das man hier so langsam aber sicher mal zu Potte kommen sollte. Das die Wege über RSC oft lang sein können ist ja mittlerweile klat aber irgendwo hört es dann auch auf denn
sonst feiern wir irgendwann das einjährige und nix ist passiert.
Und was bitteschön stellst du dir da genau vor wenn du doch weist dass da einfach nichts geht? Sag es also DTG und nicht uns. Wir hier wissen alle dass da was voran gehen muss aber wir können dabei gar nicht helfen. Und wen man das Schema betrachtet dann wird es auch ein zweijähriges feiern egal ob dir das gefällt oder nicht.Und @Madison ich habe irgendwie das Gefühl dass du heute die Keule im Garten wiedergefunden hast
Das nur so am Rande weil das doch arg auffällt. -
@Madison , ich finde das gegenüber Jan sehr unfair. Er ist wohl der einzige der wirklich nichts dafür kann dass das Update nicht kommt und er kann daran auch nichts ändern und nur genauso abwarten wie wir alle. Glaub es oder glaub es nicht, das Spielchen mit RSC/DTG läuft eben genau so und auch nur so. Da hängst als Drittentwickler wie ne tote Spinne im Netz und wartest dass der Wind dich davon fegt. Da hilft kein Genörgel, Gemckert oder sonst ein Wudermittel. Beispiele dafür und dass genau dies der Normalfall ist, gibt es bereits zur Genüge, vor allem aus dem deutschen Lager (420: 5 Monate und Update und Repaints fehlt bisher, 111 gefühlte 8 Monate weil die einen Fehler gemacht hatten, Berlin-Wittenberg 1.0 ..warum weis ich nicht .. das Update wohl weil eben einfach 6 Monate noch nicht vorbei sind, die 232 Update fehlt bisher nach 14 Monaten, 143 Update fehlt seit..ja eh .. X Jahren). Mag sich jeder selbst einen Reim drauf machen. Aber garantiert nicht die Entwickler dafür anbrüllen, denn die arbeiten eigentlich alle effektiv und schnell an diesen Updates und liefern diese auch schnell ab. Ab der Ablieferung hört der Einfluss aber auch auf. Das sind Fakten und ich meine die Diskussion um genau diese Dinge kann dann eingestellt werden weil es überhaupt keinen Nutzen bringt, weder den Usern noch den Entwicklern.
-
@FraPre , das Problem ist das nicht. Das ginge wenn sich jemand bereit erklärt diese Fahrpläne zu erstellen und logisch aufzuteilen damit man das auch lesen kann (sind ja dann nur Bilderchen und kein richtiger Text). Das Problem ist eher die Logistig der verschiedenen Strecken. Eine Lok im TS ist überall die gleiche. Die kann nicht mal feststellen auf welcher Strecke sie gerade steht. Wenn man rausfinden könnte "wie heist die aktuelle Strecke" und "wie heist das aktuelle Szenario", dann wäre eine relativ flotte Umsetzung durchaus denkbar. Aber das geht eben nicht. Also baut man im Idealfalle nur eine "Universal-EBuLa" die auf allen Strecken und in allen Szenarien funktionieren muss. Dazu kommt grundsätzlich das Problem dass man alle Fahrpläne stets "mitschleppen" muss. Wenn die ganzen anderen Probleme nicht wären die man beim Coden im TS hat, dann hätte man mehr Zeit für solche "Spielerkens", aber is halt nicht.
-
Norbert dreht mal wieder seine Hosen auf 180 rücklinks und will uns irgendwas mitteilen
Das Abspeichern der Sifa geht ja
Stimmt nicht. Die Sifa ist genauso aufgebaut wie deie PZB und LZB im Einschaltvorgang. Die ist nach dem laden aus.Wenn du mir sagst wie ich die ~200 Variablen in Controller codiere (mit vertretbarem Aufwand) dann kan nich den Zustand auch speichern. So geht es nicht wie es jetzt im TS ist. Dass es bei den Loks von RSC funktioniert liegt an der Tatsache dass die System dort sehr vereinfach gebaut sind. Dort ist der Zustand der PZB zB nur als Ein oder Aus definiert, das reicht mir für meine Abläufe im Script aber nicht, da muss mehr geprüft werden als nur Ein oder Aus. OnSave() und OnResume(), die ja seit 23014 dabei sind und auch wirklich funktionieren könnten, taugen nichts, weil man weder die Daten mit LUA vernünftig serialisieren kann um die abzuspeichern, noch kann man unterscheiden in welchem Szenario gerade gespeichert wird. Wenn ich also mir die 200 Zeilen Gaga-Code ans Bein bind um die Daten zu serialisieren (was vorher bedingt, dass alle Daten in eine LUA Table überführt werden was ein neucoden der Scripte mit sich bringt), hat man immer noch das Problem dass der Zustande auch beim nächsten laden einer anderen Aufgabe so geladen wird und das ist dann ja nun mal falsch. Man kann icht aufgabenbezogen die Daten speichern, Punkt Ende aus.
Das ist übrigens ebenfalls ein Grund warum die 120 nicht kommt. Der Scriptaufbau erfolgte dort von Beginn an ausgerichtet auf Serialisierungsmöglichkeiten und ist mehr oder weniger komplett OOP (sofern man das in LUA so bezeichnen mag, denn OOP kennt LUA nicht wirklich). Durch die fehlenden Debugmöglichkeiten im TS und der fehlenden Zeilennummernausgabe bei Logikfehlern komme ich da keinen Schritt mehr weiter. Ich weis einfach nicht wo ich den bekackten Fehlern suchen soll wenn man mir keinen Anhaltspunkt aus dem Interpreter liefert. Somit hätten wir die 120 dann auch gleich abgehandelt. Auch hier wird wohl ein kompletter Neubeginn nicht ausbleiben. Ich hätte doch lieber C++ als "Script"-Sprache gesehen, auch wenn man deutlich mehr lernen muss dafür. Aber ohne die Werte-Unterstützung des TS selbst bringt die beste Hochsprache nix. Wenn ich nicht auslesen kann was ich brauche habe ich einfach keinen Wert.
-
Sensationsmeldungen sind ja immer cool, aber wozu den Zug da rausschieben. Die wussten genau was sie machen. Das ist ein eher "kontrollierter" Brand (ist ja nicht mal einer). Die Flammen schiessen doch nur aus den beiden Essen raus, das sieht man sofort wenn man weis dass die so angeordnet sind (und das weis doch jeder der ne 218 kennt). Da bekommt der Diesel zu viel Bölkstoff oder die Ablagerungen in den Abgaswegen haben sich entzündet. Ich denke eher ersteres. Frage die zu stellen wäre, warum stellt man den Motor nicht irgendwie ab (ich weis, Diesel ist eine Selbstzünder) aber da muss es doch Notabsperrmechanismen geben wenn der "Ausschalter" nicht funktioniert. Warscheinlich ist die Dame einfach fertig und die Systeme haben versagt, ebenso wie die Kraftstoffzufuhr die wohl zu gierig wurde.
-
Ja, dabei braucht man SciTE gar nicht mehr. Das kann NPP auch. Warum SciTE die Lua Pfade umbiegt ist auch nicht klar, da es ja selbst gar kein Interpreter ist. Warscheinlich nutzt es das für die Autocompletion oder sowas, aber das hätte man ander lösen müssen.
So, die 143 gefahren und auch mir kam dieses Phänomen vor Augen. Das ist neu. Also bissel rumprobiert und ich meine zu denken, dass es dann passiert, wenn man den VSoll Steller wieder aufhebelt bevor die rote Nadel auf 0 war. Es passiert nicht immer aber manchmal. Oft reicht es einfach zu warten. Das hat was mit der "AFB Pause" zu tun die da drin ist um das Regelverhalten für den TS so anzupassen, dass die Stufenschaltung nicht noch mehr hin und her eiert. Das zu lösen würde bedeutet die AFB neu zu coden.
-
Du hattest ja die Tage in einem anderen Thread geschrieben das die Steam Variante wohl bei einigen nicht mehr so funktioniert wie sie eigentlich soll.
Das hatte aber dann doch nichts mit der Lok zu tun. Die hatten alle (wissentlich UND unwissentlich) SciTE installiert. Diese LUA IDE zerstört leider die Modulfähigkeiten des im TS implementierten LUA und so funktionieren die EL Loks nicht mehr weil die davon gebrauch machen.Ich werde die 143 grad mal 120km über den Stahl schieben. Mal schauen. Dieses Verhalten ist mir eigentlich nicht bekannt und ich bin garantiert genug mit der Dame gefahren
-
Also hier funktioniert der VSoll Steller immer. Wenn er nicht will, dann macht ihr was falsch. Die Lok ist nicht zickig, sie ist sensibel was die Bedienung und die Reihenfolge der Bedienschritte angeht. Das geschilderte sagt mir, dass hier der VSoll Steller zum Abschalten der Leistung auf 0 gestellt wird. Das ist aber leider falsch. Während der Fahrt mit Geschwindigkeistregelung hat der VSoll Steller nicht auf 0 gestellt zu werden, erst wenn die Lok steht. Das steht aber so auch in der Anleitung.
-
Prelli braucht nicht nicht weiter schauen, denn ihm erkläre ich das gern in vollem Umfang, dir nicht. Und ich bitte dich die Unterstellung zurückzunehmen ich hätte den Begriff "Brainfuck-Code" benutzt. Das habe ich nicht!
-
Ja Norbert, da sieht man mal wie viel Ahnung du hast. Jedenfalls nicht so viel wie du immer vorgibst. Du schlägst also tatsächlich als alternative Vorgehensweise an, die ZZA der 111 zu analysieren. Die hat aber mit dem was ich als "Anleitung" geschrieben hatte rein gar nichts zu tun. Die funktioniert völlig anders und das Script ist nicht analysierbar weil precompiled. Eventuell überlegst du mal vorher was du sagst, denn du machst dich lächerlich.
