Rozróżnianie desynchronizacji od celowych działań szkodliwych

[★ WafelTLD]

Witam.

W tym krótkim poradniku opiszę wam jak rozróżnić desynchronizację gracza od faktycznego celowego działania, np. taranu.

Czym jest desynchronizacja?
Desynchronizacja oznacza, że twój klient i serwer nie są zsynchronizowane na tyle, że serwer nie potwierdzi działań twojego klienta. Może to być spowodowane większymi opóźnieniami. Są jednak i inne przypadki, takie jak brak aktualizacji stanu danej czynności. Jeśli twój klient uważa, że przesunąłeś element, ale stan tego elementu na serwerze jest nie zmieniony, możesz widzieć go gdzie indziej, ale faktycznie tam nie jest. Te rzeczy mogą być błędami, ale mogą być również spowodowane utratą pakietów.

Wysoki ping, wysoka utrata pakietów może sprawić, że widzisz rzeczy, które nie mają miejsca. Warto upewnić się, czy tego typu problemy nie występują u ciebie podczas gry.
Każdy ma różny sprzęt, różny internet. Można grać na ziemniaku, ale trzeba mieć świadomość tego, że doświadczenie może nie być zależne od serwera a od wyżej wymienionych czynników.

 

Przejdźmy więc do przykładów takich desynchronizacji.

 

Najpopularniejszy przykład serwera ProjectRPG - Taran
Bardzo często zdarza się, że jesteśmy świadkami lub nawet uczestnikami, kiedy jedno auto taranuje drugie, natomiast tu właśnie warto zauważyć kiedy jest to celowe działanie, a kiedy desynchronizacja.
Celowe działanie wygląda dosadnie i oddziałuje na obie strony, taranującego i taranowanego. Jeśli jedno auto staranuje drugie, to moc uderzenia oddziałuje na oba auta.
Oba się od siebie odpychają, oba wpadają w niekontrolowany poślizg, oba uszkadzają się.

Desynchronizacja natomiast sprawia często, że tylko jedna ze stron oddziałuje w odpowiedni sposób do zdarzenia.
Jeśli osoba taranująca nie oddziałuje na sytuację tarana, auto nie uszkadza się, nie wpada w poślizg i jedzie jakby nic się nie stało dalej prosto bez jakiegokolwiek "zająknięcia" - najpewniej doszło do desynchronizacji.

Często w przypadku desynchronizacji po prostu taranujące auto nie jest naruszone, a osoba taranująca nawet nie wie, że staranowała inne auto w jej otoczeniu.
W przypadku desynchronizacji osoba nie taranuje nikogo celowo.

Przypadek nr. 2 - Przenikanie i blokowanie się drobnych elementów
W wyniku desynchronizacji może być tak, że widząc inną osobę natrafimy na przypadek gdzie postać przenika drzwi, szyby, śmietniki, pudła, beczki i inne ruchome elementy, może to powodować anomalie, np. na strefie DM, gdzie gracz strzela zza drzwi, które są zamknięte, lub wręcz przeciwnie - Gracz, myśląc, że strzela przez otwarte drzwi, może również nie zadawać obrażeń, bo serwer potraktuje je jako zamknięte.
Stanie na ruchomych elementach może powodować w przypadku desynchronizacji lewitację postaci. Jest to rzadkie, ale nie niemożliwe.
 

Rzadki przypadek - Przenikanie przez ściany
Jest to bardzo rzadki widok, ale nie niemożliwy. Postać jadąc pojazdem może z twojej perspektywy przejeżdżać przez ścianę, kiedy realnie tego nie robi.
Taki przypadek często oznacza bardzo mocną desynchronizację, bo realnie postać jedzie w zupełnie innym kierunku.
Można taką desynchronizację odróżnić od bezkolizyjnego pojazdu, jeśli pojazd przenikający przez ścianę nie wpada w ziemię, a teleportuje się nagle.
Zanim zgłosisz gracza za bezkolizyjkę, sprawdź, czy rzeczywiście to był jednorazowy przypadek, czy twój ping jest dobry i czy postać wpada w ziemię, czy jednak nie.


Jak widzicie desynchronizacja może działać na różne sposoby, a wymieniłem tylko te popularniejsze.

 

Bywa czasem, że do desynchronizacji można doprowadzić celowo, poprzez manipulację łączem internetowym lub modyfikując pliki gry.
Jest to działanie ryzykowne i grozi banem!

Obecnie żyjemy w czasach, w których mamy dostęp do nagrywania powtórek, czy to przez oprogramowanie AMD, NVIDIA, OBS, XBOX Overlay, czy MEDAL.
Korzystajcie z nich i nagrywajcie powtórki. Da wam to często bardzo przydatne informacje w razie sytuacji losowych.
Mając powtórkę jesteście w stanie sprawdzić, czy ktoś celowo was taranuje, czy może jednak to była desynchronizacja. Macie wiedzę na temat tego, czy ktoś cheatuje, czy może jednak w wyniku desynchronizacji pojawiła się tylko anomalia.

Wszystko zależy od tego, jak dana osoba zachowuje się po zdarzeniu. Jeśli robi coś bez fizycznej reakcji - często to zwykła desynchronizacja i osoba "szkodząca" nie wie, że do niej doszło.

Edytowane 28 Września przez WafelTLD

[★ InspektorDzordzo]

Solidnie napisany poradnik :3

[★ shvky]

Fajnie, że ktoś to w końcu opisał 🙂 

[★ domi22333]

Bardzo interesujące, przyda się 🙂

[casinoo]

jestem pod ogromnym wrazeniem moje oczy jeszcze  nigdy nie widzialy czegos tak bardzo niepotrzebnego 

[psychoo102]

Doceniam za wkład w napisanie tak obszernego tekstu, ale
 

• Nie każda desynchronizacja jest realną desynchronizacją
• Desynchronizacja w MTA to nie coś co jest, a jest także elementem, który przy odpowiedniej wiedzy można nadużywać, według tego poradnika każdy kto tak robi miałby być niewinny "bo stało się desynchro"

Część rzeczy takich jak np. przechodzenie przez obiekty gracza A u gracza B mogą być zarówno wyznacznikiem "desynchronizacji" w postaci tego, że u gracza A model się nie załadował, ale może też być celowym działaniem (np. podmienianiem plików w taki sposób, aby przez te konkretne ściany przenikać). To samo działa na fakt, gdy dopiero wjeżdzamy w zakres synchronizacji gracza, niektóre rzeczy takie jak np. animacje, jego "stan otoczenia" nie są zsynchronizowane automatycznie z naszym stanem, bo MTA synchronizuje głównie rzeczy takie jak stan postaci (HP, pancerz) czy stan pojazdu (stan uszkodzeń, HP).

W takim przypadku nagranie powtórki nie zmieni nic, bo powtórka jest tym jak świat widzi gracz okiem jego klienta, a to co widzi ktoś inny może być całkowicie innym stanem rzeczy.

Edytowane 23 Września przez psychoo102

[★ WafelTLD]

2 godziny temu, psychoo102 napisał:

Doceniam za wkład w napisanie tak obszernego tekstu, ale
 

• Nie każda desynchronizacja jest realną desynchronizacją
• Desynchronizacja w MTA to nie coś co jest, a jest także elementem, który przy odpowiedniej wiedzy można nadużywać, według tego poradnika każdy kto tak robi miałby być niewinny "bo stało się desynchro"

Część rzeczy takich jak np. przechodzenie przez obiekty gracza A u gracza B mogą być zarówno wyznacznikiem "desynchronizacji" w postaci tego, że u gracza A model się nie załadował, ale może też być celowym działaniem (np. podmienianiem plików w taki sposób, aby przez te konkretne ściany przenikać). To samo działa na fakt, gdy dopiero wjeżdzamy w zakres synchronizacji gracza, niektóre rzeczy takie jak np. animacje, jego "stan otoczenia" nie są zsynchronizowane automatycznie z naszym stanem, bo MTA synchronizuje głównie rzeczy takie jak stan postaci (HP, pancerz) czy stan pojazdu (stan uszkodzeń, HP).

W takim przypadku nagranie powtórki nie zmieni nic, bo powtórka jest tym jak świat widzi gracz okiem jego klienta, a to co widzi ktoś inny może być całkowicie innym stanem rzeczy.

Na jakimś niezabezpieczonym serwerze może i jest to możliwe. Na Projectcie akurat podmienianie delikatnych plików jest zablokowane, tak samo wgrywanie bezkolizyjek, czy custom animacji chodzenia, czy elementów mapy serwera. Są one zabezpieczone tak, że nawet usuwając je z plików serwera, blokując dostęp folderowi, w dalszym ciągu one się wczytują (wiem, bo kiedyś miałem możliwość zobaczenia jak to wygląda).
Fakt, niektóre elementy mapy da się podmienić, ale często wiąże się to prędzej, czy później z crashem gry. MTA nie lubi najmniejszych zmian w plikach SinglePlayera i wymusza Crasha, albo na pierwszym etapie włączania MTA, na pierwszym etapie wczytywania serwera lub w trakcie gry na serwerze w momencie zbliżenia się lub wyrenderowania w oddali podmienionej rzeczy. Nawet najgłupsza rzecz jaką jest zmiana tekstury ubrania CJ potrafi prowadzić końcowo do crashy, więc nie jest to opłacalne do celowego bugowania czegokolwiek, bo mało co jest możliwe do zbugowania w celowy sposób jeśli mowa o podmienianiu plików na tym konkretnym serwerze. To nie czasy bezkolizyjek.

Nawet jeśli zdażyłoby się, że ktoś nadużywałby jakimś cudem i magicznie potrafił manipulować takimi rzeczami, napewno prędzej, czy później ilość "przypadków" zainteresowałaby administrację. Desynchronizacja to nie jest coś co zdarza się 100 razy codziennie, a raz na "ruski rok".

Edytowane 23 Września przez WafelTLD

[psychoo102]

W dniu 23.09.2026 o 20:41, WafelTLD napisał:

Na jakimś niezabezpieczonym serwerze może i jest to możliwe. Na Projectcie akurat podmienianie delikatnych plików jest zablokowane, tak samo wgrywanie bezkolizyjek, czy custom animacji chodzenia, czy elementów mapy serwera. Są one zabezpieczone tak, że nawet usuwając je z plików serwera, blokując dostęp folderowi, w dalszym ciągu one się wczytują (wiem, bo kiedyś miałem możliwość zobaczenia jak to wygląda).
Fakt, niektóre elementy mapy da się podmienić, ale często wiąże się to prędzej, czy później z crashem gry. MTA nie lubi najmniejszych zmian w plikach SinglePlayera i wymusza Crasha, albo na pierwszym etapie włączania MTA, na pierwszym etapie wczytywania serwera lub w trakcie gry na serwerze w momencie zbliżenia się lub wyrenderowania w oddali podmienionej rzeczy. Nawet najgłupsza rzecz jaką jest zmiana tekstury ubrania CJ potrafi prowadzić końcowo do crashy, więc nie jest to opłacalne do celowego bugowania czegokolwiek, bo mało co jest możliwe do zbugowania w celowy sposób jeśli mowa o podmienianiu plików na tym konkretnym serwerze. To nie czasy bezkolizyjek.

Nawet jeśli zdażyłoby się, że ktoś nadużywałby jakimś cudem i magicznie potrafił manipulować takimi rzeczami, napewno prędzej, czy później ilość "przypadków" zainteresowałaby administrację. Desynchronizacja to nie jest coś co zdarza się 100 razy codziennie, a raz na "ruski rok".

Nie ma idealnych zabezpieczeń, a zabezpieczenia MTA nie są jakieś super trudne do obejścia. Nie będę tego udowadniał, bo wolę, żeby nagle 200 osób nie dowiedziało się jak abuse'ować to czego team MTA nie widzi sensu naprawiać, bo zrzuca winę na właścicieli serwerów, aby lepiej ich pilnowali. Gdyby było tak jak mówisz, to wgranie głupiego ENB, czy też innych prostych modów na lepsze tekstury i tak dalej powodowało by brak możliwości wejścia na serwer, a ludzie tak grają. Co prawda każda modyfikacja gry może ją wywalić, ale to jest ryzyko, które bierzesz na siebie chcąc sobie coś zmienić. Desynchronizacja to fakt, nie dzieje się ona 100 razy dziennie, ani nie "raz na ruski rok". Dzieje się ona cały czas, ale nie zawsze jest tak widzialna gołym okiem, wystarczy micro stutter klatek, skok pingu, żeby doprowadzić do desynchronizacji. Technicznie wywołanie tego zjawiska jest bardzo proste, ale nie będę nikomu dawał pomysłów jak mogliby do tego dojść i to wykorzystywać. Desynchronizacja to stan, w którym klient i serwer nie są w pełni zsynchronizowane, jest to częste zjawisko w grach sieciowych ogólnie, ale trzeba też odróżnić rzeczy, które są synchronizowane, a które nie.

[★ shvky]

Poradnik przydatny. W razie jak byś chciał coś edytować, zgłoś się do opiekuna działu. Zamykam