• Bugs-/Glitches von dehnen nur wenige Serverbetreiber wissen ! Fixt diese bei euch !

      Zitat von nicohack

      Keiner diese Probleme ist in der 5,0 gefixt ...

      Okay ich stimme dir zu! Dann haben die Devs am Projekt andem ich arbeite anscheinend gute Arbeit geleistet.

      Den Bug mit dem Z inventar shop könnte man bzw fixt man indem man in der fn_virt_buy.sqf eine Abfrage nach

      Code
      _amount = ctrlText 2404; //Line 13

      mit dem Code

      Code
      if(_amount > 20) exitWith {hint "Du darfst maximal 20 Items gleichzeitig kaufen!" closeDialog 0;};

      beheben :)

      EDIT: habe eben erst gemerkt, dass ein Fix schom im Post stand

      Es Könnten sich Rechtschreibfehler eingeschlichen haben [...] Diese Könnt ihr behalten!

      Bei einem Dupe Bug wie beim T Inventar von Fahrzeugen ist es am besten wenn man es so macht das wenn Spieler in deiner nähe sind (20-30Meter) das man T Inventar nicht öffnen kann , zb. auf einigen Servern funktioniert das mit Lagswitch zb. auf Eisenschmiede ist die grenze 10 Meter , deswegen kann man dort dupen , sollte man das auf 20-30 Meter hochstellen timed der Spieler schneller aus als er Dupen kann.

      eazypro man locked das Inventar über den life_server. Bzw. prüft und setzt man die Variable über den Server. Dann muss man da keine Begrenzung in Metern einbauen. Ich empfand die als nervig auf diversen Servern

      Zitat von skyracer2012

      Man kann auch eine fsm machen, welche in einem bestimmten Intervall überprüft, ob das Inventar schon genutzt wird.

      Ja, allerdings wenn man dann einen Lagswitch nimmt, können zwei Spieler gleichzeitig auf das Inv zugreifen.

      Szenario:
      Spieler A: Lagswitch
      Spieler B: Öffnet Inv, nimmt stuff

      Spieler A:(Im Lag): Öffnet Inv, nimmt stuff
      => Beide haben zugriff und können je nach Lag Dupen, da das Inv auf einer parallelen Zeitebene existiert, wenn man so will.
      Erklärung:
      A kann auf das Inv zugreifen, auch wenn die FSM auf seiner Instanz läuft. Der Grund dafür ist, dass die Instanz von A nie/zu spät informiert wurde, dass B auf das Inv zugreift. Aus diesem Grund reicht eine FSM/Schleife/Funktion zur Überprüfung wer auf das Inv zugreift nicht um gegen Lagswitch User vorzugehen. Selbst wenn A irgendwann wieder verbunden ist und dann die neuen Daten erhält, wer auf das Fahrzeug zugreift und dann rausgekickt wird, könnte A es so Timen, dass er die Items nimmt bevor er wieder verbunden ist und hat somit sämtliche FSM/Schleife/Funktion überlistet.

      Wenn man ein PingPong Sys macht:
      Spieler A: Lagswitch
      Spieler B: Öffnet Inv, nimmt Stuff
      Spieler A: Öffnet Inv, -> Ping bekommt kein Pong also wird das Inv nicht geöffnet ggef. kann man einen Internen Counter machen mit DC.

      =>B hat Zugriff, A war nie in der Lage das Inv zu öffnen
      Erklärung:
      Hier ist es so, dass man die Inv-Open Methode so implementiert, dass die Instanz von A einen "Ping" an den Server oder HC schickt um zu verifizieren, dass A noch alle Akt. Daten/Variablen hat, kurz noch eine aktive Verbindung zum Server hat. Der Server "antwortet" dann und das Inv wird geöffnet. (Dieser check wird natürlich auch bei B ausgeführt/bei jedem, jedes mal wenn die ein Inv öffnen)
      PS: Auf de100 hatte ich auch beide System implementiert.

      2 Mal editiert, zuletzt von Lucian (7. Juni 2019 um 21:19)