Right now, this is not a bug but is instead intentional behavior. I can change this behavior later on, but swapping parent on the fly is not something PartCache is designed to do (And I want to avoid specifically updating it to meet FC’s needs if I can).
2 Likes
Ah nvm. sorry. I didn’t read the CosmeticBulletContainer documentation.
I solved my initial problem by adding a tag for every bullet, at fire time. In CastTerminating i removed the tag. In CharacterRemoving i delete every part thats has this specifig tag. Its not the best soloution but, its the only thing i got to work.
Ever thought about adding an ammo system to the example gun? That would be much appreciated 
1 Like
I’ve abandoned my v2 engine and just go back to the old one (using sphere parts as the bullets). If I figure out a way to do it in my spare time i’ll post it here.
Hey so for bigger projectiles in my module, I use a rotated region3 until the next destination. Kinda like you raycasting to the next point, except me region3ing to the next point lol. And to get the surface normal I cast a ray to the hit parts and get the normal from there. it took me a lot of optimizations to get region3 efficient though, such as region3 caching reusing region3s if it’s the same position.
This might be useful for you since support for wider projectiles would be really cool in a fast cast.
https://gyazo.com/758bf691bd217b36b910677a2cb6ad69
Upcourse though I do this in my module, I let myself in the constructor input the width of projectile, if it’s low and doesn’t need region3 I do raycasting.
It could work, but the issue is that anything even sort of expensive should be avoided. The cast needs to update within, at the very most, a single frame. I can look into ways to do wide projectiles if that’s what people really want. I need to push v13.2.0 pretty soon here (I might just do that today, since I can scrap one of the methods implemented without any big losses), and after 13.2.0 is live I can look into this.
3 Likes
I figured it out BTW. I am just not that smart XD
1 Like
I’ve noticed this when adding the new version to my project:
is it a problem for you to add a version with rojo/emmylua type definitions? I’m not sure whether the LSP plugin supports roblox type definitions yet.
HUGE BUG LINE 333 OF ACTIVECAST YOU DO
velocity = direction.Unit * velocity
RATHER THAN
velocity *= direction.Unit
Not a bug; that’s a shorthand. They both do the same thing, ones just shorter than the other.
11 Likes
Im trying to make a gun, but it doesn’t work, I am really bad with all this module and vector stuff so I am probably doing everything wrong:
local castModule = require(script.Parent:WaitForChild("FastCastRedux"))
local newCast = castModule.new()
local newCastBhaviour = castModule.newBehaviour()
newCast:Fire(
bulletOrigin.CFrame.Position,
mouse.Hit.Position,
Vector3.new(mouse.Hit.Position) * bulletSpeed
)
Then I am getting an error on this line:
1 Like
It’s spelled behavior, you wrote behaviour.
4 Likes
I can’t figure out why are there performance issues for the life of me
Okay so this might be a longer read but I’ll try to write down any info I can.
Obviously it’s called FastCast and everyone is saying that they have great performance. However I’m having major issues with performance. My target is to have 8 players on the server, who can be firing at the same time causing minimal lag to none. However already when just two players are shooting the script gets so demanding that the server ping goes up and everything starts to lag.
I’ve tried disabling every part of my script to find out where the performance issues lie:
- Validity checking if enough time has passed since last shot and many many more validity checks cause barely any lag on the server
- Ammo counting, no impact it’s just a couple of variables and a intvalue instance
- Effects also cause little to no impact(this includes muzzle flash, reload effects, cosmetic bullets)
- So the only thing left is the FastCast module itself and it’s causing quite the lag from what I can see in the Script Performance window.
I wanted to quickly check how does the example model blaster peform and it’s very costly on the server even for one person firing the weapon(the activity goes up to even 30%, damn)
So I’m wondering, am I doing something wrong or is the module not that optimized(no offence tho it’s an amazing module).
Another piece of information I can provide is that I’ve had quite the struggle to get fast cast implemented with my tool script which handles all the tools from one script instead of many scripts inside the tools.
My method was to create a multi dimensional table containing the player and everything needed to fire their caster. A new caster is created and put into the table instead of the old one whenever the weapon needs to change. To fire, the caster is simply requested from that table.
Hey! So, I’ve been messing around with this module for a while, and I’ve been trying to get the gun to fire ONLY when the mousebutton is up or just fully clicked, do you have any idea of how I could go about doing this? I’m using this version of the module. I am aware that this might be quite a dumb question, but I’m still not that experienced with scripting. Thanks!
Edit: I’ve found the solution, apparently I didn’t write my code correctly. At around line 150, I wrote down this code.
Tool.Activated:Connect(function()
CanFire = true
end)
Quite a simple solution, but I didn’t really pay attention earlier.
I think there have indeed been unwanted performance regressions. I am working on fixing them. They came around after the addition of ActiveCast which makes sense considering it has changed from a simple event connection to an entire object to keep track of.
You’re interested in Tool.Deactivated, which fires when the mouse is released.
1 Like
Version 13.2.0 has been released!
This update has a number of good changes that you can read about here.
Most notably, cast resolution enforcement has been added! This means that it’s now possible to always cast with say, 1 stud long increments. This is great for physics simulation as it promises more accurate - and more importantly consistent - results regardless of latency or lag.
I’ve also fixed a mistake involving how I import types. I was unaware that you required a reference to the module that instantiated the type – that is, Module.MyType rather than just MyType. Whether or not this has performance or behavioral implications is something I haven’t really noticed.
3 Likes
You broke it 
studio now stops responding if I try to add the model in. Only crashes with fastcast, can insert any other model from the toolbox, but not fastcast
2 Likes
^^^
Same problem as above, inserting the model causes my studio to crash.
Only for the FastCast models
Interesting! This seems to be a side effect of the Lua script analysis beta @NinjoOnline @20amir02 – disable this beta feature and then insert the model. It works fine there.
I’ll get this information to the right people as soon as I can. For now, you’ll need to disable the feature, I’m afraid.
5 Likes
Thank you for the solution, now i can use this module.
One roadblock I ran into is that I’ve been getting errors when I try to terminate the ActiveCast in the Casters LengthChanged event.
I seemed to stop the errors by adding a check in between the lines in the module.
SendLengthChanged(cast, lastPoint, rayDir.Unit, rayDisplacement, segmentVelocity, cast.RayInfo.CosmeticBulletObject)
if not cast.StateInfo then return end
cast.StateInfo.DistanceCovered += rayDisplacement
Though I do feel like there could’ve been a better method. Just letting you know.