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.
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
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…
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?
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.
