Das ist eben so wenn man LZB geführt in einen Bahnsteig einfährt an dessen Ende ein Hp0 steht. Die LZB berechnet die Bremskurven mit einer Maximalbeschleiunigung die in der Komfortzone liegt. LZB auschalten ist nicht erlaubt bei sowas. AFB ausschlaten bringt auch nichts da dies nicht die LZB Bremskurve ausser Kraft setzt. Damit muss man halt einfach zurecht kommen wenn man LZB fahren will.
Beiträge von Maik Goltz
-
-
Und für die korrekte AFB Funktion muss nun die LZB doch neu geschrieben werden
.. also nein, sie ist nicht fertig. Und erst wenn die Lok läuft kann der Steuerwagen gemacht werden. Wird also noch ein paar Tage brauchen
PS: wer hat den Titel eigentlich verbrochen "Neues Video...". Es gab noch nie ein Video der 120. Und das hier wird auch gleich wieder weg sein. Die Leute bespitzeln einen jede Sekunde. Ich hab das Video in meinen Kanal geladen, nicht in einen von vR.
-
-
Die AFB-Funktion ist sicherlich sehr schwer nachzubilden. Mir persönlich ist sie aber weniger wichtig, weil sie mir ja die geliebte Arbeit abnimmt
Für die Lok ist es aber wichtig. Die fährt nun mal hauptsächlich mit LZB und AFB und das muss dann auch gut und sauber funktionieren. Aber auch ohne AFB ist das Regelverhalten sehr wichtig. Das war der Kernpunkt der Entwicklung bei dem Modell der es auch ewig aufgehalten hat. Mitlerweile habe ich andere Methoden gefunden beim Scripting die es erlauben das Regelverhalten einer Drehstromlok halbwegs nachzubilden (was er TS eben so hergibt).
@thenilsman die E-Bremse hat dann auch ein EaseIn bekommen. Aber sie muss einfach schneller regeln im TS wenn die AFB an ist, weil es unmöglich ist die zu erwartenden Geschwindigkeiten stets vorauszuberechnen. Der Versuch scheiterte im Stehenbleiben des TS weil die Berechnungen zu lange dauern. Und für die korrekte AFB Funktion muss nun die LZB doch neu geschrieben werden, sonst macht das alles keine Sinn. Aber ich weis mitlerweile auch da wie man es richtig machen muss. Das Problem ist nach wie vor das Debuggen im TS was quasi in eine Tortour endet. Aber wird schon werden...
-
Der Kommentar passt dazu. Die AFB ist doch ein wenig hektisch, treib der mal ein bissel mehr Ruhe ein. Und die Bremse kommt dann hoffentlich schon sachte ins Spiel eingreifend dazu.
Mit einem weiteren Jahr Programmierarbeit wird das sicher zu machen sein
-
Befindet sich ein Wagen im Zugverband der keine PassView hat kommt man nicht über diesen hinaus in die nächsten Wagen mit PassView. Wenn du von vorn nach hinten durchschalten willst, muss jeder einzelne Wagen auf diesem Durchschaltweg eine PassView haben. Ein weiterer kleiner Bug des TS der schon immer da war und den bei DTG keiner wahrhaben will.
-
Passieren kann das dennoch denn das ist ein Rundungsfehler im Code des TS. Es passiert aber weniger wenn man vom äußeren Gleis aus legt. Dabei muss man eben wie AC schon sagt, auf den Radius des inneren Gleises achten. Wenn es dann doch passiert, löscht man den Bogen wieder weg bis zur letzten Gerade und fängt nochmal an. Oft klappt es dann.
-
@Charmed-Life .. aha, und woher hast du eine verlässlichen "Zahlen" so? Natürlich wird das Produkt nur einmal gefertigt. Aber das kostet nicht unbedingt weniger Geld als ein Produkt das mehrfach gefertigt wird. Da sehe ich keinerlei Verlgeich. Der Personal- und Materalaufwand für eine Strecke kann durchaus höher sein als der für irgend ein Produkt aus Plaste dass 2 Mio mal gefertig wird. Aber ist schon recht, die Diskussion darum gehört hier gar nicht hin, denn keiner der Käufer kann das wirklich einschätzen. Aber zu verschenken hat keiner was, auch nicht DTG. Die Normalpreise sind absolut gerechtfertigt.
-
Mit der Grundhaltung "ich kaufe nur noch im Sale" fördert aber auch keiner die Qualität. Wenn weniger Geld eingenommen wird, wird auch weniger Qualität produziert. Je mehr also im Sale kaufen um so mehr schwindet die Qualität der nachfolgenden Produkte oder die Produkte verschwinden ganz weil der Hersteller nicht mehr vorleisten kann. Sollte man auch mal drüber nachdenken wenn man eine Strecke im Sale für 4,95 ersteht. Da bekommt man nämlich deutlich mehr als man bezahlt, auch wenn es natürlich diverse Defizite auf den Strecken gibt. Die Arbeitsleistung die da drin steckt ist mehr als 29,90€ wert. Die Produkte gehen in dieser Branche also schon grundsätzlich zu einem Sale-Preis auf den Markt. Meine Meinung.
-
Die Spekulationen sind doch für DTG das Marketingwerkzeug erster Wahl. Die Kunden wissen nicht was wann wie kommt und der Überaschungseffekt ist meist um so stärker und der beflügelt dann den Kaufwillen. Also je mehr spekuliert wird um so mehr verkauft sich das Produkt nachher
Marketing halt. -
Die Strecke wird nicht bis zum Release des TS2015 zurückgehalten werden. Das macht überhaupt keinen Sinn vom zeitlichen Aspekt gesehen. Das wären gut 4 Monate. In der Zeit bauen die eine neue Strecke um sie als Beigabe oder was auch immer zum Relase des TS2015 anbieten zu können. Bis dahin haben die mit M-GP Massen an Geld verdient. Darauf wird man kaum verzichten wollen. Also morgen oder nächsten DO. Ich tippe auf Morgen.
-
Gute Software lässt sich mit Early Accessethodik nicht erstellen
Das sehe ich aber ganz anders. Denn durch den early Access und die dadurch generierten Einkünfte lassen sich die notwendigen Schritte in der Entwicklung schon vor der Fertigstellung korrigieren und besser planen und somit das Endergebnis, also das Spiel oder die Anwendersoftware, deutlich ausgereifter handhaben. Ich finde das Prinzip gut und unterstütze es auch gern. Heute kann kaum noch wer wirklich gute Software im Keller entwickeln ohne die Hilfe der Ziel-Userschaft.
Die einen pfuschen rum und die anderen entwickeln Software
Mit dem Satz unterstellst du den Anbietern von Early-Access-Software den Tatbestand der Pfuscherei. Das ist leider unhaltbar und sowas möchte man von einem professionellen Softwareentwickler nicht zu hören bekommen. Damit diskreditierst du dich erneut zutiefst. Und ob der Ergebnisse deines professionellen Schaffens um so mehr. Vll solltest gerade du den Gedanken des Early-Access aufgreifen damit deine Software auch so professionell wird wie du sie stets betitelst.
-
Möglicherweise bin ich auch zu ungeduldig (hab gestern nur 16h lang AFB/LZB getestet, das hat aber ja nichts mit Geduld zu tun, neeeein gaaar nicht
) und mir kommen die Nachladevorgänge nur ewig lang vor. -
FPS Begrenzung habe ich auch an, mal auf 30 mal auf 60, je nach dem was ich testen muss. Manche kennen doch das Gestotter von Trainz. Genau sowas habe ich im TS auch. Und mein Rechner ist sauber, läuft absolut stabil, der TS schmiert nie ab (ausser ich provoziere es im Editor). Also was soll das dann sein ausser ein fehlerhafter Streaming Vorgang. Wäre natürlich gut wenn man das rausfinden könnte, mich nervt das zunehmend beim Testen, weil dann immer alles stehenbleibt und rumholpert im Script.
-
In dem Zusammenhang mit dem ChildName fällt mir grad ein, dass man so natürlich auch vorhandene Masten ohne Nodes damit ausrüsten kann. Dazu ein einfachstes Objekt mit eben einer Fläche als Node (NodeName zB "ichmagdraht") bauen und diese dann in den Masten als SceneryBP hängen. Dann einfach die Childobjekte als Node1 und Node2 bezeichnen und im GantryBP dann ChildName: "Node1" und Nodename: "ichmagdraht" eintragen, natürlich für jede Node separat.
-
Der Draht selbst ist ein ganz normales Loft section Blueprint.
.. wessen SpecialCurve aber unbedingt Catenary oder CompoundCatenary sein sein muss.
-
Also ich fahre ja nun sehr viel in diesem TS rum, also wirklich viel mehr als die meisten von euch. Und ich kann dieses Phänomen eigentlich schon genau zuordnen. Mir fällt dabei auch auf, dass es nicht immer passiert, aber in den meisten Fällen. Und das auf ein und der selben Strecke. Bei HH-H bekomme ich das bei jeder neuen Kachel. Da bleibt der TS teilweise 2 Sekunden stehen, wenn er dann fertig ist sieht man die Wälder aufpoppen. Der lädt da also die Bäume, sortiert die Transforms an Die richtigen stellen und zeichnet sie dann. Der gesamte Kram dauert um so länger je mehr von den gleichen Asset-Typen da verbaut sind. Das hat mit den Fähigkeiten der Grafikkarte gar nichts zu tun. Auch nicht mit der SSD. Ich hatte bis vor kurzem meine SSD wegen eines recht alten Raid-Controllers noch im IDE Mode laufen. Nun läuft sie im AHCI und hat das gut 4fache der Transferraten aufzuweisen als zufvor. Aber das Nachladegeruckel ist genau das selbe. Ich denke dass sich einfach zu viele über die Jahren daran gewöhnt haben und es einfach nicht mehr sehen. Man sieht es in vielen Videos von ordentlich zugebauten Strecken auch immer. Am schlimmsten ist es bei mir auf Berlin-Wittenberg und der neuen WCML-Teilstrecke. Das macht kein Spass zu fahren. Das passiert natürlich auch wenn alles runtergedreht ist, denn mit der Grafikeinstellung hat das einfach nichts zu tun.
-
Schon schade, dass man es selbst heute mit dem derzeitigen Wissensstand nicht schafft, solche "Kinderkrankheiten" zu verhindern.
Das bezweifelt ja auch keiner und wird auch gemacht. Der Kern des TS ist aber jetzt 10 Jahr alt und da macht eben keiner mehr was dran. Ist auch zwecklos das zu versuchen, das sehe selbst ich mitlerweile ein ^^. Das muss neu, von Grund auf. Aber das dauert sicher noch ein paar Jahre. Bis dahin ruckeln und stolpern wir eben weiter mit.
-
Mach dir nix draus, das Problem haben alle. Ein Nasa-Rechner bringt beim TS nichts. Der hat seine eigenen eingebauten Limitierungen. In dem Fall ist es das Asset-Streaming, was nicht wirklich Assets streamt sondern Asset-Groups. Wenn also zB. ein großer Wald auf der nächsten zu ladenden Kachel gewachsen ist, dann lädt er nicht Baum für Baum, wie man das vom Streaming erwarten könnte, sondern alles was Baum ist auf einmal, und das führt natürlich zum kurzen Stillstand je Asset-Group. Wenn man dagegen eine Kachel hat auf der aus allen Kategorien von Assets etwas verbaut ist, dann funktioniert das besser, weil jede Kategorie nacheinander geladen wird. Das sind meine Beobachtungen dazu. Da kann man einfach nichts gegen machen. Da hillt weder eine SSD noch ein Superprozessor oder Megaram weiter. Der TS hat einfach die Angewohnheit, während etwas lädt, kurz zu warten. Je mehr geladen werden muss um so mehr wird gewartet und das ist dann das "Ruckeln" beim Nachladen.
-
DOch, bei 170+1 fängt auch die Warnung in der vR Version an. Aber 171 schafft man nur bergab damit, wenn überhaupt. Um den Prüfvorgang auf Funktionsfähigkeit zu testen (kann ja sein dass er gar nicht mehr geht, warum auch immer) einfach in Zugart U > 111km/h fahren.
