Physics sleeping / lag

Hello,

Please take a look at the video - When the hit actor via trace line is grabbed by the server (I’ve not done the client replication here as the server will handle everything) - While the actor is ‘grabbed’ around, if the server stays in one place, the physics handle lets go/sleeps until the position is updated.

Does anyone know/have tricks on how to make the dragging replication smooth? - And for the actor not to hit the ground due to there being no position updates?

Youtube: - YouTube

Thanks for taking a look!

##UPDATE##

Ok, so I was playing with the below values - “Min Net Update Frequency”, I changed it to 100 which eliminates the replication ‘lag’. These values are located within the actor you’re trying to grab.

I feel that this isn’t the optimal route to take, being that the server may strain. Does anyone have an alternative?

Also, when you stay still, the grabbed item continues to drop and hit the floor. Does anyone know how to resolve this?

Any brainstorming would be appreciated.

229942-root.png

229943-rep.png

I got the same problem today.

The only workaround I found was to disable the gravity by default on the component you grab.

I also disable gravity when the PhysicsHandle grab the component and enable gravity when it drops the object.

It’s not a clean solution but for me it works. If someone knows how to fix it properly I would appreciate.

Hi! I’m not an expert, but, what I see is that only updated data is transferred to the client, so when you’re not moving the ball, its physics simulating as usual on the client, from last set location. So maybe it’s better to disable ball’s physics, on client side, while you’re holding it, somehow. Or make sure that data is transferred every frame. Just some thoughts.

Many thanks for the response - May I ask how you are replicating the change of gravity?

Even when I multicast the change, it continues to be enabled for the client.

Thanks for the response - I see what you’re getting at and sounds ideal. I noticed the node “Grab Component at Location” and “Set Target Location” relies on physics, being that the ball will go static when disabled.

I can’t find a suitable method of telling the clients to disable physics but the relationship needs to work both ways and client to client. Just trying to get the essentials set for now though.

I noticed that the movement is being replicated by the ball itself via “Replicate Movement”. Not the server telling the clients via this BP. So it seems that the client doesn’t actually know that the server is ‘grabbing’ the ball. Multicasting the event continues to wield the same result.

I disabled it on a server method of the character when it grabs the object.

Here’s a snippet my character .h

UFUNCTION(Server, Reliable, WithValidation)
	void ServerPickUpObject();
	virtual void ServerPickUpObject_Implementation();
	virtual bool ServerPickUpObject_Validate();

And here’s the snippet of the .cpp. The AGoldenCube is the object I want to grab. I did the same for the DropObject method.

void ACollectingGameCharacter::ServerPickUpObject_Implementation()
{
	UWorld *World = GetWorld();
	if (World)
	{
		const FName TraceTag("HoldingTrace");
		World->DebugDrawTraceTag = TraceTag;

		FCollisionQueryParams HoldingTraceQuery = FCollisionQueryParams(TraceTag, false, this);
		FHitResult HoldingTraceResult(ForceInit);
		FVector Start = CurrentCamera->GetComponentLocation();
		FVector End = (CurrentCamera->GetForwardVector() * 600) + Start;

		bool blocking = World->LineTraceSingleByChannel(HoldingTraceResult, Start, End, ECollisionChannel::ECC_Visibility, HoldingTraceQuery);

		if (blocking && HoldingTraceResult.Component->IsSimulatingPhysics())
		{
			UPrimitiveComponent *ObjectToPick = HoldingTraceResult.GetComponent();
			AActor* SomeActor = ObjectToPick->GetOwner();
			AGoldenCube* GoldenCube = Cast<AGoldenCube>(SomeActor);

			if (GoldenCube && !GoldenCube->GetIsHeld())
			{
				HandleComponent->GrabComponentAtLocation(ObjectToPick, NAME_None, ObjectToPick->GetComponentLocation());
				HandleComponent->GetGrabbedComponent()->SetEnableGravity(false);
				holdingObject = true;
				GoldenCube->SetIsHeld(true);
				GoldenCube->SetLastHolder(this);
			}				
		}

	}
}

Brilliant - Works nicely. Shame there isn’t a more direct solution (that I know of, clearly).

Only annoyance is the ball will slingshot if you swing the mouse in whatever directions.

Yeah I would die for a clean solution of this matter.

Yeah I got strange behaviour from the objects when I swing the mouse. Maybe increasing the net frequency of the object would fix that. I have not tested yet.

Behaviour continues in a non-replicated environment. Upping the frequency outputs the same result. ■■■■■■. Every time I ‘think’ I know the problem, back to square one! Many thanks for your input on this.

Hi Lucius9 - Disable “Soft Linear Constraint” on the physics handle component. Works ‘OK’ for me I guess. Also, set the “Min Net Update Frequency” in the actor you are trying to grab to whatever suits. Mine is on 100 for now.

If anyone has a more optimal solution to prevent the grabbed object from hitting the floor as shown in the video above, please let us know!

Hey I tried your fix earlier today and for me it worked like a charm ! I have to test this fix with enabling gravity of the object on its initial state. Thanks !

Hi guys. I was curious about what you’re doing, so decided to test out my theories. I found the solution, but it’s maybe kind of complex. And works not that pretty, but good I guess.
In short - Object is always grabbed on server. Held object’ physics is simulated only on the server, for the clients simulation is disabled. From server, while being held, object’ position is transferred to all the clients. Then, when object is released, again on the server, physics is turned back to enabled on the clients.
Here’s BP code, it’s kind of raw, just to show how the things done in general. Not sure if that’s what you’re looking for, though. Take a look.

Edit.
Uhh… never mind. It has flaws anyways, and I can’t solve them. Maybe the physics handle component is the problem. If it is what controls how often the position of a held object is updated, then it makes me think that you could modify it to get better results. Maybe it’s not to be used in multiplayer.