Der Streckenbauer erschwert die Installation aber leider auch massiv durch die üppig vorhandenen Dependencies. Fehler sind dadurch (vor)provoziert. Ein "Let's Play" Ersteller ist genau so ein User wie jeder andere und reflektiert die Probleme die bei der Installation mit solchem Asset Wildwuchs entstehen. Darüber sollte auf Entwicklerseite stets nachgedacht werden. Die Problemkette bei solchen Installationen kann sich auch über den Zusammenhang mit der Strecke selbst hinaus erstrecken und anderweitig Schaden anrichten. Es gibt einen Grund warum sich die meisten Strecken in einem einzigen Produktordner "verstecken". Tun sie dies nicht, passieren Dinge wie bei SAD's Streckenmischmasch aus Altenburg-Wildau und dem Köblitzer Bergland. Als Kunde der PayWare Version kann man sich mit der Deinstallation der Freeware die Strecke zerstören. Und hier ist nur eine einzige Abhängigkeit vorhanden. Bei 23 Abhängigkeiten ist das Ausmaß der Zerstörung am Ende so groß, dass das Spiel komplett gesäubert werden muss. Zugunsten der Anwender sollte diese Tatsache zukünftig beim Streckenbau unbedingt berücksichtigt werden (das ist eine Empfehlung).
Beiträge von Maik Goltz
-
-
Interessante Thesen und Spekulationen. Die Glaskugeln glühen.
würde vR seine direkt verkauften AddOns direkt mit einem Pfad versehen, der den Anforderungen von RSC/Steam entspricht
Das sagt sich einfach und ist nicht einfach. Das hat weitreichende Konsequenzen welche dem Kunden nicht gefallen werden.
Eine Entscheidung wie die Produkte verkauft werden liegt alleinig bei deren Hersteller und sollte nicht von den Kunden spekuliert werden.
-
Am Ende is schon mal falsche Bedienung der Fehler. Bei Überfahrt 500Hz aktiv 65/kmh absenkend auf 45km/h innerhalb 153m sonst Zwangsbremsung. Das ist der Grund der ersten Bremsung nach dem BkSig. Die nächste ist mit 38km/h zu schnell. Wechselblinken ist aktiv, also restriktiv überwacht und das bedeutet bei 500Hz aktiv 25km/h sofort sonst Zwangsbremsung. Das muss man wissen wenn man auf ein Hp0 zufährt. Blinkt es im Wechsel muss man vor dem 500er auf 25km/h sein.
Warum die 500er scharf sind bei den Vr1 ist aus dem Text ja nicht ersichtlich. Da müsste man auf der Strecke direkt nachschauen. Falscher Einbau ist nicht ausgeschlossen, aber auch falsche Funktionen an den Magneten oder Signalen sind nicht unmöglich. Bei unseren Test taten die Magneten sowas nicht und sie wurden ausgiebig getestet.
Außerdem sollte die BR101/403/402/294/218 nicht als Referenz hergezogen werden für PZB Tests. Diese Implememtierungen sind einfach falsch. Der Taurus von HRQ wäre da noch die beste Wahl wenn kein vR Expert-Line Fahrzeug zur Verfügung steht. Die Magnete machen nichts weiter als Signalzustände erfassen und zu reagieren. Den Rest muss das Fahrzeug berechnen und wenn das nicht stimmt dann stimmen auch die Ergebnisse nicht.
-
Bei Version 3 sollte es keine Probelem mit den Scheibenwischern geben. Eventuell mal das ganze Paket deinstallieren, neu installieren und anschließend den Cache leeren.
-
Bitte die letzte Version aus dem Kundenaccount des vR Shops laden und installieren. Dann werden die Regentropfen auch wieder weggewischt.
PZB kann nur eingeschaltet werden wenn das Fahrzeug steht und aufgerüstet (Stromabnehmer hoch) ist.
-
Ja wie denn?
Entsprechend der Richtlinen welche man einsehen kann.
Auf der BR 101 funktioniert sie so wie sie funktionieren soll
Tut sie nicht. Bitte nochmals die Richtlinien lesen und dann prüfen. Sie geben sich als Entwickler aus und sollten wissen wie man sich etprechend informiert und dann auch erkennt, was an der implementierten Funktion falsch ist.
Fährt ein Zug in einem Block und ich komme mit 200 Km/h hinterher, meldet mir die LZB runter auf 0 Km/h
Und das tut es auch wenn der LZB geleitete Zug nur 1km vor dieser Gefahreneinleitung ist. Somit hat der Zug 1000m um von 200km/h auf 0 Km/h zu entschleunigen. Und, das sollten Sie als Entwickler wissen, denn Sie informieren sich bevor Sie etwas als Wahrheit verbreiten, geht nicht und ist nicht mit bahnbetriebstechnisch sicheren Abläufen vereinbar. Auch in TS2013 ist es kaum möglich einen solchen Bremsweg einzuhalten. Aufgaben mit derartig falschem Verhalten wurden beim aktuellen ICE-2 Paket freundlicherweise mitgeliefert.
Was soll denn da anders funktionieren
Abermals bitte die Richtlinien lesen und verstehen. Eine Zugeinleitung auf eine LZB Fahrt wird nicht stattfinden. Zumidest nicht ohne entsprechend großzügige zeitliche Abstände. Dazu besteht eine LZB aus gleichmäßig angeordneten Blöcken und nicht aus unregelmäßig aufgestellten Signalen. Eine Zugleitung ist nur möglich wenn es einheitliche Vorgänge gibt. So kann eben im Vorbild kein Zug unabsichtlich in eine aktive LZB Fahrstraße eingeleitet werden da die LZB Rechner dies verhindern werden. In TS2013 ist dies möglich. So lange sich Signale/Züge aus einleitenden Gleisen nicht an der LZB orientieren, was bedeutet dass die Simulation erkennen muss ob sich im Bremswegabstand ein Zugverband nähert, ist eine solche Funktion nicht als LZB zu betiteln. Dazu kommt, dass die "Sichtweite" der fahrzeugseitigen Implementierung unregelmäßig und unvorhersehbar schwankt, da die aufgerufene Methode nicht korrekt implementiert ist.
und natürlich entscheidet der Designer einer Page, was er wie gestaltet
Nach gängigen und aktuell gültigen Webstandards und Fachmeinungen ist dies nicht der Fall. Der User entscheided wie das Web aussieht und zu funktionieren hat. Der Entwickler orientiert sich am Userverhalten. Denn der User ist der Endpunkt der Kette und das wichtigste Glied im Web, denn er ist das Target der Entwicklung einer Seite, sofern es keine B2B Anwendung ist. Java ist als Clientanwendung im Webbereich seit 10 Jahren nicht nur rückläufig sondern auch verschrien, und deswegen sollte es nicht eingesetzt werden. Moderne Websites basieren clientseitig auf HTML und JavaScript (was viele gern mit Java verwechseln, beide Sprachen haben aber nichts gmein), nötigenfalls etwas Flash oder Silverlight, aber definitiv keine Java driven Frontends. Java wird maximal serverseitig zur Generierung der HTML/JS Ausgaben verwendet und da ist es auch ein durchaus gängiger Standard weil flott und funktionsreich (JSP).
Ach so. Sorry es gibt ja Menschen die können keine Maschinensprache
Falls Sie auf Konfrontation aus sind, so dürfen Sie sich als enttäuscht betrachten. Der Ihnen sicher geläufige Rückgabewert der Funktion "ParseIncomingChallange()" ist void.
-
Das stimmt so nicht ganz. Die Magnete waren schon immer auch in eine Strecke einbaubar. Die Funktion derer hat sich mit dem Update nicht verändert. Lediglich das Aussehen ist erneuert worden. Dass die Magnete nur mit Fahrzeugen mitgeliefert wurden lag daran, dass diese in Aufgaben dazu verbaut waren, was dem Umstand geschulded war, dass die vorhandenen Strecken schlecht ausgerüstet waren/sind.
-
Nicht ganz ausreichend, denn es geht darum welches Signal genau, welche Strecke, die Einbausituation also. Dass ein 500er vor einem Hp1 scharf stellt kann nur ein Fehler beim Einbau sein. Die funktionieren vor den HV Signalen eigentlich wie es zu erwarten ist. Die Tests wurden ja sicherlich nicht aus dem Editor heraus direkt gestartet, denn dann kann sowas vorkommen da die Signale nicht richtig initialisieren.
Dass ein Neuladen einer Aufgabe, ohne den TS zu schliessen, zu einem SBH führen kann ist bekannt und deswegen sollte man nach einer Aufgabe den TS immer komplett schließen und neustarten.
-
Can you please explain the situations more detailed.
-
Das ist eure 143EL! Funktioniert aber eben nicht, deshalb hatte ich im Aufgabenstart beschrieben das man in die Lok soll zum Aufbügeln
Was eigentlich nicht sein kann, denn die Lok bügelt sich allein auf. Da ist also etwas nicht stimmig. Müsste gegebenenfalls getestet werden. Die Strecke liegt ja vor. -
Die BR143 aus dem vR S-Bahn AddOn wird automatisch aufgerüstet da es keine Expert-Line ist. Hier wurde wohl die TTB Version hinter die S-Bahn Wagen gespannt und die muss man manuell in der Lok aufrüsten (so wie das bei der echten Bahn auch normal ist).
-
Der Cache ist ein ObjectCache. Bezieht sich also nur auf Fahrzeuge und Strukturen aus 3D. Strecken, Aufgaben und Properties werden nicht gecacht. Warum die Szenarien irgendwann nicht mehr funktionieren ist bisher unergründlich. Der Cache ist daran aber unschuldig. Möglicherweise gibt es eine Diskrepanz zwischen SzenarioProperties und SzenariBin oder Save. Ist aber unwarscheinlich da die Mapper dort nicht erfasst sind.
-
Händisch aus dem RBlueprintSetPreLoad der SzenarioProperterties.xml löschen.
-
dennoch ist die Antwort unbefriedigend, kann ich nichts dagegen tun?
Leider nicht. Das Problem ist schon immer vorhanden und taucht nur bei Fahrzeugen mit eigenen InputMappern auf. Ab dem Zeitpunkt ab dem die Aufgabe nicht mehr funktoniert weil das Fahrzeug nicht mehr funktioniert, ist die Aufgabe verloren und muss neu erstellt werden. Das Leeren des Cache führt dabei auch nicht zum Erfolg. -
Austausch von Fahrzeugen mit eigenem InputMapper in bestehenden Aufgaben kann zur Nichtfunktion der Tastatursteuerung führen. Unlängst bekannt. Hier hilt nichts weiter als die Aufgabe neu zu bauen.
(in der Annahme dass das Fahrzeug hier mit Tools getauscht wurde oder ein Update nach dem Erstellen der Aufgabe erfuhr)
-
vR Robot möchte aus Erfahrungen mitteilen:
Der erste und größte Fehler ist die Herangehensweise an solche Großprojekte. Womit man direkt bei der Anwort auf folgenden Zitate angelangt:
....wenn um generell dahier um Hilfe gebeten wird, kommt meist nix bei raus.....
...das die ersten mit "Experten mit Fehlermeldungen" daher kommen, wo man sich fragt, wieso gewisse Leute bei Entwicklungen und Test`s nie mit machen...
Unstrukturierte Projekte sind für Experten uninteressant. Es geht um Effizienz und Nutzen und natürlich Zeit und brauchbare Ergebnisse. Experten unter den Freeware Contenterstellern sind selten und meist verschlossen und arbeiten für sich allein. Alle anderen bauen einfach drauf los, mit dem Ziel Irgendwas auf die Beine zu stellen und zu verteilen, wie auch immer das Ergebnis aussehen mag. Das ist eine Tatsache und kann vor allem an vielen Freewarestrecken einwandfrei nachgewiesen werden. Überschätzung der eigenen Fähigkeiten ist hier an der Tagesordnung. Das ist aber nicht unbedingt das Problem.
Streckenbau ist kein Kinderspiel, und wenn doch dann ist es keine gute Arbeit. Streckenbau muss aber auch unterteilt werden in Bahntechnik und Gelände/Landschaft/Gebäude. Dazu gesellen sich noch die Activities die eine ganz andere Anforderung haben und sich wieder in Richtung Bahntechnik bewegen, aber auch Kreativelemente beinhalten.
Es gilt auch hier: zu viele Köche verderben den Brei. Aber, zu wenige auch. Wer meint einen Strecke komplett alleine bauen zu können und dabei bestmögliche Ergebnisse, abstrahiert aus den Möglichkeiten der Software die zu Grunde liegt, zu erreichen, der irrt gewaltig. An dieser (laut Topic) Strecke ist genau das einwandfrei zu erkennen.
Der Robot erlaubt sich keine Meinung darüber, er stellt aber Tatsachen fest. Der Ersteller der Strecke hat ohne Vorkenntnis einfach angefangen. Statt zuerst Erkenntnisse zu sammeln und diese später in einem Neubau zu vereinheitlichen, hat er Fehler verschleppt und diese final dargeboten. Vor allem im Gleisbau und in Signalisierung, den Grundbausteinen der Bahnsimulation. Das ist nicht weiter dramatisch, da der Ersteller ganz offensichtlich von Bahntechnik, Gleisbau und Signaltechnik nichts versteht. Dafür ist die Strecke landschaftlich gut ausgebaut denn darauf versteht er sich. Hier hat also der eine Koch zu wenig am Brei gerührt. Das Ergebnis ist somit, zumindest für Bahntechnik interessierte, unbefriedigend und aufgrund von Gegebenheiten des Grundprogramms auch endgültig und somit nicht interessant.
Der ideale Ablauf für den Streckenbau wäre folgender (grob skizziert):
- Auswahl der Strecke (final)
- Erkundung der Gegebenheiten (getrennt in Bahntechnik und den Rest ... muss nicht vor Ort sein)
- Machbarkeitsanalyse anhand der Möglichkeiten des Simulationsprogramms
- Machbarbeitsanalyse anhand der Fähigkeiten des/der (mutmaßlichen) Streckenbauer/s
- Zeitplan erstellen (grob abstecken nach Fähigkeitsanalyse geteilt in Gleisbau + Streckenbestückung + Aufgaben + Tets + 3 bis 6 Monate Puffer)
- Erstellung der Grundlagen im Simulator (Struktur, Streckendateien, Gelände, Decals, weitere Hilfsmittel)
- Gleisbau (1 Person mit fundierten Kenntnissen und Verständnis von Bahntechnik und der Simulationssoftware)
- Signalisierung (ebenfalls 1 Person mit fundierten Kenntnissen, idealerweise der Gleisbauer selbst)
- weitere Gleis bezogene Arbeiten wie PZB, Hektometertafeln, sonsticke gleisverbundene Streckenmöbel
- Testen der Gleisanlagen in allen möglich erdenklichen Situationen vom Gleisbauer und Signalisierer selbst
....während des Gleisbaus kann die Vorarbeit im Modellbau abgehalten werden (Modellbauer, nicht der Gleisbauer denn der hat den Kopf voll)
- nach Fertigstellung der Bahntechnik beginnt die Ausgestaltung mit Modellen und Landschaft
- nach Ausgestaltung prüft der Gleisbauer die Strecke auf enstandene Fehler an der Bahntechnik während der Ausgetaltung
- Szenarioerstellung samt Tests
... resultierend wird der Signalisierer noch mehrfach nachbessern oder korrigieren müssen
- Test durch externe Tester mit Sachverstand (keine Leute mit rosa Brillen welche nur testen weil sie die Strecke zuerst haben wollen)
- Nacharbeiten aller beteiligter Streckenbauer anhand Fehlermeldungen der Tester (sortiert und koordiniert)
- erneuter Test (while false)
- möglicherweise ReleaseVerteilter Bau während der Erstellung der Gleisanlagen ist rein
technisch gesehen machbar aber sollte bei TS2013 unbedingt vermieden
werden. Die Fehleranfälligkeit ist zu hoch und die Fehler können kaum
korrigiert werden und verbleiben zwangsweise im Endprodukt.Fazit:
erst die Gleise bis zur letzen Schraube samt Signalen und anderen
gleisverbundenen und Ablauf steuernden Dingen erstellen, testen, testen
und wieder testen und erst danach die Ausgestaltung (Optik). Andere
Vorgehensweisen führen zum Fehlergebnis.So wird man die meiste negative Kritik vermeiden. Fehler sind aber oft unvermeidbar. Die Frage ist letztendlich welche Fehler heutzutage noch tolleriert werden sollten. Dabei spielt es keine Rolle ob es sich bei der Strecke um Freeware oder Payware handelt. Bahnsimulation ist Anspruchsvoll und beherbergt tiefe Stolperfallen die sich oft in schlechter Kritik ausdrücken und den Streckebauer in Depression versetzen weil er sich Bienchen statt Schlägen erhofft hat. Ein Blick auf Freewarestrecken aus einer anderen Bahnsimulation zeigt auf wie es sein kann.
(Dieser Beitrag ist Meinungsfrei)
-
Da hat sicher der Fehlerteufel im PDF niedergelassen. Das "Vr1/Vr2" sollte "Vr0/Vr2" lauten. Dann stimmt der Zusammenhang. Aber wer PZB auf Strecken ausrüstet, sollte diese Grundlagen bereits verinnerlicht haben. Die Anleitung ist nur aus kosmetischen Gründen beigelegt und im Eilzugtempo erstellt worden.
-
Die Ursprüngliche Frage hatte keinen Support relevanten Hintergrund.
aber offensichtlich auch ein Vollprofi. Das ist eine typische Antwort auf eine support-Anfrage, wie man es gewohnt ist. Respekt.
Beleidigung : return(void)
-
-
Der Mensch darf schon ruhig aufgeklärt werden. So einige verstehen grundsätzlich die Materie falsch. Deswegen gibt es ja den vR Robot. Er klärt auf und sagt was richtig ist. Spekuliert wird an der Börse.
Zur Urheberrechtslage bei vR/GR Produkten ist festzuhalten, dass 3D Modelle in Urheberschaft von Ulf liegen da er sie bei GR gebaut hat. Somit obliegt ihm das Recht die Modelle (3D Source Dateien) auch weiter zu verwerten. Anders sieht es bei den daraus resultierenden Produkten aus. Also hier die AddOns unter dem Label GR. An diesen hat vR keine direkten oder alleinigen Urheberrechte zur freien Weiterverwertung. Diese liegen nach wie vor bei GR. Das muss man deutlich unterscheiden. Deswegen ist es vR auch nicht möglich den Verkauf von alten GR Paketen zu verhindern. Es fehlt die rechtliche Handhabe gegenüber den Vertriebswegen die seinerzeit eingeschlagen wurden. So kann Aerosoft nach wie vor GR AddOns verkaufen. Oder der Albo Medien Verlang kann in Zusammenarbeit mit Aerosoft auch GR Produkte kostenlos beilegen. Das hat alles mit vR nicht zu tun.
