Recursion makes the code beauty and small, but has bad performance.
It can cause stack over flow by filling all the stack.
I mean, if you are using recursion where something never finishes (like the outfit, that will never finish unless the players logs out), it could cause stack over flow and crash your server.
Is nice to use recursion on things that finishes, for example, a spell effect that executes itself each 1 second for 10 seconds.
Also, about the addEvent, I think everything has a limit.
On Java language, the tables limit is int32_t, which means a limit of 4,294,967,296 elements.
I think that's the case on C++ also.
If that's the case, you will be able to store until 4,294,967,296 events (theoretically, since your hosting computer would have to support this huge amount of simultaneous events).
Another note, too fast events, like 50 ms each execution, is bad because each execution will happen a trade of protocol data between all players on the game screen depending of what you are doing.
Example, let's says you make a spell that removes 0.2% of health each 50ms until he dies, your server is in war, a lot of players on game screen and all are with this debuff effect.
That means we would need to send the health change of EACH PLAYER to EACH PLAYER'S CLIENT for EACH SPELL and EACH 50ms, etc. That's is NOT recommended (I tried do to a spell like that, and it freezes a lot). On TFS 1.2+, if the packet's limit comes on, the player will simply be kicked unless you increase the packet's limit on config.lua (but increase this it's not recommended, you should avoid several too quickly events).
A tip, is that if you are not using a event anymore, you should stop it, otherwise it will be there until the time to execution becomes.
Let's says you created some events on login that executes something in 1 hour and you don't need them anymore because they only executes if that player is online and your player is not online anymore.
I mean, the event checks if player is online on the execution's act, but does not removes it when he logs out.
Now, let's says a lot of players logs out and logs in several times.
Probably will have a lot of events that will do nothing because they are not online anymore, but is still counting to be executed in 1 hour.
The correct would be: remove the events on player logout.
How you do that: store the id of addEvent and use stopEvent for stop it.
Example (it works on all TFS releases):
-- Registering the event and storing it on a player's storage (probably on login, or where you want to register the event)
local hour = 1 * 60 * 60 * 1000
local myEventId = addEvent(myFunction, hour, myFirstFunctionsParam, mySecondFunctionsParam)
player:setStorageValue(7777, myEventId) -- (or setPlayerStorageValue(cid, 7777, myEventId) depending of your TFS version)
-- Stopping the event (probably on logout, or where you want to unregister the event)
local myEventId = player:getStorageValue(7777) -- (or getPlayerStorageValue(cid, 7777) depending of your TFS version)
if myEventId ~= -1 then
stopEvent(myEventId)
end
In resume, I recommend to use recursion for things that wont be executing for a long time, also avoid to use events that executes several times too quickly, and remember to be always careful to keep cleaning your unecessary events.