Relative Location returning World Location

Hello everyone !

So basically I’m encountering a weird problem. I’m doing a vehicle with “procedural” wheel placement, working with physics constraints for the suspensions, roll & steering system.
And in doing so, when trying to grab the relative location of my wheels, I get the world one.
Here’s the graph (used in Construction script) about the vehicle setup.

So with this setup, I grab the WheelsArray variable, do a foreachloop and print the relative location, and it returns me the world one. Why & how ? How can I fix this ?

Not a direct answer but rather something worth trying, ensure the components are not using Absolutes.

299677-annotation-2020-04-14-075139.png

edit: also, perhaps I should mention this earlier, you do Manual Attachment but never actually attach anything. When attaching a component, you also get the chance to establish its relation with the hierarchical parent.

Yeah, so, in the Online BP, the manual attachement is enabled, but it’s not on the actual BP. I tried to set it manually and then do an attachtocomponent specifying that I wanted them relative to X component, and forgot to untick it when pasting.

Tried the Set Absolute, did not change anything, the wheelsArray is still returning world location when taking the relativeLocation node… What is even weirder is that the array called Roll&SuspArray (after the AddPhysicsConstraintComponent) is returning the correct, relative location. Wich is literraly using the same transform as the AddStaticMesh.

Edit: adding more weird to the weird. When doing a DrawDebugString with, as location, the relativeLocation node of my WheelsArray (with a foreachloop), the debug string are drawn at the correct place.

And here is a vid showing what I mean :
Top left, simple Print string with the RelativeLocation of the wheels array. On the wheels, drawdebugstring with the relative location as text location

Wheel Pivot is centered in X & Z axis, while maybe a bit off centered in Y axis (a wheel pivot point is not exactly in it’s middle, in it’s width).

Edit: what I find really weird is that two nodes before adding the wheels meshes (so adding a Physics Constraint Component), RelativeLocation indeed returns the relative location. But for the wheels meshes, everything f*cks up, and RelativeLocation return a world location… And both are added with the same transform!!

Yeas, I can indeed confirm that, visually and technically, everything is working fine. Juste have a look at the video two replies back. Wheels dont go crazy when the vehicle change position in the World, they stay attached with the vehicle and act ‘normal’. It’s juste that the getRelativeLocation from these components returns a world one.

I do have another model where everything is added manually, directly in the blueprint, and it works fine. Maybe something is broken with the project ? I could try to migrate the car on another project…

No problem! Thanks for your help! I’ll keep digging on my own, and see if someones comes with something…

Edit: adding more weird to the weird.
When doing a DrawDebugString with, as
location, the relativeLocation node of
my WheelsArray (with a foreachloop),
the debug string are drawn at the
correct place.

That’s promising. What are the chances something has a weird pivot?

and RelativeLocation return a world
location… And both are added with
the same transform!!

Are you at a stage where you can actually test it visually and confirm that it, does, indeed look fine?

and RelativeLocation return a world
location… And both are added with
the same transform!!

Can you somehow demonstrate the desired component hierarchy - even if you’d need to add the components manually for now; for the debugging purposes.

Ah, I missed the vid somehow. I was hoping to observe something crazy and draw conclusions. Not sure at this point, sorry.

Turn the physics back on only after all components have been attached? Would that work?

Update on this. The problem is caused by changing the Collision Preset of the car body (wich is needed in order for the physics to work). Leaving it by default on NoCollision makes the wheels spawn in 0,0,0 with the proper relative location, but the physics does not work anymore.

Edit: Here are pics to describe the problem. Notice how the prints, once the wheels are in ‘correct’ (wich means attached to the car) position no longer indicates X=140 Y=80 Z=22.282…

Nop… Did not work either. I think I found another way to achieve what I want, but it would be nice to have the RelativeLocation work as intended (even with two simulated bodies)…

Well, nothing beside their initial transform, for placing them, is offseting them.
Basically, here is a simplified version of the problem. Oepn the only map, open the only BP, go to it’s construction Script, and tick/untick the Simulate Physics node. You’ll see that when disabled, the print return the correct relative location, and when simulating, it return a world location. Is it a bug & should I report it?
link text

In the simulated bodies, do you have anything that could potentially offset them? Generally speaking, when you’re doing simulation you’d want the mesh to be the root.

Not sure why this is misbehaving. I’ve done some procedural assembly in the past with physical constraints; not enough to figure this one out.

Necroing this post because it’s the top result when I googled this problem, and I believe this other post contains the final answer which could save folks some time: Bug get Relative Location return the to world location

“This is intended behavior. This is because when you Simulate Physics on a component, it detaches from its parent and the simulation then takes place in world space. So when you’re returning the relative location of a component that is simulating physics, you are returning its location relative to the world.”