Beiträge von Maik Goltz

Ahja, du redest also vom F3/F4 HUD nicht vom Führerstand, denn der hat einen Tacho und das ist das Rundinstrument von dem ich sprach. Das im HUD ist kein Rundinstrument sondern einfach nur ne billige Textanzeige in einem ruden Bereich aber ohne Zeiger. Dass diese aber oben Mp/h und unten Km/h anzeigt ist mir mal was gänzlich neues. Das geht eigentlich gar nicht, aber ausschließen tu ich es mal lieber nicht. Die Anzeige ist nicht mal wirklich abhängig vom Fahrzeug. Ist vll wirklich der Mix an Trackrules in der Strecke was grundsätzlich nicht gut ist. Aber das kannst du nicht beheben.

Meine These ist, dass man im Mp/h Bereich losgefaren ist, und dann in einen Km/h Bereich gekommen ist. Da das Fahrzeug in Bewegung war wurde die Anzeige der aktuellen Geschwindigkeit nicht umgestellt auf die neue Einheit sondern nur die andere die die Vzul anzeigt. Sowa einen Mix macht man eben nicht. Das ist aber nicht deine Schuld.

Wenn man mal die ganzen Websites mit Spotterbildern oder der Geschichte von bestimmten Baureihen anschaut, dann merkt man schnell, warum den ganzen "verrückten" (sorry) die Nummern so wichtig sind. Die meisten Nummern sind mit einer Geschichte verbunden. Und ja, diese Jäger und Sammler kennen diese Geschichten und Werdegänge der Nummern und Maschinen gaaaaanz genau. Wann hatte welche diese Nummer und welchen Pupper und welchen Panto und welche Bauchbinden und welche Kekse und und und. Alles harklein genau aufgeschrieben und dargeboten. Und wenn die Modellbahn eben zu teuer wird heutzutage, dann stürtzt man sich auf die virtuelle Bahn und da sind die Nummern nicht weniger wichtig aus dieser Sicht. Mir persönlich sind die Nummern völlig wurscht, da mich die Technik interessiert und nicht wo welche Nummer, eh Lok wann gewesen ist und was sie zum Frühstück hatte.

Zitat von Zugchef

Ist es mir gelungen, mich halbwegs verständlich auszudrücken?

Nein. Wo fährst du denn mit der Lok? Was ist "untere" und was is "obere". Der Tacho der 101 kann nur Km/h anzeigen und dieses Rundinstrument ist für dich das entscheidende beim Zug führen. Wenn du mit der deutschen Lok auf einer Strecke mit Mph fährst, bekommst du überall (F4/F3 HUD) ausser in Fahrzeuganzeigen im Cab (eventuell nicht bei der VZiel Anzeige der neueren LZB Version) auch mph angezeigt. Das kommt von der Schiene und lässt sich so dann erst mal nicht ändern. Baureihe 101 ist auf deutschen Strecken anzutreffen. Sollte es eine deutsche Strecke sein auf der dir Mph angezeigt werden, dann ist was mit der Strecke nicht korrekt.

Nummern, Gummis und Alu, Puffer rund oder eckig und Pantos gehören eben zur Vorbildtreue und werden leider auch sehr genau beäugt (zählbare Nieten). Kann man also nicht ausser Acht lassen.

Wenn das Soundupdate nicht nur den Sound updatet sonder auch andere Sachen dann schon. Ich hab diesen Soundfox nicht und kann das nicht nachsehen. Ist aber einfach rauszufinden. Man muss nur schauen ob die Engine oder Simulations bin da auch drin sind, dann kann man davon ausgehen dass auch da etwas geändert wurde, und das kann natürlich auch verantwortlich sein. Ist aber einfacher die Aufgabe zu korrigieren als hier weiter zu diskutieren wer nun schuld ist.

Ist eben die Frage was dem Freewareobjektbauer wichtiger ist. Dass seine Modelle erwähnt und verbaut werden, oder aber er seine eigenen Ordnerstruktur hat. Beides endet in dem was wir schon haben. Das sind keine brauchbaren zukunftsweisenden Ergebnisse. Eine Strecke gehört in einen Ordner und Punkt. Dann gibts auch weniger Zeitverlust durch Fehlersuche und mehr Zeit für den Gleisbau

Ja Spooner. Ich verweise nochmals auf 95%/3%/2%. Wenn alle Kunden so schlau wären wie ich (Eigenlob stinkt und wird auch grundsätzlich nicht praktiziert im Hause Goltz) dann gäbe es nichts mehr zu tun

Der Kunde von heute will: 24/7 Support, Preise nahe 0 und stets personalisierte Behandlung. Das geht sich nicht überein wenn das Produkt Qualität aufweisen soll. Aber das ist ein anderes Thema. "Verteufelt" wurde hier nichts. Nur als problematisch hingestellt, und das ist es rein technisch gesehen nun mal. Ein wirklich großes Problem machen nur die Leute daraus die nicht 3min auf eine aktualisierte Version der Aufgabe warten können. VR sieht sich hier aber in erfüllter Pflicht. Die Aufgabe funktioniert mit Standardmaterial einwandfrei. Damit ist die Vorraussetzung, die Aufgaben zu verteilen, auch hinreichend erbracht. Es wird ganz schön viel Luft gemacht wegen einem Szenario. Was passiert wohl wenn ein Packen aus 20 Szenarien plötzlich nicht funktioniert auf 3 Kundenrechnern? Dann fliegen Atombomben oder wie? Manche greifen ein bissle zu tief rein finde ich.

Das eigentliche Problem ist das Ziel der PlusPacks. Sie sollen den Standardcontent aufwerten. So weit so gut und sinnvoll. Aber, und da ist eben das ABER, es hätte ein zusätzliches Fahrzeug sein müssen. Nicht einfach dem vielfach verbautem Vehicle den Boden unter den Rädern austauschen. Das kann, aber muss nicht gut gehen. Bisher sind wenige Fälle bekannt die zu Problemen führen, da die Fahrpläne meist großzügig bemessen, oder der KI Verkehr wegen des müden Dispatchers eh relativ seicht zu gange geht. Wenn dann aber mal einer ein straffes Szenario baut mit ordentlich Verkehr und Situationen die genau koordiniert werden müssen, dann kommt das eben vor.

Zitat von Blomi

Was mir aber viel größere "Kopfschmerzen" bereitet, ist die Art und Weise, wie mit den Kunden umgesprungen wird.

Bitte sorgfältig differenzieren an dieser Stelle. Mit Kunden umgesprungen wird nur per Supportmail. Das ist hier nur ein Meckerzentrum. Freddy K. ist kein Mitarbeiter von vR. Er springt also schon mal gar nicht mit wem rum. Ich gehe davon aus, dass er es berichtigt und Ulf zur erneuten Überprüfung, und die muss vorher geschehen, zusendet. Erst wenn es erneut getestet wurde kann es zum Download angeboten werden. Die Mühlen laufen eben nicht immer gerade und schnell. Und dazu kommt eben dass der Fehler kein Fehler war. Es war ein Einwirken eines Paketes eines anderen Anbieters. Dieser hat sich zu der Problematik bisher gar nicht geäußert, muss er auch nicht. Genauso wenig muss sich Anbieter A um Versäumnisse von Anbieter B kümmern. VR muss mit Standardmaterial Aufgaben erstellen und testen. Dies ist so geschenen und hat auch den Test bestanden. Wenn dann ein Standardfahrzeug durch einen anderen Anbieter auf manchen Installationen verändert wird, dann ist das nicht Aufgabe von Anbieter A dies zu richten. Dann kommen wir an den Punkt mit den 4x4 Aufagen, für jede Eventualität eine neue. Das geht nicht.

Ja Ice über solche Möglichkeiten sinniere ich schon lange. Ich wollte aber einfach beginnen und in die 120 einen Kilometerzähler (unsichtbar) einbauen der einen zwingt die Lok nach x gefahrenen Kilometern zur HU zu bringen (also ab zum BW und einmal wieder ganz triggern). Sowas ist auch für ein Skin denkbar. ABER und da sind wir wieder beim Wackeldackel, es gibt keine sinnvolle Möglichkeit den Zustand zu speichern. Da es kein Event "onSzenarioEnd" für ein Fahrzeug gibt, müsste man ständig in eine Textdatei schreiben und das ist eifnach Nonsens. Also fallen derartige Dinge flach. Das andere Problem ist auch dass die Lok ja immer die selbe ist. Egal wo sie gerade fährt. Also würde die Spielerlok vll dreckig sein aber der Rest fährt im Normalzustand rum. Solang es keine Möglichkeiten gibt den Zustand eines Fahrzeugs zwischenzuspeichern, bringt das alles gar nichts.

Ice, ich stimme persönlich ja zu dass ein dirty Modell einfach naturgemäßer ausschaut. Darauf habe ich selbst auch bei vR wenig einfluss denn Ulf baut die Modelle, und zwar ohne Fototexturen weil das keine vernünftige Basis ist.

Aber hier geht es nicht im ein Repaint, sondern um automatisch umgeschaltete Skins. Da eine Lok eben aus mehr als nur einer TexturNode besteht ist das halt erst mal so nicht möglich. Ein Repaint bekommt ja immer eine neue Bin drunter und der User muss sich selbst aussuchen welche Lok er hinstellt. Das RandomSkin hat aber etwas anderes zum Ziel und das passt eben bei Güterwagen recht gut. Es geht darum dass Züge bestehend aus Wagen gleichen Types immer anders aussehen und man sich als Szenariobauer nich um die vernünftige Mischung des Zuges kümmern muss.

Stimme ich mal noch extra zu was StS und Ice sagen. Der TS2013 ist nun mal ein Wackeldackel. Je nachdem wie die WinDose (gemeinhin PC genannt) grad liegt so hängt dem der Kopf rum. Steht alles gerade ist auch der Kopf gerade. Mir stürtzt der hier nie ab. Zumindest nicht ohne Grund. Gründe sind Fehler bei der Entwicklung der Fahrzeuge, welche natürlich behoben werden bevor es das Haus verlässt. Mein System ist nicht das allerneueste (i7 auf 1366 mit 6gb TrippleChannel Ram und ne betagte GTX 560ti) aber sehr stabil. Und wenn das System stabil läuft dann auch der TS, WENN da nicht der verbrochene Murks so mancher Strecken wäre. Und da sind wir eben wieder am Anfang. Bitte was diese Sache angeht, auch wenns weh tut das zu sagen, ein ernsthaftes Beispiel an RSC und deren Streckenordner nehmen. Das hat System, Sinn und ist Stabil.

Das kann man nicht mit dem was TrainStore gemacht hat vergleichen. Die Problematik war im MSTS eine ganz andere als jetzt. Der TS2013 lädt nur das was in einer Strecke auch verlinkt, also eingebau ist wirklich als Objekt in den Speicher. Es gibt auch keine globale Datenbank, welche beim MSTS der Grund ist warum das Auslagern hilft. Wenn man im TS2013 alles rausschmeisst was nicht zu einer Stecke gehört, dann lädt der genauso viel wie vorher. Was hier bei den Leuten passiert die dann plötzlich manche Strecken laden können, ist dass als Blueprint Prelaod definierte Ordner einfach nicht mehr da sind. Sie sind aber in der RouteProperties noch eingetragen, und genau dort liegt der Hase. Aber das sagte ich schon mal. Nur irgendwie versteht das keiner wo das Problem wirklich liegt. Einfach was löschen ist keine Lösung, nur ein Aufschub oder Abwälzen der Problematik auf User. Man braucht im TS2013 keine Programme die irgendwas auslagern. Alleinig der korrekte Streckenbau ist entscheidend.

Aufgrund des Aufbaus der Modelle wird dies nicht möglich sein. Bei Güterwagons ist die Außenhülle in einer Textur abbildbar, bei einer Lok oder Personenwagen leider nicht. Die Technik dahinter schalten eine Textur in einem Child an oder aus. Bei mehreren zu schaltenden Texturen in einem einzelnen Child wird die Sach nicht lange funktionieren da die Komplexität immens steigt und Komplexität mag der TS2013 nicht.

Die Debatte kann an der Stelle benedet werden da selbst der Raildriver keine wirkliche Lösung darstellt und weitere Möglichkeiten sind nicht vorhanden.

Ja Nobsi, Schmiere ist das passende Wort für das User I/O des TS2013. Besonders hübsch wenn man mit der Maus im Wackelcab versucht einen "schmierenden" Schalter mit mehreren Positionen zu bedienen. Einfach nicht wirklich möglich. Man bräuchte so einen mechanischen Raildriver, den man einfach auf die Tastatur stellt und der dann statt Befehle zu senden, bestimmte Tasten drückt. Quasi so ne Enigma auf TS

Tasten entprellen.. den find ich gut. Ich entprelle auch bald.

Aber das Problem ist ja eingebaut in den TS. Sobald man die STRG Taste loslässt, aber die T Taste noch Kontakt hat, interpretiert er die als gerade eben gedrückt. Der Prüft also nicht ob die Taste vor dem Drücken auch in Ruheposition war oder gar mit einer anderen Taste in Kombination gedrück wurde, nein, er jongliert mit allen Tasteneingaben sofort rum. Eigentlich müsste er die Eingabe sperren bis die Taste T in Ausgangsstellung ist wenn sie vorher mit STRG betätigt wurde. Tuts aber nich. Da kann man auch nichts löten.

Ich habe das gerade nochmal genau provoziert und mir die ganzen Werte dabei ausgeben lassen. Also es passiert folgendes. Lässt man die STRG Taste los bevor die Taste T ihren Kontakt verloren hat (Key Up), wertet der TS die Taste doppelt aus (einmal als STRG+T und einmal als T) und öffnet die Türen wieder. Das passiert deswegen, weil die Türen direkt nach dem Pfiff für den TS schon zu sind, lediglich die Animation wird separat und verzögert angestoßen. Das geht leider nicht anders da man keinerlei Einfluss auf die Türkontrolle des TS hat. Die Türen lassen sich auch nur mit dem Druck auf T oder im HUD öffnen, nicht mit einem Taster im Cab. Das bedeutet dass in den nächsten Fahrzeugen mit Türsteuerung der Schließbefehl auf eine andere Taste wandern muss um diese provozierbaren Probleme zu vermeiden.

Achte mal auf deine Framerate. Ist diese sehr niedrig, musst du die Tastenkombi länger drücken, da es dann länger dauert bis der Schalter in seine Endposition gelangt. Das ist ein Umstand dem man leider nicht entgegnen kann als Entwickler. Wenn man weit unter 20 fps hat werden alle Schalter und Hebel, die etwas langsamer eingestellt, sind sehr träge.