Panzer fährt nicht Rückwärts

Passiert das jedesmal, oder nur in geschobenen Stellungen?

Netzwerk, oder Offline-Sitzung?

Im Netzwerk: Wast Du CLIENT oder HOST? (vermutlich ersteres, aber ich hätte trotzdem gerne eine Bestätigung)

Besitzer des Fahrzeugs, oder Gast/Besucher?

Kann das Verhalten mit einem einzigen Zug Ulanen reproduziert werden (ggf. auch von anderen Spielern)?

Hi Ssnake,

Er war Client und "Besitzer" des ULAN! Es war auch für mich das erste Mal eines derartigen Verhaltens, da ich das Szenario mit diesem ULAN bereits mehrfach ohne Beanstandungen gefahren habe, allerdings 4.023.

Habe einen ULAN in einem Testszenario 4.160 als Kdt, RS, MKF und in Außenansicht "gefahren" und derartiges NICHT festgestellt. Könnte also ein kurzzeitiger Systemfehler, Übertragungsfehler oder Bedienungsfehler gewesen sein.

Auch eine kurzzeitige "Signalsättigung" (Feind + Feuerkampf + Beschuss +++) schließe ich nicht aus.

mkG

Ich denke, das ist detailliert genug.

Ist jetzt Bug 7905.

Ich arbeite an der Behebung des Bugs.

Also ich habe den Ulan in einer Netzwerksitzung an einen Abhang gestellt und als gunner versucht rückwärts den Abhang rauf zu fahren und das funktioniert wie es soll.

Kannst du ein scenario mit nur einem Ulan erstellen bei dem das auftritt?

Hi rubi2,

Ich kann Dir das Szenario zusenden.Schreib mir Deine email-Adresse per PM. Alternativ biete ich Dir an, dieses Szenario als Client mal anzufahren; könnten die Zeit dann ja vereinbaren.

mkG

ULAN-Testszenario wurde übersandt!

Bug wurde identifiziert und beseitigt.

Hintergrund: Der Ulan ist unser Prototyp für eine etwas detailliertere Simulaion einer Gangschaltung. Beim Drücken von X wird die Bremse gelöst; am Vorderhang beginnt das Fahrzeug nun vorwärts zu rollen, dadurch wird der Rückwärtsgang nicht eingelegt, aber der KI-Fahrer gibt Gas, und schon fährt man vorwärts. Funktioniert auch im Offline-Modus. Muß man erst mal drauf kommen...

Das klingt spannend. Bislang habe ich den Leuten immer gesagt, SB wäre kein Panzerfahrschulsimulator, wenn ich gefragt wurde, warum der Fahrer so stiefmütterlich behandelt wird.

Ist es auch nicht, wird es auch nicht werden, selbst wenn wir den Auftrag haben, im 1. Quartal '20 ein begrenztes Motion Feedback für den Fahrerplatz einzuführen. Da geht's um die disziplinierung des Fahrers bei taktischer Geländefahrt. Sie neigen derzeit noch dazu, unrealistisch schnell über den Übungsplatz zu brettern.

Es bleibt dabei, daß wir den Fahrer selbst nicht beüben, aber er darf schon ein bißchen mehr gefordert werden. Dennoch muß man festhalten, daß das nur dann und in Einzelfällen wirklich relevant wird, wenn die Fahrerplätze auch hardwareseitig entsprechend ausgerüstet sind (Lenkrad, Pedale, Gangwahlschalter, ggf. dann noch ein Rüttelstuhl). Eine echte Fahrsimulation müßte den Drehmomentverlauf des Motors abbilden, die Übersetzungsverhältnisse der einzelnen Getriebestufen, den Sicherungskasten mit all' den elektrischen Subsystemen, im Leo beispielsweise noch die Tauchhydraulik, Brandlöschanlage, Blinker, Hupe, Licht, Tarnkreise, Batteriespannung im Grobkreis (und deren Abbau im Betrieb, abhängig vom Temperaturniveau (Umgebungstemperatur und Motorrestwärme) und der entnommenen elektrischen Leistung im Zeitverlauf, Druckniveau im hydraulischen Bremsspeicher, die Verlagerung des Fahrzeugschwerpunkts in Abhängigkeit von Turmstellung, Munitions- und Kraftstoffüllständen, Fremdstartkabel, Abschleppen mit Seil oder Abschleppstange, --- und das sind nur die Faktoren, die mir spontan und ohne größeres Nachdenken einfallen. Bei Fennek und anderen mil GL RadFz noch die Reifendruckregelanlage, Differenzialsperre, ein- und zweiachsige Anhänger, ...

Da würde man echt ein komplett neues Faß aufmachen, und wenn man das konsequent auf alle Fahrzeuge anwenden wollte, die wir bislang bedienbar gemacht haben, wären wir auf Jahre ausschließlich damit beschäftigt.

Nein.

Steel Beasts ist eine Gefechtssimulation. Unser Schwerpunkt bleibt, Simulationslücken in diesem Bereich zu schließen. Wo zu Ausbildungszwecken im Einzelfall ein Fahrerplatz ein klein bißchen detaillierter simuliert werden muß als jetzt, werden wir das natürlich tun - weil wir solche Aufträge annehmen müssen, um finanziell ausgeglichen zu sein.

Hab mch schon gefragt wo der Rückspiegel beim Leop 1 herkommt und was er soll.......

Ich sehe das halt nicht ganz so extrem. Ich (und die denke, die meisten im Consumer-Bereich) hätte nichts dagegen, wenn "sowas wie eine Gangschaltung" Einzug in die Simulation finden würde. Auch ohne, dass hardwareseitig alles (oder auch nur Teile) dafür vorhanden ist.

Da du schreibst, ihr müsst solche Aufträge annehmen, schließe ich, dass dir die Idee nicht so gefällt?

Okay, ist auch ein anderes Thema jetzt. Hier geht's ja um den Bug (der mit den nächsten Patch behoben ist).

Wie bei allen Dingen, bei denen man eine Wahl treffen muß, gibt es Elemente die man mag, und andere, die man bereit ist, hinzunehmen. Ich persönlich finde die Arbeit, die wir auf detailliertere Fahrerplätze aufwenden müssen, inhaltlich wenig spannend und als eine Ablenkung von den für die langfristige Produkt- und Firmententwicklung "wirklich wichtigen" Themen; hinzu kommt die mittel- bis langfristige Belastung durch allfällige Wartungsarbeiten. Funktionen, die man einmal eingebaut hat, wird man nur in seltenen Ausnahmefällen wieder los.

Dem Einwurf, daß niemand etwas gegen eine etwas detailliertere Modellierung des Fahrerplatzes einzuwenden hätte, werde ich nicht widersprechen. Ich muß aber das Gesamtbild im Augebehalten. Wir wollen eigentlich einen möglichst einheitlichen Detaillierungsgrad bei den simulierten Besatzungsplätzen und ihren Funktionen, hier haben wir eine deutliche Abweichung. Die wird mit hoher Wahrscheinlichkeit dazu führen, daß andere Kunden jetzt auch eine detailliertere Modellierung wollen. Es zieht also Arbeit nach sich, mit der wir Geld verdienen können (das ist gut), aber die eben auch Arbeitsleitung abzieht von, sagen wir mal, der Umstellung des GUI Frameworks (also der Code-Bestandteile, mithilfe derer wir die Benutzeroberfläche einer Modernisierung unterziehen wollen). Dabei ist eine Verhübschung des GUI nicht einmal der Hauptzweck (auch wenn es für die Vermarktung des Features unabdingbar ist), sondern vor allem, den Wartungs- und allgemeinen Arbeitsaufwand für Änderungen an der grafischen Benutzeroberfläche (drastisch) zu reduzieren, also die Produktivität unseres Teams zu steigern. Denn nur dadurch können wir bestimmte Aufträge annehmen oder zumindest deutlich schneller abschließen.

Für die Zukunft von eSim Games als Firma ist das unendlich viel wichtiger. (Nutzt aber auch nix, wenn wir uns voll und ganz auf sowas konzentrieren und in der Zwischenzeit pleite gehen, weil wir unsere Kunden und deren Wünsche ignorieren.)

Also, es sind solche Überlegungen, die mich da umtreiben.

Bug wurde lt. Release Notes in Version 4.161 behoben.