Making a combat game with ranged weapons? FastCast may be the module for you!

Resources Community Resources
#437

I dont know if your module allows it yet but you could have attachments act as the start position for the rays you do and have multiple of them i guess? much like how swordphin’s does it for his hitbox module i guess Raycast Hitbox 4.01: For all your melee needs! he has these dmg points he generate rays from (that can potentially solve hitboxes for wide projectiles)

1 Like
#438

Sort of. When it runs for the frame, instead of just incrementing forward by the frame’s delta time, it figures out how much it would increment forward. Using that information, it then attempts to split that length into a number of parts with the specified length (via the highest number of whole segments possible, e.g. if I have a distance of 11 and my segment size is 2, the amount of segments will still be 5). After doing this, it upscales the segments so that they fit the full length the closest (2.2 studs/seg in the given example) and then does a for loop, simulating each sub-segment individually.

The result is higher fidelity without sacrificing any frame time or anything like that. This can unfortunately be expensive though (if there’s a lot of segments) so it’s pretty easy to cause a lot of lag by using this.

I addressed this several times in my other posts. The short answer is “No, that’s not how I want to do it.” because it’s inaccurate. I’ll have a solution that works well in time.

1 Like
#439

FastCast is really cool. Big props to the creators.

1 Like
#441

This can be done in a loop using coroutine.wrap.

#442

Hey also I kinda figured out an issue I think with the client replication setup you showed in the video. If the server was laggy it’d do this.

1353×821 84.8 KB

https://gyazo.com/365b41ac36a988163e0420ad76684063

Basically the server might be laggy so maybe after 1 frame it’s position should be all the way there. Since your module raycasts to the next position and the projectile was supposted to be all the way at the endpoint based on the formula it would just raycast there. since the segments weren’t split into smaller segments it would just raycast to the endpoint skipping all the physcis. (When we include gravity)

Now the client must not have been laggy, so it would cover the full arc. Since the server projectile is doing hitdetection if the client hit in top of the arc it wouldn’t register because the server only did 1 raycast because of this lagginess.

Was this what the new update was supposted to solve, or was this already compensated in an older update?

1 Like
#443

This was already compensated for in the first release of the module itself.

This change helps with incorrect hit registry for physics casts (see the image – https://imgur.com/a/O80rc0D). It also makes certain operations like reflection a bit more accurate since the normal of the bullet is more accurate.

1 Like
#444

I mean that’s good but that’s not really the problem Im talking about. That only happens when the projectile is hit. What I mean is the projectile on the client has a super good curve and hits but on the server it’s lagging so hit detection is not registered because the server raycasts to the next point and doesn’t hit anything making it not do the extra high resolution check.

1172×323 31.3 KB

https://gyazo.com/7d3f15bc8e2209b6f03efb350d50b73f

This problem. basically a client has a smooth projectile it hits the target, but the server has a non smooth projectile so the server projectile doesn’t damage the avatar, since the compensation is only for when something hits.

That’s why one of the ideas I had for replication was the server constantly telling the clients where to put their local projectile every two hearbeats so the clients actually never desync they’re local projectile. The client’s will lerp/tween to this position. Useful for homing missles where over time the server and the client will dsync.

#445

What would be the best way to pass information in a bullet using PartCache, because I’m not entirely sure of how to grab an individual bullet before it is even fired out of the gun, making adding data to it impossible. If there is a good method to doing so, I would appreciate some help. I had done this prior without part cache, but I’m not sure how to do it with it now.

Basically I just want to have a folder with data like owner of bullet, the bullet the gun came from, ect

#446

I’m trying to use FastCast but with a knife in place of the blue bullet in the gun example. I can’t get the knife to spin though. This is what I put in OnRayUpdated():

cosmeticBulletObject.CFrame = cosmeticBulletObject.CFrame * 
CFrame.fromEulerAnglesXYZ(1.3,1.3,1.3)

Can you help me figure out what’s wrong?

1 Like
#447

Haven’t fully used this, but by the looks of it and reading I’m pretty sure you’re supposed to be connecting to Caster.LengthChanged, which should fire every frame because the rays are updated every frame, iirc. Try that instead of OnRayUpdated

That or, maybe make sure you’re referencing the actual knife projectile, and not anything else.

#448

You shouldn’t do hit detection on both client and server, so this shouldn’t actually be a problem.

Generally speaking, the setup is that the server does the hit detection (in which case you would enable high fidelity casts), and the client does the rendering. Recalculated casts aren’t actually visible (not only does LengthChanged not fire for a recalculation, but it also is doing multiple segments within a single frame - even if it did, it wouldn’t even be visible). In this context, the client should listen to an event from the server to know when to terminate (server fires an event, client receives that event, calls cast:Terminate())

If you need to do hit detection on both client and server for some gameplay model you’re doing, then the best option is to always enforce a specific cast length.

Using the UserData table of an ActiveCast should work in your case despite this problem. If you immediately set it up after firing the cast, then there’s no chance for any desync or anything caused by data not existing when one of the Caster’s events fire.

You’ll need to keep track of a rotation value. I recommend using the UserData table to store this.

Here’s the basic idea. In the fire function, find the line that’s calling :Fire() on the caster, and add a new value to its UserData table.

local cast = Caster:Fire(...)
cast.UserData.Spin = 0

And then in the LengthChanged event handler (OnRayUpdated) do this:

function OnRayUpdated(cast, segmentOrigin, segmentDirection, length, segmentVelocity, cosmeticBulletObject)
	if cosmeticBulletObject == nil then return end
	local baseCFrame = CFrame.new(segmentOrigin, segmentOrigin + segmentDirection)
	cosmeticBulletObject.CFrame = baseCFrame * CFrame.fromOrientation(cast.UserData.Spin, 0, 0)
    cast.UserData.Spin += math.rad(30) -- Some number here to determine the speed.
end

That should work for you ideally. If you want a spin rate (so that lag doesn’t make it seem like it spins slower) then there’s a slightly more complicated method that could be done where you base the amount of rotation on how far the knife traveled in that single frame (via using the length parameter).

1 Like
#449

Thanks! Got it to work.

I’m sure you’ve heard this a lot, but thank you so much for this module. You’ve made my life a lot easier. Also props to you for being so active and answering everyone’s questions. Keep up the great work!

2 Likes
#451

Though unlikely somebody would have a gun such as your test weapon, if you shoot in the very wedge/corner of a part your bullets can no-clip through.
Ex: https://i.gyazo.com/1af2be062ef16d23316fe792f2d54ec4.mp4

#452

There’s most likely a really small gap there. Unfortunately there’s no way to set the thickness of a raycast, only its length. So since the raycast is insanely thin, it’s probably not detecting a hit because it’s smaller than the gap, but the bullet, which is just the visualization of the raycast (that has size) appears to be hitting something. But, the bullet’s not doing any hit detection, the raycast is.

Or, it could just be a Roblox problem.

#453

no it’s a legitimate glitch
if you make the parts clip through each other and you aim at the seam you can slip projectiles through…

#454

@EtiTheSpirit Sorry to be a nuisance but I updated my fastcast version and found that partcache doesn’t function when trying to fire models. Any way I can edit partcache in order to support this?
Thanks

#455

Yeah it should be easy to do that. PartCache’s code is incredibly simple (compared to FC, at least) so changing it to use a model instead of a BasePart shouldn’t be difficult at all.

3 Likes
#456

OK I’ll mess around with it TYSM

#457

I’m having slight issues with the physics. Whenever I try to disable the bounce reflect function it disables collisions. Is there something I’m doing wrong?

#458

Could you make a super simple gun that just shoots one bullet at a time. So the script isn’t so complex.