#Thread
vestal cradle
parent can move in any direction
child will not know
parent script also does not know where it is going
bright moss
well, then you have no coherent way to define what direections to move
you need to know which way the parent is going
vestal cradle
and I don't want to pass through information in some convoluted way for the child to know where to go
I know i want it to move towards a specific point in the parent's reference frame
and naturally move in that reference frame
bright moss
Yes, but you're also asking for it to only move along a certain axis
vestal cradle
If parent is at 0,0, and child is at 0,1. Then I tell child to move to 0,0, while parent goes to 1,0.
as child is going there, the target of where it needs to go changes
motion could be more complicated. I just have +x and -y motion for simplicity
I thought parenting would take care of reference frames
bright moss
I don't know what you mean by "reference frames" here
If you move the child's local position along a single axis, then the direction the child moves will depend on the rotation of the parent
vestal cradle
if parent moves, child moves an equal amount
ignore rotation right now
no rotation
bright moss
That already happens.
The child's local position doesn't change by itself, so if the parent moves, the child follows
vestal cradle
well, I need any changes to parent's position to immediately affect child
bright moss
that is how parenting works, yes
i don't believe kinematic rigidbodies will affect this
i'm moving around a parent and child in the editor right now
vestal cradle
if I grab the transform of the parent, I can drag child around
but when parent uses MovePosition, it's like the child's Moveposition happens at a different time
which is a problem because moveposition only works on world coordinates
bright moss
the order of the MovePosition calls may be relevant
I believe the transforms update immediately
(during the physics update, that is)
bright moss
the order of the MovePosition calls may be relevant
if the transform doesn't change until the physics update happens, you'll have run both MovePositions based on the old positions
bright moss
well, you're manually screwing with the physics system
it's going to be kind of icky
perhaps you can have the parent store the position it's intending to move to, and have the child base its movement off of that
vestal cradle
I really do not want to do that
bright moss
why are you doing this, again?
bright moss
I've set up a new project and added two classes, Parent and Child. Parent moves 1 meter to the right every fixed update. Child moves 2 meters towards its parent's position every fixed update
The Child is selected here
It's always 1 meter behind
Script exectution order has no effect
You will need to tell the child where to go. It can't possibly know where its parent is going to be after the physics update
Also, the child follows a pursuit curve, which you said you don't want?
vestal cradle
I am trying to avoid pursuit curve shenanigans
bright moss
The diagram you drew shows the child object intercepting its parent -- moving in a straight line until they overlap
This is going to require knowledge of the direction the parent is moving in.
vestal cradle
execution order can matter if I tell the child where to expect parent to be
bright moss
execution order can matter if I tell the child where to expect parent to be
Yes; I'm describing the current situation
vestal cradle
I just don't understand why this needs to be so complicated
bright moss
because you're trying to do something rather complicated
you're making a child move to intercept its parent as the parent moves
If you just move towards the parent's position, you get an intercept curve
that's..just how it works
vestal cradle
This would be so easy if there was a MoveToLocalPosition
bright moss
Even if you were changing the local position of the child, not the world position, you'd still get a bit of a pursuit curve
vestal cradle
so the engine would know to move child relative to parent
bright moss
well, hmm, I will try this
vestal cradle
let's say I have a kinematic rigidbody platform just moving back and forth, and I want a player to move relative to the platform while on it
I've done this just find with a dynamic rigidbody
but how would you do this with a kinematic RB, which most people use?
bright moss
how does this compare to what you want?
aha
that looks like it matches
the fundamental problem here is that you're trying to calculate how to move the child before the parent actually moves
Parenting rigidbodies gets weird.
my code would probably not handle rotations correctly
vestal cradle
this is what I need
I do not need rotations for this at all
very few things in my gameworld will ever rotate. Maybe x-scale flip, but not rotate
vestal cradle
how did you do this
bright moss
here, I exported a package containing an example
the two relevant classes.
The parent first computes how far it's moving and where it's going to wind up
internet crapped out, oops
it’ll reconnect in a few
in hindsight, computing the goal is redundant, since you just add the world position to move to get it
Anyway. The parent then tells all of its children how far it's going to move and where it's going to move to.
The child needs to out where it's going to be after its parent moves. This tells us where our movement will actually start from in world-space. Remember that the parent's transform will only change after the physics update.
The child then converts that into its parent's local space.
Then, it moves that local-space position towards [0,0,0].
Finally, it converts this back to world-space. This is where we move to.
All of this complication happens because we can't change the parent's transform before we change the child's transform
(because they're only going to change once the physics update happens)
If we just did this, we'd lag behind the parent by one tick:
var newPos = Vector3.MoveTowards(transform.localPosition, Vector3.zero, Time.deltaTime);
newPos = transform.parent.TransformPoint(newPos);
rb.MoveTowards(newPos);
because it would move us towards where the parent was before the physics update
i wonder if you could just move the parent's transform, do all of the MovePosition calculations, and then put it back....
that'd be a little goofy
vestal cradle
i’ll need to get back to this when I get home
bright moss
you know, there's one thing that could simplify this a lot
make some empties and move those around as usual
then just move the rigidbodies into their new positions