Beiträge von Spikee1975

Weniger ist manchmal mehr, sagte mir eine befreundete Fotografin. Ich habe diesen einen Screenshot ausgewählt, ein ICMm hält in Leiden Centraal (Strecke: Randstad West 1.5)

Trotz dass ich das AP Cloudpack schon eine Weile habe, diesen Wahnsinnshimmel hab ich bisher noch nicht zu Gesicht bekommen. Man beachte auch das grandiose Stationsmodell.

Anmerkung: Wer auf einen Zufallshimmel trifft, den er gerne für ein Szenario festlegen will per "AP Weather Marker", kann einfach die AP\WeatherEP\Environment\Sky\Jahreszeit\Textures\cloud_band_01.TgPcDx mit beliebigem Editor öffnen, man kann oben die Nummer der Cloudbitmap herauslesen, die vom AP Skript ja bei Spielstart zufällig gewählt und kopiert wird. In dem Fall wäre der Markereintrag dann ";FC=F40")

Naja gut aber mir erklärt sich jetzt auch warum ich mit einigen ZZAs Probleme hatte. "Wissen was man tut" setzt voraus man kann Blueprints von reinen Daten xmls unterscheiden. Solch versierter Nutzer wird das wahrscheinlich dann auch per DOS Kommando machen.

Ideal wäre natürlich ein "Agreement" dass Content Ersteller Endungen wie .txt benutzen. Die .dcsv Dateien sind ja auch nur xml, aber eben namentlich getrennt vom Rest.

Oder einfach Finger weg, wenn man nicht weiss was man tut. Die xml tun kaum weh angesichts der heutigen Speicherkapazitäten, und ich würde Anfängern einfach dazu raten alles so zu lassen wie es ist. Hab auch Lehrgeld zahlen müssen früher...

So warte noch auf Geld dann schlage ich hier auch zu.

Zitat von TrainFW

Ja habe neulich tatsächlich die CleanAssets.bat ausgeführt. Daher kommt es dann.

Richtig. Von dieser .bat rate ich auch ab. Richtig wäre es vorher zu prüfen ob eine .bin des gleichen Namens vorliegt und nur dann die xml zu löschen.

Bedenkenlos geht immer .cost, .tgt, .dds, .tga, .ace, .igs, .ia, .pak, und .bak*. Wenn man denn wirklich nur das zum Spielen nötige behalten will. Viele Strecken blähen den Download auf weil sie .dds Texturen im Terrain Ordner mitliefern, die nach der automatischen Erzeugung der TgPcDx Dateien ja unnötig sind. Das Spiel selbst kann Roh-dds gar nicht lesen, nur wenn sie im TgPcDx Container eingebettet sind mit entsprechenden Metadaten.

Sorry für kurzes OT

Gibt's vielleicht im Loksim3D (war mein Einstieg) von Klaus Nickel der da massenweise Signale gebaut hat. Mal anfragen ob konvertieren erlaubt

Passt schon Malkondo. Dafür ist ja das Forum da.

ice Stimme vollkommen zu. Es reicht natürlich, nur den <English> DisplayName einzugeben.

Was mich an eine Schwäche des TSC Lokalisationssystems erinnert. Mein TSC ist auf Englisch, a) weil ich auch international Support gebe und b) weil mir manche deutschen Übersetzungen lächerlich und umständlich vorkommen. (Im TSW zum Beispiel wird aus einem einfachen "Go Via" ein "Gehe über einen Ort". Nee danke. Oder der TSC Fehler "Dynamische" dynamische was? - "Dynamic Lights". Ahhh so)

Nun sind alle Szenarios die man hier spielt auf einem deutsch eingestellten TSC erstellt worden. Das heisst, die <English> Einträge sind überall leer, bei z:b Service Namen, Custom Markern und normalen "DisplayText" Nachrichten an den Spieler. Keiner ausserhalb von Deutschland kann diese dann sehen, weil <English> eben global gilt, andere umgekehrt aber nicht in Szenarien. Geht man dann in den Szenarioeditor ist die Zugliste komplett leer, auch auf der 2D Karte werden keine Zugnamen dargestellt, ebenso F6 ohne Funktion.

D.h. es fehlen .lan Dateien die man erstellen muss wenn man auch möchte das fremdsprachige Spieler das Szenario spielen können ohne die fehlenden Texte (egal in welcher Sprache auch immer. Die Holländer haben TSC auch auf englisch, geben aber einfach auf niederländisch ein). Coasty z.B löst das in dem er jede Textmeldung via Script als HTML einblendet und auf <DisplayText>, <TriggeredText> und <UntriggeredText> in Szenarioanweisungen verzichtet.

Oder man stellt den TSC auf Englisch, gibt aber trotzdem deutsche Texte ein die dann im <English> feld stehen und dann für alle Spieler gezeigt werden.

Die .lan Dateien macht man mit Utiities.exe, jeder Eintrag im Blueprint hat einen 128bit-Key, dem dann die Übersetzungen zugeordnet werden. Utilties erzeugt eine xls wo du dann die Lokalisation, im einfachsten Fall die DE Spalte nach EN kopieren, erstellen kannst. Das ist der offizielle Weg, der oben genannte Schwächen ausmerzt. Guckst du dir alte Blueprints an die noch auf Kuju Schemata basieren, gab es dort sogar <Croatian> etc, bevor DTG das System auf die keygebundenen .lan files umgestellt hat um die Blueprints nicht unnötig aufzublähen und bequemer in Excel zu lokalisieren.

Ja und ich hab mir tatsächlich die Mühe gemacht, meine deutschen Railsim.de Lieblingsszenarios umzustellen, in dem ich in ScenarioProperties, ScenarioNetworkProperties und Scenario xml jeweils jeden <German>TEXT</German> ins English Feld kopiere, weil aus irgendeinem Grund xls2lan.exe bei mir nicht mehr geht und eine veraltete MSAccess Komponente als fehlend reklamiert. (Ich benutze LibreOffice, MS Office kann mich mal.)

Ach, und mal eben Sprache umstellen heisst immer Neukompilierung der SDBCache.bin, da sich die jetzt eben alle deutschen Zeichenketten aus jedem Szenario rauszieht und in die Datenbank schreiben muss.

Auf der Forenhauptseite sind ein paar verwaiste Threads immer noch sichtbar, obwohl in den Unterforen munter weitergepostet wurde. Wir haben ewig Ärger mit K-Trains Account usw.

Auch ist die Bäderbahn Molli jetzt nicht das aktuellste Thema im Projekte Forum.

Ich weiss, warum das so ist, aber könnte man evtl. die Unterforen mitberücksichtigen. Nicht sooo wichtig, sach ja nur.

Übrigens, ich habe eine Notiz auf der Downloadseite der Signale hinterlassen. Da ist ein falscher Soundpfad hinterlegt in einem der Signale für die Flügelbewegung.

Kann sich jeder selbst reparieren, die proxyxml ist leicht zu bearbeiten (und proxybin wird nicht vom Spiel verwendet und ist daher so unnötig, wie es eine ScenarioProperties.bin wäre.)

Du erstellst einen SceneryBlueprint in dem du auf das Geo verweist (Geometry ID), paar Daten wie DisplayName (wird dann im Editor angezeigt), am besten gleich noch Kategorisierung damit man's dann auch findet, und exportierst ihn dann.

ValidInScenarios heisst es erscheint auch im SzenarioEditor als szenariospezifisches Objekt. CollisionGeometry ist nicht nötig da TSC bei solchen Objekten ja keine Kollision testen muss während des Spiels.

Pickable heisst das Objekt kann nach dem Platzieren erneut angeklickt werden, z.B zum Verschieben. Sollte aktiv sein. CastsShadows = wirft Schlagschatten wenn beleuchtet von Lichtquelle die entsprechend auf Schattenwurf eingestellt ist und Sonne. Den Rest kannst du lassen wie er ist, z.B Detailstufe ab welcher Menü Qualitätseinstellung das Objekt dargestellt werden soll. Die Zeiten wo man das brauchte sind vorbei.

Was funktioniert da nicht?

Da liegt irgendwo ein Tunnel decal. Loch im Boden.

Selbst die Holländer wechseln in der zur Zeit in Arbeit befindlichen NoordoostNL 7.1 von CoHa tracks auf EZY

Wenn man beide Engine Blueprints vergleicht wird das klar warum, es wird nur der Pfad zum Lokblueprint verändert, aber nicht die ganzen Daten die sonst noch in der scenario.bin sind. Bei KI ist das meist wurscht, nur den Spielerzug bewege ich im Editor kurz hin und her um ihn "upzudaten".

Da hat eine Lok zum Beispiel die Tankfüllung so:

300

0

0

0

und bei ner anderen ist der Tank an zweiter Stelle im Blueprint

0

300

0

0

Deswegen gibts dann einen leeren Tank.

Auch Karlsruhe - Strasbourg, meine Hausstrecke, ist jetzt auf AP Vegetation umgestellt. Jetzt habe ich beinahe alle DTG LowPoly Bäume in meiner Installation ersetzt, wie es AP ja für die UK Strecken erledigt haben.

Szenario: [MSG] Mit dem Dosto in den Schwarzwald

Übrigens für dein Szenario hast du ja mit LocoSwap gearbeitet. Trotzdem wird die RSC HH 101 im Menü als Spielerlok gezeigt - LocoSwap updated die ScenarioProperties.xml diesbezüglich nicht.

Um sicherzugehen solltest du wenn alles getauscht ist einmal in den Editor gehen und die Spielerlok kurz ab- und wieder ankuppeln. Dann das Szenario speichern und TSC updatet dann alles korrekt.

Es kann auch zu leeren Tanks bei Dieselfahrzeugen kommen, die den Tank an anderer Stelle als <CargoComponent> definiert haben - LocoSwap übernimmt diese Eigenschaften nicht aus dem Tauschfahrzeug, der Editor jedoch schon, nur als Tipp .

Auf jeden Fall sind die Webseitendokumente grad nicht wo sie sein sollen, du kriegst nur die "index.html" als download. Wird schon wieder. Server läuft wohl während Inhalte live geupdated werden oder so.

Ist auf jeden Fall da nur halt leer. Wenn das DTGLive wäre würden dort im Forum schon wieder alle Matt, Harry und Alex in Panik taggen, mitten in der Nacht

Stimmt. Vermutlich wird die Seite grad gewartet. Hilft meist nur Abwarten

Danke Tom - ich liebe diese Strecke also tue ich was ich kann um das Erlebnis für alle zu verbessern.

Um meine Motivation zu erhalten, die regelmässig Erfolgserlebnisse braucht angesichts des Bergs an Assets, werde ich nach Fertigstellung des Taddel Packs gezielt mal nur die streckennahe Vegetation, welche zwischen Vienenburg und Goslar verbaut ist, bearbeiten, bevor ich die Gesamt TSTools Shapesliste dann angehe. Diese Strecke ist mir sehr extrem aufgefallen was "Wechselbüsche" angeht, das wird dann die erste Teststrecke.

Edit: Hatte grad ein kurzen PM Austausch mit Tom. Die Taddel Assets sind an sich gut, haben zwar wie oben gezeigt kurze LOD Abstufungen aber die LODs selbst (Meshes) sind nicht so grob vereinfacht wie bei anderen wo aus einem Baum übertrieben gesagt plötzlich ein Quader wird. Nichtsdestotrotz werden die auch geändert, schon allein weil ich mich nicht individuell mit jedem einzelnen Asset aufhalten kann und die noch kategorisieren müsste nach "gut / geht so". Da wirst nie fertig. Und weil sie sonst, wenn alles andere Hardwarescaling benutzt und sanft skaliert, auf einmal herausstehen werden, wo sie jetzt noch gut getarnt zwischen den "schweren" Fällen versteckt sind.

Alles was ich will ist ein Fahrerlebnis wie auf Münster-Bremen, butterweich.

Nachtrag: Natürlich wird hier nichts hochgeladen solange das Urheberrecht nicht geklärt wird. Vielleicht gibt es hier Leute die Kontake insbesondere zur tschechischen Szene haben, es ist auch nicht so selten, daß eine Lizenz die modifizierte Weitergabe erlaubt, solange der Originalautor genannt wird (auf Railworksamerica.com sehr üblich und entspannt - kein Ego, sondern Sinn für die Community, alle sollen profitieren). Ein Morava Pack selbst offiziell zu updaten wird keinen Sinn machen, da diese Assets weit verstreut in diversen MegaUpload und Streckenpaketen partiell enthalten sind. Das kann nur über einen separaten Patch erfolgen.

Findige Powershell Skripter könnten leicht ein Skript erstellen das die Arbeit die ich gerade mache automatisiert, ähnlich wie bei BR204 Repaints, die Texturlinks in der DTG Cab Geo patchen. Dieses Skript würde dann als Patch hochgeladen. Oder es gibt Programme die kleine Binär-DeltaPatches erstellen nachdem sie original und mod vergleichen und nur die Unterschiede und deren Offsets speichern (kann allerdings schiefgehen wenn verschiedene Versionen einer Geo im Umlauf sind, dann müsste man noch auf Checksumme prüfen etc - von daher ist Powershell safer da Offsets relativ zu identifizierbaren xml tags arbeiten). Geht alles wenn man will. Also meldet euch

So, grad eine Taddel Teststrecke gebaut.

Ploppen weg, aber das Problem der zu hellen Texturen wo man den einsetzenden Schatten deutlich merkt, kann ich nicht beheben. Das ist halt so und um so krasser je heller die Baumtextur. Ausser Texturen ändern (keine Lust) fällt mir da nüscht ein. Aber - besser als vorher.

Das ist der technische Grund, warum DTG, VP und AP Vegetation dunkler ist, dort fällt das nicht auf. Für natürlich hellere Bäume sorgt dann da eben ein 2D Asset was den Schatten schon in der Textur hat. Was man alles bedenken muss um Assets für ein Spiel zu bauen... Aber - eine deutliche Verbesserung des Fahrgefühls. Bin zufrieden da die Modelle sich jetzt nicht mehr in der Form verändern und "analog" statt "digital" skaliert werden.

So, nun an die Kamat Assets. Der Flow ist da und nu gehts rucki zucki, eigentlich wie ein Roboter. Klick, F4, Klick-Zieh, Ctrl+V, Ctrl+S, Klick, repeat. Ab und zu Hände ausschütteln und eine rauchen Dann SerzMaster rennen lassen, sich auf der Teststrecke am Ergebnis erfreuen, und weiter zum nächsten Provider.

Zum Thema Vegetation: Fange jetzt zuerst mit den gutsortierten Taddel Assets an.

Ich erstelle zwei Ordner - ein Backup welches nur die Originalgeos enthält und einen der die modifizierten enthält.

Es wird grundsätzlich LOD0 überall mal auf 1000 gestellt, so wie bei den AP Bäumen bei denen ich keine Leistungseinbußen merke (und ich die mal als sehr detailliert bezeichnen würde).

Workflow:

Dieser Baum hatte die lästige Abstufung 50 m (detailliertestes Modell) und dann wie man sieht 100, 250 und 500m Abstufungen. Das ist das was das Ploppen erzeugt. Da ich keinen Wert löschen darf da sich die LODController ja auf das / die enthaltene(n) Mesh(s) beziehen, kann ich das umgehen in dem ich einfach nur sage daß das Spiel das jeweilige LOD0 bis zu tausend Metern weit rendert. Die Grafikkarte übernimmt nun die Skalierung auf volle Renderdistanz, und das macht sie wesentlicher sanfter als das mit vordefinierten LOD-Sprüngen passiert.

Nichts anderes macht im TSW der Befehl "foliage.LODDistanceScale faktor". Alle Werte die man hier sieht werden in UE bei Laufzeit einfach mit faktor multipliziert. Das kann die TSC Engine (ich glaube intern heisst sie Hercules) nicht, muss also im Modell selbst angepasst werden.

Wer sich wundert, was die drei LODController sollen: Ohne jetzt das Modell selbst zu sehen wird hier wohl Blattwerk, Äste und Baumstamm einzeln definiert sein. Ganz brutal mute ich der Grafikkarte das volle Modell bis 1000m zu. Sehen wir mal

Ich verändere bewusst die drei restlichen LODs im zweiten LODController nicht da es keinen Sinn macht einen 3D Baum weiter weg zu rendern. Mich interessiert nur LOD0 des jeweiligen Meshs. Falls jedoch eine höhere Distanz doch aus irgendeinem Grund (3D Veg an entfernten Berghängen, eigentlich nicht ratsam), kann man LOD3 nehmen und auf 1500m z.B. einstellen. Das ergibt sich aus den Tests dann. Da dieser Baum aber sowieso nie weiter als 500m erschien, eher unwahrscheinlich. Ich reduziere ja nirgends die Distanz, also nondestruktives Modding

Im Hintergrund läuft stabil der TS weiter, und ich kann jede Änderung sofort testen.

Die geänderten xml werden dann verschoben in den "Modifizierte_Geos" Ordner, dort mit SerzMaster serialisiert und dann per DOS Fenster alle wieder von GeoPcDx.bin nach GeoPcDx umbennant. Vergisst man den letzten Schritt, schiesst man den TS ohne Fehlermeldung ab (alles schon passiert, in dem Fall ergibt's ne 0-byte blueprints.pak)

...und vom Provider "RWAustria" das Paket "Austria".

Tatsächlich, das war warum auch immer nicht aktiv.

mit DBTracks: (was lag da nun tatsächlich? Holz oder Betonschwellen?). Auf Wunsch wie gesagt die tracks.bins tauschen.

Es müssen einige Assetpacks geupdated werden, alle Links wie immer in der Doku. Lohnt sich

HSL Amsterdam -Tilburg / Antwerpen v4 ist draussen, zusammen mit neuen / geupdateten Szenarios