Making a part move forward but made it Move on Negative Z-Axis instead

Help and Feedback Scripting Support
#5

It moves in Positive X-Axis because you’re simply putting 1 at the X-Axis, and one is a positive number.

2 Likes
#6

If you want to make it smoother, you can remove the task.wait, and implement delta there, like that:

local Speed = 2
ball.CFrame = ball.CFrame * CFrame.new(-Speed * delta, 0, 0)

if it is too slow, you can only increase the ball’s speed.

I’d recommend, additionally, to use Vector3 instead of CFrame, to update the position directly, as CFrame is used mainly when you want to change a basepart’s position, orientation, and a lot others

5 Likes
#7

Thanks! , but my main problem is why do my “Ball” is going on 1 direction instead of going forward according to it’s rotation?

I’ve been using the statements like part.CFrame *= CFrame.new(0,0,-n) to move parts forward.

Well, you did recommend me using Vector3 to update the position (Making it move forward according to it’s rotation). Do you mind giving me the example codes?

1 Like
#8

If it was working moving parts with negative Z-Axis values, it means the orientation of the part was convenient to it. If the orientation of the part is at 360, the X-Axis would be the opposite of it, so it would move back.

You can use Vector3 like that:

ball.Position += Vector3.new(1,0,0)
#9

When you move a part using CFrame, it’s coordinate would differ according to its orientation/rotation. It is because the CFrame is the local coordinate of the part, while Vector3 is the global coordinate, so it doesn’t matter if it is 100 degrees rotated.

1 Like
#10

I tried to follow this discussion’s solution

It works before the studio’s update. Is this studio’s bug or indeedly mistake in the scripting?

1 Like
#11

Could you share the part’s orientation? Also, why are you trying to move the part’s position according to the orientation, if it doesn’t matter the value of its rotation?

#12

There’s script inside the player character. So everytime this “skill” is played, it clones the ball that was parented on ServerStorage and state their CFrame in front of the players

Ball.CFrame = HumanoidRootPart.CFrame * CFrame.new(0,0,-15)
(This code is running as i expected)

And after a few delay, it fires the remote to play the Ball Moving Animation.
The Moving script is the one i gave you a few moment ago

1 Like
#13

Alright. But is it obligatory for you to use CFrame instead of Vector? If you’re messing up with the basepart’s orientation, then using CFrame would be convenient, but if you’re not, then you could try using Vector3. You want it to be relative to its orientation?

#14

Alright, so. When you multiply two CFrames, it translates it.
Here’s how you make a part go in the direction it is facing:
(Script under the part)

local function move(studs)
    script.Parent:PivotTo(script.Parent:GetPivot() + script.Parent:GetPivot().LookVector * studs)
end

move(5) --move 5 studs forward
1 Like
#15

Yes, i want it to move relatively to its orientation
I wonder how to move a part forwardly using the Vector3 anyways

#16

Why using PivotTo? Why not CFrame or Vector3?

#17

CFrame already moves relatively to the basepart’s orientation, that’s why the ball was moving strangely.

#18

Parts are PVInstances. Functions related to Pivot all use CFrame. It is essentially CFrame functions.

1 Like
#19

I guess use LookVector then? So it’d move to where the part’s looking at

1 Like
#20

You mean’t this?
ball.CFrame += ball.CFrame.LookVector * n

I tried that one, and the ball is still moving awkwardly

#21 
local distance = 2
ball.Position = ball.Position + ball.CFrame.LookVector * distance

maybe that?

#22

what’s the ball’s orientation?

#23

could you screenshot all of the part’s properties? I’ll try to fix that inside studio

#24

The original orientation?
It’s 0,0,0

When it’s cloned to the Workspace, the ball’s orientation follows the Character’s HumanoidRootPart.Orientation.