I believe you made a typo here, you forgot to edit the second table A1 and instead copied it over to A0 instead. Just a small mistake,. It should be:
A0.WorldPosition,A0.WorldAxis = Vector3.new(0,0,0),Vector3.new(1,0,0)
--A1 here
A1.WorldPosition,A1.WorldAxis = Vector3.new(0,50,0),Vector3.new(1,0,0)
It seems that when ran on the server, the lightning doesnt show on the client… so using a ServerScript for creation wont work, this can only be achieved on the client if ran on a LocalScript by Client Replication, do you think there should be a function that automatically client replicates when ran on a server script?
You shouldn’t do it like that anyway as it unnecessarily uses server resources + the effect would only run as fast as the rate at which you receive data from the server and so will appear ‘jumpy’ at times.
I can’t assume what frameworks/modules others might use for replication. It would potentially create an inconsistency within their framework. Also, I don’t want to force how users want to set up their replication → For example, they might want to use string.pack to send over replication data or might not want to send any extra data at all as they instead want some electricity “door” (with pre-defined Lightning properties) to just open/close.
The ideal setup for replication is mentioned in the solution of this post.
titan shifting is perfect now THANKS!
I’m using this module for a lightning skill, and I need the lightning to be on a specific part, and that part will be moving, and as you know this lightning needs time to “update.” Is there any way I could have the lightning “locked” to this one part?
The module should be able to do this pretty easily.
You can use Roblox attachments as inputs for LightningBolt.new.
The attachment(s) should be parented to your specific Part.
Not really sure what you meant here but if you’re still unable to achieve what you want, send a repo file
I’m already doing this.
What I meant by “update” was for example the part that the attachment is in moves the lightning takes a few seconds to come to the new position. If you still dont understand i’ll send a video of what I mean.
how can i make my lightning effects brighter? I made some effects with it but its not brighter
If you don’t mind me asking how does this work with the image handle adornments and stuff?
Any update on this v2?
Great resource, and thanks for opensourcing this!
This has far better effects than I could ever create!
I used to make (unofficial) gears for other people previously, and I would store this module inside the gear for it to be used in VFX, obviously this is terrible practise but it is supposed to be like that because I was supposed to give these “gears” to other people, gears on Roblox have to rely on itself for asset storage and not the game its in so yeah, multiple copies of this gear inside a game would basically just not work well with this module which is why I called out “memory leak” which was the wrong thing to do.
I still use this module to this day and it works fine with minimal memory leaks because I use it properly now lol
I made this edit now cuz people still like this reply even though its baseless and wrong so now if people read this then yeah.
Heartbeat Waiting is pretty harmful to the server and client (Free permanent FPS drop) especially if its used on a long lasting script.
LightningBolt.Loop = game:GetService("RunService").Heartbeat:Connect(function ()
if not (script:IsDescendantOf(game)) then
LightningBolt.Loop:Disconnect();
LightningBolt.Loop = nil
return
end
for _, ThisBranch in pairs(ActiveBranches) do
-- E.c.t
its also pretty useful to return the loop, so it can be stopped manually.
EDIT:
This alternative above WONT stop the full memory leaks, it will just stop it if the modulescript gets deleted
I looked at the code in the linked repository and it’s perfectly fine. It only considers active effects on each iteration, so if there are no active effects it will be a no-op. This is so little compute waste that it’s not worth worrying about.
This makes no sense to me. Whether you connect and disconnect to Heartbeat many times or do that same work in 1 connection, it’s similar workload.
The Memory leaks appear fine once you run it a couple of times or two, but in a full server where the effects are constantly appearing, then it could lag the client/server,
I don’t see any potential for the code in the Github repository to memory leak – care to point out the exact line for me?
I believe he is talking about the Heartbeat loop. Technically he’s right in that the loop is in the body of your script, so it can unnecessarily hold outside variables (I’m not sure how this behaves currently but I last checked this about two months ago). That can be fixed by wrapping the loop in a do end block so the contexts are separated.
Additionally, I’m not really sure on the details as usually I try to very strongly avoid this, but, having a constant event connection does seem to lead to gradual performance issues, albeit very minor. I think it has to do with the thread scheduler though I’m not familiar with the internals of that, I’m wondering if what happens is the thread scheduler slowly falls behind so it slowly fills up the queue over the course of hours and hours of a server running.
I never have a heartbeat connection open long enough in any of my games to worry about it but I would definitely say that the thread scheduler is wack and you probably shouldn’t have an event connection open 100% of the time because even if the code is costing nothing Roblox seems to have a lot of issues regarding how it queues its threads up internally. You can see this effecting games in terms of general remote calls, but, also you can see this really and I mean really effect games that use spawn for things.
For some reason in a lot of games a few extra active threads that are doing nothing can kill performance in a certain scenario. It’s a pain to test since its not within my control, but, yeah, definitely something to look out for. (If you pay attention to the script’s rate in the activity it will pretty much sit constant at 60/s and I think this mechanism for monitoring these rates is related to the issue)
Cool so in short: the point I’m trying to get across to the other person is that leaky code in a Heartbeat connection can obviously cause memory leak issues. The code in OP is not leaky.
It is totally misguided to advice not using static Heartbeat connections to avoid memory leaks. That’s looking for the problem in the wrong place.
Tl;dr Wrap the Heartbeat connection in a do end loop and it fixes a potential memory leak in your code (And maybe consider connecting only when you need it because of thread scheduler jank)
This was meant for this very specific situation so do not assume this is a fix all solution and make your code super messy with a bunch of do end blocks. This is not a magic fix for memory leaks, do not just go around doing this, you will hate yourself.
It’s not anything wrong with the code its more so just to do with stuff that probably hasn’t been looked at too close for quite a while sitting in the engine and being very strange like I mentioned. Its been really annoying for me to figure out a lot of this.
Your ActiveBranches table is referenced in the Heartbeat connection, and its referenced in LightningBolt. Even though you nil out the data in ActiveBranches the garbage collector seems to sometimes be slow to pick up on those cases and sometimes doesn’t seem to pick them up at all when you have an active event like that. Not sure why it happens, but, using weak keys/values will fix this issue and using a do end block will too.
Just to be clear for @CrazyCats84 and anyone else reading my reply above,
I didn’t mean to imply you should avoid Heartbeat. You should just avoid a single constant Hearbeat connection all of the time unless you need to. I say that just due to thread scheduler jank/garbage collector jank, which, changes a lot when they update luau. Having one event that’s firing a lot forever can cause problems after hours of running which is only a concern if that event will be running for that many hours.
The best practice is to connect your event only when you need it, and disconnect it when you don’t (and before you connect a new one). That will avoid most issues beyond ones related to your code. Heartbeat connections and stuff don’t cause performance issues on their own unless you’re running really expensive code in them.
This is talking about ghost problems that may or may not exist. None of this discussion is helpful or originating from an actual issue both of you have seen that the OP should resolve. Adding a do-end to a Heartbeat connection only adds another scope and doesn’t change the memory or performance characteristics of the code. It’s incorrect to suggest this would somehow improve performance or memory usage in the way you suggest, as a blanket statement or just in general.
File a bug report if you see anything wrong with static signal connections that run every frame.
@OP I recommend ignoring the advice given in recent posts.
a do-end won’t fix anything what
i have no idea where you go that idea but that’s not true at all
For some reason I thought you were the OP, that’s my bad. I am going to edit my messages here to be a little more clear on what I’m trying to say as I am not suggesting anyone follow this as a blanket statement, its not intended to be a blanket statement at all.
I should clarify I mean in this very very specific case the do end block has had the potential to fix a few very specific issues from at most about three weeks ago and I am not aware if they are still in the engine or not.
It’s a bit hard to explain why it works because to be fair I don’t know the full details in and out, all I know is I have created a test where I can consistently get a hard pass or fail over at least about a 5 minute period.
The technical explanation of it is when you wrap something in a do end block it seems to work like an upvalue where its taking the value from the higher context in to the lower context. Without the do end block the engine treats the context as being the same and this in combination with an event connection can cause data to persist for (at least) a very long time under very specific circumstances, don’t go around adding do end blocks in your code please guys. 