Własność sieci | Dokumentacja – Centrum twórców Roblox

Aby wspierać złożone mechanizmy fizyczne, dążąc jednocześnie do płynnego i responsywnego doświadczenia dla graczy, silnik fizyki Roblox wykorzystuje rozproszony system fizyki, w którym obliczenia są rozdzielane pomiędzy serwer a wszystkich połączonych klientów. W ramach tego systemu silnik przypisuje własność sieci fizycznie symulowanych BaseParts do klienta lub serwera, aby podzielić pracę obliczania fizyki.

Klienci doświadczają bardziej responsywnych interakcji fizycznych z częściami, które posiadają, ponieważ nie ma opóźnienia w komunikacji z serwerem. Własność sieci poprawia również wydajność serwera, ponieważ obliczenia fizyki mogą być rozdzielane pomiędzy poszczególnych klientów, co pozwala serwerowi priorytetować inne zadania.

Własność BasePart

Domyślnie serwer utrzymuje własność każdego BasePart. Dodatkowo serwer zawsze posiada zakotwiczone BaseParts, a ich własności nie można zmienić ręcznie.

Na podstawie zdolności sprzętowych klienta oraz bliskości postaci gracza Player.Character do niezatrzymanego BasePart, silnik automatycznie przypisuje własność tej części do klienta. W ten sposób części blisko postaci gracza mają większe szanse na zostanie przez niego posiadane.

Własność zespołu

Jeśli mechanizm oparty na fizyce nie ma zakotwiczonych części, ustawienie własności na zespole w ramach tego mechanizmu ustawia tę samą własność dla każdego zespołu w mechanizmie.

Jeśli zakotwiczysz pojedynczy zespół, który nie jest częścią szerszego mechanizmu, jego własność przechodzi na serwer, ponieważ serwer zawsze posiada zakotwiczone BaseParts. Po odkotwiczeniu tego samego zespołu, jego wcześniejszy stan własności zostaje utracony i wraca do automatycznego zarządzania przez silnik.

Jeśli zakotwiczysz jeden zespół w ramach szerszego mechanizmu zespołów, jego własność przechodzi na serwer, ale własność innych zespołów pozostaje bez zmian. Od kotwiczenia tego samego zespołu przywraca jego wcześniejsze ustawienie własności.

Ustawienie własności

W grach z złożonymi interakcjami fizycznymi lub w przypadkach, gdy musisz przypisać bezpośrednią kontrolę, możesz ustawić własność przez wywołanie po stronie serwera BasePart:SetNetworkOwner().

Podczas gdy możesz ręcznie wywołać SetNetworkOwner(nil) dla serwera w przypadku obiektów krytycznych dla rozgrywki, którymi klient nie powinien móc manipulować, powinieneś to robić ostrożnie, ponieważ może to prowadzić do drżących interakcji fizycznych dla klientów.

Należy również pamiętać, że serwer zawsze posiada zakotwiczone BaseParts, a ich własności nie można zmienić ręcznie.

Rozważ pojazd, który ma obiekt VehicleSeat dla kierowcy i obiekt Seat dla pasażera, przy czym oba są zawarte w zespole pojazdu. Z domyślnymi zasadami własności, jeśli postać gracza usiądzie w Seat (pasażer), a następnie inny gracz wskoczy do VehicleSeat (kierowca), pasażer zyskuje fizyczną własność całego pojazdu, ponieważ wszedł pierwszy. Kierowca musi czekać kilka cykli sieciowych, zanim jego wejście zostanie rozpoznane, a pojazd będzie wydawał się mniej responsywny.

Poniższy Script naprawia to, przypisując ręcznie własność sieci do kierowcy. W skrypcie VehicleSeat ustawia swojego Occupant na Humanoid, który na nim siedzi, więc skrypt nasłuchuje zdarzenia Changed siedzenia, aby wykryć, kiedy gracz siada na siedzeniu. Kiedy kierowca opuszcza siedzenie, własność sieci pojazdu zostaje przywrócona do automatycznego ustawienia poprzez BasePart:SetNetworkOwnershipAuto().


local Players = game:GetService("Players")

local vehicleSeat = script.Parent

vehicleSeat.Changed:Connect(function(prop)
	if prop == "Occupant" then
		local humanoid = vehicleSeat.Occupant
		if humanoid then
			-- Pobierz gracza z postaci
			local player = Players:GetPlayerFromCharacter(humanoid.Parent)
			if player then
				vehicleSeat:SetNetworkOwner(player)
			end
		else
			-- Resetuj własność, gdy siedzenie jest nieużywane
			vehicleSeat:SetNetworkOwnershipAuto()
		end
	end
end)

Aby zapewnić płynne działanie i responsywne zachowanie, upewnij się, że przypisujesz również własność wszystkich luźnych BaseParts na szczycie pojazdu do tego samego klienta, który kontroluje pojazd.

Wizualizacja własności

Aby pomóc w debugowaniu własności sieci, Studio może renderować kolorowe kontury wokół obiektów podczas testowania gry.

Kolor konturu		Opis
	(zielony)	Twój klient posiada część i symuluje ją.
	(czerwony)	Część znajduje się w "strefie buforowej", gdzie twój klient ją symuluje, ale jest ona nadal własnością czegoś innego. Twój klient może uzyskać własność po tym, lub może zostać odrzucony.
	(biały/szary)	Serwer lub inny klient posiada tę część poprzez automatyczną własność sieci lub przez jawne przypisanie przez part:SetNetworkOwner().
	(czarny)	Część nie jest własnością ani serwera, ani klienta. Fizyka nie będzie miała zastosowania do tej części.

Należy zauważyć, że w symulacji wielu klientów każdy klient jest przypisany do unikalnego koloru, aby wskazać swoją własność; jest to odzwierciedlane w widoku Serwera, co pomaga określić, który klient posiada które części w danym momencie.

Aby włączyć wizualizację własności sieci:

Kliknij przycisk opcje wizualizacji w prawym górnym rogu widoku 3D.
W menu rozwijanym włącz Właściciele sieci.

Obawy dotyczące bezpieczeństwa

Roblox nie może weryfikować obliczeń fizycznych, gdy klient ma własność nad BasePart. Klienci mogą to wykorzystać i wysyłać złe dane do serwera, takie jak teleportowanie BasePart, przechodzenie przez ściany czy latanie.

Dodatkowo, zdarzenia BasePart.Touched są powiązane z własnością sieci, co oznacza, że klient może wywołać zdarzenia Touched na BasePart, którą posiada i wysłać je do serwera, nawet jeśli serwer nie widzi, by dotykała czegokolwiek. Na przykład, klient może sprawić, że miecz zada obrażenia innemu graczowi na mapie, uruchamiając zdarzenie przez wstrzyknięcia skryptów. Dlatego ważne jest, aby sprawdzać ważność takich zdarzeń wywoływanych przez klientów.

Zobacz Taktyki bezpieczeństwa i łagodzenie oszustw w celu uzyskania szczegółowych taktyk bezpieczeństwa i taktyk łagodzenia oszustw dla gier Roblox.