I'll post this here as it's sort of related and I don't feel like making a new thread.
I'd avoid loops as much as possible, atm they seem to block (preventing data from being received/triggered on), but if you're sending something that doesn't depend on any server-side data I suppose you could do something like:
Code: Select all
function spam(what, count, tmpInterval)
local interval = tmpInterval or 0.5
for i = 1 .. count do
tempTimer((i-1) * interval, what)
end
end
The i - 1 ensures the first command is send immediantly, I hope. You could easily expand that further to a table version if you're not sending the same thing over and over:
Code: Select all
function tableSpam(table, tmpInterval)
local interval = tmpInterval or 0.5
for i,v in ipairs(table) do
tempTimer((i-1) * interval, v)
end
end
Which would send all iteratable data to the MUD, although the table would obviously need to be an array or similar.
Currently, I'm doing this:
Code: Select all
if table.getn(processQueue) == 0 then
disableTimer("Process Queue")
else
if processQueue[1]() then
table.remove(processQueue, 1)
end
end
So in other words, functions are pushed onto a table (using table.insert) and the above timer is enabled with an arbitrarily small interval.
If the queue is empty, the timer disables itself otherwise it'll run the function in the first position. If that function returns true it is popped from the queue otherwise it's left there to run on the next iteration.
Doing things like that lets you check for balance in each individual function if needed and also counteract weird bugs such as one in MkO where casting two spells in succession (even with balance) will nullify the first whilst still costing mana.
It's also useful in that you can easily break it up further through other functions/tables as needed. I've already written an autobasher and a couple of other things (apart from my system) with it.
If you needed to send a heap of commands in succession but couldn't use loops, you could use that to keep a 'count' of how many commands have been send and measure the time between each run using stopwatches. If the time is insufficient simply return, otherwise increase the count and send. That's a pretty messy way of doing it though, and there are probably 100 improvements to be made.
I dunno if that helps or not although it might give you a few ideas.