Yeah I don’t know why that was removed… Hm. I think it was for something in debugging to test the odd pierce behavior reported some ways above.
It’s been re-added.
I can say one thing is that and does not join arrays together. In Lua, and will select the only non-nil operand, and if both are not nil, it always selects the operand on the right (so in your case blacklist is only Cannon:GetDescendants() and nothing else).
Inside of the FastCast module is a utility module called “Table”. You can use this if you’d like, simply do local table = require(FastCastModuleHere.Table). After you have my custom table module overwriting the stock table option in scripts (via that line just above), you can use table.join(projectiles:GetDescendants(), Cannon:GetDescendants())
Those replies aside, FastCast 10.0.2 has been released to fix the bug mentioned just above. Additionally, there is now a prototype of the module that uses’s the Luau Strong Type Beta feature included in both models! This should ideally run faster than the actual module (though I don’t think the speed increases will be that notable). Do note that this will not work in live games yet, and you need to enable the beta feature to actually use the module in the first place.
I got bullet reflecting to work! This module is legit a lifesaver. I tried several physics based approaches previously and none of those methods worked nearly as good as this has so far. The crazy part is that I can combo automatic fire, fast firing speed, shotgun pellets, and have all those bullets ricochet and it’s still fast - literally no lag. Just feels so unbelievable. Thank you so much for making this!
Awesome work! I’ll release a feature for this officially when I release the ability to alter trajectory during runtime (so it will be using considerably different code than what you have).
The only real issue developers may face is that this is going to be yet another complete restructure of the API + events. I’ll get into the details later down the line, but the basic gist is that casts that are currently being simulated will be their own objects.
Will you be updating the module to support the new method of casting rays? WorldRoot:Raycast() which also takes RaycastParameters and returns RaycastResults?
Maybe. I don’t know. It depends on how necessary it is. For recognition of modern API? Sure. If I do it, I’ll make a caster able to work in certain specific world contexts too for support in things like ViewportFrame, but that’s for later.
Alright I’ve been doing some API changes for the update that allows redirecting the cast in realtime. This is not live yet, just in the works.
Here’s what I have so far, if you all think I should add or change something, let me know.
First things first. Under this new update, calling Caster:Fire() will now return an instance of a new type called ActiveCast. ActiveCast offers a number of important methods, including:
ActiveCast:GetPosition, ActiveCast:GetVelocity, and ActiveCast:GetAcceleration (as well as methods to set this data too). There is also AddVelocity and AddAcceleration for gradual changes.
These methods will allow you to alter the trajectory during runtime. Should be self-explanatory.
ActiveCast:Pause, ActiveCast:Resume, and ActiveCast:Terminate
Pause and Resume should be self-explanatory. A paused cast will be frozen and not simulate. Events will not fire, and the bullet will not move nor will time increment.
Terminate will cause a cast to end early. It has a boolean parameter called skipRayHitCall which, if true, will cause the RayHit event to not fire when the cast is terminated. If false, the RayHit event will fire with its default empty args, exactly like when a cast times out and hits its maximum distance.
Secondly, events are changing just a bit. The core Caster object will still have its RayHit and LengthChanged events, with the exception that their first parameter will be a reference to the ActiveCast that caused those events to fire. On top of this, ActiveCast instances now have their own separate events for RayHit and LengthChanged that function identically to what you are used to right now.
On top of this, I’m adding methods to dispose of casters. There is an instance leak for the signal objects. calling this new dispose method will delete the bindables that are used for events.
Any opinions on this structure? Anything that should be changed?
Finally got FastCast to not be framerate based. This gif should show it well. Sometimes it has a few small wonky points which I have no idea whats causing them
I’ve been having trouble getting this to fire models instead of parts. The projectile glitches out and I can’t orient it properly. Any ideas on how to achieve this?
So ive been using fastcast for my fps game and just ran into this problem today
ive tried anchoring and unanchoring, putting the bullet part position to 0,0,0 and turning on and off can collide, but the the bullet part still seems to be coming from under the map?
has anyone else encountered this problem before? this all seems to have come completely out of the blue and there are no errors in the output so i really have no idea.
I had this problem aswell and the way I fixed it was by using this Model | Documentation - Roblox Creator Hub
Example: Bullet:SetPrimaryPartCFrame(CFrame.new(FirePointObject.WorldPosition, FirePointObject.WorldPosition + Direction))
But basically i just switched it to setting PrimaryPartCframe(the primary part value of a model) instead of setting a parts cframe and this fixed it.
NOTE: this was done on a way older version of this module so it might have to be used somewhere else now.
i got a problem where ive added terrain water to the if statement (enum.material.water) of what the debug gun can pierce. but then once it goes through terrain water it goes through all terrain. any way to fix this?
@isaiahbur I tried that method a while back but it didn’t work. The Model fires in the right direction, but the cosmetic bullet jitters all over the place and is not rotated properly
I’ve addressed this three times in this thread. Two of these times have been spent responding to you. See Reply #254 and Reply #278. My answer is the same as it was there before. Please stop asking, it’s not adding anything good to this thread. https://www.youtube.com/watch?v=0d6yBHDvKUw.
Try something like this. A minimum of 0.2 means that if they click and instantly let go, they get some speed (but very little). maximumTimeHeld should be what the variable name describes - the longest time you can hold it. If you hold it for longer than this value, you get no gain.
