Um komplexe physikalische Mechanismen zu unterstützen und gleichzeitig eine reibungslose und reaktionsschnelle Erfahrung für die Spieler anzustreben, nutzt die Roblox Physics-Engine ein distribuiertes Physiksystem, bei dem Berechnungen zwischen dem Server und allen verbundenen Clients verteilt werden. Innerhalb dieses Systems weist die Engine Netzwerkeigentum von physikalisch simulierten BaseParts entweder einem Client oder dem Server zu, um die Arbeit bei der Berechnung der Physik zu teilen.
Clients erleben reaktionsschnellere physikalische Interaktionen mit Teilen, die sie besitzen, da es keine Latenz durch die Kommunikation mit dem Server gibt. Netzwerkeigentum verbessert auch die Serverleistung, da die physikalischen Berechnungen zwischen einzelnen Clients aufgeteilt werden können, sodass der Server andere Aufgaben priorisieren kann.
BasePart-Eigentum
Standardmäßig behält der Server das Eigentum an jedem BasePart. Darüber hinaus besitzt der Server immer verankerte BaseParts, und Sie können deren Eigentum nicht manuell ändern.
Basierend auf der Hardwarekapazität eines Clients und der Nähe des Player.Character des Spielers zu einem nicht verankerten BasePart weist die Engine automatisch das Eigentum an diesem Teil dem Client zu. Teile, die sich in der Nähe des Charakters eines Spielers befinden, werden daher eher spielerbesitzend.
Zusammenbau-Eigentum
Wenn ein physikbasiertes Mechanismus keine verankerten Teile hat, setzt das Setzen des Eigentums an einem Zusammenbau innerhalb dieses Mechanismus das gleiche Eigentum für jeden Zusammenbau im Mechanismus.
Wenn Sie einen einzelnen Zusammenbau, der nicht Teil eines größeren Mechanismus ist, verankern, geht dessen Eigentum an den Server, da der Server immer verankerte BaseParts besitzt. Wenn derselbe Zusammenbau wieder entankert wird, geht sein vorheriger Eigentumsstatus verloren und er wird wieder automatisch von der Engine verwaltet.
Wenn Sie einen Zusammenbau innerhalb eines größeren Mechanismus von Zusammenbauten verankern, geht dessen Eigentum an den Server, aber das Eigentum an den anderen Zusammenbauten bleibt unverändert. Das Entankern desselben Zusammenbaus stellt sein zuvor festgelegtes Eigentum wieder her.
Eigentum festlegen
In Spielen mit komplexen physikalischen Interaktionen oder in Fällen, in denen Sie direkte Kontrolle zuweisen müssen, können Sie Eigentum über einen serverseitigen Aufruf von BasePart:SetNetworkOwner() festlegen.
Betrachten Sie ein Fahrzeug, das ein VehicleSeat-Objekt für den Fahrer und ein Seat-Objekt für einen Passagier hat, wobei beide im Fahrzeugzusammenbau enthalten sind. Nach den Standardnutzungseinstellungen gewinnt der Passagier das physikalische Eigentum am gesamten Fahrzeug, da er zuerst eingestiegen ist, wenn ein Spielercharakter im Seat (Passagier) sitzt und dann ein anderer Spieler in den VehicleSeat (Fahrer) springt. Der Fahrer muss mehrere Netzwerkzyklen warten, bevor seine Eingabe erkannt wird, und das Fahrzeug wird sich weniger reaktionsschnell anfühlen.
Das folgende Script behebt dies, indem es das Netzwerkeigentum manuell dem Fahrer zuweist. In diesem wird der VehicleSeat sein Occupant auf den Humanoid setzen, der darauf sitzt, sodass das Skript auf das Changed-Ereignis des Sitzes hört, um zu erkennen, wann ein Spieler im Sitz Platz nimmt. Wenn der Fahrer den Sitz verlässt, wird das Netzwerkeigentum des Fahrzeugs mit BasePart:SetNetworkOwnershipAuto() auf die automatische Verwaltung zurückgesetzt.
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
-- Hole den Spieler aus dem Charakter
local player = Players:GetPlayerFromCharacter(humanoid.Parent)
if player then
vehicleSeat:SetNetworkOwner(player)
end
else
-- Eigentum zurücksetzen, wenn der Sitz unbesetzt ist
vehicleSeat:SetNetworkOwnershipAuto()
end
end
end)
Visualisierung des Eigentums
Um bei der Fehlersuche des Netzwerkeigentums zu helfen, kann Studio beim Testen farbige Umrandungen um Objekte rendern.
| Umrandungsfarbe | Beschreibung | |
|---|---|---|
| (grün) | Ihr Client besitzt das Teil und simuliert es. | |
| (rot) | Das Teil befindet sich in einer "Pufferzone", in der Ihr Client es simuliert, es jedoch immer noch von etwas anderem besessen wird. Ihr Client könnte nach dieser Zone das Eigentum erhalten oder es könnte abgelehnt werden. | |
| (weiß/grau) | Server oder ein anderer Client besitzen das Teil entweder durch automatisches Netzwerkeigentum oder durch explizite Zuweisung über part:SetNetworkOwner(). | |
| (schwarz) | Das Teil gehört weder dem Server noch dem Client. Physik wird auf dieses Teil nicht angewendet. | |
Um die Visualisierung des Netzwerkeigentums zu aktivieren:
Klicken Sie auf den Visualisierungsoptionen-Button in der oberen rechten Ecke des 3D-Viewport.

Aktivieren Sie im Dropdown-Menü Netzwerkeigentümer.
Sicherheitsbedenken
Roblox kann keine physikalischen Berechnungen überprüfen, wenn ein Client das Eigentum an einem BasePart hat. Clients können dies ausnutzen und schlechte Daten an den Server senden, z. B. ein BasePart teleportieren, es durch Wände gehen lassen oder herumfliegen lassen.
Darüber hinaus sind BasePart.Touched-Ereignisse an das Netzwerkeigentum gebunden, was bedeutet, dass ein Client Touched-Ereignisse auf einem BasePart, das er besitzt, auslösen und an den Server senden kann, auch wenn der Server es nicht sieht, wenn es etwas berührt. Zum Beispiel kann ein Client mit einem Schwert einem anderen Spieler auf der Karte Schaden zufügen, indem er das Ereignis durch Skriptinjektionen auslöst, sodass es wichtig ist, die Gültigkeit solcher von Clients ausgelösten Ereignisse zu überprüfen.
Siehe Sicherheitstaktiken und Betrugsbekämpfung für detaillierte Sicherheitstaktiken und Betrugsbekämpfungstaktiken für Roblox-Spiele.