There’s been a few claims around the devspace the past few months saying that this module is prone to memory leaks. I decided to run a continuous loop on my client overnight to see if there was any merit to these claims. Spoiler alert: there was none
After creating one bolt, spark, & explosion every 4 seconds over the course of 10 hours (rendering ovar 9000 of each on my client); this was my result upon waking up this morning
Here is the repro file. It’s nothing special, but the point was to test them in isolation. lightning_quasiduck.rbxl (34.4 KB)
If you use these modules correctly, you will not experience memory leaks. Please do not make baseless claims about others creations.
It won’t help you but it’s also no detriment either. Like buildthomas said, it’s just adding a scope; neither performance nor memory are effected. Policing others style practices is… weird, to say the least
I’m not referring to a style practice or saying its bad to use a lot of do end blocks (I use them a lot in very big pieces of code) I’m just clarifying that my post is not encouraging people to add a bunch of random do end blocks everywhere just because it might help in the specific case I mentioned. See the conversation below my post, that explains why I made that edit.
There’s nothing wrong with using them or using them for organization, I use them all of the time in plenty of places for organization and for shortening scopes because of their properties with the GC.
And yeah, absolutely no performance/memory cost to these to worry about, it already costs less than an if statement or for loop and in most cases I think it should cost even less than allocating a local afaik, its really not a bad thing to use even in large quantity.
To explain how and why a do end block can be useful since I didn’t really go into that before, here’s a little rundown. A do end block creates an extra scope, which, basically means you can define local values inside and they exist only inside the do end block (inside its scope). The reason that’s useful is because the garbage collector works scope-wise, stuff inside of a scope that’s been passed over already is considered out of the scope of any executing code, because, well, it is.
Sometimes the way that the GC handles scopes is wacky when it comes to other cases and it seems to very rarely change but that prior fact should never change, even if how the GC handles out of scope data does change.
I’m not sure how that effects GC performance but I would think it might help stability if the GC can GC variables earlier, it would have less variables to worry about later, less to deallocate at once, and scopes would theoretically become free quicker. On the other hand I guess too many scopes to take into account might be bad but again I don’t really know how that works, it shouldn’t be a problem.
Can I ask why I cannot delete the bolt after a certain amount of time? I try to use LightningBolt:Destroy() as shown below but it just throws out an error.
local LightningSparks = require(game.ReplicatedStorage.LightningBolt.LightningSparks)
local LightningExplosion = require(game.ReplicatedStorage.LightningBolt.LightningExplosion)
local LightningBolt = require(game.ReplicatedStorage.LightningBolt)
local function zap(waittime, part1, part2, a1, a2, debris)
print(60)
local ranCF = CFrame.fromAxisAngle((part2.Position - part1.Position).Unit, 2*math.random()*math.pi)
local A1, A2 = {}, {}
local timeElapsed = 0
A1.WorldPosition, A1.WorldAxis = a1.WorldPosition, a1.WorldAxis
A2.WorldPosition, A2.WorldAxis = a2.WorldPosition, a2.WorldAxis
coroutine.resume(coroutine.create(function()
while true do
if timeElapsed == waittime then break end
local NewBolt = LightningBolt.new(A1, A2, 20)
NewBolt.PulseSpeed = 2
NewBolt.PulseLength = 0.5
NewBolt.FadeLength = 0.25
NewBolt.Color = Color3.new(math.random(), math.random(), math.random())
--NewBolt.MaxRadius = 1
wait(0.1)
timeElapsed = timeElapsed + 0.1
coroutine.resume(coroutine.create(function()
wait(debris)
LightningBolt:Destroy(NewBolt)
end))
end
end))
end
game.ReplicatedStorage.Effect.OnClientEvent:Connect(function(waittime, part1, part2, a1, a2, debris)
zap(waittime, part1, part2, a1, a2, debris)
end)
Is there any way to tween the values used in the lighting bolt? to get things like a smooth thickness transition or a smooth transparency transition?
Nevermind, found an alternative solution to that issue.
Proof? Have you got a rbxl that I can go into and take a look?
Also, what version is this for? Both v1 and v1.1 should have no memory leaks as far as testing goes.
The only documented bug (with actual proof) I’ve heard of is LightningSparks sometimes deleting slower than usual which will be fixed in v2 anyway. Regardless, even in v1 it does not lead to an unbounded increase in memory usage for LightningSparks.
If you find anything in v1.1, PR’s are also welcome but otherwise, document the issue on github and I’ll get around to it.
So I tested the updated modules again with the repro RBXL file I posted earlier in the thread. I still cannot find this phantom memory leak that a few users seem to be talking about.
It would really help to post proof of your claims, otherwise making such claims damages your credibility.
What is the difference between the video with the lightning strike that seems really bright, and the first video with the spheres and stuff. One looks like neon bricks and one looks like beams. Also how do you get it so bright?
I could not tell where you included the LightningSparks in the Usage example. I could neither tell where to put the attachments since they are not able to go into workspace. I still dont get the module to work. Can someone help me?
How did you do the second lightning strike effect? I can’t seem to make the LightningBolt.new() really be hitscan or as bright as the one you showcased
[EDIT]: Nevermind! The module which uses parts makes it brighter!
Yeah you need to go to the github and get the code inside of the .lua files and make modules out of them, treat their heirarchy like it’s visual studio code with rojo.
this is some really cool stuff, I’ve made some kind of tesla tower thing with it and holy crap does it look amazing, I do wonder if it’s possible to have the parts emit light though.
could that be a thing with the module or am I going to have to manually implement it?
