Beiträge von bahnjan

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

    Moin,


    ich habe einen Verdacht, bitte alle, bei denen der Bildschirm bei welcher Aufgabe auch immer schwarz bleibt den TS2012 ohne TSX-Modus starten und dann die betreffende Aufgabe. Ist der Himmel weiß, die Landschaft grell und dort wo die Sonne angezeigt wird ein "missing texture"-Fenster zu sehen, dann ist es tatsächlich ein Bug, der mit einem der letzten undokumentierten Miniupdates hinein kam.


    Bei mir war es so: seit dem einem Update (um die Jahreswende) bliebt der Streckenedi schwarz. Nur die Fahrletung war als weiße Linien sichtbar. Ich habe im Route Template Blueprint dann mal die Tageszeiteinstellungen getauscht und dann ging es wieder, kam aber nach ein paar Aufrufen zurück.


    Gruß, Jan

    Im Moment gehts aber schleppend voran, zum einen weil ich recht eingespannt bin für Köln-Düsseldorf, zum anderen weil mir schlicht und ergreifend Pläne vom Frankfurter Hauptbahnhof fehlen sowie Bilder von diesem.

    Moin Kevin,


    Gleisplan findest du hier: http://www.sporenplan.nl/ und Bilder: einen Tag Urlaub nehmen, nach Kassel fahren und von dort den ICE nach Frankfurt nehmen :) Du kannst natürlich auch nach Köln fahren und von dort nach FFM... Selber Bilder machen ist sehr wahrscheinlich die beste Variante, du weißt selbst am Besten, was du brauchst und wie du es fotografieren musst...


    LG, Jan

    ...habe aber heute Zeit damit "vergeudet", mich an der 143 zu erfreuen. So langsam wird doch ein Simulator aus dem TS2012. Ich finde die Fahrzeuge großartig und sie zeigen, was (wenn auch mit Aufwand - und Preis - verbunden) für ein Potential in den Lua-Scripten steckt. Der RE5 fährt nach Falkenberg/E. und nach Rostock. Das find ich ganz toll.


    Vielen Dank, ihr habt den Trabi in Railworks salonfähig gmacht.


    Viele Grüße
    Jan

    Moin,


    ich habe mir heute den ganzen Thread hier nochmal zu Gemüte geführt und nur gelesen, dass mit der Performance was nicht stimmt. Daran hat Siegfried gearbeitet und eine Lösung + ein paar zusätzliche Szenarien generiert. Ich weiß, wieviel Arbeit da drinnen steckt, "ein Update, das keines" is dürfte Siegfried sicher nicht gerne lesen. Dass irgendwer das Hp2 an diesem Gleis in Wildau, an das - das gebe ich unumwunden zu ein Hp1 könnte - in Wildau angemeckert hat, habe ich nicht gelesen. Aber ich bin auch nicht überall im Forum unterwegs.


    Es hat etwas mit Kultur zu tun. Der Ton, der in den Foren mitunter herrscht, vergrätzt einem die Arbeit mitunter gewaltig. Es gibt Leute, die schmeißen dann hin. Ich verstehe, dass man unzufrieden mit einem Zustand ist, der sich nicht ändert. Aber ich verstehe diese allgemeine Gebrummel und Gemotze nicht. Ihr wisst, wer die Strecke gebaut hat, es steht zu lesen, wer Szenarien und Signale hingestellt hat. Ein Post oder besser eine PM mit ner Fehlermeldung (weil ich hierüber einen Benachrichtigung erhalte) ist für jedes Update wichtig. Hab ich nicht bekommen. Jetzt ist die 1.2 draußen, eine 1.3 braucht Vorbereitung, Signale ändern heißt alle Szenarien neu testen zu müssen. Viel Zeit...


    Dass ich es gewohnt bin, diese Kultur zu pflegen, konnte man im Forum bei Train Team Berlin, jederzeit lesen. Ich weiß nicht, wie oft ich "Im Berufsverkehr 1" getestet habe. Das Hp2 hat mich nicht gestört, obwohl es sicher und ganz einfach ein Hp1 sein könnte. Ich habe es nach zwanzigmal vorbeifahren nicht gesehen. Die Betatester haben es nicht gesehen. Ihr seht es, das ist die Natur bei Sache bei komplexer Software (das weiß sogar der Gesetzgeber und erlaubt Nachbesserungsfristen). aerosoft ist an dem Ganzen nicht schuld, aerosoft hat die Strecke nicht gebaut. Sie haben auch das Update erst heute veröffentlicht, weil bis gestern die Sprachdatei für die neuen Aufgaben zur Korrektur bei mir herumdümpelte. Ich arbeite bis 16 Stunden am Tag und da gibt es mitunter andere Prioritäten. Dafür, dass ich es gestern geliefert habe und sie es heute herausgetan haben, waren sie eigentlich sehr schnell. Thats it.


    Jedenfalls sitzt keiner von uns vorm Rechner den Ar$45 platt mit der heren Absicht, euch zu ärgern. Nun erwarte ich eure PMs mit vermeintlichen oder echten Bugs, werde sie auch beantworten und daraus eine Featurelist für 1.3 machen.


    Grüße, Jan

    Moin,


    die Helligkeit der Nacht kommt bei Railworks vom Wetter. Basis ist eine recht helle Vollmondnacht. Setzt man Wolkenlayer ein, kann man im Blueprint definieren, wie dunkel es darunter ist. Die bisherigen Nächte waren mir schon immer zu hell. Ich bastel mit den Blueprints eigenes Wetter zusammen und bin damit halbwegs zufrieden. Bei Gelegenheit werd ich hier das mal beschreiben, wie das geht.


    Viele Grüße
    Jan

    Moin,


    ich hab das getestet: Strecke editieren, Lichter setzen und dann im selben Tile auf den Playbutton drücken und im Tageslicht ankommen, killt die Leuchtfunktion. Ich habe das vor einer Woche mit ausführlicher Bildbeschreibung als Bug an Railworks gemeldet. Weiß aber nicht, ob das dort im Thoommyland wahrgenommen worden ist. Wer Lämpchen verbaut, sollte zum Speichern IMMER Railworks beenden und die Speichermeldung bestätigen. Dann bleiben die Lampen am Leben.


    Gruß, Jan

    Moin,


    ich darf soviel aus der Nähtüte plaudern, dass es mit dem Update im Moment noch einzweidrei Problemchen gib, die erst geklärt sein müssen, bevor es aufn Server geht. Also bitte noch ein bisschen Geduld, denn im Moment bin ich der Klärer (und das kann *püh* dauern ) ;)


    Grüße aus der Probierküche
    Jan

    Moin,


    du musst wie folgt unterscheiden:


    Ob ein Dingens des Nachts hell ist, dafür ist der am 3D-Modell verwendete Shader verantwortlich


    Objekt mit Textur und Shader TextDiff = nachts dunkel
    Objekt mit Textur und Shader Tex = nachts hell (es wird einfach nicht von der Umgebung beeinflusst)


    Der Zusatz _day / _night (das fx davor kann man sich getrost klemmen) am Objektnamen unterscheidet, ob das eine nur am Tag und das andere nur in der Nacht dargestellt wird. Dabei ist zu beachten, dass es je Modell nur ein Tag- und ein Nacht-Dinges geben kann, sonst funktioniert das nicht. Aber: es lassen sich mehrere Objekte zu einem Tag und zu einem Nachtmodell zusammenfassen.


    Bei den Texturen kann durch den Zusatz _au, _sp; _wi; _su am Dateinamen in Jahreszeiten unterschieden werden. Soll deine Laterne in der Winternacht ein Schneehäubchen tragen und sonst nicht, dann musst du zwei Texturen haben:


    LeuchteInDerNacht.ace
    LeuchteInDerNacht_wi.ace


    Gruß, Jan

    Moin,


    wie beschrieben: du baust den Mast, dat Lämpchen für den Tag und dat für die Nacht. Sie müssen nicht verknüpft werden, es sei denn, eins der Teile wäre animiert.


    Gruß, Jan

    Moin,


    da hast du wahrscheinlich Glück gehabt, dass dich Steam an die Daten mal rangelassen hat. Ich hab die Überprüfung gemacht. Ergebnis: 47 Dateien sind nich en vogue, aber starten lässt sichs immer noch nicht. Na ich denke, morgen früh habe ich bessere Karten... Offline geht es nun auch nicht mehr, weil Railworks nach der Überprüfung jetzt weiß, dass es ein Update braucht.. *ohman*


    Gruß, Jan

    Moin,


    diese Diskussion ist so alt wie jedwede Form der Simulation. Ich mache jetzt seit 20 jahren Add-ons. Bei jeder neuen Flusi-Version ging das Gezeter von vorne los (FS5.1 mit nem 386SX und 16MHz ui ui ui...). Is also nix neues (nur die Leute sind andere). Manchmal glaube ich schon, es gehört zum guten Ton, zu zetern. Ich bin schon mit 2 (!) Fps geflogen und habs auch überlebt. Alles was über 15 FpS ist, ist schneller als ein Super-8-Film aus den 60er Jahren und darf als spielbar gewertet werden. Ansonsten vielen Dank Jim, die Idee mit einer Referenzsituation ist zwar auch nicht neu aber der Diskussion förderlich :P
    Ich denke nach wie vor: wir können froh sein, dass sich die Thommies der Bahn überhaupt angenommen haben sonst würden wir immer noch mit good-ten years old-never get updated-grusel MSTS rumfahren 8)


    Haltet durch :)
    Viele Grüße
    Jan


    PS: wenn es einen MSTS2 gegeben hätte, was denkt ihr, hätte der mit euren Rechnern gemacht???

    Die Grenze zu Sachsen ist erst hinter Petersroda - ein ganzes Stück hinter Lu Wittenberg.


    Übrigens: Niedergörsdorf hat diesen Sommer neue Bahnsteige bekommen, die rund 40m länger als die alten sind und damit endlich für die Züge ausreichen.


    *achtung* Hat jemand Bilder vom neuen Bahnsteig??? (mein Fotoset von dort ist Stand 2008...) *achtung*


    Gruß, Jan

    Erstmals angekündigt wurde die Strecke Berlin - Lutherstadt Wittenberg in der Euphorie des Rail Simulator - nicht Railworks.
    Wegen der bekannten Verkaufszahlen und Mängel des Rail Simulators erfolgten auf die schnell verschwundene Ankündigung keine Taten.

    Moin,


    es war einmal ein Add-on Berlin-Leipzig in einem Ritt für RS geplant, das sollte ich machen da hieß es aber noch, dass Kuju "mitmacht" (Stand Herbst 2006). Dann passierte ne Weile gar nichts bzw die bekannten Veränderungen von Railsimulator zu Railworks und ich habe inzwischen zusammen mit dem TTB 3 Teile Straßenbahn gebaut.


    Seit Juli sitze ich nun ernsthaft am Add-on. Komplett fertig ist der Abschnitt km 19 Gbn einschließlich Cramerkurve, einem Stückchen BAR über Lf, Thy, Tn bis kurz hinter Woltersdorf Hp. Problem ist halt, dass ich auf so gut wie nichts eigenes (Texturen, Objekte) aufsetzen kann, sondern alles neu bauen muss. Außerdem will ich die Strecke nicht mit Englischen Häuschen bestücken, es soll schon so aussehen, wie es in Berlin/Brandenburg/Sachsen/Sachsen-Anhalt aussieht. Jetzt kommt noch ein Satz "Jugend forscht" dazu, wie man die neuen Eigenschaften des TS2012 für sich nutzbar machen kann, da hängt es auch ein wenig daran, wie schnell wir mit Informationen bestückt werden. Ein paar lustige Effektchen mit einigen Shadern habe ich schon gesehen, da müssen dann Dinge im Nachgang wieder geändert werden. Kostet auch wieder Zeit.


    Ich werde euch auf dem Laufenden halten. Ich denke, die ersten Bilder kann man zeigen, wenn Berlin-Stadtgrenze - Luckenwalde fertig gebaut ist.


    Viele Grüße
    Jan

    Moin,


    da themenverwand, will ich das Thema im Thread nochmal aufgreifen. Für meine Beton-Fahleitungsmasten brauch ich Hektometertafeln. Nachdem ich Wiki und Kuju-Guidelines gelesen habe (wo wortwörtlich das selbe drinnen steht, habe ich mit erstens einen Textureset gebaut, der Texturen für die Zahlen 0-9 enthält. Dann habe ich eine Hektometertafel gemaxt und Quadrate draufgesetzt, die 1_0300_primarydigits1..3 heißen 1 mit zwei Quadraten (vorn und hinten) für einstellige Zahl, ...digits2 für die zweistellige Version mit 4 Quadraten und...digits3 mit der dreistelligen Fassungaus 6 Quadraten.. Als Texture habe ich dafür eine Multipart-Texture gebaut und habe die mit Zahlen versehen: 0 für die dritte Stelle, 1 für die zweite Stelle, 2 für die erste Stelle. Die Materialien dazu heißen P_Num_0..2 mit primarynumber_0 - 2.ace. Jeedes der Submaterialien hat als Shader TexDiff . Etwas tricky war es, die Nummern den Rechtecken zuzuordnen: in der Browser list: Mesh select, dort Poly selektiert und dann im Browser Material gerufen und die Nummer des Multimaterials gewählt. (ich fürcht, dass hier der Fehler liegt, habe aber keine andere Idee, den Quadraten eine Texture aus der Multitexturetabelle zuzuordnen...) Das Ergebnis sieht so aus wie in der Wiki beschrieben. Es erkennt auch, wieviele Stellen meine Zahl für die Kilometrierung hat, aber es übersetzt dieZahl nicht in die Texturemap, sondern schreibt nur 210 auf die Tafel. Look here:



    In der Eigenschftsseite habe ich 344 für den Kilometer 34,4 am Asig Trebbin eingetragen.


    Die blueprints für den textureset sowohl als auch für die Hektometertafel übersetzen Fehlerfrei, lediglich das Zuordnen der richtigen Zahlen funzt nicht.
    Ich finde nicht, was ich falsch gemacht habe. Hat jemand ne Idee??


    Viele Grüße
    Jan