What’s problem you are encountering?
I created a solution, but am troubled with wheather it is clean code as it seems counter-productive.
What have you tried that didn’t work?
I’ve tried asking AI and looking for solutions through google search looking for any web pages that has any discussions on it, but couldn’t find any really and AI just said it’s bad, but the given solutions to make it good didn’t keep the solution while being clean code.
the screenshot above shows my solution which creates a custom block than runs the custom block than deletes the custom block and it’s under a receive event hat block with the code parameter.
the above screenshot here shows the custom block that creates a clone that broadcasts to itself and the parameter contains ringified code for the clone to run for itself.
The screenshot above shows the inner-workings of my custom block. It works by insuring a sprite variable of clones is made which is a variable to better organize my clones instead of using the my clones block because I had issues with the my clones block. I have been thinking about implementing the custom block from scisnap v3 to not run that part of the code if their is already a sprite variable clones. In fact I’ll probably do it right after I post this.
I’m looking for an answer confirming if my current solution shown in the first image is the best way to go about it or an answer detailing a better way
I would say it is bad practice. Dynamically creating custom blocks is very messy, and can lead to problems, especially if the block was never deleted (such as if the project was stopped before the block was deleted). The ability to create and modify custom blocks is definitely not meant to be used in cases like this. If you are just trying to run a script, there is no benefit (only downsides) to dynamically creating custom blocks, and then running them, especially since creating a custom block is slow.
If you are trying to run code in a clone, why not just use tell [ V] to ({} @>) @:> ? You can stick the clone directly into the first slot, and the script (in the variable) in the second slot. If you want to not wait, just stick the tell block inside launch ({} @>) @:>
I assume the reason you were creating a custom block is because the script was running in the original sprite instead of the clone. This is due to context, which is basically the ring just remembering what script (and sprite) created it. You can rebind the context in a couple ways. The first and by far the easiest, is to just use tell [ V] to ({} @>) @:> . Another way is to use which will return a new ring that will run in the current sprite. You can replace the second slot with (this [script V]) to have it be able to access the variables in the current script.
Just as a cool tip, if you right click a script and click “script pic”, you’ll download an image of that script. What’s more is that you can actually drag and drop the script back into snap to get the script back. It’s really useful when sending scripts on the snap forum, especially because we’d be able to see definitions of any custom blocks that were used.
which will return a new ring that will run in the current sprite. You can replace the second slot with