Mass incorrect if Physics == OverlapAll

Not sure if this is intended behaviour or not, but If I create a pawn with a mesh, and try and alter the mass using the override and Mass in Kg, then if I have Physics == OverlapAll, then the mass of the object is 1.0kg.

If I then attach an object, the mass changes to the correct value.

If I just change the Physics to BlockAll initially, then all of a sudden the mass is correct.

I’m using 4.7.6

Hi AusPaco,

What type of mesh are you adding to the pawn? Skeletal mesh or static mesh?

Also, how are you attaching an object? Please provide screenshots if possible.

I’m adding a Static mesh, but the issue crops up before that. Here’s what I can do to reproduce the error. I’m using the following class:

(Sorry, it went past the character limit, wasn’t sure what the best way to post it was

Steps:

  1. Create a blueprint based on this character. Put a staticmesh on it.

  2. I’m using Multiplayer - 2 players. Each uses the blueprint created above (default pawn)

  3. If I use the Collision Preset - Block All - the mass is correctly displayed on the screen as 200.0 for each pawn

  4. If I change it to OverlapAll - they all display 1.0 on the screen.

If I put two copies of the actor in the world, and change the settings on one of them, then they display as above - ie, one will return 1.0 and one will return 200.0

Hope this helps!

Hi AusPaco,

The first step is for me to reproduce it. Seeing as your project seems fairly far along, there would be a lot of code to put together. Could you provide me with the project or a sample? To cut down on space you could delete the Binary, Saved, Intermediate folders and the SQL database file and then upload it to a third party site like DropBox or Mega if you cannot fit it here. Otherwise you could simply provide me with the code files themselves.

Did the code I have already posted not work?

It is set to include files that you have not provided, which is using classes, functions, and variables from those files as well.

Sorry, I stripped all the code out, but left the includes. They aren’t required though, they aren’t referenced in the code. If I get a chance I’ll remove those lines for you.

I commented out the includes for the files that I didn’t have which also made me have to comment out the following lines as the compiler didn’t know what they were:

//Equipment Components
UPROPERTY(VisibleAnywhere, BlueprintReadWrite, Category = StaticMeshAssets)
UEquipmentComponent* equip_top;         // top socket

//Equipment Components
UPROPERTY(VisibleAnywhere, BlueprintReadWrite, Category = StaticMeshAssets)
UEquipmentComponent* equip_right_arm;

Those were commented in the .h file and this one line had to be commented in the .cpp

equip_top = NULL;

After doing that, I was able to create a blueprint with the custom class but changing the collision from BlockAll to OverlapAll, both mid-simulation and outside of it, didn’t cause the mass to decrease below 200. Could you try commenting these lines out and see if the issue still occurs? If so, could you provide me with a test project with the error occurring so that I can see it first hand?

Hi , thanks for you effort so far :slight_smile:

From 4.7.6 launcher I created a blank c++ project. Here are the content, source, and project files :

https://dl.dropboxusercontent.com/u/63330882/Debug.

I’m still getting the same behaviour I described above. On the line that displays the mass, it will be 1.0 or 200.0 depending on the collision settings

Here’s a screenshot :

Ah, the first time I got your code I was looking for the difference in the details panel. ‘Ship Mass = #.#’ had been showing 0 at all times for me, and it does with the test project you gave me as well even though the ‘Mass in Kg’ in the details panel showed 200. I changed the following line to make it show something other than 0:

GEngine->AddOnScreenDebugMessage(-1, 10.f, FColor::Green, FString("Ship Mass = ") + FString::SanitizeFloat(StaticMeshComponent->GetMass()) + FString(" Role = ") + FString::FromInt(Role));

to

GEngine->AddOnScreenDebugMessage(-1, 10.f, FColor::Green, FString("Ship Mass = ") + FString::SanitizeFloat(BodyInst->MassInKg) + FString(" Role = ") + FString::FromInt(Role));

After doing this, it displays 200 correctly and doesn’t change when the collision is set to OverlapAll or BlockAll. I’m not very familiar with using FBodyInstance so I’m unsure of what could be causing the issue. I’ll be looking into it further, but let me know if changing that line fixes anything.

Hi , I’ve just worked around the issue by setting the collision to BlockAll and working from there.

Regarding the incorrect number being displayed - I found that the ship also seemed to have the wrong mass - Ie, when I applied a force to it it moved much faster, and the velocity didn’t change if I altered the mass. Again if I changed to BlockAll it seemed to work fine, so I suspect there is some setup that doesn’t get called unless there is blocking.

Unfortunately I’m still unable to reproduce the issue itself, but I am glad that you’re able to continue working on your project. If you are content using the workaround, I’ll be resolving this issue for tracking purposes. If you do wish to continue this report however, please feel free to comment and it’ll reopen.

Have a nice day!

Really? You don’t get the same display? I’ve just tried it by changing the Tick fn to:

void ADebugPawn::Tick(float DeltaTime)
{
	Super::Tick(DeltaTime);
	if (!bDoneFirstTickInit)
	{
		FirstTickInit();
		bDoneFirstTickInit = true;
	}
	StaticMeshComponent->AddForce(FVector(100, 0, 0));

}

And creating two pawns. One I have BlockAll, and the other is OverlapAll. One accelerates away, the other stands still.

Just to be clear, for my own point of view I’ve moved on, and it is no longer an issue for me. However, I still think it is a bug, and I’m sure will catch out others. That’s the only reason I’m proving further info. I’m just a bit confused why you would call it resolved? I thought the bug report place was so that I could help you guys find bugs and at least put them on the radar to fix at some stage. Or is it just so that you can help people find workarounds for their own individual problems?

The reason it was set to resolved is that I was still unable to reproduce the issue with the information provided and I had assumed that you were done researching the issue. It was only as a precaution to prepare for if you were done responding. I apologize for acting hastily.

I have managed to reproduce the issue now however, looks like the StaticMesh I was applying was the problem. Using the TwinStickUFO worked however. I’ll be looking into the issue and I’ll get back to you as soon as possible.

I’ve found out what the exact issue is. The issue is actually that the Collision Enabled field is being set to anything other than Collision Enabled, which is done when using OverlapAll. This causes the editor’s code to skip vital parts of UpdateMassProperties, thinking it doesn’t need to seeing as this object is not going to collide with anything, which is wrong as you could be applying force to it. I’ve put in a bug for the issue under the number UE-16076.

As far as a workaround for now, I would suggest using a Custom preset and setting the Collison Enabled field to Collision Enabled and then setting all of the check boxes to Overlap. This should work as a temporary solution. I’ll be sure to update you here when the issue is fixed.

Have a nice day

Thanks :slight_smile:

Hi again AusPaco,

I’m here to update you and let you know that the fix has been made and I have verified it. It’s not a direct fix but a warning has been added to let the user know to change this field. I can’t tell as of now when the fix will be implemented into a binary version of the engine, but I can confirm that it is coming.