SCP-966 ohne NVG sichtbar

  • Nick

    Hat den Titel des Themas von „SCP-966 ohne NVG's sichtbar“ zu „SCP-966 ohne NVG sichtbar“ geändert.

  • wurde bereits ein Bug Report gemacht, welcher anscheinend behoben wurde aber wie es aussieht immernoch ist.

  • mcNuggets

    Hat das Label Nicht reproduzierbar hinzugefügt.
  • Zitat von Nono
    Zitat von mcNuggets

    Reproduktion?

    Meines Wissens nach ist das Ganze so: Sobald der Spieler A vor Spieler B (SCP-966) auf dem Server war, funktioniert es wie gewollt.
    Sollte Spieler A aber nach Spieler B (SCP-966) auf den Server kommen, so kann er SCP-966 auch ohne Nachtsichtgerät sehen.

    Inwieweit hierbei das betreten des Jobs eine Rolle spielt, weiß ich jedoch nicht mehr. Ich meine aber es war unabhängig davon, wann man in den SCP-Job gegangen ist. Auf diese Art ist es reproduzierbar und tritt immer wieder auf.

    Testet es?

  • Das ergibt aber nicht allzu viel Sinn so ziemlich.

    Ist das genauer getestet wurden und ist dieses Verhalten wirklich dadurch reproduzierbar?

  • Aber wieso reicht das eine Mal dann ein Jobchange?

    Das beißt sich mit deiner Theorie.


    Habe mal eine Änderung vorgenommen, die es beheben könnte.

    • +1

    Wie ist das developement technisch den gelöst, 966 Instanzen unsichtbar zu machen?
    Ich würde wie folgt vorgehen, was den Bug vielleicht behebt, denn meine Vermutung ist, das hier tables zwischen Server und Client versendet werden, diese Kpmmunikation aber nur fehlerhaft oder nicht vollständig funktioniert.

    Code
    hook.Add('PrePlayerDraw','Make966Invisible',function(ply)
    if ply == LocalPlayer() then return end
    if ply:getJobTable().command == 'scp966' then
        if LocalPlayer():IsNightVisionOn() == true then
            return false
        else
            return true
        end
    end
end)

    Ich habe mir hier eine Hook zunutze gemacht, mit welcher man das Rendern eines Spielers, dessen Job den command /scp966 hat, auf dem Client verhindert, solange die Nachtsicht aus ist. Die Abfrage für die Nightvision müsste noch abgeändert werden, ich hab keine Ahnung wie das in eurem code gemacht wird.

    Der Code ist komplett Clientseitig und benötigt kein Networking.


    Bei Fragen stehe ich gerne weiter zur Verfügung

    Quellen:

    https://darkrp.miraheze.org/wi…Player/Shared/getJobTable

    https://wiki.facepunch.com/gmod/GM:PrePlayerDraw

    • +19

    Das ohne Networking, weil dein Hook für jeden einzelnen Spieler unendlich oft durchläuft, was durchgehend Performance zieht.

    Außerdem greifst du auf Index Calls zurück, die wohl einer der ineffizientesten Methoden des Cachings sind.

    Ich greife auf lokale arrays zurück, die keine C++ Calls machen müssen.

    Also was ist schlimmer? Ungecachede LocalPlayer Anfragen x Mal die Frame, anschließend gefolgt von 2 Index Calls (potenziell mehr in deinen imaginären Funktionen) und dann noch der Fakt, dass selbst nach all dem, dein Code trotzdem nicht richtig funktioniert, weil keinerlei universell genutzter Wert gesetzt wurde, der definiert, dass dieser Spieler unsichtbar ist, den man abfragen könnte, um zu verhindern, dass 3D2D und HUD Elemente gezeichnet werden?


    Also:

    1. Wieso cachest du LocalPlayer nicht, anstelle tausender C++ Anfragen die Frame?

    2. Wieso fragst du den Job Command ab, statt den Team Index Namen, was millionenfach effizienter wäre?

    3. Wieso nutzt du einen Hook, der zum Resultat hätte, dass absolut nichts funktioniert?


    Wie ich es mache und wieso es millionenfach besser ist:

    Buhu für den 1 Bit Networking der stattfindet (Schweigeminute).

    Abgesehen davon, existieren bei mir nur Abfragen, die nur passieren, wenn SCP-966 existieren und nur anhand der Anzahl der existiertenden SCP-966.

    Dazu kommt, dass mittels eines Werts überprüft werden kann, ob besagte SCP-966 sichtbar sind, das selbe gilt ebenso für die Spieler.


    Der Fehler passiert ebenso nicht im Local Game, sondern nur auf dedizierten Servern.

    Zurückzuführen darauf, dass ein Net Event nicht ausgeführt wird, obwohl es das sollte.


    Den Code komplett clientside zu stellen, wäre viel leistungsintensiver + wir sind ein dediziertes Team aus Entwicklern und wissen bestens Bescheid und brauchen keinen Laien, der uns eine Non-Lösung präsentiert.


    Was hättest du stattdessen tun können?

    Nach dem Code fragen (PRIVAT) und dich actually damit auseinander setzen, statt öffentlich zu prahlen, dass wir es doch schon lange hätten fixen können, was wir wie gesagt for the sake of good and optimised code nicht tun.