Do you have to close a coroutine.wrap()?

Help and Feedback Scripting Support
#1

I’m experiencing a ton of lag with a script I made, generated by CPU load. I’m presuming this is because of all the coroutines I’m wrapping in order to independently open and close the constraint doors on my vehicle, and I’m wondering if these will stay open even after the function ends.

In other terms:

local function colorPart(part)
    part.BrickColor = BrickColor.Random()
    wait(1.5)
    part.Transparency = 0.5
end

coroutine.wrap(colorPart)(workspace.SpecialPart)

Will a separate thread be kept open even after the part would turn transparent?

#2

Coroutines are collected as garbage in Lua as long as they are finished and not yielding meaning the code finished running in them, so yes.

Prior post confirming this from 2019: Do coroutines eventually get terminated by Lua when not in use? Or do I have to stop them myself

As for the lag, coroutines shouldn’t be lagging you unless maybe you’re spamming them, and even then the skill I’m working on spams 6 coroutines in less than a quarter of a second and causes no issues if I spam it for 10 minutes or longer since Lua collects them as garbage after they are finished, this could only cause lag if you are spamming a ton at once and or not finishing the code inside such as pausing them with a yielding event like a “While Loop”.

3 Likes
#3

coroutine.wrap works by initiating a new state and returning the wrapped resumer function for it. the “thread” becomes dead after it errors or finishes executing its code. assuming that there are no other references of it left over, it will become eligible for garbage collection.

2 Likes
#4

The source of your ‘lag’ might be coming from how you call this, and the contents of the function each time it’s called. Is this a specific example of how you’re calling it right now? Or is there some other method you’re doing?

1 Like
#5

I’m calling the coroutines exactly as in the example above, and at max they contain a in pairs loop to for instance change a property in all doors or suspensions.

I actually started considering the source of the lag the physics simulations, keeping in mind that my vehicles are actually pretty detailed buses made of multiple parts; but I’m not yet sure, as there isn’t anything really out of the ordinary: hinges on the wheels (although I don’t use these to generate thrust), servos to turn the front ones, a few doors which are pretty much a single hinge with a servo and cylindrical/prismatic constraints over the wheels for a sort of “air cushion” that lets the bus lower to “make it easier for passengers to climb aboard”.

As I’m pretty new to these things, I might have messed something up, but these all seems pretty ordinary for a constraint vehicle…

#6

I’m no genius, but I can most definitely say this is most likely not causing any source of lag, just as long as it’s not in some sort of infinite loop functionality / without a wait time with an extended loop amount.

Consider making use of this, and seeing exactly where the memory is being called upon. Then make use of simple debugging tools/techniques. Good luck!
image

1 Like
#7

Having an infinite loop will eventually cause lag in the long term? I do have one for swiveling the wheels to the steer angle and some other minor things. Any way, I should change this to not have an infinite loop as those are not the best way of approaching this IMO. And, thanks for the other tips!

#8

Of course. Let me know if you need anything else.