Rather than crudely using this thread as a soapbox for your own preferred module, how about you mention the issues with the docs so that it can be fixed? There’s a fully commented example gun and full documentation including on internal objects, and I thought that’d be enough (and it is, for most)
4 Likes
What is an efficient way to resolve the issue with bullets freezing and staying permanently if the caster dies? I don’t really understand the solution above. This issue should probably be resolved within the example gun itself as it happens there too.
I tried putting the server scripts from the weapon itself into ServerScriptService, which sort of resolves the issue. I’m not sure if that’s a proper way to do it.
ive noticed that when using higher speeds, the bullet starts further and further away from the firepoint. Is there a way t make the bullet actually follow the raycasts and start at the gunfirepoint when firing at high speed instead of starting like 200 studs in front?
I am not completely sure on how FastCast operates internally, but after reading about it briefly I think I have an idea. If the bullets are framerate dependent this means the next position of said bullet would be calculated using the current Heartbeat fps value.
For example, if you wanted an object to move at a rate of 10 studs per second you could make the movement frame dependent which will accurately update the position even when framerate dips. If we assume Heartbeat updates at a fixed 60 times per second we can use its delta time (time since last update) for calculating how much to update a position value in a single frame. This can be done by multiplying the speed by the delta time.
10 * (1/60) = 0.1667 studs per frame
To verify this value, if we were to multiply it by the amount of frames per second it would give us 10 (might be a little off due to rounding).
0.1667 * 60 = 10 studs per second
So these large gaps you are seeing is probably due to this fact. For example, if the speed was instead 2000 then the math would look like this:
2000 * (1/60) = 33.333 studs per frame
This is obviously a way bigger number and what it means is that every frame the position displacement would be approximately 33 studs.
The only way to really remedy something like this is to modify your system to still be frame dependent but also update multiple times per frame. Now this obviously has its limits; too many updates per frame might be too much to handle in one frame.
Anyways that’s just a little insight on what your issue might be related to. Also I realize Heartbeat does not update at a fixed rate, but the value was just for example purposes.
And feel free to correct me if I’m wrong about the internals of FastCast. I haven’t taken the time to read in depth about it.
2 Likes
It’s mostly a render issue. The cast will start from the fire point but won’t render until the first update (the first call to LengthChanged), which occurs on the next frame.
4 Likes
Hey man, I was curious so I tried out your test gun today. I just made a new place in Roblox and your gun keeps inserting itself into my game when I press “Play” or “Play here”. I have no idea how this happens but it’s pretty annoying.
Here is a video. As you can see I do not have the gun anywhere in my game. It also generates an insane amount of errors, which isn’t caused my my script since it only has 1 clickdetector function in it.
https://i.gyazo.com/42ae6c4028aefa4dd3f046ae719d0071.mp4
https://i.gyazo.com/2d4373c96c7473bd2860b09295e13d2e.mp4
Like many other users I’m having trouble with the player dying, bullets not being removed, and freezing in place.
I’m using the example gun. I have FastCastRedux and PartCache script hierarchies in ReplicatedStorage. When the Server script of the gun starts, I have it parent itself into ServerScriptService, which does let the bullets continue rendering after the player dies.
This only partially resolves the issue, since now every time a player respawns with the gun, another copy of the server script is moved into ServerScriptService, which means I now need a method of detecting when all bullets of a caster have been terminated so I can remove the old server script. Is there a solution to this? What is the preferred method?
I feel like for a module that is designed to make guns that kill characters, making it work properly after a character dies is not easily done, or at least is not considered what should be default behavior, or am I missing something?
I’ve read through many of the replies in regards to this issue, and have taken the steps suggested (moving the server script out of the Tool itself) but as explained above that only partially solves the issue, since now you have to figure out how to dispose of the old server scripts which are still rendering bullet objects from characters who have died.
Do I need to tag each gun and have the same server script check for new guns and create casters for them rather than have a server script for each gun?
At this point it seems like it would be much easier to store each cast on the server script and destroy all existing bullets when the character dies rather than try to let them keep rendering.
edit: the solution I’ve come up with for now is creating a table on the gun server script called ‘allCasts’. In the Fire() function I add the simBullet object to the allCasts table. I create a Tool:Unequipped() connection that loops through the casts and calls cast:Terminate() on them. Not the ideal solution but seems to work well for unequipped the tool and character death.
1 Like
then how would you render it when immediately?
@EtiTheSpirit
Hey, a question in regards to multiple weapon visuals. I have one Caster and one Behavior on the client handling all bullet visuals every time a request comes in, just changing the Acceleration and other Bullet Specifics on the spot before firing. Is this an acceptable way of handling it?
Hey, I need help again…
I want to use the casterRayPierced event to change the FilterDescendantsInstances array when it bounces off of an object. To be more specific, in order to do this lightsaber deflect thing, once the bullet pierces the saber, the character model of the person who blocks it is now inserted into the FilterDescendantsInstances. I put that code into the casterRayPierced event, but when I get casterRayHit back, the filterDescendantsInstances are the original ones from the start.
I know there is weird behavior with the RaycastParams object. Can you guys give me some insight on how to edit RaycastParams of the ActiveCast through the pierced event?
EDIT:
I have a workaround, but it’s pretty bad:
In your canRayPierceCallback, instead of returning true, instead, always return false, and in the cases that it does return true, call caster:Fire(…) again with the new parameters, whilst also having a new RaycastParams object there. Seems to work fine for me so, but I would really like to know how to edit RaycastParams in the rayPierced callback. It seems like re-firing the caster isn’t how this module is intended to work.
EDIT 2: I found the solution! apparently querying RaycastParams points to a copy, not the actual one, so instead, you have to make a separate table, then set the params new property to that. You also must put this in CanRayPierce, not RayPierced.
1 Like
I moved the server script into ServerScriptService, adjusted it a bit, so all “guns” works off that single script. Not sure if it’s a good idea but at least the bullets don’t stay in the air anymore.
This is the ideal way to do it. A master script that serves as a unified spawner for all bullets of the same type.
Would it be possible to visualize the projectile’s trajectory with beams when using this module? Say, something like this. A use case example would be if you want aiming to be easier for users in your game.
I’m having issues with armour pieces blocking the bullets from damaging a target. Is there a way to whitelist them so that bullets can go through them?
Also, is there a way to maybe have each bullet act as a straight beam rather than individual bolts?
If I had to guess I’d say that the “GunFirePoint” isn’t exactly where it should be, since bullets should start at the position of the that fire point attachment.
@Xan_TheDragon
Is there any plan to implement the bullet penetration system based on the part’s thickness?
Since I’ve tried using this method, for example, BasePart.Size.X/Y/Z but it doesn’t work accurately since if the projectile is coming from the x-axis but the code check for the z-axis part size and I don’t know how to check what axis of where the projectile is coming from.
I’ve tried using this method but I can’t get it to work using your FastCast system.
2 Likes
I’ve implemented bullet trails in my game. The issue is that they don’t replicate very well from the server to the client. Do you think it would be a good idea for the server to simulate the cast as well as send the cast data to the client so the client can create the cast locally and simulate the trail.
I’m sorry, i replied the wrong person, but when i do this, it give me an error ‘‘Cannot statically invoke method ‘ReturnPart’ - It is an instance method. Call it on an instance of this class created via PartCache.new’’
I am using this in my game to power dodgeballs. It is creating a lot of network issues. Players lagging and jumping around etc…
I used the example raygun provided, changed it to be a ball shape, and to only shoot one ball every 1.5 seconds. Any ideas on why its causing such significant network jitter when there are only ever 4-5 balls bouncing around at any given time?
Is there any way to prevent shooting through walls?