Beiträge von SeKu

Spikee1975,

ich fürchte, bei allem Respekt, dass Dein Wissen um den Einsatz von AI/KI in der Softwareentwicklung, nicht mit Deinem breiten Wissen um den TSC mithalten kann.

Was für exorbotante Kosten, entstehen denn, Deiner Meinung nach?

Mit einer 16 GB VRAM Grafikkarte von ATI oder Nvidia läuft das LLM lokal, da entstehen nur Stromkosten. Es gibt ein breites Angebot auf Abo-Basis bei der man subventionierte Tokens im Vorraus bezahlt und Du kannst auch über OpenRouter LLM ohne Abo über Per Token Usage bezahlen.

Und um meine Argumentation vom letzten Post aufzugreifen und zu bestätigen, was FreD bereits erläutert hat: Die zielgerichtete Entwicklung läuft über Specs und kleine Slices, nicht über einen Prompt. Auf Deutsch: Du legst wie bei der Entwicklung ohne KI, vorher fest, was Du erreichen möchtest, wie Du es erreichen möchtest und welche Zwischenschritte dafür notwendig sind. Du legst ein Testframework fest und welche Abhängigkeiten eingebunden werden müssen. Es folgen Festlegungen zu Konventionen, Datenmodellen und Design.

Erst wenn Du diese Aufgaben erledigt hast, kann es in die Umsetzung gehen.

Eine einfache Aufgabenstellung wie "bau mir ein GTA7" wird EIN Ergebnis liefern, aber sicher nicht das gewünschte Ergebnis. Da kommt dann eher ein Browsergame für YouTube bei heraus.

Also ist Deine Schlussfolgerung, dass die Kompatibilität bei einem Rewrite in Rust keine Rolle spielt, nicht korrekt. Damit eine vollständige Kompatibilität erreicht werden kann, ist das Gegenteil der Fall.

Genauso wie OMSI2 Addons von OpenOmsi profitieren, könnte der TSC profitieren, wenn es eine moderneres Frontend gibt, dass moderne Hardware besser ausnutzen kann.

In diesem besser liegt auch keine "Überheblichkeit", sondern nur andere Möglichkeiten.

FreD,

aber genau das macht etablierten Entwicklern vielleicht auch Sorge. Bislang konnte nicht jeder, der will, ein Programm schreiben. Davor stand immer erst das Lernen der Programmiersprache. Algorithmen sind nicht abhängig von der Programmiersprache, man musste sich aber vorher mit dem Problem, dass man lösen wollte, auseinandersetzen. Jetzt gibt es diese Einstiegshürde nicht mehr.

Letztlich kann (noch) jeder selbst entscheiden, ob er Software nutzen möchte, die von KI erstellt worden ist oder auch nicht.

Wichtig ist der Output, der Code und wenn der keine Fehler hat, spielt es in meinen Augen keine Rolle, wer den Code geschrieben hat. Da FreD nach eigener Beschreibung vorgeht, wie andere Software Developer auch, nur der "Mitarbeiter" eben Opus oder Fable heißt.

Und um mal eine deutliche Aussage zu treffen, das ist kein Vibe Coding dass hier betrieben wird:

Wer mir nicht glaubt, kann ja gerne mal in ClaudeCode/OpenCode/DeepSeek Harness versuchen mit dem Prompt, "Bau mir einen TSC Klone" zum Erfolg zu kommen. Das wäre dann Vibe Coding und wird garantiert nicht funktionieren.

Wer mit KI arbeitet, stellt schnell fest, das Vorerfahrungen aus professioneller Software Entwicklung immer hilft, Vibe Coding ganz sicher immer nicht zu einem gewünschten Ergebnis führt.

ice kennst Du

Materialize

schon?

Nick,

gute Idee, es auch mit dem TSC zu versuchen. Viele ungelöste Probleme würden eine neue Chance erhalten, gelöst zu werden und modernere Hardware könnte ihre Stärken ausspielen, bei einer Umsetzung in Rust.

Es gibt ja die Möglichkeit, die anderen Texturen, die für ein PBR Material üblicherweise verwendet werden, aus der Diffuse Textur abzuleiten.

Ich wünsche Nemo1095 viel Erfolg, gehe aber davon aus, dass der Ansatz der anderen Projekte mit Rust und nicht UnrealEngine erfolgsversprechender sind.

Ich würde auf Probleme zwischen den RSSLO Signalen und den höherwertigen Rollmaterialen tippen. Ich habe auch immer wieder die von pschumacher036 beschriebenen Störungen, wenn ich auf RSSLO Strecken ohne Signalupdate versuche, Rollmaterial von vR, RWA oder 3d Zug ICE's einzusetzen. Soweit ich es verfolge, gibt es zB beim LZB Verfahren Probleme, über die im Forum berichtet wurden.

Es gibt bei RSSLO Signalen ja eigene Trigger, die aber von der Komplexität, die die Signale und Trigger von Schuster bieten, weit entfernt sind.

Vielleicht mal einen der DTG ICE's ausprobieren? RSSLO nutzt auch immer die weniger komplexen ICE's bei eigenen Szenarien.

Hello Paul,

there could be other differences in the GeoPcDx Files, which would lead to a general incompability between Steam and RSSLO shop versions.

If the mesh has only some texture mapping differences, the repaints will not work.

Most of the updates, fixes and repaints you can dowload from this forum require the RSSLO shop versions of the addons, because of a possible incompability. There are quite often sales discounts on the RSSLO shop too, if you are interested. You safe more money by not buying twice, even If the Steam sales tend to have higher discount.

👋

Sjef61,

Du könntest überlegen, Dich als Freeware Entwickler im Forum registrieren zu lassen, wenn Du mehr Uploads als Nachrichten hast, ist das bestimmt ein gutes Kriterium. Aber guck Dir die Regeln besser an, bevor ich daneben liege, mit dem Hinweis.

Danke für die Waggons, die Texturen sehen wirklich gut aus. 👍

Für mich ist das alles relativ einfach, so wie man sich bettet, so liegt man:

Es ist nachvollziehbar, dass sich TSW Creator genervt fühlen, da sie stellvertretend die Prügel für DTG entgegennehmen, für Probleme, die sie überhaupt nicht beeinflussen können. Wenn so wie bei TSG Projekten mehrere bekannte (ex) Forumsmitglieder beteiligt sind, ist der Frust sicher noch viel größer, da man sich "kennt".

Aber das Problem bleibt DTG, die Fehler im "Simulator" Anteil und nicht Content von Thirdpartys. Das Problem bleibt DTG, da Updates und Patches zu teuer für die Konsolen Shops sind, anderseits ist der Konsolenmarkt für einen Simulator (!) so wichtig, dass man sich erst gerade von der Toaster-Generation mit 15 Jahren auf dem Buckel, getrennt hat.

Das Problem bleibt die Unreal Engine 4, oder das Unvermögen von DTG, die Leute einzustellen, die Fehler und Probleme im TSW Core anzugehen und zu lösen.

Die Qualität der TSG Addons ist in meinen Augen weiterhin für sich selbst sprechend und es ist aber für den Kunden schwer auf ein Highquality Paket, in einem suboptimal entickelten Simulator, zu setzen.

Sie "erwähnen" es bei RSSLO, die benötigte Strecke ist in den Voraussetzungen verlinkt.

Der Link führt nicht zu Steam. Wenn in den Combines die Nutzung einer Steam Strecke möglich ist, steht es extra dabei.

In diesem Fall würde ich also erwarten, funktioniert die Verlängerung nicht mit einer Steam Strecke.

Ist eigentlich einfach. Guck Dir "Combine Südbahn" an, dann kannst Du den Unterschied erkennen.

Grundlagen TS-Tools oder RW-Tools:

Du musst, nach dem Du neue Strecken installiert hast, auch die RouteProperties.xml Dateien einlesen lassen, damit TS-Tools die neu installierten Strecken auch "findet".

Mehr eigene Recherche, weniger Fragen(!) 😉

Stimmt, die Güterwagen von RailStudios sind sehr empfehlenswert, aber mit fraglicher Verfügbarkeit für Neueinsteiger.

Da ist, denke ich, der Ansatz von tom87 sehr gut gedacht, auf aktuell sicher verfügbares und bereits weiter verbreitetes Material zu setzen.

Stephan218 ist aktuell wieder sehr fleißig beim Asset erstellen und auch bei mir zeichnen sich ein paar Stunden am Horizont für den TSC ab, so dass noch ein paar extra Wünsche der Beiden erfüllt werden können.

Einen schönen Sommer und freut Euch auf den Herbst/Winter im großflächig umgebauten und erweiterten virtuellen Harz. Ich habe die großartige Arbeit der Beiden Protagonisten aktuell bekommen und bin begeistert. ♥️👍

Ich habe auch eher einen c#/c++ Grundstock im Kopf, bin aber auch hier ein Amateur und kein Profi.

1.Verwirrung(hoffentlich)

Du kannst schon mit lokalen Funktionen arbeiten, die habe ich in Deiner Throttle LUA Datei erhalten und nur namentlich angepasst. Du kannst sicher auch mit deinem Grundansatz weiter kommen, und den Funktionsnamen direkt aufrufen. aber ich habe Dir gezeigt, was für mich funktioniert.

Dadurch dass ich einen Teil der TSC-"Boilerplate" in jedem Skript mitliefere, habe ich bestimmt auch Nachteile, kann aber wie Du beschrieben hast, die Systeme voneinander getrennt halten.

2.Verwirrung:

Ich habe schon einmal die These hier im Forum aufgestellt, dass diese zentrale LUA auch immer die Werte der Controls "durchreichen" muss und bislang hat niemand, der es besser beschreiben kann, widersprochen.

Allgemeine und geteilte Verwirrung😉:

Viel ist nicht wirklich LUA abhängig, sondern soweit wie ich es verstehe, der Art geschuldet, wie das Skripting im TSC funktioniert oder besser welche eingebauten Werte manipuliert werden müssen.

Mein PZB Skript ist sehr ähnlich aufgebaut, aber inzwischen mit richtiger StateMachine und lokalen Funktionen, um auch alle überlagernde Beeinflussungen korrekt darzustellen und den ausgewählten Führerstand zu berücksichtigen. Da wird es demnächst ein Update für das V200 Paket geben.

Aber ich habe zB meine G320b immer noch nicht fertig, weil ich nicht glücklich mit der Steuerung und insbesondere der Bremssimulation bin. Scheitert am Zeitmangel im Moment.

Lösungsansatz für Profis und Amateure mit etwas Zeit:

Was sehr empfehlenswert ist und ich von Spikee1975 erfahren habe: Guck Dir die Skripte von Armstrong Powerhouse an.

Eine Empfehlung direkt von mir:

GitHub - JachyHm/RailWorksLUAscriptExamples: Example LUA scripts for RailWorks.

Example LUA scripts for RailWorks. Contribute to JachyHm/RailWorksLUAscriptExamples development by creating an account on GitHub.

github.com

ist sehr aufschlussreich.

4. Verwirrung

Das ist eine Art von Vererbung, soweit ich es verstehe. LUA bietet das nativ nicht und so umgeht man diese native Einschränkung, soweit mir bekannt.

Weil LUA nicht so logisch kompiliert, wie man sich das wünschen würde. Leider hast Du Fehler im Skript, die sich unter einer bestimmten Bedingung aufheben und dann das Default Verhalten zulassen, wäre mein Erklärungsversuch.

Dein Hauptskript und dein eingebundenes Skript haben Fehler, die zwar kompilieren, aber logisch nicht funktionieren können, soweit ich es beurteilen kann.

Das Hauptskript müsste auf den von mir beschriebenen "require" Ansatz umgestellt werden und das Nebenskript hat umständliche Funktionsnamen, die Probleme verursachen könnten, oder korrekt aus dem Hauptskript aufgerufen werden müssten.

Und nur weil ich eine Variante kenne, heißt das nicht, dass ich alle möglichen Varianten kenne.

Ich versuche Dein Skript anzupassen und schicke es Dir hier zurück, damit Du testen kannst.

Ich würde erwarten, dass es eigentlich in der Animation einfach eine Bewegung des Hebels gibt. Ob die einzelnen Frames der Animation an bestimmte Positionen oder Raststellungen orientiert sind, oder in linearen Animationen auf/ab, links/rechts oder aufgeteilt auf, ab, links, rechts vorliegen, hängt vom Autor ab.

Aber neben dem Namensraum für Objekte, den man als Entwickler frei wählen kann, innerhalb der TSC Vorgaben, gibt es reservierte Namen, die dann die Mechanik fest eingebaut von "Kuju" oder besser dem TSC bekommen.

reverser, horn, sander guck am Besten in die Dokumentation, gibt es bei ChrisTrains.com.

Hier würde man VirtualControls einsetzen, um das Verhalten des TSC zu korrigieren.

So kann man zB Druckluftbremsen und Hauptluftleitung in eine Bremssimulation auslagern, um das gewünschte Verhalten zurück an den TSC zu geben und die Ausgabe der Anzeigen im Führerstand daran auszurichten.

Umgekehrt, könntest Du so Positionen/Stellungen der Hebel auslesen und für deine Simulation nutzen.

Also ich fürchte, Du hast da schon einen Fehler im "require" Vorgang, bei der V200 habe ich folgende Zeilen im Hauptskript:

##

require "Assets/Kuju/RailSimulator/RailVehicles/Diesel/V200/default/engine/sifa.lua"
Sifa_Initialise = Initialise
Sifa_Update = Update
Sifa_OnControlValueChange = OnControlValueChange
Sifa_OnCustomSignalMessage = OnCustomSignalMessage


(...)


function Initialise ()
    Sifa_Initialise()
    Call( "BeginUpdate" )
end

(...)

function Update (timer)
    Sifa_Update(timer)
(...)
end
##

usw

Eventuell verstehe ich Deinen Ansatz nicht, aber wenn Du das Originalskript mit "require" einbindest, "kaufst" Du das Verhalten aus dem Orginalskript mit.

Wenn Du zB eine Zugsicherungsvsariante einbinden willst, die das Orginal nicht hat, dann ist das eine valider Ansatz, weil Du hinzufügst, nicht überschreibst.

Für eine Veränderung vorhandenen Verhaltens, müsstest Du das zentrale Skript neu aufsetzen, sonst kämpfst Du mit dem Verhalten aus dem Orginalskript.

Nein, nur die Assets, die im Handbuch aufgelistet sind, werden für das Harznetz benötigt, es sei denn es wird explizit darauf hingewiesen, dass eine Strecke voll installiert sein muss. Das Romanian Asset Pack 7 ist nicht mehr direkt über Railstudios.com zu beziehen, es gibt aber Alternativen, wenn Du bei einem anderen rumänischen Hersteller etwas gekauft hast. Die halten eigene Downloadlinks bereit. Ob es gerade einen Link ohne Bezahlung gibt, kann ich nicht sagen, dafür bin ich zu weit weg vom TSC zur Zeit.

Aber gerade das Harznetz liefert eine Vielzahl eigene und streckenspezifische Assets direkt mit.

Trau dich einfach, "Google" fröhlich los, wenn Du etwas nicht direkt findest. Versuch es mit HaSi V3. Wenn auch in die Jahre gekommen, ein fantastisches Beispiel für noch heute gut intallierbarer Freewarekontent mit jede Menge Mehrwert und einer Basisstrecke zum Eisbecher Preis im Sale.

Versuch es mit:

SysCall ( "CameraManager:ActivateCamera", "ExternalCamera", 1 );

Es könnte sein, dass die Views durchnummeriert sind. Nur ein Gedanke, keine Garantie.

? natürlich ist man dann dort auf einer leeren Fläche, wenn man Bremerhaven löscht, dass ist Sinn und Zweck einer Löschung.

Man kann sich dann über Szenarios neue Einstiegspunkte schaffen, die nicht am Route-Origin Punkt liegen, wo man gerade fleißig baut.