Panzer fährt nicht Rückwärts

  • Habe eben beim zocken einen BUG festgestellt.


    Als ich eben im ULAN unterwegs war und ich dann im Feuerkampf stand, wollte ich aus der Richtschützenansicht RÜCKWÄRTS fahren. Leider ist der nach vorne gerollt. In der Kommandantenansicht rollt er rückwärts wenn man auf X drückt. Auch in der Außenansicht. Aber NICHT in der Richtschützenansicht. Dort rollt er nur langsam nach vorne wenn man X drückt.

    Sollte auf jeden Fall mal behoben werden!


    Ob das bei anderen Fahrzeugen auch der Fall ist, weiß ich noch nicht.

  • Passiert das jedesmal, oder nur in geschobenen Stellungen?

    Netzwerk, oder Offline-Sitzung?

    Bitte keine Privat-Nachrichten an mich!
    eMails integrieren sich viel besser in meinen Arbeitsablauf, oder schreibt's gleich ins Forum, OK?

  • Bislang IMMER. Ich war auf offenem Gelände. Keine geschobenen Stellungen.


    War im NETZWERK


    Edit: Im Einzelspieler geht es komischerweise..

    Teste grad auch die anderen Fahrzeuge

  • 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)?

    Bitte keine Privat-Nachrichten an mich!
    eMails integrieren sich viel besser in meinen Arbeitsablauf, oder schreibt's gleich ins Forum, OK?

  • 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

  • Also grad nochmal im NETZWERK probiert.


    Das Problem tritt beim CLIENT ( bei mir) auf . Nicht beim HOST.

    NUR wenn das Fahrzeug (ULAN) an einem Vorderhang steht! Wenn es eben ist oder eben genug ist, dann fährt er auch im RS rückwärts.

    Man muss als RS gefahren sein. Wenn man als RS am Vorderhang steht und ein wenig nach vorne fährt und dann anhält, anschließend auf X rückwärts fahren möchte, rollt der ULAN vorwärts. NUR als RS und NUR wenn man CLIENT ist.

    Die Leos fuhren hierbei normal rückwärts den Hang hoch.


    Hab es auch auf einem kurzen Video aufgezeichnet.

    Kann es dir ggf zuschicken.

  • 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

  • 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...

    Bitte keine Privat-Nachrichten an mich!
    eMails integrieren sich viel besser in meinen Arbeitsablauf, oder schreibt's gleich ins Forum, OK?

  • 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.

    "Dass die Bundeswehr 70 Millionen für ein altes Segelschiff ausgegeben hat, finde ich sehr liebenswert. Wie toll wäre es, hätten sie noch ein paar Millionen Euro für Hellebarden und Katapulte übrig."
    - Peter Breuer (@peterbreuer)

  • 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.

    Bitte keine Privat-Nachrichten an mich!
    eMails integrieren sich viel besser in meinen Arbeitsablauf, oder schreibt's gleich ins Forum, OK?

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



    Behüter und Bewahrer des Andenken an den
    Leopard 1 bei der deutschen Panzertruppe

    Ssnake wrote:


    Quote


    You and Eisen, Sirs, are self-centered, passive-aggressive whiny, rivet obsessed, ungrateful trolls, and I'm having enough of this


  • 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).

    "Dass die Bundeswehr 70 Millionen für ein altes Segelschiff ausgegeben hat, finde ich sehr liebenswert. Wie toll wäre es, hätten sie noch ein paar Millionen Euro für Hellebarden und Katapulte übrig."
    - Peter Breuer (@peterbreuer)

  • 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.

    Bitte keine Privat-Nachrichten an mich!
    eMails integrieren sich viel besser in meinen Arbeitsablauf, oder schreibt's gleich ins Forum, OK?