Fastcast bullet is being offset when player moves

Help and Feedback Scripting Support
, ,
#1

You can write your topic however you want, but you need to answer these questions:

  1. What do you want to achieve? Keep it simple and clear!
    I currently am trying to make a simple weapon system using fastcast to render bullets quickly on the client. How do I account for player movement when I spawn bullets to shoot?

  2. What is the issue? Include screenshots / videos if possible!
    Whenever the player moves, the bullet spawns at an offset position to the gun point. As I’ve noticed, the offset amount scales the greater the player’s walkspeed is. The issue itself is mostly self-explanatory. Attached is a video as proof:

  3. What solutions have you tried so far? Did you look for solutions on the Developer Hub?
    I’ve looked through dev hub, however none of the solutions I’ve tried so far have actually worked.

Right now, what happens in my script is that a hitscan module passes in an origin, cast behavior, hit position, and shoot range into a module for creating cosmetic bullets. Then the cosmetic bullet is fired on a client caster. The origin for the hitscan module is determined using an attachment’s world position, which is on the viewmodel’s weapon.

Here’s the code
Hitscan Module:

local origin = self.pModule.camState == "FirstPerson" and self.v_weapon.Shoot.Attachment.WorldPosition
DrawCosmeticBullet(player, self.Shoot.BULLET_NAME, self.castBehavior, origin, mouse.Hit.Position, self.Shoot.BULLET_RANGE)

DrawCosmeticBullet:

return function(Sender : Player,
	BulletTemplateName : string,
	CastBehavior : FastCast.FastCastBehavior,
	Origin : Vector3,
	MouseHit : Vector3,
	Range : number,
	ShootPointInfo)

local Direction = (MouseHit - Origin).Unit
		ClientCaster:Fire(Origin, Direction, 100, CastBehavior)
end

The issue is likely not related to a delay on the scripting side. I used os.clock() to check the time in between when the shoot request is made, and the fastcast bullet fires, and it’s a negligible amount.

Because I noticed the offset had a correlation to the player’s velocity, I tried adding the velocity to the player’s movespeed but it was still offset by a small amount. I don’t know if I’m doing it wrong or something, but this is generally what I tried:

local StartPoint = Origin + RootPart.Velocity * deltaTime

I seriously don’t know what the issue is at this point, if anyone could offer any advice or help I’d greatly appreciate it!

1 Like
#2

can’t really say much without the full system, however are you sure it isn’t the latency issue? Not sure how you set up the client/server but if you are getting the position for gun on the server to fire the bullet from, that differs drastically from where the player actually is on their own client.

#3

it has nothing to do with the origin position, it’s because there’s no conservation of momentum. you need to add the player’s velocity onto the initial velocity of the bullet, not its origin point.
although this does change the direction the bullet travels, adding it onto the Direction variable above will not work, you need to add it directly onto the velocity vector of the bullet, since i have never used FastCast i dont know how that would work, but in pseudocode this would be it: Bullet.Velocity += Player.Velocity

#4

The cosmetic bullet projectile is being rendered on the client, and there shouldn’t be any delay there. I even tested using os.clock() to find the time that had passed between when I fire the bullet and when I set the origin point, and it’s way less than a frame.

#5

Fastcast lets you fire a bullet given an origin vector, direction vector, and a velocity vector.
Following your suggestion, I’ve adjusted from this:

local Direction = (MouseHit - Origin).Unit
ClientCaster:Fire(Origin, Direction, Direction * 1000, CastBehavior)

to this:

local Direction = (MouseHit - Origin).Unit
ClientCaster:Fire(Origin, Direction, Direction * 1000 + HumanoidRootPart.Velocity, CastBehavior)

However, the bullet is still being offset. In fact, I don’t think it’s made a noticeable change at all compared to before, please give feeback:

#6

ok so i got fastcast and i had to fiddle around with it to figure out how it works, i got it working just fine with whats essentially the same code that you have just tried

one thing i noticed when reading the documentation is that you need to manually position the bullet via the LengthChanged event, can you show me the code that is responsible for positioning the bullet?

#7

Here’s the function:

local function UpdateBulletPos(cast, lastPoint, direction, length, velocity, bullet)
	if not bullet then return end

	local goalCF = CFrame.lookAt(lastPoint, lastPoint + direction)
		* CFrame.new(0, 0, -(length/2 - length))    

	local trail = bullet:FindFirstChildWhichIsA("Trail")
	if trail then
		trail.Enabled = true
	end

	bullet.CFrame = goalCF
end
#8

i tested it a bit more and im certain that its the trail. because the trail will drag behind the bullet it appears as if its lagging behind, which it technically is supposed to do since its a trail, you will have to use a different way to model tracers.

try removing the trail and see whether the bullet itself is behaving the way it should, if it does then its confirmed to be the trail’s fault for creating this illusion of lag.

oh btw -(length/2 - length) is the same as length/2

#9

although at high speeds it really should be negligible but i really cant think of anything else that could be causing this because it is working perfectly fine for me

#10

You’re right, it seems to be an issue with the trail unfortunately. Looking at some other forum pages and they seem to be saying the same thing. Fastcast renders the bullets a single frame late, which might also be exacerbating the issue. Since trails probably aren’t viable now, looking into beams.

Also, about your point earlier about adding the rootpart velocity to the initial velocity, it changes the angle of the bullet in an unintended way, so I ultimately deleted it.

Much thanks for the help, will keep you updated on how implementing beams into the system goes!

#11

Yes i did mention in the first reply that it would change the direction the bullet travels, this however is realistic even though it may not appear that way in certain situations, like when you shoot and then stop moving.

i don’t have a solution for that, generally the faster the bullet the smaller this angle will be.

i won’t really be able to help you out with this

#12

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.