I am currently making a personal modular gun system that can integrate itself into most of my projects with relative ease, and one thing that i’m planning for it is for it’s visuals and their replication. As of right now i’m using the FastCast Api on the server to both raycast and deal damage AND also cast the visual effects like bullets and bulletholes.
What i want to achieve is to use fastcast for hit detection exclusively on the server and also using it on the client for visuals only. I can easily make bullet holes on client as that is just cloning a part in replicated storage and changing cframes. But bullet effects however im stumped on what method i should use.
Method im thinking of right now
When player A fires their gun, they create visuals for the gun they already have, while the server fires fastcast exclusively for hit detection and uses a remote event to :FireClient() every other client with the necessary information(Velocity, raycastparams, direction and origin, etc) so that all the other clients can simulate the visual effects for themselves, reducing unnecessary work for the server and it being much smoother as its simulated per client. While this is viable i am concerned about performance issues if multiple player’s are firing guns at high speed and there might be much work for the server constantly sending visual info for every client in a for loop.
Anyways, it is late where i’m at and if you have any ideas or more efficient method of what i’ trying to get then i would appreciate the help
I would recommend doing fastCast on server to avoid hackers, but funnily enough the creator of FastCast created PartCache, for all your quick part-creation needs PartCache which works with FastCast to cut down on server lag massively
I actually do this system for my mech game where each mech can have up to 4 fast firing guns and data transmission rates stay below 5kbs.
The way I did this was as you described. Have a client fire their gun. When they fire it gets sent to a client module where the module handles weather they are either a “sender” or “receiver”. If they are a sender they are the one firing. If they are a receiver then they are the ones observing.
After firing the module sends data to a server fire handler. This handler has only one job and that is to take data from the client and pass it to every OTHER client. so that’s, the gun, the spawn, the bullet data and everything else relevant. As well as weather they are a sender or receiver in Boolean value. Make sure when you’re firing for guns that have spread that you PRE CALCULATE IT otherwise spread will be different for every client. This also means you’ll have to send data for spread through the server.
Once the server has the data it simply tells every client to do the same thing. Each client has a client receiver script which its sole purpose is to simply draw the bullets on their end.
Damage I believe is handled by the server to some degree but client has the hit detection. It’s not the most elegant solution but I think the sheer complexity of code may deter some exploiters.
If you want extra security you might want to look into custom remote events which have authentic keys where the server listens for a client to send data with a certain key. Everything happens with only one remote event.
However if you manage to find a more elegant solution do keep me posted I’d like to hear more on this side of development. Either way for most games which only have 1 gun per player this can let you achieve phantom forces levels of data transmission for sure!
As for performance, simply from my own stress testing with about 5x4 guns firing at any one time with a 0.1s interval I experienced about 50kbs on the receiving with not much change to ping. This method is much more efficient than simply having the server do everything and a lot of games that use fast cast suffer from this. I’m talking about games that use the unedited FE gun kit. Simply guns that are server side and only one person firing at a high rate will overload the server with over 100ms ping even up to 200ms. This is because the server draws bullets for every client constantly and is also handling hundreds of remote events at once causing an overload. Having clients do all the work for themselves is simply more efficient. The server here just passes the data to each client.
I attempted the proposed method of data transmission from the video and from performance tests this is what i benchmarked
3 benchmarks
5 functions that instance parts into workspace (in the server)
each functions record tick() before and after instancing the part
0.1 interval between calls
started on runtime and ended on near similar times
Standard 1 remote event per listener results(1 remote events → 1 listeners)
in seconds
0.00017, 0.0000691, 0. 00006042
In conclusion having 1 remote event for multiple listener with keys perform slightly better. But these results may differ for how it’s run and what device since i tested it in studio
Interesting… and what of the peer-peer communication model? What about that? And honestly if the time your shaving off is less than 5% I don’t think it’s a significant factor it’s surprising how using one keyed remote event is somehow more efficient than multiple unprotected but I’m willing to call that more of a fluke. Regardless it seems that using protected events will simply be better in the long run.
