Using Physics to get a ball to an exact position

when it’s green, the ball should always go in. however it more or less always hits the rim rather than going in.

here’s my code

local function calculateT(distance)
    local d = math.clamp(distance, 0, maxDist)

    return minT + (d / maxDist) * (maxT - minT)
end

local t = calculateT(player:DistanceFromCharacter(targetHoop.AimPosition.Position))
local x0 = ball.Position
local g = Vector3.new(0, -game.Workspace.Gravity, 0);
local v0 = (targetPos - x0 - 0.5*g*t*t)/t; -- targetPos is a position in the middle of the netting
        
ball.AssemblyLinearVelocity = v0
1 Like

Either the rim model or aim position is the issue.

Or it could even be Roblox’s physics solver which has integration errors this post could help.

I’ve tried positioning aim position in many different places, the result however is the same. If the issue does lie with roblox’s physics solver, then my question would be what would the solution be? I can only think of maybe, a bezier curve with AlignPosition, which sounds like a nightmare in terms of replication

I would say don’t overcomplicate it, just make the rim bigger and you are done. If it clashes visually just make an invisible hitbox or something.

If you really have to you should try doing what the post says and get correction.

I have no idea where you got this from you are probably overcomplicating it.

No matter how big the rim gets, the issue still exists because the margin of error is really large depending on where you shoot it from

Bump

It could be that the animation is causing the issue as it is changing the starting position and ultimately affecting where the ball is up and down causing it to more or less hit the backboard or the tip of the rim. Try turn off the animation and see if the ball makes it more often than with the animation on.

The ball gets detached from the player, the velocity is calculated from the balls position, and then immediately the velocity is applied so I’m not sure about that, I will try it though

Could the network owner of the ball (I assume it’s a model) have anything to do with this? I’ve had issues with humanoid physics when a npc would get close to a player or get far away, the network owner would change and cause lots of issues. I always had to set the network owner to the server so it wouldn’t try to offload the physics to clients.

Rather than relying on the physics solver, I would manually move the projectile along the computed path. See EgoMoose’s solution:

I’ve used on Monkey Poop and other games and it is always reliable as it is computed.

Collisions are important to me though… but this might be the solution I have to end up relying on.

Another issue i find with CFraming the ball, is that the replication is not smooth, and the balls movement looks jittery on higher pings

The network owner is set to the client so it isn’t changing, but I can set it to the server only and see what happens