Scripting Helpers is winding down operations and is now read-only. More info→

Raycasting Bullet Drop Issue?

Asked by

8 years ago

I've been working on a cframe bullet drop script, where it creates a ray every so often based on raysPerSecond and metersPerSecond (basically studs per second.) The issue is that when i increase the raysPerSecond, the "bullet" drops a lot faster than a lower raysPerSecond. When the raysPerSecond is set to 6, it gives me roughly the right travel time to bullet drop, but when I increase it, it drops a lot more compared to its travel time. Here's the script:

local plr = game.Players.LocalPlayer;
local char = plr.Character;
local m = plr:GetMouse()


local metersPerSecond = 500;
local raysPerSecond = 30;
local dropPerSecond = Vector3.new(0, -30, 0)
local maximumDistance = 1000;

function fire()
    local metersPerRay = metersPerSecond/raysPerSecond;
    local raysGenerated = 0;
    local function generateRay(startPosition, direction)
        raysGenerated = raysGenerated + 1;
        local bulletPath = Ray.new(startPosition, direction*metersPerRay)
        local hit, position = game.Workspace:FindPartOnRayWithIgnoreList(bulletPath, {char})
        if hit ~= nil then
        else
            wait(1/raysPerSecond)
            if raysGenerated < maximumDistance/(metersPerSecond/raysPerSecond) then
                generateRay(position, ((position-startPosition)+(dropPerSecond/(raysPerSecond))).unit)
            end
        end
    end
    generateRay(char.Head.CFrame.p, (m.Hit.p-char.Head.CFrame.p).unit)
end


m.Button1Down:connect(function() fire() end)

1 answer

Answered by

aquathorn321 858

8 years ago

I tested your code by creating a new part at the end of every ray. I didn't notice any change in changing raysPerSecond to a constant until I tested changing it in metersPerRay. To fix this, you can just change raysPerSecond in line 12 to a constant.

The problem this leads to is found in line 16: local bulletPath = Ray.new(startPosition, direction*metersPerRay)

The bulletPath will be shorter if you increase raysPerSecond, which in turn causes the bullets to fall faster because generateRay is called more often before finding a part.

This was my basic understanding without looking at it too hard. The problem might also occur just because you're dividing with it, which means you'll get a smaller value wherever it is used as you increase raysPerSecond. aquathorn321 858 — 8y

when i divide the drop by the raysPerSecond, this is supposed to combat that. If i keep it a constant number, it will just speed up the bullet and the drop will be less when i lower raysPerSecond. JunoElysium 15 — 8y

I've condensed ythe code to the bare minimum, hope this makes it easier to understand, sorry JunoElysium 15 — 8y

That would solve the problem entirely, but I am thinking of doing a setting for minimal lag where the bullet's tracers will be a bit more blocky (lower raysPerSecond.) I've tested it, and a raysPerSecond of 12 has twice the bullet drop of a raysPerSecond of 6, so there has to be some equation to make sure they both have the same amount of bullet drop. The problem is most likely in line 22, as that JunoElysium 15 — 8y

View all comments (4 more)

Also, the time it takes to travel without bullet drop is the same throughout any raysPerSecond. JunoElysium 15 — 8y

fixed it, had to take the bullet drop and divide it by raysPerSecond squared, rather than just raysPerSecond. Thanks JunoElysium 15 — 8y

You'd have to change something in the part that calculates the drop using metersPerRay, maybe by using an exponential function of some sort. Keep in mind that the less frequently you cast the rays, the less accurate the drop wil be. aquathorn321 858 — 8y

At First I thought it was the accuracy of the ray's drops, but sometimes it would go 10 times the normal bullet drop. I did " generateRay(position, ((position-startPosition)+((dropPerSecond*2)/(raysPerSecond^2))).unit)" for line 22 and it worked. JunoElysium 15 — 8y

Raycasting Bullet Drop Issue?

1 answer

Answer this question