I’m working on a multiplayer game in Unreal Engine 5 where players can spawn and attach objects (such as crates, furnaces, etc.) to a physics-based ship. However, I’ve encountered several issues with the attachment system, and I need guidance on the best approach.
The setup:
The ship is a physics-based Pawn (Simulate Physics = True).
Players can spawn various objects and place them on the ship.
The ship has designated “Spawn Zones” (Scene Components with specific tags) where objects should be attached.
Objects should stay in place while the ship moves and allow further interaction (e.g., opening a UI).
The issues I’m facing:
If I attach objects with AttachToComponent (to the SpawnZone component inside the ship), they sometimes detach, jitter, or even fall off when the ship moves.
If I enable Simulate Physics on the attached object, it starts shaking and behaving unpredictably.
If I disable physics before attaching, the object often sinks through the ship’s collision or does not properly interact with other objects.
If I use Weld Simulated Bodies, the object stays in place but then loses proper physics interaction with the player and other objects.
When interacting with a UI (for example, opening a crate’s inventory), the UI sometimes immediately closes, likely due to physics updates affecting the object.
What I have tried:
AttachToComponent() with and without SnapToTarget.
Weld Simulated Bodies = True.
Physics Constraint components (caused performance issues in multiplayer).
Disabling physics before attaching and enabling it after (led to strange physics behavior).
Using SetBase() instead of AttachToComponent.
What is the best way to handle this in UE5?
What is the correct method to attach objects to a moving physics actor so that they:
Move properly with the ship without jittering or detaching.
Remain interactive (so players can open UI, move them later, or interact).
Have proper collision behavior with the ship and other objects.
Work efficiently in a multiplayer environment.
Any help or best practices would be greatly appreciated! Thanks in advance!
Hello @Jorgy_M !
In this case when you are sure you want to the object to be fully attached.
I recommend to add a static/skeletal mesh component (or a custom component children of it) to the ship. In the moment you place the component set the mesh from the actor you have in the hand to the component and delete the actor in your hand. The first part should be done in each client.
You can update the collision to make it work and you component could work and you can add the interaction and whichever behavior in that component or in other actor without visual.
This will reduce a lot of the work of networking layer of the game. The actors will be always attached to their locations.
Hopes this works.
Let me know if you need more help.
Hi… I tried attaching an actor (not a static mesh) to a mesh (as a child) on the ship, but if physics is not enabled on the attached object, it simply won’t attach no matter what you do – you will lose it sooner or later. However, if you enable physics on the attached object (actor), strange things happen, such as the object jittering and being unable to interact with it.
UE strangely implements the mechanics of attaching static objects (actors) to moving (flying) physical objects. As soon as you attach something to the target object (the ship) and apply physical force for movement or flight, all attached actors start behaving unpredictably—no matter what you do. Either they detach if physics is disabled, or interactions with them become completely unrealistic. Yes, if you stop and no longer apply physical forces to the ship, everything works fine, but that’s not a real solution to the problem.
P.S: This is some unreal level of workaround, considering that UE itself is already one big workaround. Is there really no clean logic, no proper approach to dynamically attaching an actor to a physical object and just forgetting about it? Why do we need to create all these hacks with static meshes, intermediary components, and complicated hierarchies? And then there’s the secondary issue of code optimization—how can you optimize it for stable performance, especially in a networked game, if from the very beginning, you’re forced to build your logic around some kind of messy workaround?
Sounds more a problem with the replication of the location that movement in particular.
It can be some problems if the actors is attached to a base even in that actor has a character movement component.
That’s why I recommend to avoid using actor location replication and use a static mesh in each client.
We are talking about testing in single player mode. Try creating a physical object, such as a cube, and spawn a dynamic actor on it, attach it, either to the cube, or to an intermediary object. Then, possess the cube, and fly around with the attached object, for testing—I think you’ll understand everything.
Unclear regarding what your expectations are. Which part of the above does not work for you, specifically? Here’s one thing that sits under the hood and can cause issues:
Disable it, otherwise you’ll get mass distributed unevenly which will affect simulation which pawn’s movement component emulates. Note this works per collider and vertex density dictates the centre of mass (last time I had to deal with it, at least).
If I use Weld Simulated Bodies, the object stays in place but then loses proper physics interaction with the player and other objects.
This is the path to take generally. Could you elaborate on what you mean by the proper physics interaction loss? The pawn no longer collides using the new volume that stems from the extra attached components / actors? If so, when movements components do their thing, the only component they care about is at the root of the actor, anything attached is not taken into account while sliding collision is calculated.
You’d need to rewrite how the system works. You may have some success with:
