Hey again tunepunk,
As blackhornet and Magistross mentioned, recursion is likely not what you want for this situation.
I gave my example in terms of the opacity scenario you mentioned only for illustrative purposes, I wouldn't recommend actually using recursion to handle opacity.
My fault, I misunderstood.
I understood you were interested in having a function act in a self-contained manner over time, but I didn't realize you were interested specifically in controlling opacity.
As Magistross mentions, with too much recursion you can run out of call stack space. This is what I meant in my first post when I mentioned the "Maximum call stack size exceeded" error.
Triggering smooth transitions
To trigger a smooth change over time, you can use an extra instance variable to store the desired target value, (such as "100" for opacity), and then every tick, move the actual opacity value towards that target value by an increment, (such as 2).
So if you have a sprite that starts with 0 opacity, and the target is set to 0 as well, the sprite stays at 0 opacity.
If you then set the target value to 100, the sprite's opacity will start counting up to 100, at a rate of 2 per tick.
As Blackhornet mentioned you can use families to make it easier to get this behavior to work across a variety of similar objects.
Layers, Sprites, & Families
A single family will only work on a set of objects that all belong to the same plugin type, such as Sprite.
To get a family that affects sprites to affect layers, you can create a sprite object called "layerTool" (or whatever you want) and put a layerTool object on each layer you wish to control. Set the "Visibility" of the layerTool objects to 0 and then create events for them that set their corresponding layers to match their opacity every tick.
Now you should be able to control layer opacity with the same family events that control sprite opacity.