Hello developers! Today I come to you with an issue that is a little odd but I think at least a few of you may have an idea on how to fix it.
I have a rain system in my game that uses attachments. All attachments are in a single, non-moving part. Between each set of 2 attachments is a trail. The 2 attachments are moved down until they hit their destination (a point set for them when they’re created via raycast). Once there, the attachments and trail disappear and a part if spawned at the ground where it hit. It emits 1 splash particle, waits for it to disappear, then the part is destroyed.
The only problem is that for some reason, and this usually only happens after a few seconds, the particle parts simply stop getting destroyed. Someone mentioned it had something to do with “yielding”, but I’m not sure what that means.
Whoever mentioned yield I believe may be on to something, which may have been one solution to your problem! Here are a few threads from the forums that I found for you that may help in conjunction with yielding and the scheduling of your raindrops!
I’m not sure this will work, but maybe you could try using a different method of removing the part? I’m not entirely sure what the difference is between part:remove() and part:Destroy() but perhaps destroy yields while remove does not? It’s just an idea, I have no idea if this will work or not.
You could remove the wait and create a function to remove the particle, then call it with delay() (This is assuming that it is, in fact wait() that yields the script and not Destroy())
Yea that seems right. Keep in mind that the delay function won’t stop the code currently running, and creates a new thread for the code in the callback (I’m pretty sure). So if you put any code under delay(), it’ll run immediately and not wait 0.6 seconds.
On another note, how would you guys go about instancing these parts for single particle emissions in the most efficient way possible, meaning less stress on the client?
(While still achieving the ‘splash’ effect of a raindrop of course)
If I were you, I’d make 2 particle Emitters (one on top, one on bottom) and have each emit a particle (bottom emits splash, top emits rain). Hopefully the player wouldn’t notice they’re not always lined up, but it would be a huge boost performance wise. As for your situation, if you want the rain to avoid going into buildings, and splashing on the roofs of cars and such, I think your idea is the best way to go about it.
Maybe instead of using a physical part for rain drops, you could use 2 attachments with a beam, color the beam blue, and have the attachments move down? That way at least physics wouldn’t be working on a part.
I’m using spawn(function() for a separate function from this case. The problem is, the new delay I’ve added seems to make this other spawned function not begin until all of the delays have gone through, which could take up to 5 to 10 seconds since there’s many of them in a row.
How would you guys go about making sure this new spawned function activates as soon as it’s spawned, rather than waiting for delays from other functions to complete?
That’s a tough one - I’m not sure the limit on how many threads a script can have going at once, but I’m sure it has to do with that. Maybe turning down the rate of rain particles spawning would keep the amount of threads to a minimum? To be honest I’ve never had any kind of experience with running too many threads, so I won’t be as useful in that regard. Sorry about that.
Is there a particular reason the Debris service has been ignored? For those who are unaware of this beautiful thing, it lets you line up items to be destroyed.
game:GetService(“Debris”):AddItem(part, 3)
Will add the part to the debris service, and destroy it after 3 seconds. You can run this line of code directly after instantiation of the part and it will destroy it 3 seconds later
