It’s likely related to how you’re removing it. Run through the code yourself and see if it makes sense that it might be just not colliding.
Yeah I could see to making a more lightweight demo.
2 Likes
There are absolutely zero gaps, it’s an actual glitch.
I can’t get rid of the bouncing without disabling the hitboxing I’m so frustrated
Apologies for the delay. I basically took the existing example gun and trimmed out the fat. FC Simple Gun - Roblox
I don’t know if this is what you wanted, but it’s certainly a lot less information to take in. You will need to make use of the API pages in all likelihood as I did remove comments from it (for the most part) and change some stuff.
3 Likes
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