No–ModuleScripts are simply modularized scripts, meaning that they can be repurposed and used, almost limitlessly, by other scripts. They have nothing to do with links whatsoever. I personally recommend that you read through this developer wiki article on ModuleScripts, or search for tutorial videos on YouTube, to learn more about them.
NOTICE: As is typical with major version changes, this API is absolutely not compatible with legacy versions! You will need to rewrite your scripts too.
Changes:
Fire method takes in less parameters and uses RaycastParams as one of those parameters.
New API for raycasting is now implemented.
Calling Fire now returns a new object called an ActiveCast which allows for controlling the ray during runtime.
Highlight: ActiveCasts
ActiveCast is the name of the new object that represents an individual bullet. A new instance is returned every time the Fire method is called.
They have three sets of methods: Setters, Getters, and Adders. Each one of these sets has three methods to affect velocity, acceleration, and position on the fly! (cc @Telosmos, @Fire540Games, @GFink)
There is a list of each individual section of the cast’s motion! To get the dynamic stuff to work, casts had to be turned into piecewise functions. The table storing the data for each piece is exposed (check out the API) so you can do whatever you might want with the information.
Casts are pausable! You can freeze bullets in mid air and then unfreeze them as you see fit.
Casts can be terminated early! Don’t want a bullet? Just :Terminate() it. (cc @iiNemo)
New event: RayPierced – It’s RayHit, but it fires when the ray pierces something instead. (cc @ki2005rill)
Once again, everything is on the wiki, so if you want details, you ought to have a look there. An example gun + the formal update will be released later. If you want to test it, let me know if anything breaks or whatever the case may be.
Very intuitive that casts can be manipulated during their runtime. I like Pause and Resume especially. Also having access to data at each new raycast outside the old LengthChanged event is helpful.
Side note here, aren’t these three functions pointless/bloat if we already have the ability to retrieve and update the properties listed (position, velocity, acceleration)? It seems to me you could just do Cast:SetVelocity(Cast:GetVelocity + x).
I can’t really read the source code at the moment but im assuming all the bullets are created on the server, or are they created on the server and the client, server raycasting for hit detection, client raycasting for visuals.
In my module I do that, make bullets on all the clients for visuals. Server for hit detection. And bump up the servers bullets position based on the time pinged, and all the other clients to based on how much it took time from the shooter to the server pinging a client. The server destorys the bullet “data” it’s doing for raycasting when hit or after 400 studs. The client does that except the client uses a physical bullet
The reason Im asking is the module your doing is super efficient like mine and im wondering if your managing it on the server or the client. My thing can make 60 bullets a second to with absolutely no lag at all , and im wondering if thats good. The problem with me for doing it seperatly on the client and the server is that I can’t make a scalable solution for changing trajectios on the go, since the server would have to update the bullet with an id to all the clients. And this brings a lot of edge cases what if the clients bullet is already destoryed, ect.
Module scripts are nothing more then a script which returns a table, and that table can be used when you call require(). They are normal scripts that’s why you can run normal code in them. The only difference is modules only run one time, so after you call require() on the module once the module just returns the reference to the table made.
Basically only difference between a module script, and a normal script is module scripts have the ability to actually return stuff, which can be used by other scripts.
The module is a module. The side it runs on is the side that its required on. This means that to split workload across server and client, you have to require it on both the server and the client. It can be used for both simulation and for simple rendering with the same API (for simulation you can have no cosmetic bullet + do damage on hit, and for rendering you can have a cosmetic bullet + do nothing on hit). The ideal case would actually be to not link the server and client. Have preset bullet behavior and just have them execute that behavior in their own little bubble. Of course this may not be possible in all cases, but for the client render bullet, you could just use the new API to manually terminate the client’s bullet when the server says it’s hit.
As for performance of the module I have been able to test cases of over 300 bullets/sec without lag. I think it can go higher but I haven’t bothered to benchmark past that point.
Oh I was just asking since I had a misconception of it automatically doing it for you, since devforum post was talking about it in an other topic. Also when I used the example gun it was kind of laggy with 60 bullets a frame on my very low end computer, I disbaled effects debug mode ect. Im guessing it’s because of serverside rendeing, and the low end computer I used is pretty bad.
In my projectile class, Client does raycasting for visuals, server for hit detection. Im guessing with client rendering fastcast would be super efficient. But this brings problems as dynmically changing paths would be hard.
I think I woudln’t do this when a bullet hits something I want the client to have immediate visual feedback. I don’t want the extra delay time fired from the servers offsetted bullet. Even with lag compesation the server bullet is offsetted in the left a bit, in my module.
How many raycasting operations did you get per frame at max? I never tested but im sure roblox can handle 1k raycasts. Also I found a piece of code which was kinda redudant in my opinion, im not to sure if its in the new verison would you mind if I share it to you? Nevermind it’s fixed in the new version.
WOW! Thank you very much!
Unfortunately I can only build. Trying to wrap my head around the coding part now, but this is quite complex stuff for me.
I am making a racing game and plan to launch some arcing fireballs from the vehicles forward, so I was really happy to find your module and hope to be able to do that with nice instant feedback for players and no lag because of the server.
I managed to make a version with a physics fireball objects created on the server but than that is quite laggy.
I also need to figure out the part where the projectile goes faster forward when the vehicle is moving forward and is launched slower when moving backwards while shooting.
You know this thing: https://www.youtube.com/watch?v=BLuI118nhzc
You need to add the velocity of the car to the bullet. When you shoot something with a gun, the shot thing’s velcoity isn’t just striaght out from the gun it also includes the velocity of the gun if the gun is moving.
Just add how much the car is moving to the velcity of the bullet to get the calculated velocity of the bullet. It should work since it works in my projectile module to.
Oh and for the arc just use a bullet drop formula it make’s the bullet look like it’s traveling in an arc. If you want it simulate an ark like when you throw something in real life use the projectile motion formula.
Alright. FastCast 11.1.0 has been released to address the recent issues. THIS HAS MORE BEHAVIORAL CHANGES.
The rough overview:
+ Added new CastTerminating event to Caster which fires before a cast terminates.
* ActiveCast no longer has events. They are now in the Caster object as before.
* Changed the way ActiveCasts are updated.
- RayHit no longer fires if a cast reaches its max distance! Only Terminating fires.
So one of the big things you need to do is no longer destroy your cosmetic bullet in RayHit. – You should now destroy that in the RayTerminating event. RayTerminating fires whenever the cast ends, RayHit only fires when the ray hits something. This means that if the ray hits something, both events will fire (RayHit fires first, CastTerminating fires last).