Skrypty rabunku sklepów i banków w FiveM: konfiguracja i projektowanie po stronie serwera

Objaw: gracze robią rabunek sklepu bez policji online, ten sam sklep jest rabowany dziesięciokrotnie z rzędu, lub oszust odpala jedno zdarzenie i otrzymuje całą wypłatę.

Skrypt rabunku to mała maszyna stanów po stronie serwera: sprawdzaj reguły, uruchamiaj, czekaj, płać. Większość exploitów pochodzi z umieszczenia tych kroków na kliencie. Ten artykuł obejmuje bezpieczny projekt i błędy konfiguracyjne, które powodują problemy powyżej.

#Przepływ, który chcesz

Pomyśl o każdym rabunku jako o czterech krokach i uruchamiaj kroki 1, 2 i 4 na serwerze:

1. Start request: klient prosi o rabunek sklepu. Serwer sprawdza liczbę policji, cooldown, odległość i że nikt nie go nie rabuje.
2. Lock: serwer zaznacza sklep jako rabowany i ustawia cooldown.
3. Action: klient gra pasek postępu, hacking lub wytrychanie.
4. Finish: klient zgłasza ukończenie, serwer sprawdza czas, który upłynął i odległość ponownie, następnie płaci.

Klient obsługuje tylko wizualne efekty. Nigdy nie decyduje o wyniku.

#Liczba policji

Wymagaj minimalną liczbę policjantów na służbie, liczoną na serwerze. Skrypt, który czyta liczbę z klienta, lub ze wartości, którą klient wysyła, jest trywialne do obejścia. Kod liczenia znajduje się w setting up a police job. Sprawdzaj to, gdy rabunek się zaczyna, i decyduj, czy należy sprawdzać ponownie przed wypłatą.

#Cooldowny przechowywane na serwerze

Przechowuj stan w tabeli serwera, o kluczu po id lokalizacji:

-- server
-- [id] = { busy = bool, last = os.time(), robber = source, started = os.time() }
local robberies = {}

local function canRob(id, cooldown)
    local state = robberies[id]
    if not state then return true end
    if state.busy then return false end
    return (os.time() - state.last) >= cooldown
end

Dwa szczegóły są ważne:

• Tabela w pamięci resetuje się, gdy zasób restartuje. Jeśli chcesz, aby cooldown przetrwał restart, przechowuj ostatnią godzinę rabunku w bazie danych.
• Ustaw busy gdy rabunek się zaczyna i wyczyść go, gdy się kończy lub gdy rabusnik się rozłączy, lub sklep pozostaje zablokowany na zawsze.

#Nagrody tylko z serwera

Najczęściej występujący exploit to zdarzenie nagrody, które klient może sam odpalić:

-- WRONG: any client can fire this
RegisterNetEvent('robbery:reward', function(amount)
    exports.ox_inventory:AddItem(source, 'money', amount)
end)

Rozwiązaniem jest nie mieć tego zdarzenia w ogóle. Serwer decyduje o kwocie i płaci wewnątrz kodu, który zweryfikował rabunek:

-- server (ox_lib callback)
lib.callback.register('robbery:finish', function(source, id)
    local state = robberies[id]
    if not state or state.robber ~= source then return false end
    if os.time() - state.started < Config.MinDuration then return false end

    local ped = GetPlayerPed(source)
    if #(GetEntityCoords(ped) - Config.Stores[id].coords) > 5.0 then return false end

    state.busy = false
    state.last = os.time()
    local amount = math.random(Config.Reward.min, Config.Reward.max)
    exports.ox_inventory:AddItem(source, 'money', amount)
    return true
end)

Zwróć uwagę na trzy kontrole: ten sam gracz go uruchomił, upłynęło wystarczająco dużo czasu i gracz wciąż jest w sklepie. Odległość po stronie serwera działa, ponieważ serwer zna pozycję gracza z OneSync. Zobacz securing server events i server callbacks dla wzoru.

Ostrzeżenie: nazwa przedmiotu dla gotówki zależy od Twojej konfiguracji. Używaj przedmiotu lub funkcji frameworku, którą Twój serwer używa dla pieniędzy, i trzymaj ją na serwerze.

#Alertowanie policji

Powiadom oficerów, gdy rabunek się zaczyna, z serwera, każdemu policjantowi na służbie:

-- server: send to each on-duty officer you found with your police count
TriggerClientEvent('robbery:policeAlert', officerSrc, Config.Stores[id].coords, Config.Stores[id].label)

Na kliencie dodaj blip i powiadomienie. Możesz również przekazać alert do Twojego zasobu dyspozycji zamiast budowania własnego, co daje oficjantom jedno miejsce dla wszystkich rozmów. Mała opóźnienie lub szansa na cichą alarm sprawia, że rabunek wydaje się mniej skryptowy. Blips są pokryte w creating blips.

#Częste błędy konfiguracji

• Police count set to 0 podczas testowania, a następnie pozostaje to na live serwerze.
• Zakres nagrody zbyt wysoki. Rabunek, który płaci więcej niż godzina jakieś pracy, jest farmowany. Porównaj z Twoim wynagrodzeniem, jak w balancing the server economy.
• Cooldown zbyt krótki. Z kilkoma sklepami i szybkimi cooldownami gracze rotują między nimi.
• Brak sprawdzenia odległości na etapie ukończenia, więc gracz może uruchomić rabunek i zebrać go z całej mapy.
• Potrzebne przedmioty (wytrych, wiertło) nigdy nie usunięte, lub usunięte na kliencie.
• Flaga busy nigdy wyczyśczona po rozłączeniu lub błędzie skryptu.
• Współrzędne skopiowane z innej mapy. Jeśli używasz inne MLO lub mapę, lokalizacja sklepu jest nieprawidłowa.

Testuj z drugim kontem, które nie jest adminem, ponieważ uprawnienia administratora mogą ukryć brakujące sprawdzenie.

#Checklist