You’re running a slightly out of date version of the module (11.0.0) – The latest version is 11.1.0 which has changed it to what the API mentions now. Apologies for the confusion.
Something kind of weird, In studio the module performs fine but on a live server it barely works at all, even firing a single bullet a second from one player is causing my ping to spike from ~80ms to upwards of 300ms. This is using the debug gun with nothing changed, so i don’t think it’s my code. Any ideas why this could be?
Here’s what I mean, sorry for the framerate being a bit choppy. Recorded this on my laptop
Studio:
robloxapp-20200826-0212530.wmv (1.3 MB)
Live Game:
robloxapp-20200826-0211526.wmv (1.4 MB)
This is on an empty baseplate with no other server-side scripts running so I think it has to be the module, unless I’m missing something. It kind of looks like the lag begins after the first ray is destroyed, as the bullets seem to be smooth until the first one hits the wall at which point it becomes very choppy
There seems to have been a number of unexpected regressions in performance. I’ll have a look.
I was not able to nail down why the performance issues would occur (with the exception of instantiating ActiveCasts, but I don’t know how well Luau handles that).
I did, however, fix a bug causing the Set methods to not function properly. Version 11.1.1 fixes an issue where calling Set
methods (for positon/velocity/acceleration) would add it instead, and where Add
methods would actually add the input value * 2.
These methods now function properly, set will now directly set the value, and add will now add the value.
Thanks for taking a look at it, could you reupload the previous version so we could use it in the meantime? The current version doesn’t feel useable in its current state
Yeah. Here it is. Example gun won’t be backported. API V1 is still up on the Github so you should still be able to refer to that. FastCast Legacy - Roblox
Thanks for all the work you put into this
I’ve done an update to the new version of the module and it seems to perform pretty good now. It’s not perfect but it seems to be better.
When Luau strong types are complete, I will be optimizing the module with it as best as I can.
Wait why are you using a hearbeat loop for each bullet fired why don’t you just loop through the bullets in one hearbeat loop.
I can’t say for sure as I am not the OP but I think the reason behind this is because it’s easier for each Bullet to have its own Heartbeat Connection, and if a loop is used for one Heartbeat Connection it causes a situation in which the last item in the list is reached a lot slower than the first.
TL;DR, to process all bullets simultaneously instead of sequentially.
Doesn’t lua run on a single thread anyways, so wouldn’t one hearbeat get executed first and then the next connection, ect? Or is it because the speed that the next hearbeat connection gets executed is faster then looping to the next item?
Months later and no reply. Feel free to chime in here…
You didn’t show any of the code you use or the code you edited in the module. How are we supposed to help you? guess the problem?
Because management of the connections is difficult. It used to actually do this but it caused a mess because yes, lua is single threaded, but you need to remember that each cast runs in its own coroutine. This can cause concurrent table changes (and did during testing) which often caused bullets to be missed. Yes, I did use custom indices.
Having a connection per cast is far easier to manage since I can just tell a cast to disconnect itself rather than having to keep track of its index in a table for a completely different class and telling it to remove itself from that table, potentially when other entries may be removed or added before it.
I don’t know if this is intended or not, but I intend to make the bullet fire really slow so I can have a spreading effects when the bullet is generated, I found that if you do that and walk forward the bullet fly faster then the intended value.
Since in the example gun the bullet inherits the velocity of the humanoidrootpart, so if you move it adds the velocity of the humanoidrootpart to the bullet, (it’s also how it works in real life to)
Best to add that to acceleration. I believe that the HumanoidRootPart velocity thing you mentioned was commented out in the debug gun.
Hmm let me check, I remember it being there but I might be wrong.
Hmm no for me in the debug gun that code isn’t commented out.