@toadkick No apologies needed. I didn’t feel like you were doing anything except defending your position on the code you posted. My code was just generic code that I felt was one way of doing what was asked. Your code was another way, levels above mine because I learned something from you. So keep up the better examples, because if I can learn from you, so can others.
After reading this discussion with much interest it seems like a perfect example of six and two threes both approaches have equal merit with correct use 
we as developers should not be trying to best each other, but collaberate for the best solution
Perhaps also for the record Thread.sleep only delays the particular thread from where it is called and it is a bit rubbish for getting an exact delay because ultimately the operating system decides when a thread wakes up 
@XanDDemoX, agreed. Yeah, I only used Thread.sleep as an example to explain the difference between a delay and a pause. Thread.sleep stops at the current line and Codea just isn’t capable of doing that which is why we need to use things like timers to help us exclude code from being called, essentially simulating a pause.
@XanDDemoX You are of course entirely correct that we shouldn’t be trying to show each other up other or put others down…I probably did come across that way. I wanted to present an alternate solution, not present it as the only solution, but my glorious editorial kind of negates that sentiment. Sorry 
No apologies needed we also can’t progress without strong discussions and my first timer attempt was massively fail 
local time = 0
while ElapsedTime-time < 1 do
time = ElapsedTime
end
Stack overflow == bye bye Codea
@XanDDemoX, haha nice. That example would put you in an infinite loop as time = ElapsedTime and ElapsedTime-ElapsedTime is always 0 
Ah I missed off the incrementing part time=time+ElapsedTime not that it works anyway
I’ve got a slightly different approach to an accumulating timer which doesn’t require globals I’m not sure if anything similar has been posted but hey here it is
Timer = class()
local _timers = {}
function Timer:init(seconds,start)
self.seconds = seconds or 1
self.ticks = 0
self.ontick=function() end
if _timers[self] == nil then
_timers[self]=self
end
if start ~= nil and type(start) ~= "boolean" then
start = nil
end
self._dotick = start or true
end
function Timer:start()
self._dotick =true
end
function Timer:stop()
self._dotick =false
end
function Timer:dispose()
self:stop()
if _timers[self] ~= nil then
_timers[self] = nil
end
end
function Timer.tick(self)
if self ~= nil and self._dotick == true then
self.ticks = self.ticks + DeltaTime
if self.ticks > self.seconds then
self.ticks = self.ticks - self.seconds
if self.ontick ~= nil then self.ontick() end
end
elseif self == nil then
for k,v in pairs(_timers) do
k:tick()
end
end
end
Usage
function setup()
local timer=Timer(2)
timer.ontick =function() print("tick") end
end
function draw()
Timer.tick()
end
@XanDDemoDX: A nice timer, similar to others I’ve posted around here as well To be clear, it’s not the accumulator itself that I was railing against (as mentioned, under the hood tween.delay uses an accumulator itself). Mainly it’s the fact that, to effect a delay without using tween.delay (or something like your timer class), you have to a) explicitly maintain your own accumulator, b) explicitly update the accumulator every update, and c) put the code you want to delay in an inconvenient place, usually far away from the rest of the related code (namely the draw function). If you only ever need 1 bit of deferred code in your program, that’ll do. But it doesn’t scale if you need to do it more than once, and you usually do for all but the simplest programs.
Since most of the actual logic for a timer is simple, you can do what you did (and what tween.delay does), which is abstract the details of accumulators and all that away, so you only have to specify the important/interesting bits when you want to defer executing some code: the interval to wait, and the code to execute.
@toadkick Thank you I certainly agree tween.delay is a very elegant solution and there is somewhat an element of jumping through hoops and promotion of inelegance when it comes to timed code or timing reliant code.
There’s also a secondary unfortunate problem that it will generally suffer from factors which are out of the control of the code under contexts such as multiple timers, for example my timer class will become inaccurate for subsequent calls out to tick timers if the previous tick is a long running task.
Then there are other elements such as operating system scheduling, garbage collection and errors on the developers part during manual handling or platform limitations for example real time systems often require special interrupt scheduling and high performance code to be implemented to achieve their goal. One small mistake and kerboom everything’s messed
@Mason Has any of this code been helpful to you or have we gone overboard with the different delay routines. You just joined the group a few days ago and in another post you said you we’re new and needed help. I don’t know how well you know Lua or Codea, but I feel like your question has been brushed aside and we’re not being of any help, especially if you’re new and don’t understand all of this.
@dave1707 Yes, most of it has been helpful, I know I little bit of lua. The reason I needed to ask this question was because on the previous program I used it had the wait function built in. So I had to type was wait(1) and it would wait 1 second.
@Mason: Unfortunately it’s not quite so simple in Codea. Mainly it has to do with the difference in architecture of Codea and the other app that you were using. Codea is a little “closer to the metal” so to speak, whereas it sounds like the other app has an additional layer of stuff underneath the one you, the programmer, work in. Basically, in Codea, the programmer works at that lower layer. You can’t really implement a wait function like that in Codea because it would completely halt program execution (or “block” the program) until it’s done. You don’t want to do that, because (among other reasons) you need Codea to keep calling your draw function while you are waiting, or else nothing will get drawn to the screen during that time. About the best we can do here is tween.delay (or a similar method), where in addition to specifying the amount of time you want to wait, you have to also specify what you want do when you’re done waiting (as opposed to the program completely halting execution and resuming after the delay), so that the program can continue doing the other stuff it needs to do in the meantime.
Hopefully that’s not too confusing…I can try to explain in a little more detail if you need me to.
I think it’s been healthy to have some disagreement because it tests different approaches and we all learn something. Thanks all!
I agree that the same questions keep being asked. Why don’t we set up a FAQ for questions with fairly short answers, like this one? Then we could include both solutions - accumulator and tween. I can see the elegance of tween, but for noobs coming from other languages, accumulators will be more intuitive initially - and they are best for some cases like FPS.
@Mason perhaps we can help you with your implementation if you are / get stuck ? but you’ll need to give some details about what you need a timer for and post some code
Why don’t we make the FAQ post written by @Simeon and The one @Ignatz wrote to be made compulsory through go through while joining the forum something like Terms and Conditions. then maybe people won’t ask “Where Should I Start From?”
FAQ is really for reference, ie to find a specific answer - there’s not much point reading all of it as a beginner (unless you already know how to program and want to pick up tips).
How about a “snippets” section? it could contain very small and concise peices of useful code and tips and tricks in there with care taken to word things for developers of any level and to avoid things getting convoluted perhaps it could have some specific rules of appropriateness and conciseness enforced by the mods.
@XanDDemoX - absolutely, that would be good, too. I’ve added that on the wiki page as well.
Can you put in your recent snippets that you’ve been posting?
Certainly just need to get myself an account, track down my snippets and not break my own convolution rules
Ok, see item 14 on wiki page for the link